Detecting APT Attackers in Memory with Digital DNA™

HBGary’s Digital DNA™ system is an alternative to traditional signature-based approaches to detecting malicious backdoors. While the “APT is not Malware” mantra is common, APT commonly use malware. To be precise, APT is just a hacker in the network. Remote access to the network is guaranteed only through stolen VPN credentials, or through the placement of a remote access tool (RAT) – in other words, malware. So, enter DDNA.

DDNA is designed around generic detection of subversive code. To do this, HBGary disassembles everything on-the-fly and pushes it through a sieve of regular expressions that match against control flow and data flow features. I thought it would be fun to delve into some specific examples.

As Martin recently pointed out in his blogpost, APT has started to use in-memory injections as a means to hide code. We have noticed remote-access functions injected and split over a range of memory allocations.


In the screenshot, you can see a dozen 4K (0x1000) allocations injected into explorer.exe. (Note: this type of activity can be detected using the free Responder CE.) Each page of memory only contains a tiny portion of the overall malware – something that would frustrate most AV scanners. However, the allocations themselves are suspicious to Digital DNA™, and in particular the last page has a suspicious code fragment that scores quite heavily in Digital DNA™. This illustrates why a filesystem-only view is not sufficient to detect APT tools. Many advanced techniques involve modifications to the running system and can only be detected in memory.

In this example, the hacker hasn’t hooked anything. Instead, he starts some additional threads to service the malware code. Even though the malware has been split over a dozen pages, the hacker has only started two threads. In this example, allocations #8 and #11 each host a thread subroutine. The other memory pages each hold specific subroutines. For example, one of the memory pages has a function for installation into the registry, while another has a function for hiding a copy of the malware in an alternate data stream. It’s these suspicious behaviors that Digital DNA™ is focused on detecting. Furthermore, it’s the behaviors being used together that will really light up color-coded DDNA alerts.

One suspicious feature is when code exists outside the bounds of a known module. This will occur if the hacker allocated additional space for storing an injected routine. This is commonly done using VirtualAllocEx(), but can also be achieved using the stack of an injected thread. In the latter case, CreateRemoteThread() is used with a stack size argument large enough to store an injected routine. In either case, executable code is detected outside of a defined module, and this will score as suspicious by default even without further analysis.

Moving further, however, injected code is typically handwritten assembly. In most cases, the operational code will not resemble known compiler patterns (such as code compiled by Visual C++ or Borland). In particular, the code may contain position-independent operations – function calls and data references that are designed to work independent of the address where the code lives in memory. These are further indicators of suspicion. In my experience, the only time this kind of code appears in a legitimate binary is when DRM is being used (DRM looks and smells like malware anyway).

To look back at our example, it had some interesting techniques for embedding data inline with code:


In the example, you see the “w32_32” string in use, but what makes this interesting is how the string is embedded inline to the code. Right before the string we see a short call that jumps over the string, and code execution continues on the other side. Again, this idiom is suspicious and can be detected generically, as opposed to reliance on a specific string or byte pattern.


In the case of Digital DNA™, code 16 30 detects short calls and jumps over inlined networking related strings. How did we get here? HBGary detected that some APT groups were producing this code pattern as a result of some code-level anti-forensics tools. This is exactly the kind of pattern that produces big wins on the detection side as the code is often cut-and-paste or the obfuscation is applied in batch to otherwise custom-compiled malware. (Of course, now that I’ve blogged about it they will switch off to another trick – it’s OK, we have thousands of traits to detect suspicious behaviors).

Another example of handwritten code is the CRC function used by the hacker to load his table of function pointers. This CRC-based technique has been around in shellcode for a long, long time (digression: I think I released the first public CRC loader in shellcode in the early 2000’s – it was 32-bit CRC. Thinking back, Halvar Flake publicly released a better and smaller 16-bit CRC loader in shellcode shortly afterward. The technique has been written about many times since).

The routine that actually calculates the CRC is usually hand-made – so it too can become a form of attribution. But even if it’s not hand-made, the proximity of CRC to a GetProcAddress() call would be indicative of this pattern. In our APT example, the author has created a CRC for loading a function table:


