Well after a VERY long break they've released the latest puzzle. This one has to do more with parsing and pulling info about wireless. While I probably have the skills to do it, I'm not sure I'll participate in this one. School is finishing up and my free time is very short in this next month.
If nothing else I may just figure out the answers without writing any specific program to be released for it.
It has been out a good week so far and I have yet to grab the pcap file and look it over. Satori will probably spit out an error as I have it set to reject wireless packets as I haven't wanted to parse out the extra header info in the past.
May run into through a converter so Satori can at least read it in, though I'll lose most of what they want you to find with SSID stuff and beacon packets.
Subscribe To
Posts
All Comments
Showing posts with label forensics contest. Show all posts
Showing posts with label forensics contest. Show all posts
Thursday, May 5, 2011
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.
Thursday, December 17, 2009
Forensics Contest #2 Finalists and Winners
Based on the PaulDotCom 180 podcast Franck and Jeremy were the winners, they decided to have co-winners this time around. Erik and NetworkMiner ended up being finalists again and got special mention in the podcast.
As of this posting they haven't actually published this at the forensicscontest site, but I guessed at the URL and picked up the Finalists along with the winners from the podcast.
Will be fun to look through the winners submissions over the next few days/weeks. Contest #3 is hopefully due out in the next 7-14 days.
Update:
Posted:
Contest Winners and writeup now posted
I made the SemiFinalist list (top 15), just didn't make the finalist list (top 8). Maybe Contest #3!
As of this posting they haven't actually published this at the forensicscontest site, but I guessed at the URL and picked up the Finalists along with the winners from the podcast.
Will be fun to look through the winners submissions over the next few days/weeks. Contest #3 is hopefully due out in the next 7-14 days.
Update:
Posted:
Contest Winners and writeup now posted
I made the SemiFinalist list (top 15), just didn't make the finalist list (top 8). Maybe Contest #3!
Monday, November 23, 2009
Network Forensic Challenge #2 - update
Ok, the submission date got extended an extra week, which ended yesterday. Erik put out version 0.90 of NetworkMiner in which he added support to pull out SMTP messages from captured data. He found a bug in 0.90 and released 0.91 yesterday, it can be found here.
My answers are here:
1. Username:sneakyg33k@aol.com
2. Password:558r00lz
3. mistersecretx@aol.com
4. fake passport and a bathing suit.
5. secretrendezvous.docx
6. 9E423E11DB88F01BBFF81172839E1923
7. Playa del Carmen, Mexico
8. AADEACE50997B1BA24B09AC2EF1940B7
I used the pcapcat perl script from NFC #1 to extract the initial data. The one thing I think is a bit unrealistic in these contests is the packet captures are too small, there isn't 100-500 MB of stuff to sift through, trying to decide what is needed/not. Due to download feeds and whatnot I understand why that is, but.... Feeding a 100 kb pcap file through makes life quite simple. Anyway, I emailed the author of pcapcat, for what we've seen in #1 and #2 that script works fine, but if any packets are resent, or out of order, pcapcat fails to take that into account and just puts the data in the output file in the order it was seen in the pcap file. I tried to make some changes to it to fix that, but it was beyond what i could figure out in a short enough time period. Sent my thoughts on to him and we'll see if it gets updated in a future release. We could have used tcpflow, wireshark, etc to get the initial conversation dumped out.
Anyway, however you get the raw data is up to you, dump to it a file and then for me, feed it through smtpcat.pl which will parse it into whatever attachments it may have, pull the username/password out and decode them. You'll still need to do an MD5Sum on the extracted file. My script was completely hacked together, no subs, just start to finish run and output. Not pretty, but functional!
Open up the extracted file and you'll see the location they are meeting at and because .docx files are just zipped up files you can do an unzip on the .docx file, browse around, find the image file and do an MD5Sum on it also.
I'm being a bit vague on this one because it has been well over a month since I did most of this, and I don't recall all the specifics anymore. Here is someone else's writeup on how they did it, goes into a bit more detail, but same idea. His smtpcat is of course different than mine.
Update: (ok had some time to run through this for those who may need some more info)
First lets see what conversations we have going on in evidence02.pcap:
C:\nft>perl pcapcat.pl -r evidence02.pcap
[1] TCP 192.168.1.159:1036 -> 64.12.102.142:587
[2] TCP 192.168.1.159:1038 -> 64.12.102.142:587
Lets dump each:
C:\nft>perl pcapcat.pl -r evidence02.pcap -w file1.txt -d 1
C:\nft>perl pcapcat.pl -r evidence02.pcap -w file2.txt -d 2
Pull up each file in notepad or your favorite text editor and you'll see file1.txt isn't what we want, but about canceling lunch with someone. File2.txt though appears to have an attachment. Looking through it we can see the answers to some of our questions and we can see what the attachment is:
------=_NextPart_000_000D_01CA497C.9DEC1E70
Content-Type: application/octet-stream;
name="secretrendezvous.docx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="secretrendezvous.docx"
We could just copy/paste the attachment into a nice web form on google and get it to spit out the file, but that defeats the purpose the exercise (though that is what I did initially to get the answers).
So next we feed it through smtpcat.pl like this:
C:\nft>perl smtpcat.pl -r file2.txt -w dir2
it will create the directory dir2 if it doesn't already exist and drop the attachments found in file2.txt into it.
We also get the following output:
Credentials:
username: sneakyg33k@aol.com
password: 558r00lz
Other info:
From: "Ann Dercover"
To:
Subject: rendezvous
Attachments and other top level info:
Content-type: multipart/mixed
Effective-type: multipart/mixed
Body-file: NONE
Subject: rendezvous
Num-parts: 2
--
Content-type: multipart/alternative
Effective-type: multipart/alternative
Body-file: NONE
Num-parts: 2
--
Content-type: text/plain
Effective-type: text/plain
Body-file: dir2\msg-860-1.txt
--
Content-type: text/html
Effective-type: text/html
Body-file: dir2\msg-860-2.html
--
Content-type: application/octet-stream
Effective-type: application/octet-stream
Body-file: dir2\secretrendezvous.docx
Recommended-filename: secretrendezvous.docx
We now know her username, password, who the email was from and to, along with the subject and the # of parts and what it created. Since there were no suggested names for the plain and html parts it made some up for it.
The username/password were both base64 encrypted. The 2 types of Authentication that we can easily decode are AUTH LOGIN and AUTH PLAIN, both being base64 encrypted, just different formats of storing the data. smtpcat.pl will handle both, even though only one was needed for this.
Here is what we have in dir2:
Directory of C:\nft\dir2
11/28/2009 02:53 PM 87 msg-860-1.txt
11/28/2009 02:53 PM 402 msg-860-2.html
11/28/2009 02:53 PM 207,438 secretrendezvous.docx
Looking at the .txt or .html files (both the same info one just plain text, one html) Ann asks her sweetheart to bring their fake passport and bathing suit to the attached address. Guess we need to go look at the .docx file.
Opening up the .docx file in OpenOffice we see that it is a picture of google maps telling where to meet. Running an extraction on the .docx file we can go to the word\media directory and find the attached image called image1.png. Do an md5sum on that file and on the original .docx file to get the md5's for them.
Again smtpcat.pl could be cleaned up a bit to add more stuff and be written cleaner, but for what was needed here this worked great. Using pcapcat.pl worked in this example, but as noted before, it does not take into consideration out of order packets, retransmissions, etc, so something else may be needed in "real life", though I still really like it!
My answers are here:
1. Username:sneakyg33k@aol.com
2. Password:558r00lz
3. mistersecretx@aol.com
4. fake passport and a bathing suit.
5. secretrendezvous.docx
6. 9E423E11DB88F01BBFF81172839E1923
7. Playa del Carmen, Mexico
8. AADEACE50997B1BA24B09AC2EF1940B7
I used the pcapcat perl script from NFC #1 to extract the initial data. The one thing I think is a bit unrealistic in these contests is the packet captures are too small, there isn't 100-500 MB of stuff to sift through, trying to decide what is needed/not. Due to download feeds and whatnot I understand why that is, but.... Feeding a 100 kb pcap file through makes life quite simple. Anyway, I emailed the author of pcapcat, for what we've seen in #1 and #2 that script works fine, but if any packets are resent, or out of order, pcapcat fails to take that into account and just puts the data in the output file in the order it was seen in the pcap file. I tried to make some changes to it to fix that, but it was beyond what i could figure out in a short enough time period. Sent my thoughts on to him and we'll see if it gets updated in a future release. We could have used tcpflow, wireshark, etc to get the initial conversation dumped out.
Anyway, however you get the raw data is up to you, dump to it a file and then for me, feed it through smtpcat.pl which will parse it into whatever attachments it may have, pull the username/password out and decode them. You'll still need to do an MD5Sum on the extracted file. My script was completely hacked together, no subs, just start to finish run and output. Not pretty, but functional!
Open up the extracted file and you'll see the location they are meeting at and because .docx files are just zipped up files you can do an unzip on the .docx file, browse around, find the image file and do an MD5Sum on it also.
I'm being a bit vague on this one because it has been well over a month since I did most of this, and I don't recall all the specifics anymore. Here is someone else's writeup on how they did it, goes into a bit more detail, but same idea. His smtpcat is of course different than mine.
Update: (ok had some time to run through this for those who may need some more info)
First lets see what conversations we have going on in evidence02.pcap:
C:\nft>perl pcapcat.pl -r evidence02.pcap
[1] TCP 192.168.1.159:1036 -> 64.12.102.142:587
[2] TCP 192.168.1.159:1038 -> 64.12.102.142:587
Lets dump each:
C:\nft>perl pcapcat.pl -r evidence02.pcap -w file1.txt -d 1
C:\nft>perl pcapcat.pl -r evidence02.pcap -w file2.txt -d 2
Pull up each file in notepad or your favorite text editor and you'll see file1.txt isn't what we want, but about canceling lunch with someone. File2.txt though appears to have an attachment. Looking through it we can see the answers to some of our questions and we can see what the attachment is:
------=_NextPart_000_000D_01CA497C.9DEC1E70
Content-Type: application/octet-stream;
name="secretrendezvous.docx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="secretrendezvous.docx"
We could just copy/paste the attachment into a nice web form on google and get it to spit out the file, but that defeats the purpose the exercise (though that is what I did initially to get the answers).
So next we feed it through smtpcat.pl like this:
C:\nft>perl smtpcat.pl -r file2.txt -w dir2
it will create the directory dir2 if it doesn't already exist and drop the attachments found in file2.txt into it.
We also get the following output:
Credentials:
username: sneakyg33k@aol.com
password: 558r00lz
Other info:
From: "Ann Dercover"
To:
Subject: rendezvous
Attachments and other top level info:
Content-type: multipart/mixed
Effective-type: multipart/mixed
Body-file: NONE
Subject: rendezvous
Num-parts: 2
--
Content-type: multipart/alternative
Effective-type: multipart/alternative
Body-file: NONE
Num-parts: 2
--
Content-type: text/plain
Effective-type: text/plain
Body-file: dir2\msg-860-1.txt
--
Content-type: text/html
Effective-type: text/html
Body-file: dir2\msg-860-2.html
--
Content-type: application/octet-stream
Effective-type: application/octet-stream
Body-file: dir2\secretrendezvous.docx
Recommended-filename: secretrendezvous.docx
We now know her username, password, who the email was from and to, along with the subject and the # of parts and what it created. Since there were no suggested names for the plain and html parts it made some up for it.
The username/password were both base64 encrypted. The 2 types of Authentication that we can easily decode are AUTH LOGIN and AUTH PLAIN, both being base64 encrypted, just different formats of storing the data. smtpcat.pl will handle both, even though only one was needed for this.
Here is what we have in dir2:
Directory of C:\nft\dir2
11/28/2009 02:53 PM 87 msg-860-1.txt
11/28/2009 02:53 PM 402 msg-860-2.html
11/28/2009 02:53 PM 207,438 secretrendezvous.docx
Looking at the .txt or .html files (both the same info one just plain text, one html) Ann asks her sweetheart to bring their fake passport and bathing suit to the attached address. Guess we need to go look at the .docx file.
Opening up the .docx file in OpenOffice we see that it is a picture of google maps telling where to meet. Running an extraction on the .docx file we can go to the word\media directory and find the attached image called image1.png. Do an md5sum on that file and on the original .docx file to get the md5's for them.
Again smtpcat.pl could be cleaned up a bit to add more stuff and be written cleaner, but for what was needed here this worked great. Using pcapcat.pl worked in this example, but as noted before, it does not take into consideration out of order packets, retransmissions, etc, so something else may be needed in "real life", though I still really like it!
Saturday, October 24, 2009
Network Forensics Challenge #2
They are at it again, we barely got the answers for #1 and #2 got put up a few weeks ago. I did it originally within ~30 mins using the web, wireshark and a few other local programs on my machine. But I wanted to stand a chance of actually winning this time, so instead of just sending them the answers I actually started writing a few .exe programs to parse the data out. I have/had them done and then decided I better do something I was willing to share the source code on, so I wrote out a perl script.
Perl is not something I ever work in, have only done it a few times before, so it was a bit painful to do, especially coming from a Pascal background and not a c one! if statements and eq vs = and other little gotchas killed me today, but after about 4 hours or so I came up with a 258 line .pl file that parses it out nicely. There is a lot more I could add to it, but since I'm by no means a perl programmer and my hands are cramping up typing this as it is, it was time for a break and time to call good enough good enough!
I'll release the script after the deadline if i'm not picked as a finalist and it is added to their site.
This was another fun project to work on and it forced me to dig into a programming language I should have learned long ago, but never have. So always good to expand your knowledge some.
Perl is not something I ever work in, have only done it a few times before, so it was a bit painful to do, especially coming from a Pascal background and not a c one! if statements and eq vs = and other little gotchas killed me today, but after about 4 hours or so I came up with a 258 line .pl file that parses it out nicely. There is a lot more I could add to it, but since I'm by no means a perl programmer and my hands are cramping up typing this as it is, it was time for a break and time to call good enough good enough!
I'll release the script after the deadline if i'm not picked as a finalist and it is added to their site.
This was another fun project to work on and it forced me to dig into a programming language I should have learned long ago, but never have. So always good to expand your knowledge some.
Saturday, September 26, 2009
Network Forensics Contest Results
A month or two ago philosecurity.org started a nice little Network Forensic contest. It wasn't too hard and wasn't too easy. It gave me a chance to parse through some traffic and see what was going on. Then to carve a file out of a packet capture, using some of the SANS 508 stuff I learned awhile back before I picked up my GCFA cert.
The original puzzle can be found here and then again here when SANS decided to sponsor it and give an On-Demand course away for the winner.
Well happy to say I at least got everything right, though I didn't win, nor was I one of the finalists. All of the finalists scripted out a way to answer the questions, or had one program that did it all (or most of it). The results can be found here.
Erik Hjelmvik, author of NetworkMiner, who is using some of the tcp and dhcp fingerprinting stuff from Satori was one of the finalists and implemented some new stuff in 0.89 to become a finalist, though not a semifinalist since it wasn't all scripted out either. (When I used NetworkMiner to parse it out, it was only version 0.88, Erik hadn't released 0.89 until after I put my submission in).
From a straight Network Forensics standpoint I understand why they wanted it scripted out, but from understanding how to actually do it I'm glad I didn't depend on an automated program to do it (granted each of the finalists I believe had to write their own programs to do this). If you understand how to carve the data out then you can do this with pretty much any data, if you depend on a utility to do it, you may have to wait for updates to it if/when things change.
Ultimately I just wanted to make sure I could do it and am happy that I got it done and answered correctly. I was more interested in it from fingerprinting stand point anyway and spent more of my time on seeing what else was on the network!
If anyone wants to do it, the puzzle and pcap files are still out there!
Here was my submission and all my notes (again I was interested in the rest of the network):
Answers:
1. Sec558user1
2. Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
3. recipe.docx
4. 50 4B 03 04
5. 8350582774E1D4DBE1D61D64C89E0EA1
6. Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary.
How I got there:
Tools Used:
Satori - http://myweb.cableone.net/xnih - Passive OS Fingerprinting
NetworkMiner - http://sourceforge.net/projects/networkminer/ - Network Forensic Analysis Tool, used for cookie stuff and a few other sanity checks
FrHed - http://frhed.sourceforge.net/ - used to Hex Edit the file to remove the initial stuff prior to the magic number
Wireshark - http://www.wireshark.org - view and export pcap file
HashGenerator - http://pagesperso-orange.fr/cycocrew/delphi/applications.html - computer hashes
Google of course to find some of the other info
----
Writeup:
I started with 2 programs, one I wrote geared completely towards passive OS fingerprinting, Satori, and the other program NetworkMiner which I've worked with the developer on a little in the past. Using Satori I mapped out the machines identified in the packet capture and got an initial layout of the network. Determing which systems did what on the network. Then feeding the capture through NetworkMiner I was able to get some of the initial Clear Text information that was going on between clients. Once I had a better idea of what type of data was in the capture I started picking away at it with Wireshark.
Knowing Ann's IP it was easy to get started in wireshark with a simple filter of (ip.host == 192.168.1.158). With this in place and scanning through the packets for anything out of the ordinary in the hex window. Basically I knew there had to be some type of clear text conversation going on due to what NetworkMiner had seen. We see Ann's computer is talking to a 64.12.24.50 (bos-m013a-sdr3.blue.aol.com). Since it is an AOL server it is probably AIM being used, but I did not verify that. The information looks to be SSL based on the destination port, but ends up being in clear text. I assume this was an attempt to get past any egress filtering, but didn't dig into it since that wasn't requested at this time.
Identifying who she was talking to was fairly simple, and digging into whatever protocol the chat program she was using would have probably been a good idea. Based on other things I saw she appears to be comunicating with Sec558User1.
Eventually she transfers the file to the other user at computer 192.168.1.159, which appears to be a Windows XP box. Depending on your env this may be a dead give away that you are having issues. Looking at the other systems on this network they all appear to be Linux Boxes, so a new rogue XP box sticks out like a sore thumb. Something like packet fence which does DHCP fingerprinting may be useful to block computers like this off their network or at least make it a little harder for them to get a valid IP and use the network.
In packet 92 we see the beginning of the file transfer. Sending the file recipe.docx
The rest of the file transfer which starts in about packet 109 where we are able to right click on it and do "Follow TCP Stream". This shows both directions of traffic. Next we need to go to the bottom and filter by 192.168.1.158 --> 192.168.1.159, getting just the data that Ann's computer is sending to the XP box. Select Raw and do a Save As. This will save "extra" info in the file, which we will need to remove based on some file carving next.
We now know, or appear to know the type of file it is based on the file name above. We need to look up that magic number. A docx file really is a zipped file so it has the same magic number which is: 50 4B 03 04 14 00 06 00
We now open up the file we saved in a hex editor and do a search for the above magic number. Once we find it we delete anything prior to it and resave the file. There is always the chance that there will be extra junk at the end too that may need carved off.
After that, we can open up the file with OpenOffice or Microsoft Word and see what the data is. We could also unzip it instead and look at the .xml files generated if we need to find out more about the initial file.
Run the file through your choice of md5sum programs and you should be good to go.
-----
Below is the notes I took while I went through the system, typically wouldn't put them in a report, but there was a few interesting pieces of info in there I found.
Extra info and general notes on systems on the network and what they appear to do:
192.168.1.2 - Linux 2.6 possibly, limited info, did what may have been a scan of 192.168.1.157. Connected on port 80, but just did a handshake and said goodbye, no header info exchanged.
192.168.1.10 - default gateway I assume
192.168.1.30 - NTP Client Box, running SSH server (192.169.1.2 connected to it)
192.168.1.157 - running Samba 2.2.7 - 3.0.x client (actually 3.2.0, need to update Satori)
print queue
HTTP Server, or at least port 80 is open
Herbivore/SANS
192.168.1.158 - Linux 2.4 or 2.6 box, packet 92 starts sending recipe.docx, packet 112 using cool filexfer sends it also
NTP Client
Talking to 64.12.24.50, most likely sec558user1
FTPs file to 192.168.1.159, syn comes in in packet 109
192.168.1.159 - Windows XP, 2000 or 2003 box (XP based on Web)
talking to 64.12.25.91
downloads zip file of smiley faces from 205.188.13.12
goes off to at.atwola.com, requesting DNS info for them after download of resume.doc
pulled file (httpget) with: (removed since it was actually linking to the ad in this post!)
pulled file (httpget) with: (removed since it may have linked to ad also).
"username" on cookie: JEB2=4A839DDB6E65181C45921CB2F00016D8; ATTACID=a3Z0aWQ9MTU4NzdpYTAwYTh2Ymk=; ATTAC=a3ZzZWc9OTk5OTk6NTAyODA=; badsrfi=V0d710994e8ccb8db64a83a07939b2; atdemo=a3ZhZz1hbTM6dWEzOTtrdnVnPTE7; AxData=; atdses=0
atwola.com appears to be "spyware/adware" based on a quick search
External Hosts
64.12.24.50 - bos-m013a-sdr3.blue.aol.com
64.12.25.91 - bos-m007c-sdr4.blue.aol.com
64.236.68.245 (dns requested info by 192.168.1.159)
64.236.68.246 (dns requested info by 192.168.1.159)
205.188.13.12 - no DNS entry, only talking to 192.168.1.159 via SSL), downloaded a zipped file of smile faces and their manifest.
10.1.1.20 - DNS server, NTP Server
Clear text data, (192.168.1.158 to 64.12.24.50) (owned by AOL, so possibly AIM traffic)
E4628778....Sec558user1
Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
E4628778....Sec558user1*..c.z.........
G7174647....Sec558user1.......R..7174647..F.CL...."DEST.......................F.........'...........recipe.docx.*.V......
G7174647....Sec558user1*.V..{.......*..
7174647....Sec558user1..............J.H.........+..1n....+...O............J.........7174647..F.CL...."DEST.......*.V..".......*.1...........
Sec558user1..*.V..........*.y..N....w...
Sec558user1..............J.H.........+..1n....+...O............J......a........X....< HTML >< BODY >< FONT FACE="Arial" SIZE=2 COLOR=#000000>thanks dude< /FONT>< /BODY>< /HTML >.
......+..1n....+...O.........*.V..".......*.............Sec558user1..*.V..........+.Q.....L.....Sec558user1..............J.H.........+..1n....+...O............J......s........j....< HTML >< BODY>< FONT FACE="Arial" SIZE=2 COLOR=#000000>can't wait to sell it on ebay< /FONT>< /BODY>< /HTML >
............Sec558user1..*.V..".......+.............Sec558user1..*..d.".........H...........Sec558user1..*..e.J.........
I5088496....Sec558user1..."................see you in hawaii!....*..f.".........J...........Sec558user1..*.V......
DOCX (zip) Magic Number:
50 4B 03 04 PK..
ZIP PKZIP archive file (Ref. 1 | Ref. 2)
Trailer: filename 50 4B 17 characters 00 00 00
Trailer: (filename PK 17 characters ...)
DOCX, PPTX, XLSX Microsoft Office Open XML Format Document
JAR Java archive; compressed file package for classes and data
SXC, SXD, SXI, SXW OpenOffice spreadsheet, drawing, presentation, and text files
WMZ Windows Media compressed skin file
XPI Mozilla Browser Archive
XPT eXact Packager Models
50 4B 03 04 14 00 06 00 PK......
DOCX, PPTX, XLSX Office 2007 documents
Use Follow TCP Stream, just get one side of converation. Save as Raw. Lookup "magic number"
Search for it in Saved file. Delete everything prior to that and resave, get:
Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary.
Hash on the File is:
8350582774E1D4DBE1D61D64C89E0EA1
The original puzzle can be found here and then again here when SANS decided to sponsor it and give an On-Demand course away for the winner.
Well happy to say I at least got everything right, though I didn't win, nor was I one of the finalists. All of the finalists scripted out a way to answer the questions, or had one program that did it all (or most of it). The results can be found here.
Erik Hjelmvik, author of NetworkMiner, who is using some of the tcp and dhcp fingerprinting stuff from Satori was one of the finalists and implemented some new stuff in 0.89 to become a finalist, though not a semifinalist since it wasn't all scripted out either. (When I used NetworkMiner to parse it out, it was only version 0.88, Erik hadn't released 0.89 until after I put my submission in).
From a straight Network Forensics standpoint I understand why they wanted it scripted out, but from understanding how to actually do it I'm glad I didn't depend on an automated program to do it (granted each of the finalists I believe had to write their own programs to do this). If you understand how to carve the data out then you can do this with pretty much any data, if you depend on a utility to do it, you may have to wait for updates to it if/when things change.
Ultimately I just wanted to make sure I could do it and am happy that I got it done and answered correctly. I was more interested in it from fingerprinting stand point anyway and spent more of my time on seeing what else was on the network!
If anyone wants to do it, the puzzle and pcap files are still out there!
Here was my submission and all my notes (again I was interested in the rest of the network):
Answers:
1. Sec558user1
2. Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
3. recipe.docx
4. 50 4B 03 04
5. 8350582774E1D4DBE1D61D64C89E0EA1
6. Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary.
How I got there:
Tools Used:
Satori - http://myweb.cableone.net/xnih - Passive OS Fingerprinting
NetworkMiner - http://sourceforge.net/projects/networkminer/ - Network Forensic Analysis Tool, used for cookie stuff and a few other sanity checks
FrHed - http://frhed.sourceforge.net/ - used to Hex Edit the file to remove the initial stuff prior to the magic number
Wireshark - http://www.wireshark.org - view and export pcap file
HashGenerator - http://pagesperso-orange.fr/cycocrew/delphi/applications.html - computer hashes
Google of course to find some of the other info
----
Writeup:
I started with 2 programs, one I wrote geared completely towards passive OS fingerprinting, Satori, and the other program NetworkMiner which I've worked with the developer on a little in the past. Using Satori I mapped out the machines identified in the packet capture and got an initial layout of the network. Determing which systems did what on the network. Then feeding the capture through NetworkMiner I was able to get some of the initial Clear Text information that was going on between clients. Once I had a better idea of what type of data was in the capture I started picking away at it with Wireshark.
Knowing Ann's IP it was easy to get started in wireshark with a simple filter of (ip.host == 192.168.1.158). With this in place and scanning through the packets for anything out of the ordinary in the hex window. Basically I knew there had to be some type of clear text conversation going on due to what NetworkMiner had seen. We see Ann's computer is talking to a 64.12.24.50 (bos-m013a-sdr3.blue.aol.com). Since it is an AOL server it is probably AIM being used, but I did not verify that. The information looks to be SSL based on the destination port, but ends up being in clear text. I assume this was an attempt to get past any egress filtering, but didn't dig into it since that wasn't requested at this time.
Identifying who she was talking to was fairly simple, and digging into whatever protocol the chat program she was using would have probably been a good idea. Based on other things I saw she appears to be comunicating with Sec558User1.
Eventually she transfers the file to the other user at computer 192.168.1.159, which appears to be a Windows XP box. Depending on your env this may be a dead give away that you are having issues. Looking at the other systems on this network they all appear to be Linux Boxes, so a new rogue XP box sticks out like a sore thumb. Something like packet fence which does DHCP fingerprinting may be useful to block computers like this off their network or at least make it a little harder for them to get a valid IP and use the network.
In packet 92 we see the beginning of the file transfer. Sending the file recipe.docx
The rest of the file transfer which starts in about packet 109 where we are able to right click on it and do "Follow TCP Stream". This shows both directions of traffic. Next we need to go to the bottom and filter by 192.168.1.158 --> 192.168.1.159, getting just the data that Ann's computer is sending to the XP box. Select Raw and do a Save As. This will save "extra" info in the file, which we will need to remove based on some file carving next.
We now know, or appear to know the type of file it is based on the file name above. We need to look up that magic number. A docx file really is a zipped file so it has the same magic number which is: 50 4B 03 04 14 00 06 00
We now open up the file we saved in a hex editor and do a search for the above magic number. Once we find it we delete anything prior to it and resave the file. There is always the chance that there will be extra junk at the end too that may need carved off.
After that, we can open up the file with OpenOffice or Microsoft Word and see what the data is. We could also unzip it instead and look at the .xml files generated if we need to find out more about the initial file.
Run the file through your choice of md5sum programs and you should be good to go.
-----
Below is the notes I took while I went through the system, typically wouldn't put them in a report, but there was a few interesting pieces of info in there I found.
Extra info and general notes on systems on the network and what they appear to do:
192.168.1.2 - Linux 2.6 possibly, limited info, did what may have been a scan of 192.168.1.157. Connected on port 80, but just did a handshake and said goodbye, no header info exchanged.
192.168.1.10 - default gateway I assume
192.168.1.30 - NTP Client Box, running SSH server (192.169.1.2 connected to it)
192.168.1.157 - running Samba 2.2.7 - 3.0.x client (actually 3.2.0, need to update Satori)
print queue
HTTP Server, or at least port 80 is open
Herbivore/SANS
192.168.1.158 - Linux 2.4 or 2.6 box, packet 92 starts sending recipe.docx, packet 112 using cool filexfer sends it also
NTP Client
Talking to 64.12.24.50, most likely sec558user1
FTPs file to 192.168.1.159, syn comes in in packet 109
192.168.1.159 - Windows XP, 2000 or 2003 box (XP based on Web)
talking to 64.12.25.91
downloads zip file of smiley faces from 205.188.13.12
goes off to at.atwola.com, requesting DNS info for them after download of resume.doc
pulled file (httpget) with: (removed since it was actually linking to the ad in this post!)
pulled file (httpget) with: (removed since it may have linked to ad also).
"username" on cookie: JEB2=4A839DDB6E65181C45921CB2F00016D8; ATTACID=a3Z0aWQ9MTU4NzdpYTAwYTh2Ymk=; ATTAC=a3ZzZWc9OTk5OTk6NTAyODA=; badsrfi=V0d710994e8ccb8db64a83a07939b2; atdemo=a3ZhZz1hbTM6dWEzOTtrdnVnPTE7; AxData=; atdses=0
atwola.com appears to be "spyware/adware" based on a quick search
External Hosts
64.12.24.50 - bos-m013a-sdr3.blue.aol.com
64.12.25.91 - bos-m007c-sdr4.blue.aol.com
64.236.68.245 (dns requested info by 192.168.1.159)
64.236.68.246 (dns requested info by 192.168.1.159)
205.188.13.12 - no DNS entry, only talking to 192.168.1.159 via SSL), downloaded a zipped file of smile faces and their manifest.
10.1.1.20 - DNS server, NTP Server
Clear text data, (192.168.1.158 to 64.12.24.50) (owned by AOL, so possibly AIM traffic)
E4628778....Sec558user1
Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
E4628778....Sec558user1*..c.z.........
G7174647....Sec558user1.......R..7174647..F.CL...."DEST.......................F.........'...........recipe.docx.*.V......
G7174647....Sec558user1*.V..{.......*..
7174647....Sec558user1..............J.H.........+..1n....+...O............J.........7174647..F.CL...."DEST.......*.V..".......*.1...........
Sec558user1..*.V..........*.y..N....w...
Sec558user1..............J.H.........+..1n....+...O............J......a........X....< HTML >< BODY >< FONT FACE="Arial" SIZE=2 COLOR=#000000>thanks dude< /FONT>< /BODY>< /HTML >.
......+..1n....+...O.........*.V..".......*.............Sec558user1..*.V..........+.Q.....L.....Sec558user1..............J.H.........+..1n....+...O............J......s........j....< HTML >< BODY>< FONT FACE="Arial" SIZE=2 COLOR=#000000>can't wait to sell it on ebay< /FONT>< /BODY>< /HTML >
............Sec558user1..*.V..".......+.............Sec558user1..*..d.".........H...........Sec558user1..*..e.J.........
I5088496....Sec558user1..."................see you in hawaii!....*..f.".........J...........Sec558user1..*.V......
DOCX (zip) Magic Number:
50 4B 03 04 PK..
ZIP PKZIP archive file (Ref. 1 | Ref. 2)
Trailer: filename 50 4B 17 characters 00 00 00
Trailer: (filename PK 17 characters ...)
DOCX, PPTX, XLSX Microsoft Office Open XML Format Document
JAR Java archive; compressed file package for classes and data
SXC, SXD, SXI, SXW OpenOffice spreadsheet, drawing, presentation, and text files
WMZ Windows Media compressed skin file
XPI Mozilla Browser Archive
XPT eXact Packager Models
50 4B 03 04 14 00 06 00 PK......
DOCX, PPTX, XLSX Office 2007 documents
Use Follow TCP Stream, just get one side of converation. Save as Raw. Lookup "magic number"
Search for it in Saved file. Delete everything prior to that and resave, get:
Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove the saucepan from heat. Allow to cool completely. Pour into gas tank. Repeat as necessary.
Hash on the File is:
8350582774E1D4DBE1D61D64C89E0EA1
Subscribe to:
Posts (Atom)