The use of anti-forensics techniques to hide malicious activity (malware installation, intrusion, data theft, etc.) can be something of a concern during an examination; in fact, in some cases, it's simply assumed when particular data or artifacts can't be found.  It's easy to assume that these techniques were used when we look at a very limited range of artifacts; however, as we begin to incorporate additional and more comprehensive data sources into our analysis processes, we begin to be able to separate out the anti-forensics signal from the noise.

The term "anti-forensics" can refer to a lot of different things.  When someone asks me about this topic, I generally try to get them to describe to me what they're referring to, and to be more specific.  As with anything else, nomenclature can be important, and messages get scrambled when the use of terms becomes too loose.  Rather than address this as broad topic, I thought we'd take a look at some of the common techniques used to hide evidence on or remove it from a system...

TimeStomp
One of perhaps the most publicly discussed anti-forensic techniques is referred to as time stomping, in part due the name of the tool used to demonstrate this capability.  While this initially threw a monkey wrench into our analysis processes, it was quickly realized that the use of this sort of technique (and tool) could be detected.  Then, as things tend to go in any eco-system, there was an adaptation to the technique...rather than modifying a 64-bit time stamp with a 32-bit value, the technique was adapted to copy the file times from kernel32.dll onto the target file, preserving 64-bit granularity.  Once again, analysis techniques were updated.  For example, in 2009, Lance Mueller talked about detecting the use of time changing utilities in his blog.  There's been discussion regarding techniques for changing the $FILE_NAME attribute time stamps, as well as those within the $STANDARD_INFORMATION attribute, just as there have been techniques for detecting the use of this technique.  Direct and thorough analysis of the MFT (the analysis of which is predicated by having a thorough understanding of the MFT records themselves) can be revealing, whereas techniques such as detecting program execution and David Cowen's NTFS TriForce can prove valuable insight, as well.

Tools: MFT parser, knowledge of MFT records

Changing the System Time
Okay, let's say that rather than changing the times of specific files, and intruder changes the system time itself.  This would mean that, after that change, the times recorded by the system would be different...so how could we detect this?  One way to do this is to list available Event Log records by sequence number and generated time...if the system time were rolled back, this activity would become evident as the sequence numbers increased but at one point, the time generated was earlier than the time for the previous record.  Lance Mueller's first forensic practical exercise provided a great example of how to detect system time changes using this technique.

Tools: evtparse.pl ('-s' switch)

Zapping Event Records
I've heard analysts state the there were gaps in the available Event Logs, so an intruder must have been able to remove specific event records from the log.  Again, I've heard this claimed, but I've never seen the data to support this sort of thing.  Writing a tool to do this is hazardous to the intruder...it may not work, and may instead crash the system.  Why not just do something much simpler, such as (given the appropriate privileges) clear the Event Log and disable auditing all together.

I've had to analyze a number of Windows systems where the Event Logs have been cleared, and with Windows XP and 2003 systems in particular, it's been pretty trivial to recover a good deal of those deleted event records.

Checking the LastWrite time of a Registry key within the Security hive file (see the auditpol.pl RegRipper plugin) will help you determine when the audit policy of the system was last modified.

Multiple Techniques
What we've discussed thus far was not intended to be a comprehensive listing of all anti-forensics techniques; rather, I wanted to look at a couple and point out analysis processes that you could employ to detect the use of such techniques.  The thing about using anti-forensics techniques is that less is better; the fewer and more simple the techniques used, the harder they are to address.  For example, simply deleting a file...downloader, executable file, etc...after us is perhaps the simplest technique to use, as it prevents an analyst from obtaining a copy of the file for analysis.  Say a script downloads and executes a file, then deletes it...the analyst may still find artifacts to indicate that the file was executed (i.e., Prefetch file, AppCompatCache artifacts, etc.) but not be able to determine explicitly what the file was designed to do.

