Before getting started with those details, I have to credit Nitin and Vipin Kumar for posting details and source code for reading Bitlocker protected volumes [2]. Their work was invaluable when writing the original paper, and proved so again in this case.

First, in my paper I was incorrect when I stated the size of the Full Volume Encryption Key (FVEK) was always 512 bits. As Kumar and Kumar note, the size of the key varies based on the algorithm being used. The FVEK is 512 bits if either of the Elephant diffuser modes is used. But if they are being used, the key is the same size as the encryption strength. That is, when working in AES128 mode the FVEK is 128 bits, and when in AES256 mode, the FVEK is 256 bits.

Second, when the Elephant diffuser is not in use, each sector is encrypted and decrypted using AES in CBC mode with the initialization vector set to all zeros. The sector number has no impact on the encryption process. As a side note, the practical effect of this decision is that identical sectors will appear identical in both ciphertext and plaintext. Whether or not that's a practical advantage for an attacker is debatable, but my personal recommendation is to use one of the Elephant diffuser modes.

Third, my paper did not specify how Windows would deal with a BDE protected volume if the volume header becomes damaged. My current case involved such a damaged drive and I now have an idea of how Windows handles this situation: it doesn't. Neither BDE nor the repair-bde [3] program were able to make heads or tails of the volume. I had to write a custom program, “Scarlet,” which could decrypt the volume [4].

Finally, the changes in Bitlocker version two are documented in my presentation on BitLocker to go [5]. These include things like the new metadata format and passwords as volume protectors.

