Webcheck.dll

I saw via Twitter today that a new post had gone up on the TrustWave SpiderLabs Anterior blog, regarding some malware that the TW folks (by that, I mean Chris Pogue) had detected during some engagements.

I think it's great when analysts and organizations share this kind of information, so that the rest of us can see what others are seeing.  So, a big thanks goes out to TrustWave, and the next time you see Chris at a conference, be sure to say hi and buy him a beer...or better yet, treat him some bread pudding! 


What I'd like to do is take a moment to go through the post and discuss some things that might add something of a different perspective or view to the issue, or perhaps something .

As you can see from the post, Chris uses timeline analysis to locate the malware in question, and he's got some really good information in the post about creating the timeline for analysis (Chris uses the log2timeline tools).  I'm sure that there's quite a bit about the engagement and the analysis that weren't mentioned in the post, as Chris jumps right to the target date within his timeline and locates the malware.

I like the fact that Chris uses multiple analysis techniques to corroborate and check his findings.  For example, in the post, Chris mentions looking at the file's $STANDARD_INFORMATION and $FILE_NAME attributes in the MFT, and confirming that there were no indications of "time stomping" going on.  This is a great example that demonstrates that anti-forensics techniques target the analyst and their training, and that a knowledgeable analyst isn't slowed down by these techniques.  I think that the post also demonstrates how timelines can be used to add context to what you're looking at, as well as increase the level of confidence that the analyst has in that data.

One of the things that kind of struck me as odd in the post is that there's mention of the "regedit/1" entry in the RunMRU key, and then the post jumps right to discussing the InProcServer32 key, based on the timeline.  The RunMRU information (ie, key LastWrite time) is from a user's hive, so another key of interest to check might be the following:

Software\Microsoft\Windows\CurrentVersion\Applets\Regedit

As you'd think, this key contains information about the key that had focus when the user closed RegEdit.  Specifically, the LastKey value (mentioned in MS KB 244004) contains the name of that key.  This value might be used to make a bit of a transition between the RunMRU data and the changes to the InProcServer32 key that's mentioned in the post, and possible provide insight into how the malware was actually deployed on the system. 

As Chris points out in the post, the value type being changed from "REG_SZ" (string value) to "REG_EXPAND_SZ" does allow for the use of unexpanded references to environment variables, such as %SystemRoot%.  One statement that I don't really follow is:

So now the threading for webcheck.dll is no longer pointing to the legitimate file, but to the malware!

The threading model listed doesn't have anything to do with the path...I'm going to have to reach to Chris and find out what he was referring to in that statement.  He follows that up with this statement later in the post:

So not only did the attackers use a legitimate threading, but they made sure to use a shell extension that was trusted by Windows.

Again, I'm not clear on the "threading" part of that statement, but Chris is quite correct about the shell extension issue.  Basically, the Windows shell (Explorer.exe), which is launched when a user logs into the system, will load the approved shell extensions, which includes this particular malware.  Trust seems to be implicit, as there are no checks run when Explorer goes to load a shell extension DLL.  This is a bit different from the shell extension issue I'd mentioned last August, in part because it doesn't use the DLL Search Order issue.  Instead, it simply points Explorer directly to the malware through the use of an explicit path.

All in all, I'm glad to see that Chris and the TrustWave folks sharing this kind of thing with the community.  I do think that there's more that isn't being said, like how the malware actually got on the system (ie, how it was deployed), but hey, we all know that there are some things that can't be said about engagements.  And that's okay.

Book Review: Malware Analyst's Cookbook

Michael Hale Ligh was kind enough to provide me with a review copy of a book he recently co-authored along with Steven Adair, Blake Hartstein, and Matthew Richard, titled Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code. The book was an excellent read, and is an extremely valuable resource for any analyst in this industry.

First off, I am not a malware reverse engineer. Yes, I do have some experience working with malware, but not to the level that reverse engineers (RE) such as the authors tend to operate. I work with some really smart folks who do malware reverse engineering all the time, and they're very, very good at it. As such, during IR or digital forensics analysis, I tend to exchange information with the RE folks, providing what I've found and then taking what they find, and performing iterative analysis. I've found over time that this approach provides a much more in-depth analysis than the sum of it's parts.

That being said, weighing in at a hefty 18 chapters, the Cookbook covers a wide range of topics specific to reverse engineering and analyzing malware, from anonymizing your research activities to honeypots to malware classification and automated analysis and beyond. Throughout the book, the authors present "recipes" for using various tools (many of which are open-source) to solve specific problems. For example, chapter 3 includes several recipes involving YARA, an open-source, Python-based tool for identifying and classifying malware. Many other popular tools are also used, including ssdeep, Didier's PDF tools, and even RegRipper. Chapter 15 goes discusses effectively using Volatility for memory analysis. Many of the examples provided in the book are based on the real-world experiences of the authors, lending considerable credence and value to the demonstrated skills and information imparted.

