This is the continuity from the last post. It doesn’t matter whether ur using acid, base, any SIEM/SEM and if you fail to manipulate/using/exploit/understand/interprate all the data available at your disposal, validating intrusion / extrusion incidents is probably nearly impossible.
For acid as example, there’re lots of information regarding the current day’s event on its main page. You can see the Last 10 high priority alerts, Traffic profile by protocol, snapshot and many others.
And we may select any alerts to be presented the alert individual page.
I guess many others SIEM/SEM basically have the same features as this one or maybe perhaps few additional features as well. Again the question is how can we possibly use all the information provided by this SIM/SEM/SIEM? Depending ONLY with these alerts information in order to validate incident is tough job (do I sound redundant here?)
Just imagine, the only info that u have are all the information related to the IP and TCP. The header length, options, flags and others besides the payload which I do think is the nearest thing to the full content data (also depends on the snaplength as well). For web application attack, IMHO session and full content is important. For session, mainly to gather the information on the conversation between the attacker and the victim, I mean that including the flags, options, size and many others. For example like one incident posted in SANS Internet Storm Centre forum, and this event commented or analyzed by Mr Richard Bejtlich in his blog titled Nothing to See Here , based on the conversation data recorded, it seems that the supposed to be “attacker” is actually the victim. Why? Based on the tcp flags involved in the conversation where the “attacker” actually replying to the source. Take note of the SYN ACK flags from the “attacker”. Unless the “attacker” sending too much SYN or SYN RST (I think a server, esp web server shud not initiate any connection. Correct me if I am wrong) Then we can consider the “attacker” is actually the real attacker.
Full content data will tell us how the server responding to the request by the client. For remote file inclusion as example, any request to include a remote file to the vulnerable path of the server’s application either successful or failed. 404 or 200. Ok not as simple as that but that kind of information can saves a lot of time in validating that kind of attack to our web server. Agree?
Tell me how can you validate this remote file inclusion attempt based on this info? You received 200 Web-PHP remote include path (remote file inclusion) alerts and all you have is this kind of payload to assist your analysis.
Ok you might want to know exactly what the attacker intended to do the the webserver by downloading his script. Based by this payload you might want to retrieve the file from http://mail.wtg.lviv.ua/c.txt. But remember if the attacker is lil bit clever, he might remove that script once he either successfully include the file or failed. If that file removed, we don’t have any clue at all right? (Besides scouring the webserver directories – basically or usually in /tmp) But what if he didn’t put it there? Might start scratching your head
Or maybe we can identifying whether the path that he tried to exploit exist or not in the webserver. As example based on the payload we might want to identify whether the directory (/cgi-bin/pemasaran/admin/) or the file (admin_topic_action_logging.php?) exits. If the path is incorrect or the file didn’t exist, we can expect the attempt is not successful. But how long does it take to validate this kind of attempt when the attacker attempted to include in different files and different path?
That’s why IMHO depending ONLY with this kind of information will make our job nearly impossible and time wasting.
Next posting I will show you the beauty of having the session, full content and alert data in validating events or incidents. Sguil rocks!