(Cross posted at: http://jessekornblum.livejournal.com/281123.html)

[1] Jesse Kornblum, Implementing BitLocker Drive Encryption for Forensic Analysis, Journal of Digital Investigation, 2009, (5)3,pp. 75-84. http://jessekornblum.com/publications/di09.html.
[2] Nitin and Vipin Kumar, Analysis of Window Vista Bitlocker Drive Encryption, http://nvlabs.in/
[3] Microsoft Corporation, How to use the BitLocker Repair Tool to help recover data from an encrypted volume in Windows Vista or in Windows Server 2008, 2010, http://support.microsoft.com/kb/928201.
[4] Why Scarlet? Because frankly, I don't give a damn how you get the keys, but you have to have the keys to decrypt the drive. Margaret Mitchell (novel) and Sidney Howard (screenplay), Gone with the Wind, Warner Brothers pictures, 1939.
[5] Jesse Kornblum, BitLocker to Go, DoD Cyber Crime Conference, 2010 http://jessekornblum.com/presentations/dodcc10-1.pdf.

I have a .doc file created with MS Office (not sure which version).  The original system is no longer available.  This file has changes (using the track changes feature) embedded in it.  The nature of the case is to determine the actual date when the data was originally entered.  I am able to see the changes that have been entered.

My question is: Can I determine the dates/times for which each change was made.

Speaketh the Guru:

If track changes was enabled, you should see the date and time of each change when the document is viewed. These timestamps are displayed by default in programs like Microsoft Word. Naturally, you would not see if any changes were made before track changes was turned on.

The .DOC file format is extremely complex. Details about the format are now public, but require a lot of effort to understand. To my knowledge the best .DOC parsers on the market, other than Office products, are the free and open source competitors to the Office suite. There are no forensics tools geared to parsing such documents that I am aware of, precisely because of their complexity. This is not to say that a parser could not be built, you would just have to weigh the value of what the document contains (or could prove/disprove) against the time and expense of building it.

Have a question for the Guru? Ask it now.

Our Role

Kyrus’ role in this effort was to reverse engineer binaries associated with Zeus activity and attempt to identify commonalities in said binaries. The work was broken down into two main phases.

Phase I. Microsoft provided us 70 binaries, five of which were PEs. Four of the five PE binaries were packed. We unpacked them and reconstructed the import tables for easy viewing in IDA Pro. One binary was not obfuscated and was used as a baseline for our comparison. It contained the following core functionality:

• HTTP communication capability
• Remote Process Injection.  Uses WriteProcessMemory to inject executable code into a remote process.  Generally this is either used by debuggers or malware.  Since this binary has no debugger functionality, we assume the reason for its inclusion is malicious.
• Screenshot Capability. Allows this application to save and send back screenshots to the server.  This allows an attacker to see what exactly is showing on the victim’s screen.
• VNC-Type Server Functionality.  Allows the attacker to control the mouse and keyboard of the victim’s computer.
• Keyboard Logging Capabilities.  Allows the attacker to send keystrokes to a server to get victim’s passwords that are typed into the keyboard.
• Browser Logging and HTTP injection capability.  Hooks nspr4.dll to allow logging and injection of HTTP and HTTPS data
• Windows mail download. Allows the attacker to view the victim’s email if the user uses Windows Mail or Outlook Express.
• Self-Delete using a bat file.

After using entry point analysis and Zynamics BinDiff on the unpacked versions of the binaries in question, we were able to conclude that all five binaries were compiled from the same code base, probably to help them evade common anti-virus products. At this point we asked ourselves two questions:

1. Are these binaries similar to Zeus, and if so, how similar?
2. Were these binaries compiled with a Microsoft toolchain, and what evidence supports this?

Were the structural similarities of our recovered binaries similar to Zeus? Fortunately, copies of the source code to Zeus have been made publicly available, so we compiled our own copy of Zeus and compared it to the aforementioned binaries.

Compare and Contrast

We compiled Zeus with symbols and compared it to the unpacked binary we were given with BinDiff. 703 named functions out of 895 total were matched by BinDiff. Of those 698 had a similarity rating of 1.00 and confidence value of 0.92 or greater. Exceedingly strong evidence that our samples are compiled versions of Zeus.

Next we searched for functions within our copy of Zeus that had a very low probability of being duplicated or copied by accident. We chose the screenshot logic, the API interception logic, and and VNC server implementation. In every case, there was an exact or extremely high match in the control flow graph between our copy of Zeus and the programs that we analyzed.

We then used the Interactive Disassembler (IDA) to find and extract control flow graphs from each of the applications we were given, as well as the copy of Zeus that we compiled. In each case the structure of functions within each program were identical.

The similarities we noticed suggested that it was highly likely that Microsoft compilers were used to build our suspect binaries. We built Zeus with a Microsoft compiler and noted that the code produced was identical to our suspicious samples.

We also performed a mechanized comparison of the structure of the control flow graphs in each of the five programs against the Zeus binary we built from source. We performed static control flow reconstructions from the program images, and then used a simple algorithm to discover and extract functions within the program and convert them into an intermediate format that could be analyzed withNetworkX. The NetworkX graphs showed that for the functions we identified in these binaries, almost all of them were structurally identical to functions within Zeus.

Finally, we used the industry standard 'fuzzy' hashing technique via the ssdeep program to compare the unpacked binaries. Three of the files we analyzed were found to have large stretches of identical patterns of bytes, giving us a high degree of confidence that these three files are essentially the same.

Phase II. Microsoft provided us with several hundred binaries that were known or suspected to be related to the SpyEye, ICE-IX, and PCRE Trojans. Of the binaries we were able to analyze (repeating the process noted above), each were highly similar to Zeus.

Why This Approach?

Combating cyber crime is a complicated affair. As with any sort-of “good” vs “evil” situation the latter have myriad advantages over the former, who have to operate within various constraints lest they themselves violate the law. Every case is a slow, tedious slog of both technical and legal grunt work. Despite the tens of billions of dollars that have been spent on cyber security recently just in the U.S. alone, events like those that occurred today are actually quite rare.

Yet it is precisely activities like this, and previous efforts led by Microsoft’s Digital Crimes Unit, that are more likely to produce positive results over the long term. Zeus and its ilk are platforms from which a wide range of malicious and illicit activity can be launched. Fighting the discrete activities launched from such a platform is like shooting down a plane launched from an aircraft carrier: they’re just going to send more planes. If you want to have an impact you need to negatively impact the carrier.

As long as cyber crime fighting efforts are focused on end-points, discrete incidents and the perpetrators of same, we will never impact the perpetrators of cyber crime on the same level as they impact innocents. This is a problem that must be attacked at scale, or we resign ourselves to a world where cyber crime will always be lucrative and largely risk-free.

Let me just state unequivocally: No one cares.

Rarely do you talk to someone at the C-level – someone who has profits and Wall Street and the Board on his mind – who cares about who his adversary is or what their motivations are. The occasional former military officer-turned-executive will have a flash of patriotic fervor, but then the General Counsel steps up and the flag would be furled. In the end the course of action they all approve is designed to make the pain go away: get the evil out of the network, get the hosts back online, and get everyone back to work. I haven’t talked to every executive about this issue, so your mileage may vary, but one only need read up on the hack-and-decline of Nortel understand what the most common reaction to “someone is intentionally focused on stealing our ideas,” is in the C-suites of American corporations.

This is not a new problem. You have never, ironically, heard of d’Entrecolles. American industrial might wasn’t a home-grown effort: we did the same thing to our cousins across the pond. Nortel is only a recent example of a worst-case industrial espionage scenario playing out. Ever heard of Ellery Systems? Of course you haven’t.

IP theft is not a trivial issue, but any number of things can happen to a given piece of IP once it is stolen. The new owners may not be able to make full or even nominally effective use of the information; the purpose or product they apply the IP to has little or nothing to do with what the IP’s creators are using it for; the market the new owner is targeting isn’t open to or pursued by the US; or in the normal course of events, what made the IP valuable at the point of compromise might change making it useless or undesirable by the time its new owners bring it to market.

More to the point: Our business culture does not demand anything beyond financial performance in the short term. The person responsible for a bad security decision today will have cashed out long before any consequences of IP theft are felt by the victim corporation.

Companies that suffer the fate of Ellery and Nortel are notable because they are rare. Despite the fact that billions in IP is being siphoned off through the ‘Net, there is not a corresponding number of bankruptcies. That’s not a defense; merely a fat, juicy data point supporting the argument that if the fate of the company is not in imminent danger, no one is going to care that maybe, some day, when certain conditions are met, last week’s intrusion was the first domino to fall.

If you are honestly interested in abating the flow of IP out of this country, your most effective course of action should be to argue in a context that business will not only understand but be willing to execute.  Arguing Us vs. Them to people who are not in the actual warfighting business is a losing proposition. The days of industry re-orienting and throwing their weight behind a “war” effort are gone. “More security” generally comes at the expense of productivity, and that is a non-starter. Security done in a fashion that adds value – or at the very least does not serious impede the ability to make money – has the potential to be a winner.

I say ‘has the potential’ because to be honest you can’t count on business decision-makers caring about security no matter how compelling your argument. Top marks if remember the security company @Stake. Bonus points if you remember that they used to put out a magazine called Secure Business Quarterly that tried to argue the whole security-enabling-business thing. Did you notice I said “remember” and “used to?”

We have to resign ourselves to the very real possibility that there will never be an event so massive, so revealing, that security will be a peer to other factors in a business decision. While that’s great for job security, it also says a lot about what society values in the information age.

To test the new hash set, I created a Windows 7 virtual machine and hashed all of the files on it. I then submitted all of those files to the Kyrus NSRLookup server, with the following results:

$ nsrllookup -K known.txt -U unknown.txt -s nsrl.kyr.us < all.txt &&
wc -l *own.txt
40650 known.txt
7567 unknown.txt
48217 total

Of 48,000 input files, 7,600 were unknown. That’s a lot of unknowns! So I made a custom version of md5deep (which will be published soon), which only hashes Windows executables. I then hashed just the Windows executables on my VM and submitted them to the server:

$ nsrllookup -K known.txt -U unknown.txt -s nsrl.kyr.us < exe.txt &&
wc -l *own.txt
15937 known.txt
291 unknown.txt
16228 total

That's a LOT fewer files overall! We went from a total of 48,000 files to 16,000. That's a dramatic reduction thanks to ignoring non-executable files. Why just executables? Depending on the case type, you may only be looking for executables. In eDiscovery or illicit imagery cases, where the focus is on documents, you are probably better off searching for those file types directly rather than attempting to eliminate everything else. When doing executable analysis, look for executables!

But the real payoff  from this process is that there are only 291 unknown executables! That's actually manageable. Comparing 291 executables against the Malware Hash List is entirely do-able, as is sending the hashes to a service like VirusTotal. (Truth be told, I looked at the filenames of those 291 files, and most of them were part of VMWare.)

If you're champing at the bit to try out searching for executables, you can use another tool I wrote, Miss Identify, http://missidentify.sf.net/, to try it now. As a bonus, that program can generate warning messages when it finds executables which don't have an executable extension.

Finally, like you I have heard the complaints about the NSRL, such as http://ballinyourcourt.wordpress.com/2011/08/31/de-nisting-defective/. I asked the NSRL folks for a comment on the matter and they told me the following:

In December 2011 NIST identified a type of container file they were not recursing into when generating the hash sets. Failure to process these container files led to many hashes being omitted from the data set. The latest hash set, produced in January 2012, contains many more files, especially for those files in Windows 7. The next hash set, version 2.36, scheduled to be released in March 2012, will have even more.

They added, "NSRL appreciates ALL feedback from the community. We endeavor to respond in a timely manner, and we encourage you to contact us directly at nsrl@nist.gov to enable NSRL to turn a solution around within a publication cycle."

How much of your job as a lethal forensicator is spent searching for needles in haystacks? Known File Filters can be helpful in this regard . . . until the filters get too large to be useful. Reducing the data set you have to look through in order to find that precious needle (ouch) is one of those Holy Grail problems forensics people have been trying to address for years.

NIST on the Case

NIST is kind enough to distribute the National Software Reference Library (NSRL). A collection of hashes of known software (usually provided by vendors themselves), it contains over 78 million hashes, 21 million of which are unique. It is arguably the best resource almost no one uses because 78 million is enough hashes to choke almost any forensics tool you’re using. Go ahead and try it. We’ll wait . . .

One Step Beyond

Starting today we are offering (in Beta) the Kyrus NSRL Lookup Service (NSRLookup), which is based on the hard work of Rob Hansen at Red Jack, who coded nsrlquery. You can download a Windows binary or the *nix source code at SourceForge. Once installed, you can use the output of Jesse Kornblum’s md5deep to query the server. The output can be piped directly:

C:\> md5deep -r * | nsrllookup -s nsrl.kyr.us

. . . or a saved file can be used

C:\> md5deep -r * > known.txt
C:\> nsrllookup -s nsrl.kyr.us < known.txt

By default the server responds with the hashes of unknown files. You can get the hashes of known files by adding the -k flag, like this:

C:\> nsrllookup -s nsrl.kyr.us -k < known.txt

To see a help screen and a list of all command line options, use the -h flag:

C:\> nsrllookup -h
nsrllookup for Windows version 1.0.6-1
nsrllookup [-hvukx] [-U FILE] [-K FILE] [-s SERVER] [-p PORT]
-h: display this help message
-v: display version information
-u: show only unknown hashes (default)
-k: show only known hashes
-U FILE: write unknown hashes to FILE
-K FILE: write known hashes to FILE
-s SERVER: connect to a specified nsrlquery server
-p PORT: connect on a specified port

Please report bugs in the Sourceforge discussion forum.

We hope that NSRLookup proves useful to the forensics community. It isn't quite a “find evidence” button, but with people like Rob trying to tackle the problem, its close. If you’d like to provide us with your feedback, please contact us.

From the SANS site:

In one hour these Digital Forensics and Incident Response experts will discuss the coolest techniques and solutions they have discovered in 2011. If you have never been to a lightning talk it is an eye opening experience. Each speaker has 360 seconds (6 minutes) to deliver their message. This format allows SANS to present 10 experts within one hour, instead of the standard one presenter per hour. The compressed format gives you a clear and condensed message eliminating the fluff. If the topic isn't engaging, a new topic is just 6 minutes away.

If you cannot attend in person, you can watch the simulcast by registering at:

https://www.sans.org/webcasts/digital-forensics-incident-response-lightning-talk-%96-live-webcast-94919

It is tough being in cybersecurity. Defense is a cost center, and it's hard to find meaningful metrics to demonstrate success. Interest in security is also cyclical: Major breaches stir action, but as time passes, interest and resources wane, though the threat is still there. Yet the biggest problem with cybersecurity is ourselves. Before we can succeed, all of us must agree to change.

Read the full article here.

http://research.microsoft.com/apps/pubs/default.aspx?id=156020

The gist: I want to build a model of what each CPU instruction does in an unguided (completely automated) manner. we'll do it by having the CPU execute instructions and observing their side effects. this lets us build a "very good" model of what each instruction does.

The problem is how do I have input samples that can let me see everything? i.e. what if add is fine for integers from 0 to 1000000 but at 1000001 there is a problem? "the only way to find out is to exhaust" you say, that is, exhaustively try every possible input value (and every combination of input values).

That sucks. They have an algorithm that lets them do it "smarter". I'm still deciphering it, it's in the paper.

This is interesting to me because you can consider each instruction as a "function" and when you say "oh I have a way to reason about these functions reactions to certain inputs", ears should perk up.

Anyway, some results:

"We also discovered cases where observed behaviors contradict the x86 reference manual (which is unsurprising given the size and complexity of the spec). For instance, we discovered by accident while debugging our template T -ARImain that the overflow OF flag should be set to 0 after executing IMUL[8] with 65 and 254 as inputs according to the Intel spec, while the OF flag is actually set to 1 after the execution of this instruction with those inputs on an Intel XEON3.7 processor.

Moreover, we discovered, again by accident, that the semantics of instruction varies across Intel processors. For instance, on an Intel XEON3.7 or Core2 or i7 M620 processors and in accordance with the x86 spec, executing instructions ROL, SHL or SHR does not set the overflow OF flag if the count argument is not 1. However, on an Intel i7-2620M processor (HP EliteBook 2760p, 2.7Ghz, 8Gb RAM, 64-bit) processor, the OF flag is set to 1 even for certain   cases when the count argument is greater than 1. Our template T -BSf lag is actually unable to capture this behavior, which is why we detected these corner cases.

Finally, and unsurprisingly, we also discovered several errors in previous manually-written x86 instruction handlers used in the whitebox fuzzer SAGE [5]"

We discovered something similar with the shift/rotate instructions while implementing a project of our own (I forget the exact details, but I think it had to do with rotating by more than the register width would "still work" even though that case wasn't covered in the intel documentation). if you can put infrastructure like this together, you can discover interesting things about CPUs.

And of course, if you see some malware doing something "weird seeming" with instructions, you could perhaps infer that they were trying to do something like fingerprint what CPU they were on or flummox static analysis tools doing  instruction-level emulation, and then you could infer that whoever wrote the malware might have had enough time on their hands to come to grips with works like this paper.

The downside to being able to make that inference is I'm sure if you know just that much, you'll be super quick to blame anything "weird looking" on "oh I bet they're doing some super awesome per-cpu heuristic etection thingy" when really it's just some behavior you've never seen before. there has to be a word for that thought trap ...

And of course, there is prior academic work in discovering discrepancies between the docs and the reality, these people did it too: http://www.cl.cam.ac.uk/~pes20/weakmemory/index3.html there are some similarities between the Cambridge approach and the MS research approach, but, the Cambridge model of the CPU is built by hand (as I recall) and the thing the MS research model brings to the table is the automated building of the model.