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
6 comments:
Bejtlich's blog entry sees to be little but a squabble over terminology: an article in DarkReading used the term 'anti-forensics' in a way Bejtlich thinks is wrong: 'anti-forensics' means something else, though he can't remember who defined it that way.
All this gives me is an indication of the relative immaturity of this particular field of practice: terminology is still in a state of flux. (And in case anyone wonders, that's an attack of the field itself as insufficient for its purpose -- which I hereby define as 'contra-forensics'.)
I can't even decide why it is important to make that particular distinction. Indeed, insisting on a distinction seems to be as harmful as insisting that 'security' somehow is some kind of sum of confidentiality, availablility and integrity, which are the standard terms used to define security.
Anonymous,
I have to say, I'm having a bit of trouble following your line of reasoning.
Also, it's easy to sit back and criticize others from behind a keyboard. Perhaps rather than deriding the community for being immature, could you point the community in the necessary direction? I would hope that would serve everyone best in the long run.
I believe one distinguishing factor is the intent of the user. We have seen the defense that a user was just cleaning up their privacy information when it is suspected that their real intent was to remove or "invalidate factual information for judicial review".
In the end I think the distinction is important for uncovering intent which may or may not lead to spoliation.
Jim,
Good perspective, and thanks for posting.
One of the things I'm always a bit leery of is a discussion of "intent" based on only technical information found in an image. There are times when "intent" can be easily confused...for example, indicators of defrag activity from only the Prefetch files. Unfortunately, this doesn't establish intent.
I've seen instances where someone had "evidence elimination" tools installed for some time, and based on other information, they appeared to have been used quite regularly...therefore, how can someone say that the user "intended" to use them for the purposes of spoilation for one specific instance?
From a purely technical perspective, I'd suggest that intent can be something that's difficult, at best, to determine.
Of course it's easy to criticize others behind a keyboard ... as far as a blog is concerned, its the only place I can be. Doing it in print would be far too late, and to an audience who may not even know about the blog entry.
Why handicap myself? (And as for taking you more literally than intended, ... words are all I have to go on. If you don't mean what you say, I will probably misinterpret.)
Jim's point about intent is a good one in general... proving intent is important. But I don't think that is *really* what the words are meant to express. Both Bejtlich's and Keydet89's definition use the term 'attack' and 'countermeasure', and thus clearly indicate that they are deliberate and intentional (here's one of those cases where meaning what you say is important). Bejtlich confuses the issue somewhat when he says that network traffic encryption is an example of anti-forensic technique. But there intent is paramount: if the intent is to prevent forensic analysis, true. If the intent is to provide confidentiality, then no. Then the antiforensic effect is only a side-effect. The SSD TRIM command has negative effects for forensic analysis, but the intent is not there.
So again, why insist on a distinction? As forensic analysts, we have to be aware of intent to hide, and to mislead, confuse, overload ... but what practical use is it to say that signs A, B and C are anti-forensic and E, F, G counter-forensic? Does it help us unravel what has happened? Does it help presentation in court?
Or does it only muddy our thinking, insisting on distinctions where none clearly need to be made, and thus seduce us into spending time on making distinctions without a difference?
I'm a pragmatist -- or I try to be. If a definition isn't useful for what we want to accomplish, drop it.
As for pointing the way ... no, not in this context. I'm not pointing the way towards something better, I'm pointing at something to avoid: 'Don't get too close to that boghole'.
Over and out.
If you don't mean what you say...
By "behind a keyboard", I meant that you aren't signing your posts with your name. You've got some interesting points...you'd think that you'd want to make the distinction as to from whom they come.
Post a Comment