However, to use multiple techniques requires additional planning and effort.  If this is done automatically, then either a larger application, or multiple applications will need to be downloaded to the system.  The problem that the intruder then runs up against is that the applications have to be tested specifically against the version of Windows that has been compromised...different versions of Windows may have different functionality behind the API, and the applications may not work correctly, or may even crash the system.  The more "sophisticated" the technique used, the more planning and effort is required.  If multiple applications are used, it's more likely that indications of program execution will be found.  If a more manual approach is used, then the intruder must spend more time and engage with the system more, again leaving more tracks and artifacts as they interact with the environment.

Summary
The key things to remember with respect to determining or detecting the use of anti-forensics techniques are:

1.  If you suspect it, provide it.  Find the evidence.  If you suspect that a particular technique has been used, gather the data that supports, or ultimately disproves, your theory.  Don't just wave your hand and suggest that "anti-forensics techniques were used."  If you suspect that one or more techniques were used, identify them explicitly.  Then, you can pursue demonstrating or disproving your theory.

2.  Remember that you're not only on the same battlefield as the bad guy, but you actually have an advantage.  You're examining an acquired image, which is the "scene of the crime", frozen in time and unchanging.  You can go back and start your analysis over again, without the fear of loosing any of your previous artifacts.

3.  Document your analysis; if you didn't document it, it didn't happen.  Once you've documented your analysis, including both what worked and what didn't, you can then incorporate your findings into future analysis, as well as share your finding with other analysts.

The term "anti-forensics" is used sometimes to describe efforts attackers use in order to foil or frustrate the attempts of the good guys to discover what happened, when it happened, and how it happened. Many times, what comes to mind when someone uses the term "anti-forensics" are things like steganography, rootkits, and timestomp.

Richard Bejtlich went so far as to make a distinction between the terms "anti-forensics" and "counterforensics". On Wikipedia, the term "anti-computer forensics" is used to refer tocountermeasures against forensic analysis, while "counterforensics" refers to attacks directed against forensic tools. For additional clarification on the terms, see W. Matthew Hartley's paper on the topic here; the paper is three pages long, and makes a clear distinction between the two terms.

In short, from Hartley's paper, anti-forensics refers to techniques and technologies that "invalidate factual information for judicial review", whereas counterforensics refers to tools and techniques that "target...specific forensic technologies to directly prevent the investigator from analyzing collected evidence". Hartley's paper gives some very good examples to illustrate the differences between these two terms, so I strongly suggest reading the three pages.

Very often, we use these terms (in some manner) to describe what an attacker or intruder may do, but one thing that's not discussed often is how this applies to responder's actions, or inaction, as the case may be. In that regard, there are a couple of things that organizations and responders need to keep in mind:

1. You can not just grab the disk and expect to get what you need. Live response, including memory acquisition, is becoming more and more important, particularly in the face of questions brought on by legislative and regulatory compliance. Too many times, a response team (consultants, not on-site staff) will be called in and during the course of response, but provided with goals. Then, after the fact, the victim organization will start with questions such as, "...was data exfiltrated?" and "...how much data was exfiltrated?" Fortunately, consulting responders have faced these questions often enough that they can often head them off at the pass, but what do you do when the victim organization has already taken systems offline before calling for help? Would it have been beneficial to the overall response if they'd captured memory, and perhaps some volatile data, first?

2. Temporal Proximity - lots of stuff happens on Windows systems, particularly since Windows XP was released, that have an antiforensics effect...and much of it happens without any interaction from a user or administrator. Let's say that a bad guy gets into a system, uploads a couple of tools, runs them, copies data off of the system, then deletes everything and leaves. While the system is just sitting there, there are limited defrags going on, System Restore Points and Volume Shadow Copies are being created and removed, operating system and application updates are being installed, etc. It won't be long before, due to a lack of responsiveness, all you're left with is an entry in an index file pointing to a file name. Once that happens, and you're unable to determine how many records were exposed, you will very likely have to report and notify on ALL records. Ouch!

