SANS SEC508 Forensics - Solutions
Day 2 -- UNIX Traffic Analysis
What approx. pkt begins the ftp attack?
-
Solution
-
Packet 240 (first SITE EXEC command)
Which packet indicates that the attack succeeded?
-
Resolution Steps
-
Look for the end of the strange-looking strings and look for normal UNIX commands
-
Solution
-
Packet 417 -> Request: id;
-
Extra Tips
-
Follow the TCP stream to show them the whole hacking session
How many rootkits were downloaded
-
Resolution Steps
-
Select tcp/21 traffic only (filter: tcp.port == 21)
-
Filter out the attack stream
-
Sort by Info to obtain the ftp RETR commands.
-
Solution
-
3 rootkits were downloaded:
-
Zer0.tar.gz
-
copy.tar.gz
-
ooty.tar.gz
Retrieve the files
-
Resolution Steps
-
Locate the 3 FTP RETR commands identified in the previous section
-
Follow TCP stream on the 3 FTP-DATA flows which follow the FTP RETR instructions
What port did SSH use?
-
Resolution Steps
-
A telnet to port 22 on a normal system shows something like: SSH-2.0-OpenSSH_4.3
-
Edit > Find Packet -> SSH-
-
Follow TCP Stream
-
Shows tcp/24 and SSH version 1.5-1.2.27 which corroborates the commands from the .bash_history
What ssh client did the attacker use?
-
Resolution Steps
-
Can be derived from the SSH traffic above
-
There actually are 3 sessions: one very short, the other ones long.
-
Version: Putty-1.5
-
Putty is a the most popular Windows SSH client
USB Key
Analysis
-
Image to analyze: seized_usbkey.img
-
The exercise belongs to a USB Key while the Answers reference an floppy image. Sector information does not match but the general discussion still applies.
456-486 (31) -> EOF
487-491 (5) -> EOF
-
_IMMYJ~1.DOC
-
DOC FILE
-
DELETED (No FAT Chain)
-
FAT Size: 20480
-
Sectors: 1 [416]
-
Sectors Needed: 40 ((20480 + 511) / 512)
-
Recovery: 40 [416 - 455]
-
Extraction: dcat -f fat img/usbkey.img 416 40 > _IMMYJ~1.DOC.dcat
-
Scheduled Visits.exe
-
ZIP File
-
FAT Size: 1000
-
Sectors: 2 [487 488]
-
TASK will only show as many sectors as are needed for the given file size, i.e., 2 sectors: 487 & 488
-
Related FAT Chain: 487-491 (5) -> EOF
-
Extraction: dcat -f fat img/usbkey.img 487 5 > Scheduled\ Visits.exe.dcat
-
cover page.jpg
-
JPG File
-
FAT Size: 15585
-
Sectors: 1 [834]
-
Sector 834 is actually not allocated (dstat -f fat img/usbkey.img 834)
-
Sectors Needed: 31 ((15585 + 511) / 512)
-
Possibly Related FAT Chain: 456-486 (31) -> EOF
-
Extraction: dcat -f fat img/usbkey.img 456 31 > cover\ page.jpg.dcat
-
strings cover\ page.jpg.dcat -> pw=goodtimes
-
_IMMYJ~1.DOC - Had been deleted, therefore no FAT Chain, and only the first sector was referenced in the FAT. Recovery is performed using the reported size to calculate the number of sectors, and extracting them starting at that first sector.
-
Scheduled Visits.exe - Zipfile.
-
Size according to the FAT Directory Entry is 1000 & 2 sectors are referenced, which is consistent.
-
The size (1000 bytes -> 2 sectors) is not consistent with the corresponding FAT Chain which shows 5 sectors (the size of a file occupying 5 sectors would be between 2049 and 2560 bytes).
-
The fact that the zip file seems to be corrupted may indicate that the Directory Entry information is wrong; we therefore use the FAT Chains information instead.
-
Extraction is performed by extracting 5 sectors (5 x 512 bytes = 2560 bytes) beginning at the first sector.
-
cover page.jpg - JPG File.
-
The size is 15585 however there is just 1 referenced sector. Non-consistent.
-
Additionally, the referenced sector is not allocated. Non-consistent.
-
There is a Chain in the FAT which seems to not belong to any file. Hypothesis: it belongs to this one (actually it does).
-
Conclusion: The referenced sector was manipulated (removing the rest). A strings of the image shows pw=goodtimes which may be the password of the zip file (actually is).
-
The Scheduled Visits.exe is decrypted with the password goodtimes.
Fixing the Image
Sectors before file system: 42
File System Layout (in sectors)
* Total Range: 0 - 48971
* Reserved: 0 - 3
** Boot Sector: 0
* FAT 0: 4 (b 2048) - 193 (b 98816)
* FAT 1: 194 (b 99328) - 383 (b 196096)
* Data Area: 384 (b 196608) - 48971 (b 25073152)
** Root Directory: 384 (b 196608) - 415 (b 212480) -=-=> Cluster 2 -> Sector 384
** Cluster Area: 416 (b 212992) - 48971 (b 25073152)
Cluster Area: Cl 2 / Sctr 384 / b 196608 -> Cl 776898 / Sector 416 / b 25073152)
Root Dir: Cl 2 / Sctr 384 / b 196608
Sector Size: 512 - Cluster Size: 512 - Total Cluster Range: 2 - 48557
FAT CONTENTS (in sectors)
-------------------------
456-486 (31) -> EOF --- 456 (b 233472) - 486 (b 248832)
487-491 (5) -> EOF --- 487 (b 249344) - 491 (b 251392)
-
Fixing Jimmy Jungle.doc
-
Characteristics
-
Root Entry: 5
-
Reported Size in Root Entry: 20480
-
First Cluster in Root Entry:
-
Reported First Cluster: 416
-
Fixes
-
FAT Chain should be: 416 (b 212992) - 455 (b 232960) -> 2 (0x0002) - 41 (0x29)
-
In the Directory entry we should have 416 -> 2
-
In the FAT area we should have 0x003 -> 0x0029
-
Starting on byte 2048, and after f8ff, fill with sequencial cluster numbers (0x0300 -> 0x2a00)
-
Fixing cover page.jpg
-
Characteristics
-
Root Entry: 8
-
Reported Size in Root Entry: 15585
-
First Cluster in Root Entry:
-
Reported Sector of First Cluster in Root Entry: 834
-
Fixing
-
First Cluster in Root Entry should be: 456 -=-> 456 - 416 (start of cluster area) + 2 = 42 (0x2a)
-
Sector of First Cluster in Root Entry should be: 456 (according to fsstat)
-
Change Starting Cluster to 456 (0xc801) in the directory entry:
-
Goto Offset 196608, find dir. entry for cover page.jpg, change starting cluster from 0xa401 to 0x2a00
-
Fixing Scheduled Visits.exe
-
Characteristics:
-
Root Entry: 11
-
Reported Size in Root Entry: 1000
-
First Cluster in Root Entry:
-
Reported First Cluster in Root Entry: 487 -=-> 0x0049 = 73 in Dir Entry -> 487 - 416 (start of cluster area) + 2 = 73
-
Fixing
-
Size should be <= 2560 (0x000a)
-
Change the size from 0xe803 to 0x000a
