The attacker downloaded two files to my Linux honeypot. One of which TSK can find, the other I know was downloaded because I saw the HTTP traffic, and I know it was installed based on the files it created and modified and the setup script was found with strings, but I can't find the tar.gz or the directory and files that were in it.
I located data block that contains the install script with blkcat, but when I try to find the inode number with ifind, it says it can't find the inode. Does anyone know how I can find the files?
ifind -o 208845 -i raw -f ext3 -d 623356 image.dd
Inode not found
According to your command line, this is an EXT3 file system. If so, and if the inode is unallocated, there will be no way to associate the data block with the inode.
When you delete a file on ext3 the block pointers are zero'd out. Since ifind uses the block pointers in an inode to associate the datablock, you're out of luck. That's why recovering deleted files from ext3 is so much harder than ext2. In ext2 the inode is marked "unallocated", but the block pointers remain.
The fact that the directory that contained the files you're looking for was also deleted makes it harder.
If this is an educational prospect, then try this
1) using fsstat, find out which block group your data block falls into (listed at the bottom of the output)
2) use 'fls -Frd' to show deleted files
3) use istat to have a look at the $Orphans and try to identify inodes that have "Group X" where X is the group your block falls into. This can narrow it down.
See what you can find with the above information. Depending on how many orphans there are in that directory (I'm assuming orphans because the directory was deleted as well), you may be able to recover a great deal of metadata. Just remember that even if you do identify potential candidate inodes for the deleted files, using icat to recover the contents won't work because the block pointers are still zero'd. If you use istat on an inode in the $Orphans from fls, you'll see the field at the bottom, "Direct Blocks " is empty.
Hope this helps,
Barry
http//
Thanks bgrundy, that explains a lot!
I just used strings to search the image for rk.tar.gz and found what appears to be a directory entry that contains rk.tar.gz as well as the rk/ directory that was in that archive. Do you know of anything I can do to get more details, such as the parent directory name or anything else?
I'm pretty sure it's in /usr/X11R6/ because that's the file location of the attacker's wget-log error log and rk/. I'm just not sure why block 4580 doesn't show rk.tar.gz like block 4233, because other than that they appear to be the same directory.
blkcat.exe -i raw -f ext3 root.dd 4233
g<☺ ♀ ☺☻. ☺±♦ ♀ ☻☻.. e ♀ ♥☻lib ºc ♀ ♥☻bin »~ ► ☻include ┬{☺ ♀ ♥☻man ·╖☻
► ♣☻share ►=☺ ¶ ☺rk.tar.gz ╚▒♦ É☼☻☻rk
blkcat.exe -i raw -f ext3 root.dd 4580
g<☺ ♀ ☺☻. ☺±♦ ♀ ☻☻.. e ♀ ♥☻lib ºc ♀ ♥☻bin »~ ► ☻include ┬{☺ ♀ ♥☻man ·╖☻
► ♣☻share ►=☺ ☺wget-logz ╚▒♦ É☼☻☻rk
Anyway, thanks for the help!
I just used strings to search the image for rk.tar.gz and found what appears to be a directory entry that contains rk.tar.gz as well as the rk/ directory that was in that archive. Do you know of anything I can do to get more details, such as the parent directory name or anything else?
I'm pretty sure it's in /usr/X11R6/ because that's the file location of the attacker's wget-log error log and rk/.
I'm not entirely sure, from reading your post, if rk/ is a deleted directory or not. If it's unallocated, but not orphan, then you should see it with fls (-rDd) under /usr/X11R6.
At this point you will need to make some assumptions about how bad guys work. Based on simple experience first, lets say the bad guy downloads the tar file (rk.tar.gz) to /usr/X11R6 and then immediately extracts it, creating the rk/ directory, which is populated by the files contained in the archive. He runs the tools and rename/moves them to where they need to be (or just runs them, depending on what's in the kit), and then deletes the rk/ directory.
So, assuming you know the inode of rk/, you can postulate that the directory and it's contents were created at roughly the same time (when extracting the tar file). If so, then look for *consecutive* inodes within the $Orphan Files Directory (bottom of your root output from fls). The un-named files in that directory are deleted files, usually from deleted directories (hence the "-/r" notation).
Let's say rk/ is inode 22600. If you look through $Orphans and see inodes 22601, 22603, and 22605, then I would be willing to bet those inodes (look at them with istat) were part of the tar file. The really interesting and useful info is the gaps in the run. Notice that in my example 22602 and 22604 are missing. Those are still likely part of the archive, and IF the perp MOVED those files to another location (even if he changed the name) the inode will stay the same but be in a different directory (like /dev/ or /lib or /etc, etc). So as soon as I see something like that I'll run ffind on the skipped inodes (22602 and 22604) to see if they are elsewhere, still intact and part of the kit. On the other hand, if the perp COPIED the files out of the archive, it will get a new inode and be harder to find that way.
All of this just goes to show that TSK is a powerhouse for examination - when you do this on an actual disk, and the deleted files and orphans run into the hundreds plus, being able to BASH loop and script (perl for the real wizards) is a huge benefit.
This also goes to show that knowing the file system you are examining is every bit as important as being able to string commands together. TSK is the perfect tool (in my opinion) for training this sort of stuff since each individual tool looks at a different layer of information.
Again, I hope this helps a little. I don't want to be too long winded, but it's hard to explain this stuff in this kind of setting.
Barry
This is awesome! I took your advice and looked at the orphans, found the gaps, and sure enough those gaps were files from rk.tar.gz that were moved to other directories. I've learned a lot, thanks!