The point is that intruders very often don't have to use any fancy or sophisticated techniques to remain undetected on a system or within a network infrastructure. What tends to happen is that responders and analysts may have only so much time (8 hrs, 16 hrs, etc.) to spend on investigating the incident, so as long as the intruder uses a technique that takes just a bit longer than that to investigate, they're good. There's no real need to use counter- or anti-forensics techniques. Very often, though, it's not so much the actions of the intruder, but the inaction of the closest responders that have the greatest impact on an investigation.

Thoughts?

Resources
Anti-forensics.com
Antiforensics.net
ForensicsWiki: Anti-forensics
Adrien's Occult Computing presentation
CSOOnline article: The Rise of Anti-Forensics
Lance Mueller: Detecting Timestamp Changing Utilities

Most of us are aware that DECAF is back, with a new version. Ovie had interviewed Mike and posted the podcast (I'd also posted, and others had commented), and the next day, the original DECAF was taken down. Now it's back, like Die Hard sequels, or a bad MRE...but I kid. See? Smiley face. ;-)

So, how do DECAF and tools like it affect the current state of incident response (IR) and digital forensics (DF) analysis, if at all?

In order to discuss this, let's go back to COFEE. MS released COFEE as an LE-only tool, and IMHO, that's the reason for the hoopla surrounding its release and subsequent "leak"...that it was LE-only. The fact of the matter is that while COFEE was released by MS, and includes the use of several native Windows apps and some from MS/SysInternals, it's really just a glorified batch file with some add-ons to make it's use and deployment easier...which, I think, is the key to understanding the nature of COFEE.

While COFEE was released by MS, it wasn't developed by MS in the way that Windows 7 or MSWord were...instead, it was a small group within MS that led the charge on developing and releasing COFEE to law enforcement.

Now, please understand...I am not disparaging the efforts of this group at all. In fact, I applaud their efforts in stepping forward and taking the first step to do something. I mean, there have been plenty of similar frameworks out there for folks to choose from, and some of them very good...but for some reason, COFEE was very well received. However, I will suggest that perhaps making something too easy to use isn't always the best solution. Sometimes, when it really comes down to it, it may be better...albeit not necessarily easier... to educate the user than it is to make a tool easier to use and deploy.

Given that, my own personal, overall assessment of COFEE is that it's a tool produced by folks who don't do a great deal of IR or "live response" work, for folks who don't do a great deal of IR or "live response" work. Don't make this statement out to be something that it isn't...I'm not disparaging anyone when I say this. All I'm saying is that in the corporate arena, many of us have taken the time and effort to educate ourselves on the issues and nuances of live response, whereas LE may not have had that sort of time...after all, when I'm reading or testing stuff, I'm sure most LE are diligently working to put bad guys in jail.

Then there was DECAF. I remember that there was discussion about "LE-only" this and "vulnerabilities" that. However, listening to the CyberSpeak podcast interview, there's no specific mention of what those "vulnerabilities" are. The "vulnerability" that Mike and friends found in COFEE was never specifically stated during the interview, pretty much leaving that particular issue up to speculation on the part of the community as a whole.

So where does that leave us? I'd suggest that the release of DECAFv2 really doesn't change anything at all. Here's why...

First, I don't necessarily see a vast deployment of this sort of tool. Think about it...how much encryption is being used for nefarious purposes? From what I've seen over the past 10 or so years, as well as from talking to others, the use of steganography outside of the academic or lab environment seems to be another one of those "urban legends" of digital forensics. Even when looking at some pretty sophisticated or large-scale intrusions, I (and others) haven't seen a great deal of what's generally referred to "anti-forensics". I hate to say it, but it really isn't necessary.

Second, I don't see this being deployed on servers to any great extent. I mean, really...think about it. Your company gets compromised and a great deal of money is spent to get a consulting team on-site to assist. Do you want to be the one to explain to the CEO why you installed DECAF on a system, when the efforts of the responders were hampered, or worse, the system BSoD'd?

