Hackers of the Lost Ark Answers
Let's start out with the winners. We received many, many wonderful answers this time around. I promised I'd select three winners who would get a copy of my Malware book, but I've decided to pick six winners instead. Why did I choose six? Well, for two reasons.
First, I did it because I can. Nothin' wrong with that, right? Second, and perhaps more important, I did it because we got such good entries, and several of our winners have won a "Crack the Hacker" challenge before. That's no problem at all if you've won in the past. I don't like those contests where previous winners are not elligible to win again. I say... if you rock hard, continue to rock hard! We all benefit by learning from each other, so any winner of a "Crack the Hacker" challenge is more than invited to win again, and again, and again! But you've gotta be really, really good. So, because we had three winners that have rocked hard before, I added three additional winners, for a total of six. All of these entries were technically excellent, and win the big prize. Here they are, in no particular order:
Kenneth Mazie: Short and to-the-point answers are much appreciated. Great stuff.
John Tennyson: A solid, well-thought-out answer.
Kevin Shannon: The briefest of our winners, but focus and accuracy win the game.
gnick: Good analysis.
Jay Swofford: I love how you tear each problem apart systematically, and confirm your analysis by actually running the commands. That's the best way to see how things work -- pop open a command prompt and look at what *really* happens.
David Perez: Your detailed analysis showed great insight. Reading it was a pleasure.
And now, here are my own answers to the challenge:
1) What was the purpose of the attacker's "dir" and "find" commands?
Clearly, the attacker is using dir to create a list of files present on the c:\ drive. The attacker runs dir with the /S flag to get a list of all files in all subdirectories, which he stores in the file called file.txt. The attacker then runs the find command against file.txt to search for the string "LostArk". The /N option in find will show the line number in the file, presumably so the attacker could open the file and find out where in the directory structure the sought-after file is located.
Now, the attacker could have done this far more easily, avoiding the "find" command altogether by using the /B flag with dir to print out the full directory of each file it displays. That way, the attacker could instantly see where the mysterious file is located.
So, that was the attacker's general plan, and how it could have been optimized. But, there was some additional complexity lurking under the sheets with those darn attributes! Who would have thought the simple "dir" command could be so confusing? That's Windows for you! Let's take a closer gander at the "/a:hsr-h-s-r" stuff.
First off, the "/a:" flag is used to make dir display files with special attributes. The "hsr" stands for "hidden", "system" and "read-only" files, respectively. When prefixed with a minus sign "-", a user can omit files with these attributes from the output.
Seems simple enough, doesn't it? Well… it isn't!
As it turns out, when using dir with multiple attributes, the search isn't an "or" operation. That is, "dir /a:hsr" DOES NOT show files with the hidden, system, or read-only attribute. Instead, "dir /a:hsr" is an "and" operation, meaning show me only the items that have the hidden, system, and read-only attributes all set at the same time. So, with just the "hsr" notation, the attacker is looking for very rare files indeed!
But, it gets even uglier. When an attribute list for dir includes elements with a "-", that means I want files without those attributes (i.e., "/a:-h" means show me all files that aren't hidden). But, here's the rub… if there are conflicting attributes in the list (such as an "h" and a "-h"), the latter ones in the list override the earlier ones. Doh!
So, the attacker is saying he wants all files that are hidden, system, and read only, but then says that he wants none of those attributes. Putting that all together, the attacker will only see files that don't have the hidden, system, and read-only attributes. In other words, the "/a:hsr-h-s-r" ends up omitting all of those special file types for the attacker, and the dir command just yields a list of regular files.
To help make this murky dir behavior more clear, consider this scenario. I created four text files in a directory called c:\temp\test. I've set specific attributes to these files, as follows:
• hidden.txt has the hidden attribute
• plain.txt is just a plain file (no special attributes)
• read-only.txt has the read-only attribute
• system.txt has the system file attribute
Look at the results of these commands in the figure below.
Yikes! So, the attacker's mistake is now apparent… the "/a:hsr-h-s-r" effectively cancels most of itself out, thereby showing the attacker only those files without the hidden, system, or read-only attributes. In other words, the bad guy is only searching for some of the files, and not all of them!
A handful of our contest entries discovered this treachery. Kudos to those bright folks who figured it all out. : )
Now, you might be wondering whether I expected everyone to know about these subtleties of dir... actually, no. However, when presented with some forensics evidence, it's sometimes useful to recreate the attacker's actions on a separate test system, just to see what he was up to. For this challenge, you could have figured this out by popping up a cmd.exe and trying out the dir command just like the attacker did. That's what I was hoping you'd do, and many of our winners did just that.
2) What was the purpose of the attacker's "strings" command?
As many of you pointed out, the strings command isn't built into Windows, so the attacker was clearly using a version he or someone else had uploaded. The syntax of this strings command conforms to the Sysinternals version, written by Mark Russinovich, available here . This very handy program searches through files for sequences of textual strings. The purpose of this command was to search through all files in all subdirectories (the –s flag) for an ASCII string (the –a flag). The output was dumped to the find command to look for "9906753", the number stenciled on the Ark's crate.
Several of you rightly pointed out that the –a flag will force the strings command to ignore Unicode strings, making it focus on only ASCII. That's absolutely correct. With the Sysinternal strings, you get to choose whether you want to search for ASCII or Unicode, but not both at the same time. To search for both, you'd have to run strings twice, once with the –a flag, and once without it.
3) What was the purpose of the attacker's "lads" command?
Like strings, the LADS command is not built in to Windows. The attacker or a system administrator must have loaded it on the machine. This command, whose name is an acronym for "List Alternate Data Streams", was written by Frank Heyne, and is available here. The tool searches for alternate data streams hidden underneath existing Windows files and directories. Alternate data streams represent an entire subterranean world underneath an NTFS partition, where data can be hidden so that no built-in Windows command or tool can find it! Instead, we have to rely on third-party tools like LADS to search for it.
The attacker is using LADS to search through the c:\ drive and all subdirectories (the /S flag), piping his results through the find command to identify files with the string "LostArk" in their stream name.
Also, just as Windows has no built-in commands to find alternate data streams, it also lacks a capability for deleting such streams as well. To bridge this gap, Mark Russinovich has released a nifty tool called "streams" here that can be used to search for and, most importantly, to delete streams. That's cool. LADS cannot delete streams; it can only list them.
4) What was the purpose of the attacker's "dd" command?
One aspect of this question stumped a few of you… The dd command creates a copy of a drive partition, or, as it is used here, to make a dump of the system's physical memory (the input file directive does that, as in if=\\.\PhysicalMemory). This syntax conforms to the Windows dd version released here by George M. Garner, Jr. As with many of the earlier commands used by the attacker, dd is likewise not included in Windows by default, and must have been loaded separately. This command is immensely useful in creating images for digital forensics analysis, and I recommend that you carry a copy around on a CD in case you ever need to create a drive backup or memory dump for analysis!
The conv=noerror directive tells dd that it should keep on running even if it encounters an error. In particular, when dumping memory, dd sometimes encounters a spot of memory that it cannot read, because it doesn't have the proper permissions. If you run dd without conv=noerror, it will give up when it reaches this condition. Abandoning the search at an error makes dd omit from your analysis all other areas of memory not yet searched, just because of one stinking little error.
Now, the dd evidence that you saw on WINIAC's screen wasn't all that useful by itself. With just the "if" and "conv" settings, dd would have dumped the entire contents of physical memory to standard output, giving the attacker a jumbled mess on the screen, as well as ringing the system bell when various terminal characters associated with beeping are encountered. That's pretty yucky and not terribly useful.
But, the attacker's command didn't end there! Unfortunately, hitting F7 in a cmd.exe window only shows by default the first thirty-six characters of each command typed by the attacker. So, you are looking at only the first part of the dd command syntax used by the bad guy. The rest of the command isn't shown with F7, but did actually include the of= syntax, to dump physical memory into a file, suitable for searching by the attacker.
To get the full syntax of the commands typed by an attacker, New Jersey Jones could have run the "doskey /history" command instead of hitting F7. However, in my own forensics analyses, I like to hit a simple F7 and get a screen shot of the most recent commands using a digital camera. That way, I don't actually have to run any commands on the machine to get a feel for what the bad guy was up to. After getting my photo of the most recent commands shown by F7, I back up the system for digital forensics analysis (thanks, dd!) and then explore the system in more detail.
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!
Now, this one was a wide-open question for you folks to ponder. We got dozens of cool, amazing answers here. Check out our winners' entries above for some of these nifty ideas.
So, that's it for this month. Thanks to everyone for playing, and to Infosec Writers for hosting our challenge.
Stay tuned for next months' challenge... A Phish Called Wanda!
--Ed Skoudis
July 4, 2004
