Friday, May 14, 2010
A dose of clarity for the "APT"
I also applaud Josh’s note that APT uses existing tools. Other experts seems to think this is not the case, or that they don’t use packed malware, or that APT don't use botnets. Why wouldn’t they? It seems the more that someone tells me what APT isn't, the more it becomes clear they have no idea what APT really is. If APT use existing malware, which I’ve always maintained, then packing is par for the course, because it's a cheap way to defeat signature based detection definitions at the gateway and host alike. Perhaps the APT did some recon into the network and learned that using XYZ packer would defeat the AV solution at the desktop. The US government created the term APT to characterize a class of threats originating from Chinese and Russian state sponsored and criminal elements, not to classify a type of malware.
Since the government coined the term "APT" it has always been about Russian and Chinese attackers, BOTH criminal and state sponsored. For the government, it's very difficult to draw a line between the two. If you understand information operations, then you know that APT will use any and all means at their disposal to achieve the mission objective. If this means use of packers, so be it. The same applies to _any_ rule or definition someone puts in my face telling me what APT is and is not. An IO campaign will include a full spectrum of capabilities. In the context of cyber, each attack on a government facility, contractor, or commercial entity could be a single operation that is part of a larger campaign. Operations could be designed to assume false personas such as impersonating college students in a dorm room, or even a false-flag - impersonating the intelligence service of another foreign country. If you truly know what APT is about, you know that you can't start boxing it up and packaging it.
As Josh pointed out, the adversaries are constantly evolving and adapting. The old models are being defeated. The government has known about APT for a while and that new approaches to enterprise security had to emerge. This is one of the reasons that the USAF and DHS both funded HBGary to address this evolving threat. Our company and our technology are pushing the envelope forward.
Friday, April 30, 2010
Cyber Threat
When we talk about cyber threats, we need to conceptualize the relationship between the person and the software entity. Cyber threats are not just about malware, nor just about a human actor. You can't separate the two. It doesn't make sense to talk about human threats that don't manifest in cyberspace. And, malware that isn't backed by human intent would cease to be a threat. Our job is to explore this relationship between a human and his manifestation in cyberspace. The very word 'cyber threat' implies this relationship. It's direct and basic.
Monday, April 5, 2010
Active Reversing
I first presented active reversing in 2007 at the Blackhat show in Vegas. At that time, the concepts were mostly theory, backed by a few prototypes I demo'd during the talk. It's taken us three years but I am very proud to say we have stayed the course and delivered something that is a true game changer for reverse engineers. It works so well that it's cheating.
Active reversing is when you obtain program understanding via runtime instrumentation, data collection, and statistics. Active reversing puts the focus on volatile runtime behavior as opposed to static disassembly. This transforms the tradecraft of reversing in many ways. For one thing, it promotes reversing to a larger professional audience. People who are already comfortable reading packet sniffer logs can now reverse engineer software. The data collected from a point in memory resembles the kind of data collected by a packet sniffer, the only difference being the data structure of the packet is actually an internal structure within a software program. Observing just a string can reveal what a function is responsible for.
Active reversing empowers you to reverse engineer by exercising a software program's capabilities and features. Consider that runtime code coverage reveals which functions are executing and when. This allows you to simply observe which functions execute in response to an action you have taken with the software. For example, if you want to find the password handling function, just review which functions executed after you typed in the login information. Filtering can be used to remove code that has executed more than once, or code that has already executed in response to another action. This so-called background noise may represent utility functions and general purpose packet handling. Once filtered, you are left with only the newly executed password handler functions. This approach can identify functions when searching for data might be difficult - for example if the data is numeric and not easily predicted. More than anything, this approach is fast. In just a few minutes you can have most of the major features of a program mapped to code.
HBGary just published a very technical whitepaper on software exploitation using REcon, with lots of screenshots and step-by-step how-to. Check it out: Software Exploitation with HBGary's REcon.
Friday, March 12, 2010
The Nature of Funded Threats
Monday, February 8, 2010
Responder 2.0 Released!
For fun, here are some sneak peeks of Responder 2.0
Above is the REcon recorded execution timeline from a particularly nasty APT malware that plagues the DoD by constantly hopping from NIPRNet to SIPRNet and vice versa, primarily through the dreaded USB stick.
The above diagram is a second malware. This malware puts the capital 'P' in APT. We were first introduced to this one back in 2005 during a DoD infection. The above sample we obtained just a few weeks ago, and clearly it's a variant of the original - that's almost 5 years and still going strong! The diagram shows the code and dataflow for a function that enumerates machine-specific data after an infection drops, this is then sent via the C&C channel when the malware reports in. This kind of behavior is very common in persistent malware, as the bad guys need to keep track of their machine-infection inventory. A little story goes like this: location 1) this queries the uptime of the machine.. 2) checks whether it's a laptop or desktop machine... 3) enumerates all the drives attached to the system, including USB and network... 4) gets the windows username and computername... 5) gets the CPU info... and finally, 6) the version and build number of windows. Quite thorough eh?
In a nutshell, Responder 2.0 cuts through APT like butter. More Info.
Thursday, February 4, 2010
See You in Sac-Town at ISSA
Tuesday, February 2, 2010
Is the term ‘malware’ eclipsed by ‘APT’?
Many of us have been analyzing malware for years and functionally the malware today is just the same as it was three years ago, but back then we didn't call it APT. In general, this got me wondering why people change the terms used to describe something (for anything in life)? For this malware and APT thing the best I could come up with is that many existing security companies adopted the term 'malware' many years ago, and thus their product offerings become tightly associated with the word 'malware'. Over the last few years or so, as people within the DoD and elsewhere realized that existing security investment wasn't adequate to protect their network, instead of calling the investment a failure for missing the malware, they instead decided to call the missed malware by a new name. Think: "This isn't malware; it's something new, so of course the millions we've spent doesn't address it!". A stretch?
The fact is this - malware has always had the ability to be updated in the field, it has always been able to be remote controlled, and it has always had the ability to spawn a remote shell to a live attacker. And, it has always had the ability to scan the file-system for files like source-code and CAD drawings, and it has always had the ability to exfiltrate those files. At all times and without exception, these malware programs have been operated by real and persistent humans at the other end. The malware doesn't operate itself, it's not an automaton. For the last 365 days, I just called that malware.