Third, DECAF is signature-based, and does ship with some default signatures (although I have no idea what "FTK Imager Port" is from the Press Release page...I don't use any tool named that, so I guess I'm safe). Beyond that, how many users are going to go about crafting and distributing custom signatures? I mean...really. Better yet, who's going to write the DECAF signature for DECAF?

Fourth, let's say that you do encounter a system with DECAF installed...it's likely going to be an uber-admin's desktop or laptop...and there are other ways to collect data. Like pull the hard drive out and image it. Sure, you may not be able to get volatile data, but you may not need it for what you're doing, or you may have other data available to you.

Finally, I have no doubt that someone's going to come up with a DECAF detection tool. There are tools available that will detect the presence of whole disk or volume encryption on live systems, and detecting the presence of DECAF running...and doing so using a tool with random signatures (remember RootkitRevealer??) makes use of capabilities that have already been employed. In a way, this reminds me of the whole escalation stuff that happens with combat weapons. Tanks have armor, so someone makes a TOW missile. Then someone puts reactive armor on the tank. Then someone else puts a probe on the end of the TOW missile. And on. And on. DECAF comes out...someone else will ultimately produce a DECAF detection tool.

Circling back around to the beginning of the post, what we, and in particular LE, don't necessarily need is easier to use tools. Sure, there's a certain level of usability in GUI-based tools over CLI-based tools, but what's needed is education, first and foremost. After all, a knowledgeable responder is better prepared. Knowing is half the battle! or something like that...

It still happens...an "event" or "incident" occurs within an organization, and the initial response from the folks on-site (most often, the organization's IT staff) obliterates some or all of the "evidence" of the event. Consultants are called to determine "how they got in", "how far they got" into the infrastructure, and "what data was taken", and as such, are unable to completely answer those questions (if at all) due to what happened in the first hours (or in some cases, days) after the incident was discovered.

Check out Ignorance wrecking evidence, from AdelaideNow in Australia. It's an excellent read from the perspective of law enforcement, but a good deal of what's said applies across the board.

One of the things that consultants see very often is a disparity between what first responders say they did during an initial interview, and what the analyst sees during an examination. Very often, the consultant is told that the first responders took the system offline, but didn't do anything else. However, analysis of the image shows that installing and running anti-virus and -spyware tools, deleting files, and even restoring files from backup all happened. A great deal of this can be seen once the approximate timeline of the incident is determined...and very often, you'll see an administrator login, install or delete/remove stuff, etc., and then say that they didn't do anything.

Why would this matter? Let's take a look...

Many analysts still rely on traditional examination techniques, focusing on file MAC times, etc. So an admin logs into a system and runs an AV or anti-spyware scan (or both...or just 'pokes around'...something that happens a LOT more than I care to think about...), so now all of the file access times on the system have been modified, and perhaps some files have been deleted. Anyone remember this article on anti-forensics that appeared in CIO Magazine? Why worry about that stuff, when there is more activity of this nature occurring due to either the operating system itself, or due to regular, day-to-day IT network ops?

So what's the solution? Education and training, starting with senior management. They have to make it important. After all, they're the ones that tell IT that systems have to stay up, right? If senior management were really aware of how many times (and how easily) their organization got punked or p0wned by some 15 yr old kid, then maybe they'd put some serious thought and effort into protecting their organization, their IT assets, and more importantly, the (re: YOUR) data that they store and process.

On one of the online forums this evening, someone posted about reading the latest issue of 2600 and finding an article that mentions the use of "antiforensics" techniques, specifically with regards to one forensic analysis application in particular.

My response was this:

[Most of] these techniques don't defeat tools...they defeat examiners.

Thoughts?

I read an interesting article recently that talks about antiforensics. At first glance, the article is something of an interesting piece, but reading it a second time and thinking about what was actually being said really got me thinking. Not because the article addresses the use of antiforensics, but because it identifies an issue (or issues) that needs to be addressed within the forensics community. Yes, these tools are out there, and we should be thankful that they we made available by someone...otherwise, how could we address the issue? So, what do we need to do to update our methodologies accordingly? Perhaps more importantly, should be be trying to get ahead of the power curve, rather than playing catch up?

I do feel that it is important to mention something else in the article that I found very concerning, though:
"...details of the TJX breach—called the biggest data heist in history, with more than 45 million credit card records compromised—strongly suggest that the criminals used antiforensics to maintain undetected access to the systems for months or years and capture data in real time."

Strongly suggest, how?

The article goes on to say:
"Several experts said it would be surprising if antiforensics weren’t used."

Several experts? Who? Were any of them involved in the investigation? If they were, what "expert" reveals this kind of information, and keeps his or her job? If not...why are they speculating? It just seems to me that this part of the article is out of place, and when viewed within the context of the entire article, breaks up the flow. The article has a logical progression of here's the issue, okay we've identified it, let's get about fixing it...which all makes sense...but then this bit of speculation seems out of place.

Overall, though, it appears that the article points to some issues that should be addressed within the digital forensic community. Are the tools we have worthless? Not at all. We just have to make better use of the information we have at hand. The article mentions building layers of "evidence", using multiple sources of information to correlate and support what we found in our digital investigation.

Also, Harlan's Corollary to Jesse's First Law of Computer Forensics really seems to be applicable now more than ever! ;-)

