Boston Key Party: Heath Street write-up

Problem intro:

During my time at KGB I learned how to hide all the stuff from alpha-dog. But damn it, I somehow lost some of the most important files… : 100

They provide what appears to be an ext3 file system image.  Just for grins and because its easy, I ran “foremost” (a file carving tool) to see what it would find.  It only found one file, a zip file.  And that is encrypted and we don’t know the password.  So that got me thinking that I would need to examine the file system for clues about the password.

I also ran “strings” on the disk just to see what would pop up, and it turns out there were a ton, and they mostly seemed to be notes about various spy agency goings-on.

Nothing jumped out as a password, so I started mining the strings from the image to try to guess the zip file password.  Of course, the password could be something that you’d have to read and figure out, or it could be something that isn’t an ASCII string, or it could be encoded in some way… so I gave up on that in favor of doing some more forensics work.

I decided to use a forensics suite called “dff” to do the work.  I really like dff.  In the course of examining the file system, there were obviously hundreds of files named “secret123”, “secret124” and so on.  Many contained short text strings (found above), some were empty, some were deleted.  I resigned myself to reading them, when I noticed a file named “.secretXXX” (I forget the actual name).  Two things were interesting about this.  The first is that its name starts with a period: in the Unix world that’s a signal that the file should be “invisible” by default.  This is often used to hide things (though its trivial to find them).  The other item of interest is that “dff” identified the file type as “KGB Archiver”.  I thought “wtf?!  how could dff know about a file type that appears to have been made up for this scenario?”  It wasn’t, of course: turns out this is an actual file compression program.

Downloaded it, installed it in a Windows VM, ran it on the file – the key was right there.

The encrypted zip file was a red herring…

An Incident Post-Mortem…

I thought it would be fun to post an abbreviated post-mortem we did on a compromised computer from a few years ago. I’ve tried to strike a balance on detail so that a variety of audiences could understand this, but I’m sure the more technical among you would like more details (ask me, I’ll share) and this abbreviated version might even be too detailed for others. My main reason for posting this is to talk about perspectives on compromised computers and anti-malware software, but we could also talk about forensic techniques, log analysis, timeline reconstruction and so on.  I think I’ll save the detailed forensic, log analysis, and timeline discussion for a later post.  

Let’s start with the results of the analysis, which you can find at Incident Analysis (shortest).  This is an abbreviated version of a timeline analysis of a compromised computer from a few years back – I’ve anonymized the data but kept the timestamps.   

In an investigation like this we typically construct a timeline composed of chronological data pulled from a variety of sources: file system metadata, log files from the affected system and other systems, network traffic logs and so on – anything that might be relevant that could help reconstruct the chronological history surrounding the event in question (this is what forensic specialists are calling a “super timeline” these days, we didn’t used to have a special name for it :-).  This original data might consist of millions of events (or more, sigh).  In this case I focused mostly on evidence from the local system and our IDS logs over a relatively short slice of time (a few hours).  When you make maple syrup you boil 40 gallons of sap to make a gallon of syrup.  In a similar fashion, when you do forensic timeline reconstruction you “boil” hundreds of thousands of events down to a few thousand events, and might even take it further – in this case this is the 3rd “boil” from my original set of events, and we’re down to what’s essentially hand written commentary about what I observed from the logs from the 2nd boil, as it were.   The “big picture” you should be looking for from the analysis I linked to above is that a computer got infected through vulnerable software, and this led to a cascade of malware being installed on the system.  Some of this malware was caught and stopped by the anti-malware software but most was not, and most importantly, the main downloader was not.  This ultimately led to the computer sending at large quantities of spam. One question that I wanted to address is the question of how we should view things when our anti-malware software blocks something bad.  I think its fairly common for people to think “good, my anti-malware software just saved me from that malware” and in some cases, that might be correct.  But I’ll make the following observations…

Anti-malware software doesn’t catch everything.  Anti-malware software on this computer obviously detected some things in this example but it completely missed others.  The miscreants know this, and actively seek to avoid detection.  Fresh malware is typically not detected by many anti-malware products, and it often takes days or weeks for the anti-malware vendors to start detecting it.

Just because your anti-malware product detected and blocked/cleaned/deleted/quarantined something doesn’t mean that you’re safe.  I think its best to regard anti-malware as a detection mechanism rather than as a preventative measure.  Yes, with luck, sometimes (most of the time?  some of the time?  rarely?) it will prevent malware from taking root on your machine.  But if it detects and blocks something how do you know whether it missed anything?  Did it catch the first stage downloader or some later stage?  If it missed the first-stage, what else did it miss?

I’m not arguing that anti-malware is useless.  Obviously some things were detected by anti-malware, and well before we noticed anything at the network level through network based intrusion detection.  I’m a belt-and-suspenders sort of security guy, I think its prudent to use multiple layers of detection/prevention.  Defense in depth, etc.  

Reinstallation is better than disinfecting.  Good luck cleaning up from something like this.  How would you know whether you got everything?  Granted in some cases its possible, but (a) how do you know you’ve gotten everything when you’re likely using the compromised system to investigate itself and do the fixing (go read Thompson’s “Reflections on Trusting Trust” 🙂 and (b) for the sake of “plain old” disaster recovery (disk failure, theft, building caught fire, etc) you probably should have some sort of capability for quickly restoring systems in the event of a disaster – and if you do you can probably restore a system quite quickly and painlessly.  If you’re disinfecting rather than reinstalling b/c reinstalling is too hard, I’d suggest that you need to work on your disaster recovery procedures.  Apart from ensuring that you’ve removed all of the malware, you also have to worry about the configuration changes that the malware might have made to the system – did you find and fix all of those?

The missing piece: finding the root cause(s) and fixing the exploitable vulnerability.  In this case the system had a vulnerable version of Adobe Reader installed and that this was used to perform the initial infection via malicious PDF files.  But I don’t think its common for people to do much of a root cause analysis on compromised computers – you frequently hear them talking about disinfecting or reinstalling them, but if no RCA is done and the initial point of entry is unknown, they’re just a target waiting to be infected again.  Was it a missing patched?  An old version of Java left behind when you updated it?  Was the computer user browsing the web using an account with administrative privileges?  Did they fall for a tech support phone scam? Find the exploitable vulnerability and fix it (and fix it on the other affected systems as well)!