HOLA 5
Hackers of the Lost Ark Winning Answers
By: Jay Swofford
The facts we have to work with:
A) The crate number of the Ark is 9906753
B) A record of this crate number and storage information is found on WINIAC
C) The record is in a file by the name of "LostArk.txt"
D) WINIAC runs the original Windows 2003 operating system
E) The text strings "Ark of the Covenant" and "9906753" occur inside the text file LostArk.txt
F) The commands the attacker used, in order, were:
dir c:*.* /a:hsr-h-s-r /S > file.txt
find /N "LostArk" file.txt
strings -s -a c:\ | find "9906753"
lads c:\ /S | find "LostArk"
dd if=\\.\PhysicalMemory conv=noerror
cls
echo Please Buy Ed's Malware Book!
G) The attacker's working directory is the root directory of the C drive. (The prompt is C:\> and the attacker never issued a change directory command).
1) What was the purpose of the attacker's "dir" and "find" commands?
Dir Command:
dir c:*.* /a:hsr-h-s-r /S > file.txt
Dir is the DOS command for displaying a directory structure. The c:*.* tells the dir command to display files of any name. The /a:hsr-h-s-r tells the dir command to display files with the attributes of hidden (h), not hidden (-h), system (s), not system (-s), read-only (r), and not read-only (-r). The /S tells the dir command to recurse all subdirectories. Last the attacker took the output of this complex command and redirected it to file.txt, creating the file from scratch (>).
However, actual testing of the command shows that it does not behave in the expected manner. On an actual Windows 2003 system, I received the following outputs (without recursing and not listing directories):
What is actually in the directory with attributes:
autoexec.bat HS
boot.ini HS
config.sys HS
file.txt -
io.sys RHS
msdos.sys RHS
ntdetect.com RHS
ntldr RHS
pagefile.sys HS
dir c:*.*
autoexec.bat
config.sys
file.txt
dir c:*.* /a:h
boot.ini
io.sys
msdos.sys
ntdetect.com
ntldr
pagefile.sys
dir c:*.* /a:s
boot.ini
io.sys
msdos.sys
ntdetect.com
ntldr
pagefile.sys
dir c:*.* /a:s
io.sys
msdos.sys
ntdetect.com
ntldr
dir c:*.* /a:-h
autoexec.bat
config.sys
file.txt
dir c:*.* /a:-s
autoexec.bat
config.sys
file.txt
dir c:*.* /a:-r
autoexec.bat
boot.ini
config.sys
file.txt
pagefile.sys
dir c:*.* /a:hsr-h-s-r
autoexec.bat
config.sys
file.txt
dir c:*.* /a:-h-s-r
autoexec.bat
config.sys
file.txt
Note that the command run by the attacker did not return the expected output of all files, but the output of just those files who were not hidden, read only, or system. This is because of a "feature" of the dir command that each attribute can be listed just once (on or off) and the last one listed is the one that takes effect. The attacker should have run the following commands:
dir c:*.* /a:hsr /S > file.txt
dir c:*.* /a:-h-s-r /S >> file.txt
Note that the second command appends the output to the file, preserving the output of the first command. The attackers file.txt does _not_ include files that are hidden, read-only or system!!!!
Find Command:
find /N "LostArk" file.txt
The find command is used to search for text strings within a file. The /N will return the line number that matches the given string. So here the attacker is trying to print to screen any filenames or directory names, that include the string "LostArk" along with the line number in file.txt. The attacker will not get the path to the file in question, as they did not use the /B switch when running the dir command to create the file. The /B would have used the "bare" format of just a filename with full path (no summaries or file data).
2) What was the purpose of the attacker's "strings" command?
Strings Command:
strings -s -a c:\ | find "9906753"
The strings command is part of the bin utils at GNU.org. The strings command displays printable strings within a file. However, this is not the GNU.org version as that version does not support a -s option. The SysInternals strings.exe (http://www.sysinternals.com/files/strings.zip) command does however. So we must assume that the attacker is using this version. In that version the -s option causes the strings command to recurse subdirectories. The -a option causes it to print out ascii strings only. This is another mistake by the attacker that they did not print unicode strings. This again may cause them to miss the real file. They then pipe the output of this command to the input of the find command. This will print to screen all files that contain the ascii string "9906753". Specifically it prints:
path\filename: matchinglinewithinfile
3) What was the purpose of the attacker's "lads" command?
Lads Command:
lads c:\ /S | find "LostArk"
Lads is produced by Heysoft.de (http://www.heysoft.de/nt/ep-lads.htm). It lists all alternate data streams within the NTFS volume. This command when piped to the find command, will show all files with a name or alternate data stream name containing the string "LostArk".
4) What was the purpose of the attacker's "dd" command?
DD Command:
dd if=\\.\PhysicalMemory conv=noerror
There are a number of dd utilities for Windows. I will assume that the attacker is using the version produced by G. M. Garner, Copyright 2002. The command as shown will dump the raw output of RAM memory to screen and will continue even if errors occur. However, we must realize that we are probably not seeing the entire command. The command history buffer display in Windows 2003 truncates the commands at the window edge. Therefore, there could be an output file (of=filename) specified. Or, even better, the output could be piped to a strings command which is would then be piped to a find command which is then redirected to an output file.
For instance:
dd if=\\.\PhysicalMemory conv=noerror of=ram.img
OR
dd if=\\.\PhysicalMemory conv=noerror | strings -a | find "9906753" > number.txt
OR
dd if=\\.\PhysicalMemory conv=noerror | strings -a | find "LostArk" > name.txt
All three of these commands would display the same in the buffer history window.
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!
There are a number of places:
1. It could be in unicode, thereby not being detected by the strings command used by the attacker. Use the "strings -s -u" command in step 2.
2. It could be in hidden, system or read-only files, inadvertently missed via the dir error made by the attacker. Run step 1 twice, as noted above, to capture these files into file.txt.
3. If the hard drive has been reformatted, it could like in the inter-partition gaps on the physical drive. Use dd to capture an image of the hard drive. This can be done by printing it standard out and piping it to a strings/find command sequence, or by piping it to a netcat pipe to a remote system. Then analyze the hard drive image. (dd.exe if=\\.\C: | strings "LostArk" OR dd.exe if=\\.\C: | nc.exe <IP> <PORT>)
4. It could be in slack space (RAM slack does not exist in Windows XP and 2003 so it won't be there). This will also be found by the method in item 3.
5. It could be inside the Master File Table if the file is small (only files too large for the 1024 byte MFT record are stored outside the MFT. This will also be found by the method in item 3.
6. It could be in the swap file, which was not searched by these tools as it was currently in use. This will also be found by the method in item 3.
7. It could be stored as a blob or text field within a binary database structure or similar. Search the drive for database software or file formats.
8. There could be multiple partitions or drives on this disk. It could simply be on the D: drive. Run "net share" to find admin shares for each physical drive and then repeat all commands on each drive. Or run fdisk to view the configured partitions as they may not be NTFS and therefore would not show under the "net share" output.
9. It could be in unused sectors of the hard drive. This will also be found by the method in item 3.
10. It could be in the recycle bin. Examine the recycle bin of each user.
11. It could be in a compressed file. Check for EFS volumes, .zip files, and other compressed file types.
12. It could also be in stego hidden within an image, so use stego software to detect hidden data within images.
13. Look for PGP encrypted disks or files.
There are literally thousands of ways to hide data on the disk. But since this is a US Government computer it is probably already found by our attacker as it probably was a plain text file in the root of C:!
A) The crate number of the Ark is 9906753
B) A record of this crate number and storage information is found on WINIAC
C) The record is in a file by the name of "LostArk.txt"
D) WINIAC runs the original Windows 2003 operating system
E) The text strings "Ark of the Covenant" and "9906753" occur inside the text file LostArk.txt
F) The commands the attacker used, in order, were:
dir c:*.* /a:hsr-h-s-r /S > file.txt
find /N "LostArk" file.txt
strings -s -a c:\ | find "9906753"
lads c:\ /S | find "LostArk"
dd if=\\.\PhysicalMemory conv=noerror
cls
echo Please Buy Ed's Malware Book!
G) The attacker's working directory is the root directory of the C drive. (The prompt is C:\> and the attacker never issued a change directory command).
1) What was the purpose of the attacker's "dir" and "find" commands?
Dir Command:
dir c:*.* /a:hsr-h-s-r /S > file.txt
Dir is the DOS command for displaying a directory structure. The c:*.* tells the dir command to display files of any name. The /a:hsr-h-s-r tells the dir command to display files with the attributes of hidden (h), not hidden (-h), system (s), not system (-s), read-only (r), and not read-only (-r). The /S tells the dir command to recurse all subdirectories. Last the attacker took the output of this complex command and redirected it to file.txt, creating the file from scratch (>).
However, actual testing of the command shows that it does not behave in the expected manner. On an actual Windows 2003 system, I received the following outputs (without recursing and not listing directories):
What is actually in the directory with attributes:
autoexec.bat HS
boot.ini HS
config.sys HS
file.txt -
io.sys RHS
msdos.sys RHS
ntdetect.com RHS
ntldr RHS
pagefile.sys HS
dir c:*.*
autoexec.bat
config.sys
file.txt
dir c:*.* /a:h
boot.ini
io.sys
msdos.sys
ntdetect.com
ntldr
pagefile.sys
dir c:*.* /a:s
boot.ini
io.sys
msdos.sys
ntdetect.com
ntldr
pagefile.sys
dir c:*.* /a:s
io.sys
msdos.sys
ntdetect.com
ntldr
dir c:*.* /a:-h
autoexec.bat
config.sys
file.txt
dir c:*.* /a:-s
autoexec.bat
config.sys
file.txt
dir c:*.* /a:-r
autoexec.bat
boot.ini
config.sys
file.txt
pagefile.sys
dir c:*.* /a:hsr-h-s-r
autoexec.bat
config.sys
file.txt
dir c:*.* /a:-h-s-r
autoexec.bat
config.sys
file.txt
Note that the command run by the attacker did not return the expected output of all files, but the output of just those files who were not hidden, read only, or system. This is because of a "feature" of the dir command that each attribute can be listed just once (on or off) and the last one listed is the one that takes effect. The attacker should have run the following commands:
dir c:*.* /a:hsr /S > file.txt
dir c:*.* /a:-h-s-r /S >> file.txt
Note that the second command appends the output to the file, preserving the output of the first command. The attackers file.txt does _not_ include files that are hidden, read-only or system!!!!
Find Command:
find /N "LostArk" file.txt
The find command is used to search for text strings within a file. The /N will return the line number that matches the given string. So here the attacker is trying to print to screen any filenames or directory names, that include the string "LostArk" along with the line number in file.txt. The attacker will not get the path to the file in question, as they did not use the /B switch when running the dir command to create the file. The /B would have used the "bare" format of just a filename with full path (no summaries or file data).
2) What was the purpose of the attacker's "strings" command?
Strings Command:
strings -s -a c:\ | find "9906753"
The strings command is part of the bin utils at GNU.org. The strings command displays printable strings within a file. However, this is not the GNU.org version as that version does not support a -s option. The SysInternals strings.exe (http://www.sysinternals.com/files/strings.zip) command does however. So we must assume that the attacker is using this version. In that version the -s option causes the strings command to recurse subdirectories. The -a option causes it to print out ascii strings only. This is another mistake by the attacker that they did not print unicode strings. This again may cause them to miss the real file. They then pipe the output of this command to the input of the find command. This will print to screen all files that contain the ascii string "9906753". Specifically it prints:
path\filename: matchinglinewithinfile
3) What was the purpose of the attacker's "lads" command?
Lads Command:
lads c:\ /S | find "LostArk"
Lads is produced by Heysoft.de (http://www.heysoft.de/nt/ep-lads.htm). It lists all alternate data streams within the NTFS volume. This command when piped to the find command, will show all files with a name or alternate data stream name containing the string "LostArk".
4) What was the purpose of the attacker's "dd" command?
DD Command:
dd if=\\.\PhysicalMemory conv=noerror
There are a number of dd utilities for Windows. I will assume that the attacker is using the version produced by G. M. Garner, Copyright 2002. The command as shown will dump the raw output of RAM memory to screen and will continue even if errors occur. However, we must realize that we are probably not seeing the entire command. The command history buffer display in Windows 2003 truncates the commands at the window edge. Therefore, there could be an output file (of=filename) specified. Or, even better, the output could be piped to a strings command which is would then be piped to a find command which is then redirected to an output file.
For instance:
dd if=\\.\PhysicalMemory conv=noerror of=ram.img
OR
dd if=\\.\PhysicalMemory conv=noerror | strings -a | find "9906753" > number.txt
OR
dd if=\\.\PhysicalMemory conv=noerror | strings -a | find "LostArk" > name.txt
All three of these commands would display the same in the buffer history window.
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!
There are a number of places:
1. It could be in unicode, thereby not being detected by the strings command used by the attacker. Use the "strings -s -u" command in step 2.
2. It could be in hidden, system or read-only files, inadvertently missed via the dir error made by the attacker. Run step 1 twice, as noted above, to capture these files into file.txt.
3. If the hard drive has been reformatted, it could like in the inter-partition gaps on the physical drive. Use dd to capture an image of the hard drive. This can be done by printing it standard out and piping it to a strings/find command sequence, or by piping it to a netcat pipe to a remote system. Then analyze the hard drive image. (dd.exe if=\\.\C: | strings "LostArk" OR dd.exe if=\\.\C: | nc.exe <IP> <PORT>)
4. It could be in slack space (RAM slack does not exist in Windows XP and 2003 so it won't be there). This will also be found by the method in item 3.
5. It could be inside the Master File Table if the file is small (only files too large for the 1024 byte MFT record are stored outside the MFT. This will also be found by the method in item 3.
6. It could be in the swap file, which was not searched by these tools as it was currently in use. This will also be found by the method in item 3.
7. It could be stored as a blob or text field within a binary database structure or similar. Search the drive for database software or file formats.
8. There could be multiple partitions or drives on this disk. It could simply be on the D: drive. Run "net share" to find admin shares for each physical drive and then repeat all commands on each drive. Or run fdisk to view the configured partitions as they may not be NTFS and therefore would not show under the "net share" output.
9. It could be in unused sectors of the hard drive. This will also be found by the method in item 3.
10. It could be in the recycle bin. Examine the recycle bin of each user.
11. It could be in a compressed file. Check for EFS volumes, .zip files, and other compressed file types.
12. It could also be in stego hidden within an image, so use stego software to detect hidden data within images.
13. Look for PGP encrypted disks or files.
There are literally thousands of ways to hide data on the disk. But since this is a US Government computer it is probably already found by our attacker as it probably was a plain text file in the root of C:!