There is discussion now and again in computer forensic circles regarding "anti-forensics", techniques that are used on systems to remove or obfuscate the artifacts that an examiner may look for and analyze. These are usually discussed in the context of purposeful actions performed by a user or attacker, but not so much in the sense that there are "under the hood", "behind the scenes" activities that go on as part of normal, day-to-day operations of the operating system that can serve the same function.

What is it that happens behind the scenes on a live XP system that most of us don't really know about? Have you ever fired up FileMon or RegMon and just watched what they recorded on a live system, without you interacting with the system at all? Now...move the mouse pointer across the screen...

While XP is a treasure trove of artifacts for an examiner, there are also things that the examiner needs to keep in mind when performing artifact extraction and analysis, particularly when it comes to looking for deleted files. When a file is deleted on a Windows system (not moved to the Recycle Bin, but really deleted), it's common knowledge that its not really gone. In a nutshell, the sectors that the file occupies are still on the hard drive, although they are now available for use by the operating system. And there's a lot that XP does to use those available sectors.

Many applications, such as MS Word, like to create temporary files while you're editing a document, and then delete those when you close the document. The sectors used by those temporary files need to come from somwhere. Yes, this is an application-specific issue and applies to any version of Windows that the application is running on.

XP creates System Restore Points, every 24 hrs by default, but also during various other actions, such as software installation or removal, etc. These Restore Points contain files that consume sectors. See my book for more information on Restore Point analysis.

Every three days, the XP Prefetch function performs a limited defragmentation of files on the hard drive. While this is limited, it still moves the contents of some sectors, overwriting others.

Speaking of XP Prefetch, when a user (any user) on the system launches a "new" application, a Prefetch file may be created for that application (assuming the 128 Prefetch file limit hasn't been reached). On my system, I have 104 .pf files, ranging in size from 8K to over 100K. Again, sectors are consumed.

As discussed in the Registry Analysis chapter of my book, there are a number of places within the Registry where a user's actions are recorded in some manner. New entries are added to the Registry, increasing the size of the files...not just the user's NTUSER.DAT file, but some actions will added entries to the HKLM hives, as well.

Of course, there are also a number of Registry settings that will have an effect on the examiner's analysis; these are addressed in detail in my book. While these aren't specific to XP, they do have a decidedly anti-forensic effect.

I mention these things because many times an examiner may be looking for evidence of a deleted file, carving unallocated space looking for a keyword or a file header, and come up empty. Remember Harlan's Corollary? ;-) Funny how there just seem to be more and more ways to apply that corollary...

Sites discussing anti-forensics aren't hard to find:
The MetaSploit AntiForensics Site
Ed Skoudis is quoted on antiforensics in 2003
Marcus K. Rogers' presentation
Ryan Harris' DFRWS paper