The CRC calculation is referenced from a routine that is rolling through KERNEL32.DLL and calling GetProcAddress(). This pattern screams for attention “Hey! I’m malicious!”


So again, Digital DNA™ for the win. The CRC can be detected using a generic method, and when detected in control flow in proximity to GetProcAddress() loop, it scores hot with trait C3 F7.

These are just some examples of how Digital DNA™ focuses on analyzing the code itself, as opposed to blacklisted MD5’s or ASCII strings. It is not possible to specify these behavioral patterns with simple languages like OpenIOC or even ADXML (Active Defense’s XML for scan policies) – they can only be detected programmatically. That is why our product Active Defense doesn’t depend on IOC’s alone to do the job – in fact, Active Defense starts with full physical memory analysis and Digital DNA™ sequencing. IOC’s come second and only if the user wants to extend the default detection capability with custom threat intelligence. The two methods work well together, Digital DNA™ to detect new and unknown threats, and IOC’s as a follow-up sweep for known APT behaviors.

Using IOC’s effectively

One of the reasons we invented Digital DNA™ is because IOC’s alone aren’t good enough. A problem arises when IOC’s are only used to detect known threats. Think about this – if your IOC’s are just a blacklist of recently discovered malware MD5’s and unique strings then its equivalent to a small AV dat file. Even though IOC’s can be used to detect TTP’s (i.e., scanning the enterprise for split RAR archives or recent use of ‘net.exe’) we generally see them employed to detect specific malware files. If your organization has a database of IOC’s then look for yourself. How many entries have MD5 checksums? How many are specific to a malware sample, a specific registry key used to survive reboot, etc? If you see an overabundance of these signatures then beware – this is the same old blacklist-driven security model that has been failing us for over 10 years now. On the other hand, if you are using IOC’s to scan for more generalized things, such as command-line usage, access times on common utilities, executables in the recycle bin, etc., then you are on a far better trajectory. I support open intelligence sharing, but I caution you against falling into the “magical strings” bucket. Too often our industry shares threat intelligence in the form of blacklisted MD5’s or IP addresses – this kind of threat intelligence is nearly useless.

HBGary’s managed services team generates many IOC’s in the course of their work, and I am happy to say that we share all of them with our Active Defense customers – we don’t keep them secret. They are provided automatically in the form of a library that is auto-updated. Customers can pick and choose from many search definitions and use these as a basis to create their own custom searches. Our team tries to steer away from malware-specific indicators, and instead focuses on the generic attack patterns that can be detected at the host. We give these to our customers because we want them to get the most from our software. We enable people to be self-reliant.

When you use Digital DNA™ and IOC’s together, you aren’t relying on a “magical bag of strings” that go stale every two months. Instead, you are detecting new threats and then using IOC’s to apply attrition against the attacker’s persistence. This is a strong defensive position. This is why our proven behavior-based solution approach is increasingly winning us new customers – even unseating our competition in many accounts.

-Greg

APT - The Plain Hard Truth

The survivors from the front line have reported in. We stand on the ridge, a tangled mess of bodies behind us. We are the ones who have chased the demon, descending into the binary pit the users call the “enterprise”, and climbed up the other side. What we have seen is not pretty. The collective corporate filesystem is a parking lot for castaway software barely able to run on modern operating systems, squeezing the last bit of life out of burned out win32 DLL’s. There are big piles of unwashed garbage downloaded by employees that were passing by, never deleted, never clean. The strangest mutated crap has been swept tightly into temporary directory corners that have since calcified and become permanent.

More than a single digit percentage of these software programs are a biohazard. Some are just plain broken, wheezing out juice from a hooked windows message chain just long enough to cough up and die, only to be resurrected by the swift kick of a boot-time registry key the next time the machine reboots. Some have pretty little labels of well-known companies – clearly so you won’t look twice at them and notice how they are exfiltrating personal browsing statistics and other data to some cloud server – really like malware but allowed by the EULA that you didn’t read. Some of these things don’t seem to have any purpose but to act as a low-fidelity binary listening device.

