Analysis Techniques: ======================================================================================= Since the raw data for this task was in the form of a snort log, snort seemed like the perfect fit for an anqlysis tool. The first thing I did was to blow the whole capture out into a text file. Then I ran the log (the binary version) against a set of rules downloaded from www.snort.org. This pointed out the obvious attacks for me and gave me a basis for writing some rules to clean up the log. Next I scanned the text version of the log and noticed some interesting things. Mainly the remote shell traffic from the netcat sessions. I kept writing tweaking my rules until I was satisfied that I had enough data to perform the analysis without too much noise. In some spots I had to refer back to the full log. For instance, my rules would only log the first packet of an http response (I didn't want to see the .gifs so I looked for the content type of text/html in the rule). I also did not include things like the ftp data channel although they did yield data for my analysis. Here are the rules I used: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg: "Resrticted http-iis-unicode-binary"; flags: AP; content: "%C0%AF"; content: "..%AF.."; nocase; reference:arachnids,452; logto: int.txt;) alert tcp $HTTP_SERVERS 80 -> $EXTERNAL_NET any (msg: "Outbound http Response"; content: "Type\: text"; nocase; flags: AP; logto: int.txt;) alert ICMP $EXTERNAL_NET any -> $HTTP_SERVERS any (msg: "IDS311/ping-scanner-L3retriever"; itype: 8; icode: 0; content: "ABCDEFGHIJKLMNOPQRSTUVWABCDEFGHI"; nocase; depth: 32; logto: int.txt;) alert tcp $HTTP_SERVERS 6968 -> $EXTERNAL_NET any (msg: "netcat session 6968"; flags: P+; logto: int.txt;) alert tcp $HTTP_SERVERS 6969 -> $EXTERNAL_NET any (msg: "netcat session 6969"; flags: P+; logto: int.txt;) alert tcp $HTTP_SERVERS 6868 -> $EXTERNAL_NET any (msg: "netcat session 6868"; flags: P+; logto: int.txt;) alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS msadc/msadcs.dll access";flags: A+; content:"POST /msadc/msadcs.dll"; nocase;logto: int.txt;) alert tcp any 21 <> $HTTP_SERVERS any (msg:"FTP control channel";flags: AP+; logto: int.txt;) alert tcp $HTTP_SERVERS 80 -> any any (msg:"HTTP access of test.txt. How do they know about it?"; content: "this can't be true"; nocase; flags: A+; logto: int.txt;) The packets containing Unicode attacks in the original logs appeared multiple times each (maybe due to the preprocessor http_decode: feature???). Anyway I modified the unicode rule to only log one instance of each command, thus "Resrticted http-iis-unicode-binary". I logged the output of this run to a text file and stepped through it packet by packet and made notes. I started each note with a unique string (!@#) so that I could later grep on it to extract my comments to a summary. The file attackSummary.txt contains the comments without the packets and the file annotatedDump.txt contains the comments inline with the packets they pertain to. It would have liked to have written a script to at least extract the snort timestamps and timestamp the comments in the summary but did not have time. Assumptions ======================================================================================= At around 02/04-06:20:44.578658 in the capture, a new IP connects to a netcat listner and obtains a remote shell. Due to the timeliness of this IP joining the party, what they type and their knowledge of the system, I am assuming that this is either the attacker bouncing off of another server, or someone in close contact with the original attacker (via IRC perhaps). Also, right after the attacker creates the file test.txt (this can't be true), this file is hit by many different browsers running on different OSs and coming from different IPs. Somehow all of these people know about this new file very quickly. IRC again??? QUESTIONS ======================================================================================= 1.) Which exploit(s) were used to attack the system? ------------------------------------------------------------ The two vulnerabilities used to attack the system were the IIS Unicode attack and the MDAC/RDS vulnerability (feature?). Below are descriptions of the exploits as well as a description of the toolkit. --IIS Unicode attack--: REFERENCE: http://www.securityfocus.com/bid/1806 (BugtraqID 1806) http://whitehats.com/info/IDS452 PRIVILEGES YEILDED: Commands will execute under IUSR_machine context by default. EXPLOIT SOFTWARE: IE5 browser. There are some scripts that will perform the exploit for you but in this case the http request headers indicate that the requests were sent from an IE5 browser. This attack requires that permissions include 'executables' (as well as script, etc.) on the target directory within IIS. --MDAC/RDS vulnerability--: REFERENCE: http://www.securityfocus.com/bid/529/ http://www.securityfocus.com/archive/1/30456 http://www.securityfocus.com/archive/1/13882 http://www.wiretrip.net/rfp/msadc.pl PRIVILEGES YEILDED: System level EXPLOIT SOFTWARE: It appears that the msadc.pl script was used to perform this exploit. The main tipoff is the muiltipart content boundary of '!ADM!ROX!YOUR!WORLD!' in the http request. The test for the msadc.dll 'GET /msadc/msadcs.dll' shortly before each command is sent is another clue. --Toolkit Analysis--: Netcat - nc.exe is version 1.10 (you can see the version string in the FTP data stream). Flexible tool used in this case to create a remote command shell. It uses the privileges of the process used to start it. pdump.exe & samdump.dll - Judging from the size of pdump.exe in the ftp control channel traffic, this looks like pwdump2.exe (32768 bytes). This is supported by the size of samdump.dll (36,864 bytes). This program will dump the usernames and password hashes from the SAM database. 2). How were the exploits used to access and control the system? ------------------------------------------------------------ -First the both exploits were verified. Unicode attack was used to read the boot.ini file. The MDAC exploit was used to create a file (c:\fun) and then Unicode exploit used to read it. -Next the MDAC exploit is used to create an FTP script to download a toolkit (original scripts use an ftp server www.nether.net, but these do not work. Eventually an ftp server running at the attackers own IP 213.116.251.162 is used). The toolkit consist of samdump.dll, pdump.exe and nc.exe (see toolkit analysis for more information). -A copy of cmd.exe called cmd1.exe is made in the local (for the Unicode exploit) directory. This does not seem to be crucial to the attack but it keeps the Unicode attack paths shorter and could potentially get around targeted logging of the command interpreter. -After a fair bit of trouble, the toolkit downloads. -The Unicode exploit is used to start a netcat listner using -e option to send inbound requests to the cmd1.exe command interpreter. -Attacker connects to this listner (using a command such as 'nc 172.16.1.106 6969' on their system) and obtains a remote shell. -The attacker sets their mind towards using pdump to get the password hashes into a file (This would have to be done via the priviledged MDAC exploit). This does not seem to work well. -Next, the attacker tries to escalate the permissions of the user accounts that his shell and the Unicode exploit might be running as (IUSR_KENNY and IWAM_KENNY). Eventually succeeds at using MDAC exploit to run 'net localgroup' commands to add these accounts to the local administrators group. The privileges of his shell do not seem to have changed though. -After a bit more exploring the attacker attempts to use the MDAC exploit to create and account call testuser and then add to the administrators group. This does not work. -Since pdump does not seem to be working, the attacker tries using the MDAC vulnerability to run rdisk -s to dump a current copy of the sam database to the 'c:\repair' directory. -After many attempts, the timestamp of 'sam._' appears to update. (NOTE: The system clock on the compromised machine appears to be in the ballpark of 11 hours and 4 minutes behind that of the snort machine). Attacker then dumps the compressed sam database into the file 'c:\har.txt' for later removal. -Next the attacker copies the file containing the sam (har.txt) to the wwwroot, then comes and grabs it using a browser. -Finally the attacker creates an FTP script and ftps off a copy of whisker. 3.) What was done once access was gained? ------------------------------------------------------------ Below is a list of notable highlights. Please see the file attackSummary.txt for a blow by blow description of the attack. If you want to see how these comments pertain to the packets, you can refer to the file annotatedDump.txt which is where these comments originated (I just grep'd the annotated dump on !@# to generate the attack summary). Highlights: -read boot.ini file -downloads toolkit -obtains SAM database -raises privileges of IUSR_KENNEY and IWAM_KENNY accounts to that of administrator -establishes remote command shell -checks for connected netbios sessions (net sessions) -reads some exploit files -leaves various calling cards -creates a copy of cmd.exe -explores directory structure of machine -looks in Outlook Express folder (for emails???) -copies default.htm to default.html -appends a '.' to default.htm -creates a new file at the web root called test.txt (which gets a surprising number of browser hits from assorted IPs) -grabs a copy of whisker 4.) How could this attack been prevented? ------------------------------------------------------------ --IIS Unicode attack: PATCH THE SYSTEM! Don't allow IIS executable permissions on anything (not always practical). --MDAC/RDS vulnerability PATCH THE SYSTEM! Don't install demo files see http://www.securityfocus.com/bid/529/ (solution tab) see http://www.microsoft.com/technet/security/bulletin/MS99-025.asp --Netcat remote command shell This tool is really flexible so a wily attacker could likely get it to work through port redirection (inboound on port 80, outbound on port 25 or something similar) unless a lot of analysis is going on but the fact that inbound connections are allowed on high ports indicates a pretty loose firewall. 5.) How much time did you spend on this analysis and writeup? ------------------------------------------------------------ .5 hrs - Getting rules files and performing initial scan 1.5 hrs - Initial review of full dump file .5 hrs - researching vulnerabilities 1 hrs - Writing snort rules 4.5 hrs - Annotating cleaned dump file 2 hrs - creating this document + __________ 10 hrs - total time Bonus Question) Do you feel that the attacker in question knew if this was a honeypot? If so, why or why not? ------------------------------------------------------------ I believe so. Mainly because a note was left behind stating as much. But..... This relies on one assumption. At around 02/04-06:20:44.578658 in the capture, a new IP connects to a netcat listner. This is the session that leaves the note. Since the timing is so tight with other events in the system, I am assuming it is the same attacker, or at least someone in close communication with the original attacker. Some other logical indicators might be: The presence of a directory full of exploits and also a copy of a vulnerability scanner might indicate that the machine's owner has an interest in security. Someone like that would likely not leave a machine so wide open. Of course someone else could be stockpiling these programs here but no attempt was made to hide them. The machine name is KENNEY (as indicated by the IUSR_ IWAM_ accounts). In Southpark, Kenney is a sacrificial lamb of sorts who gets killed in every episode (then comes back to life). This is not dissimilar from a honeypot. Ok maybe looking a bit too deep here. You killed Kenney, You B@%#!rds