Chapter 10 is near and dear to my heart, not only due to the discussion of ADSs, but also due the fact that the authors wrote their own RegRipper plugins! That's right! These guys found some things of value with RegRipper and wrote their own plugins. It brings a tear to my eye to think that my little tool is all grow'd up!

Some of the truly powerful aspects of the book include clear, thorough explanations of the presented topics, as well as easy-to-follow examples that allow the reader to follow along and learn by doing (I tend to learn more by doing than reading). Whether you're an aspiring reverse engineer, incident responder, or forensic analyst, this book will be an extremely valuable resource to you. For example, some of the explanations of how systems get infected with malware (JavaScripts, infectable document formats, HTML injection, etc.), as well as artifacts to indicate a malware infection, will prove extremely valuable to IR/DF folks. Heck, even if you're a somewhat-seasoned malware reverse engineer, it's likely that this Cookbook will show you some things that you haven't seen before, or show you some ways of looking at malware that you haven't thought of before.

Much of what's in the Cookbook goes beyond commercially available applications and clearly demonstrates the use of Python- (or Perl-) based open source tools that accomplish specific objectives. The cookbook even goes so far as to explain and demonstrate how different malware-related activities are performed, as well as how they can be detected.

I have to say that reading through the Cookbook gave me a new appreciation for what malware reverse engineers do. I also walk away from the book with a better understanding, not only of how to look for malware during IR/DF activities, but also how to better provide information and data to our reverse engineer once I've found it. I also walk away from it knowing that I'll be back. With more study and practice, I'm sure I can do some modicum of malware analysis beyond what I already do, and while I know that I'll never be at the level of the authors, I thank them for a truly exemplary and valuable resource. If I didn't already have it, this Cookbook would be on my Christmas wishlist...at the very top!

Infinite Malware & Infinite Protection?

Infinite detection of malware? In Sophos' blog entry "To infinity and beyond" it's pointed out that there's an infinite number of malware threats (and that there'll be more tomorrow). It's also implied that customers are protected against these infinite threats by infinite detection capabilities - which is obviously taking the theme in to some far-flung infinite parallel universe with infinitely better anti-virus solutions that we have in our particular reality.

Nevertheless, their perspective of infinite malware is quite correct. Given that malware can by dynamically generated (checkout the paper on x-morphic attack engines), exhibit polymorphic capabilities and is generally created faster than it can be counted, captured and cataloged, then for all intents and purposes it is infinite.

Which means I have to chuckle when I hear or read any media coverage about the number of malware a particular vendor has captured and written detection signatures for. It's like saying "look, I tripped over 2,543,234 pieces of malware around the world last year and developed protection of each of them". Then, with my mathematicians hat on... infinite threats minus 2,543,234discovered threats still leaves an infinite number of threats. Or, expressing detection coverage as a percentage of scale of the threat = zero percent.

Obviously that's not precisely true. Anti-virus technologies are generally OK at detecting the stuff they've seen before and with generic catch-all signatures they can often capture or label related families of malware as being malicious - or at the very least "suspicious". The problem tends to grow in to frustration when practically every binary file downloaded from the Internet gets marked as "suspicious" - and hence the label becomes meaningless.

Despite all this, Sophos is spot on - there's an intinite number of malware out there, and there'll be more tomorrow. Welcome to the day after yesterday.

Forgotten Password?

The increased proliferation of malware and botnet agents designed to rapidly intercept, retrieve and copy the passwords you use on a daily basis to access Internet resources likely means that it may be time to revisit many of those longtime-standing password policies. Given all the "best practice" guidelines I've seen over the years, I think that (in practical terms) they're increasingly missing the mark in defending against today's threat landscape.

One particular "best practice" that I think needs to be re-thunk... "don't write your password down."

I blogged a little more on the topic over on the Damballa site... It's safer to write your password down...

-------

Common wisdom over the last couple of decades has been to never write down the passwords you use for accessing networked services. But is now the time to begin writing them down? Threats are constantly evolving and perhaps it�s time to revisit one of the longest standing idioms of security � �never write a password down�.