Everything looks bad. So, it’s no wonder that hackers can just plug something new in and nobody notices. As long as it doesn’t infect five million residential banking customers then nobody is going have a description of the suspect. That is the reality of hacking today, and it has nothing to do with advanced persistent threat. It has to do with the enterprise and the complete LACK of control you have over the endpoint. When security is limited to the network perimeter, you are not in control. Oh, and what a breath of fresh air the mobile device is. A new pile of software, mostly social media, that is directly connected to thousands of strangers that are not your employees, communicating in real-time with processes running within your defensive wall. In effect, you now have thousands of potential multi-homed routers to 3G-space* from your network that don’t belong to you.

*4G if your lucky

Here are some basic security facts:

• Today, malware is a tool for persistent adversaries
  
• Adversaries are financially or politically motivated
  
• Intrusions involve a real human being or hacking group that targets your organization directly (*)
  
• Attackers are motivated to steal something from your network

*Somehow in the mid-2000’s it seems like the security industry lost its way and forget about the basic tenants of Hacking Exposed – unfortunately you cannot condense a set of MD5 checksums out of the hacker problem.

Recently during presentations I have outlined three primary threat groups we face today. I have illustrated the evolution of these in the following diagram.


A. Criminal Enterprise – these are the guys who make more money than drug cartels and the reason a malware economy emerged over the last few years. This is what mere mortals mean when they talk about malware, and the reason people get malware and hackers mixed up all the time.

B. Rogues – these are the hacking groups that you can enumerate on any given day. There are hundreds, if not thousands worldwide. These guys are all capable. The graph expands much slower than criminal enterprise because they aren’t fueled by cash. As early as 2000 these guys were already defacing, DDOSing, and partaking in ‘mostly harmless’ hackery. Yet, a small subset have always been deeply malicious and get pleasure out of destroying things. Others pick up a cause and act like cyber terrorists. And still others really are cyber terrorists.

C. Rogues meet cash - these hired mercenaries are the ones who write malware, sell zero day, and get sucked into the vortex of organized crime. These guys are very, very dangerous.

D. The problem today - all the membranes have been breached - the threat is blended. We live in a time where a state interest can simply buy access to adversary networks from criminals who are selling their botnets. Where state sponsored attacks can be vectored through private hacking groups. Where private hacking groups can fund their operations from cybercrime, while targeting corporations and governments with methodology indistinguishable from APT. There is no tidy bucket to place the threat, all the wires are now crossed. The only thing that is consistent here is that hacking is hacking, and it always looks and smells the same when you see it. This is why the term ‘APT’ is so tired.

E. Private hackers working for the man - when you catch a Chinese malware in a DoD contractor network, it almost always looks like it was written by a “kid”. This “kids” malware is then used to steal the plans for a weapons program that can only have value to the PLA. All the security vendors looking at APT come up with corny little codenames for all the hacking groups (HBGary included), but at the end of the day it’s all the same thing.

F. Thank God for APT - a board room level term that we can all use to cover our you-know-what when we tell the man our millions of dollars in security spending has done nothing for us.

If you want a no-holds-barred, no excuses, and no-snakeoil analysis of APT and the reality of countering it, you should check out HBGary’s new whitepaper The New Battlefield.

-Greg

Shady RAT is Serious Business

Ira Winkler makes some interesting points in his CIO article on Shady RAT. I tend to agree with his observation that security vendors spend too much energy infighting when we all should be facing a common enemy. It is true that Shady RAT is just one of many other, similar attacks. There is no harm in trying to draw attention to the elephant in the room - APT is a grave and serious threat to U.S. companies as well as national security. Shady RAT may appear to be 'sloppy' but it can still be APT. Within infosec the term APT has been debated - but we at HBGary have a very simple definition: if there is interaction with the host, we call it APT. Now, most of the attacks we deal with are targeting intellectual property and appear to have state sponsored underpinnings. The attackers usually leave tools behind, additional backdoors, etc., but none of these are very complex. The malware and techniques are mostly unsophisticated and sloppy, but yet they succeed and remain persistent. Our assumption on this - APT does the minimum necessary to get the job done. If they don't need hard core boot sector viruses and kernel rootkits, they aren't going to use them. We as an industry have a responsibility to protect our customers from a very serious and evolving threat. Downplaying the seriousness of this threat undermines the reason we are here.

-Greg