HOLA 4
Hackers of the Lost Ark Winning Answers
By: gnick
You rock, Jersey! Another terrific challenge - I'm looking forward to seeing how you might go about hiding "LostArk.txt" on WINIAC. I have to admit that I am still a little stumped over that strange "dir" command - I'll have to check out your explanation on that too. Thanks for posting!
**************************************************************************************************
It's a good thing Jersey was quick! Fortunately for him, since the attacker was going through the trouble of reading the physical memory of WINIAC just before he got caught, his previous searches probably didn't give him what he was after. Let's just hope that Jersey's Fedora isn't so tight that he can't think his way through this!
1) What was the purpose of the attacker's "dir" and "find" commands?
This "dir" and "find" commands are trying to locate any accessible file on the C: drive with the term "LostArk" in the file name.
dir c:*.* /a:hsr-h-s-r /S > file.txt
This is a very strangely structured "dir" command. If the Attribute (/a) option had been called thusly: "/a:hsr" or thusly: "/a:-h-s-rhsr", then it would have shown only the files with the "Hidden", "Read-only", and "System" tags set. However, the current configuration: "/a:hsr-h-s-r" seems to be intended to list only files with none of those three flags set. I believe that using "/a:-h-s-r" would give identical results. I see four possible reasons that the malicious Neo-Nazi might have structured the command this way:
a) He's intentionally being confusing and added the redundant "hsr" just to keep Jersey guessing.
b) He's doing something terribly clever and has out-witted me.
c) "dir" works differently on the 1936 release of Windows 2003 Server than it does under other Windows versions and DOS. (I have never had a chance to play on a Win2003 box, so this is a real possibility…)
d) His shaved head has allowed the sun to bake his brain and he didn't realize that the "hsr" would be overridden by the " -h-s-r". (Baked Brain Syndrome or BBS is a common problem for baldies.)
The rest of the "dir" command is very straight-forward:
"c:*.*" – List all files on the C: that I'm allowed to see
"/S" – Search all subdirectories that I have access to recursively
"> file.txt" – Write the results to the file "file.txt"
find /N "LostArk" file.txt
The " find" command is pretty simple. It just tells the OS to search the file "file.txt" for any occurrence of the string "LostArk" and include the line number every time it reports a success. Most likely, the attacker will just be sitting back and watching the output so that he can browse through "file.txt" to the returned line numbers and find out which directory the suspected files are stored under.
2) What was the purpose of the attacker's "strings" command?
strings –s –a c:\ | find "9906753"
The "strings" command here will scan through all accessible files on the C: drive and extract any character strings that it can find (That will most likely take a good long time if this is a large server.) The "-a" flag tells "strings " to search the entire file rather than just the data section. [Actually, the -a flag is to specify ASCII... Ed.] Parsing the output through "find" will filter out all strings that do not contain "9906753". [Actually, it locates all strings that contain this number... Ed.] Piping the output through "grep" instead of "find" would probably have been much more useful, since the attacker could have easily viewed the lines of text surrounding the string in question and report the specific file in which the string is found. But, we's in Windows, so we works with what we gots.
3) What was the purpose of the attacker's "lads" command?
lads c:\ /S | find "LostArk"
This command searches the entire C: drive for any available alternate data streams and then searches them for "LostArk". [Actually, it just looks for files that have the string "LostArk" in their name...Ed.] Under NTFS, all files have at least two data streams [Actually, they don't... they usually have just one, but can have an arbitrary number of additional ones if someone or some application tucks data inside a stream... Ed.] . The first contains security information, permissions, etc. The second contains the normal file information. The third, forth, etc. could contain just about anything. Lads is a handy little tool that detects these data streams. The " /S" option tells "lads" to include subdirectories – It is similar to the "/S" option for "dir".
4) What was the purpose of the attacker's "dd" command?
dd if=\\.\PhysicalMemory conv=noerror
This is a handy way to use "dd" under Windows (although it would probably be easier to use an output file using "of=" than try to parse through this information on stdout). All this command does is dump what is currently in the computer's memory bit-for-bit to stdout. The "conv=noerror" means that "dd " should keep working even if it encounters a read error.
5) Where else might the file be hidden on the system, and how would the attacker (as well as New Jersey Jones) find it? Be creative!
A) The most obvious. The file could be on the D: drive (or any other drive for that matter). Our nasty Nazi searched only the C: drive for the file(s) he wanted. Either he or Jersey could easily expand the search by wrapping the same commands in a FOR loop. The replacement for the " dir" command would look something like this:
Grab a list of mounted devices from the registry:
(0) regedit /e "drives.txt" "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices"
Wipe out any existing file called "file.txt":
(1) del file.txt
For each mounted device, list all accessible files and directories in "file.txt":
(2) for /f "tokens=3,5 delims=\:," %A in ('type "drives.txt" ^| find /I "\\DosDevices\\" ^| sort') do if 0x%%~B lss 0x60 dir %A:\*.* /S >> file.txt
I have tested the commands above under Win2k and am just assuming that they work under 2003 Server. If not, the following would do essentially the same thing, but it's not nearly as graceful and would search mapped as well as local drives:
Wipe out any existing file called "file.txt":
(0) del file.txt
Try to take a recursive directory listing of each potential drive letter:
(1) for %A in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO dir %A:\*.* /S >> file.txt
A similar wrapper could be applied for the "strings" and "lads" searches for similar results.
B) The file could have either the "hidden", "read-only", or "system" flag set. I believe that the attacker's "dir" command would overlook these files. Restructuring that command like I described in question (1) would be the simplest of several methods that could solve this issue.
C) The file could be stored in a directory that the attacker does not have access to. Assuming that he has Administrative privileges, it would be pretty easy to reset security permissions on each of the drives and force the child directories to propagate inheritable permissions. This would leave a pretty obvious trail of what the attacker was up to that would be inconvenient to erase, but I think that the attacker has already demonstrated that subtlety is not his primary concern.
D) "LostArk.txt" could be encrypted. Bypassing this minor hurdle is left as an exercise for the reader.
E) "LostArk.txt" could have been copied line-by-line into registry keys and stored in the registry. To check, Jersey could try the following:
Dump the entire registry to a .txt file:
(0) regedit /e "reg.txt"
Search it for the strings that we know it contains:
(1) find /n "9906753" reg.txt
(2) find /n "Ark of the Covenant" reg.txt
F) "LostArk.txt" could be compressed as part of a .zip file. A rough search could be done like this (assuming WinZip's command-line tools are installed to the default directory):
Dump a list of mounted drives:
(0) regedit /e "drives.txt" "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices"
Wipe out any existing file called "zipfiles.txt":
(1) del zipfiles.txt
Find any accessible files with a ".zip" extension:
(2) for /f "tokens=3,5 delims=\:," %A in ('type drives.txt ^| find /I "\\DosDevices\\" ^| sort') do if 0x%%~B lss 0x60 dir %A:*.* /s /b *.zip >> zipfiles.txt
Unzip them all to subdirectories within the local directory:
(3) for /f "tokens=1 delims=" %A in ('type zipfiles.txt') do "C:\Program Files\WinZip\wzunzip" -e –ybc –ye "%A" ".\"
Make a list of .zip files that were embedded within other .zip files:
(4) dir /s /b *.zip > zipfiles.txt
Unzip them to subdirectories within the directories where they're currently stored:
(5) for /f "tokens=1 delims=" %A in ('type zipfiles.txt') do "C:\Program Files\WinZip\wzunzip" -e –ybc –ye "%A"
Steps (4) and (5) could be repeated several times to get at deeply nested ..zip files. A very similar procedure could easily take care of .rar's, .bz2's, and similar files that may exist.
G) "LostArk.txt" could have been deleted (residing in unallocated space). There are several different tools available to try to recover files that have been "lost" on the hard drive. Unfortunately, I don't have enough experience with them to recommend one. I'm sure that the digital forensics expert, New Jersey Jack, would know much better than I would which tools to use.
H) On the same note, the file could be hidden in slack space or in blocks that are marked bad. Similar forensics tools could be used to investigate this possibility.
I) WINIAC could have a root kit installed that prevents "LostArk.txt" from being seen from remote locations. If he was allowed, Jersey could boot WINIAC from a CD and run some tests on the hard drive to see if it is still a kosher Windows install. Unfortunately for the attacker, if the root kit is any good and if it's set up properly, it would be very difficult for him to detect remotely. Fortunately for the IT community at large, Win2003 root kits are pretty hard to come by.
J) "LostArk.txt" could be on a hard drive on WINIAC that is not mapped to a drive letter. In this case, the drive should still show up under the Device Manager. If there's an unmapped drive there, the attacker or Jersey should be able to mount it and search just like any other.
K) "LostArk.txt" could be on a partition type or file system that is not supported under Windows 2003. If that is the case, the attacker would have to go to some degree of difficulty to get access to it (although it's probably not impossible). Jersey, however, could easily reboot the computer into another OS and then proceed with his search.
L) "LostArk.txt" could be embedded in an image or audio file. Extracting it would mean trying many different steganography software packages that all embed the data in different ways. Unfortunately for the attacker, many of these software packages encrypt the data prior to embedding it. Once again, key-less decryption is left as an exercise for the reader.
M) There are certainly many more (nearly an unlimited number) of ways to hide data. However, I think that this response is already long-winded enough - I'm signing off. Good luck, Jersey, stop them Nazis!
-gnick
**************************************************************************************************
It's a good thing Jersey was quick! Fortunately for him, since the attacker was going through the trouble of reading the physical memory of WINIAC just before he got caught, his previous searches probably didn't give him what he was after. Let's just hope that Jersey's Fedora isn't so tight that he can't think his way through this!
1) What was the purpose of the attacker's "dir" and "find" commands?
This "dir" and "find" commands are trying to locate any accessible file on the C: drive with the term "LostArk" in the file name.
dir c:*.* /a:hsr-h-s-r /S > file.txt
This is a very strangely structured "dir" command. If the Attribute (/a) option had been called thusly: "/a:hsr" or thusly: "/a:-h-s-rhsr", then it would have shown only the files with the "Hidden", "Read-only", and "System" tags set. However, the current configuration: "/a:hsr-h-s-r" seems to be intended to list only files with none of those three flags set. I believe that using "/a:-h-s-r" would give identical results. I see four possible reasons that the malicious Neo-Nazi might have structured the command this way:
a) He's intentionally being confusing and added the redundant "hsr" just to keep Jersey guessing.
b) He's doing something terribly clever and has out-witted me.
c) "dir" works differently on the 1936 release of Windows 2003 Server than it does under other Windows versions and DOS. (I have never had a chance to play on a Win2003 box, so this is a real possibility…)
d) His shaved head has allowed the sun to bake his brain and he didn't realize that the "hsr" would be overridden by the " -h-s-r". (Baked Brain Syndrome or BBS is a common problem for baldies.)
The rest of the "dir" command is very straight-forward:
"c:*.*" – List all files on the C: that I'm allowed to see
"/S" – Search all subdirectories that I have access to recursively
"> file.txt" – Write the results to the file "file.txt"
find /N "LostArk" file.txt
The " find" command is pretty simple. It just tells the OS to search the file "file.txt" for any occurrence of the string "LostArk" and include the line number every time it reports a success. Most likely, the attacker will just be sitting back and watching the output so that he can browse through "file.txt" to the returned line numbers and find out which directory the suspected files are stored under.
2) What was the purpose of the attacker's "strings" command?
strings –s –a c:\ | find "9906753"
The "strings" command here will scan through all accessible files on the C: drive and extract any character strings that it can find (That will most likely take a good long time if this is a large server.) The "-a" flag tells "strings " to search the entire file rather than just the data section. [Actually, the -a flag is to specify ASCII... Ed.] Parsing the output through "find" will filter out all strings that do not contain "9906753". [Actually, it locates all strings that contain this number... Ed.] Piping the output through "grep" instead of "find" would probably have been much more useful, since the attacker could have easily viewed the lines of text surrounding the string in question and report the specific file in which the string is found. But, we's in Windows, so we works with what we gots.
3) What was the purpose of the attacker's "lads" command?
lads c:\ /S | find "LostArk"
This command searches the entire C: drive for any available alternate data streams and then searches them for "LostArk". [Actually, it just looks for files that have the string "LostArk" in their name...Ed.] Under NTFS, all files have at least two data streams [Actually, they don't... they usually have just one, but can have an arbitrary number of additional ones if someone or some application tucks data inside a stream... Ed.] . The first contains security information, permissions, etc. The second contains the normal file information. The third, forth, etc. could contain just about anything. Lads is a handy little tool that detects these data streams. The " /S" option tells "lads" to include subdirectories – It is similar to the "/S" option for "dir".
4) What was the purpose of the attacker's "dd" command?
dd if=\\.\PhysicalMemory conv=noerror
This is a handy way to use "dd" under Windows (although it would probably be easier to use an output file using "of=" than try to parse through this information on stdout). All this command does is dump what is currently in the computer's memory bit-for-bit to stdout. The "conv=noerror" means that "dd " should keep working even if it encounters a read error.
5) Where else might the file be hidden on the system, and how would the attacker (as well as New Jersey Jones) find it? Be creative!
A) The most obvious. The file could be on the D: drive (or any other drive for that matter). Our nasty Nazi searched only the C: drive for the file(s) he wanted. Either he or Jersey could easily expand the search by wrapping the same commands in a FOR loop. The replacement for the " dir" command would look something like this:
Grab a list of mounted devices from the registry:
(0) regedit /e "drives.txt" "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices"
Wipe out any existing file called "file.txt":
(1) del file.txt
For each mounted device, list all accessible files and directories in "file.txt":
(2) for /f "tokens=3,5 delims=\:," %A in ('type "drives.txt" ^| find /I "\\DosDevices\\" ^| sort') do if 0x%%~B lss 0x60 dir %A:\*.* /S >> file.txt
I have tested the commands above under Win2k and am just assuming that they work under 2003 Server. If not, the following would do essentially the same thing, but it's not nearly as graceful and would search mapped as well as local drives:
Wipe out any existing file called "file.txt":
(0) del file.txt
Try to take a recursive directory listing of each potential drive letter:
(1) for %A in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO dir %A:\*.* /S >> file.txt
A similar wrapper could be applied for the "strings" and "lads" searches for similar results.
B) The file could have either the "hidden", "read-only", or "system" flag set. I believe that the attacker's "dir" command would overlook these files. Restructuring that command like I described in question (1) would be the simplest of several methods that could solve this issue.
C) The file could be stored in a directory that the attacker does not have access to. Assuming that he has Administrative privileges, it would be pretty easy to reset security permissions on each of the drives and force the child directories to propagate inheritable permissions. This would leave a pretty obvious trail of what the attacker was up to that would be inconvenient to erase, but I think that the attacker has already demonstrated that subtlety is not his primary concern.
D) "LostArk.txt" could be encrypted. Bypassing this minor hurdle is left as an exercise for the reader.
E) "LostArk.txt" could have been copied line-by-line into registry keys and stored in the registry. To check, Jersey could try the following:
Dump the entire registry to a .txt file:
(0) regedit /e "reg.txt"
Search it for the strings that we know it contains:
(1) find /n "9906753" reg.txt
(2) find /n "Ark of the Covenant" reg.txt
F) "LostArk.txt" could be compressed as part of a .zip file. A rough search could be done like this (assuming WinZip's command-line tools are installed to the default directory):
Dump a list of mounted drives:
(0) regedit /e "drives.txt" "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices"
Wipe out any existing file called "zipfiles.txt":
(1) del zipfiles.txt
Find any accessible files with a ".zip" extension:
(2) for /f "tokens=3,5 delims=\:," %A in ('type drives.txt ^| find /I "\\DosDevices\\" ^| sort') do if 0x%%~B lss 0x60 dir %A:*.* /s /b *.zip >> zipfiles.txt
Unzip them all to subdirectories within the local directory:
(3) for /f "tokens=1 delims=" %A in ('type zipfiles.txt') do "C:\Program Files\WinZip\wzunzip" -e –ybc –ye "%A" ".\"
Make a list of .zip files that were embedded within other .zip files:
(4) dir /s /b *.zip > zipfiles.txt
Unzip them to subdirectories within the directories where they're currently stored:
(5) for /f "tokens=1 delims=" %A in ('type zipfiles.txt') do "C:\Program Files\WinZip\wzunzip" -e –ybc –ye "%A"
Steps (4) and (5) could be repeated several times to get at deeply nested ..zip files. A very similar procedure could easily take care of .rar's, .bz2's, and similar files that may exist.
G) "LostArk.txt" could have been deleted (residing in unallocated space). There are several different tools available to try to recover files that have been "lost" on the hard drive. Unfortunately, I don't have enough experience with them to recommend one. I'm sure that the digital forensics expert, New Jersey Jack, would know much better than I would which tools to use.
H) On the same note, the file could be hidden in slack space or in blocks that are marked bad. Similar forensics tools could be used to investigate this possibility.
I) WINIAC could have a root kit installed that prevents "LostArk.txt" from being seen from remote locations. If he was allowed, Jersey could boot WINIAC from a CD and run some tests on the hard drive to see if it is still a kosher Windows install. Unfortunately for the attacker, if the root kit is any good and if it's set up properly, it would be very difficult for him to detect remotely. Fortunately for the IT community at large, Win2003 root kits are pretty hard to come by.
J) "LostArk.txt" could be on a hard drive on WINIAC that is not mapped to a drive letter. In this case, the drive should still show up under the Device Manager. If there's an unmapped drive there, the attacker or Jersey should be able to mount it and search just like any other.
K) "LostArk.txt" could be on a partition type or file system that is not supported under Windows 2003. If that is the case, the attacker would have to go to some degree of difficulty to get access to it (although it's probably not impossible). Jersey, however, could easily reboot the computer into another OS and then proceed with his search.
L) "LostArk.txt" could be embedded in an image or audio file. Extracting it would mean trying many different steganography software packages that all embed the data in different ways. Unfortunately for the attacker, many of these software packages encrypt the data prior to embedding it. Once again, key-less decryption is left as an exercise for the reader.
M) There are certainly many more (nearly an unlimited number) of ways to hide data. However, I think that this response is already long-winded enough - I'm signing off. Good luck, Jersey, stop them Nazis!
-gnick