Back in the day, a password was a critical part of the corporate identity system. You supplied your user ID and password pair in order to get online and to access key corporate resources. Access controls then extended the authentication model to enable greater control of what users could see, do and change. As new systems came online, and as business extended beyond the in-house corporate networks, additional (i.e. separate) authentication systems came in to play. Despite multiple attempts at developing and deploying single sign-on (SSO), most employees still need to juggle a dozen passwords in order to do their work. If they have external Internet accounts as well, then they�ll be juggling several dozen additional passwords. Once you thrown in their personal Internet accounts (webmail, Twitter, Facebook, LinkedIn, PayPal, Amazon, etc.) you�re quickly neck-deep in password soup.

Whats traditionally been the problem with writing down password anyway? Well, since passwords are the critical ingredient for access control, corporate security teams have long �educated� employees in to never writing them down. To do so would potentially expose yourself to impersonation � and you�d ultimately be responsible for whatever (damage) the impersonator did in your name.

In the meantime, Internet guides, popular PC magazines, and practically every website that forces you to create a login account, all extol the virtues of never writing your passwords down. They also give you lots of additional advice � such as �use a strong password�, �use a unique password�, �never use the same password on a different site�, etc. All of which make it incredibly difficult for any practically minded human to keep track of which password belongs to which website. The net result being that the �password rules� are being repeatedly broken.

Now, to ease some of this burden, there have been a spurt of software tools that�ll help remember passwords on your behalf. For example, the popular web browsers all provide some capability in this area. The problem though is that the bad guys have better tools. Practically all of today�s malware(along with all those botnets you hear about each day) have the built-in capabilities of grabbing/stealing both the passwords you�ve remembered and type in each time you visit a favorite website, and the passwords being conveniently �remembered� by the software on your computer.

Why would writing down a password be good? Well, it�s not a question of being good � just better. Granted, anything you type on your computer can (and will) be grabbed by the malware it�s been compromised with- but the lowest hanging fruit for the bad guys lies with all the stuff you�ve already asked your computer to remember on your behalf. After 3 months of use, web browser �remember� functions may have captured 50+ sets of authentication details. Within a few seconds of computer compromise, all three moths worth of stored credentials will have been copied and stolen (oh, and they�re neatly formatted and sorted) � so the malware doesn�t need to do any work, and it doesn�t matter if your anti-virus software gets an update tomorrow capable of detecting the malware and removing it. The damage is already done.

Staying hidden on a victims computer is not a trivial task for many malware � particularly wide-spread Internet malware (anythingwith a name you may have read about). There are lots of things that can go wrong. AV updates may detect the infection, dropper websites may be taken down, uploading sites may be sinkholed, CnC domains may be hijacked, etc. so it�s become important for modern malware to steal as much information as possible within the shortest possible time. Factors such as conveniently storing all your authentication details on your computer and recycling popular (i.e. memorable) passwords reduce the time the malware needs to be operating in order to steal critical data.

What about a few high-level odds?

• 1:3 � home PC being infected with malware with password stealing capabilities in a given year.
• 1:4 � home PC being infected with a botnet agent in a given year
• 1:8 � corporate PC being infected with malware with password stealing capabilities in a given year
• 1:12 � corporate PC being infected with a botnet agent in a given year
• 1:160 � your car being stolen in a given year
• 1:700 � your home being burgled
• 1:600,000 � being struck by lightning

I think it�s time to revisit the �never write a password down� idiom. Prioritizing best practices in password management, I�d be inclined to list them in the following order:

1. Don�t use the same password on multiple websites
2. Don�t let your computer �remember� your password!
3. Use a �strong� password � preferably something with 12+ mixed characters
4. Don�t use a predictable algorithm � e.g. abc123
5. Change your passwords regularly. For sites with lots of personal information and associated monies, change every 2-3 months. For other sites, try every 6-12 months.
6. Don�t reuse past passwords � even if you think it�s a cool password.
7. Don�t write your password down.

Yes, that�s right � writing down your passwords come in at a distant 7th place. In practical terms, even if you only manage the first 4 on the list, you�re probably going to be juggling at least a couple of dozen passwords (or more thank likely that�ll be 40+ on a regular basis for most people that spend any time online). The probability that your computer(s) will be compromised and that the information will be stolen by the bad guys malware is much, much greater than the probability that someone will manage to break in to your house and target all the post-it notes you�ve stuck around your screen with all your passwords on them. In corporate environments there�s a higher probability that the evening cleaning crew would gain visibility of he passwords (so post-it notes aren�t to be recommended), but that risk of an insider threat is still going to be lower than your work computer being compromised.

The first 6 password recommendations would trump the 7th in most cases � provided you take care in how and where you write your passwords down. Be smart about it� but don�t underestimate the risks posed by modern malware either.