Weaponization of Cyberspace

The weaponization of cyberspace started with the advent of criminal enterprise, and over time has enabled cyber warfare for a mass audience. Some of the best exploitation technology was created for banking fraud. These tools include remote access botnets, multi-platform reliable exploits, command and control schemes, zero-day exploits, and blackhat-VPNs for anonymous access to the Internet.

Because the technology was developed in the underground it can be purchased by anyone - it's unclassified and not controlled by state security. As a result, very advanced attack technology has been disseminated to a greater population and non-state threat actors have emerged. Now individual citizens can access the same weaponized technology that was previously only used by the state-level efforts to conduct espionage that advances national interests. These same 'rogue hacking groups' have emerged with mixed ideological goals - many of them anti-state, religious extremist, and anti-corporate. There are hundreds of internationally organized groups that can be enumerated by anyone willing to do a little open-source intelligence research.

The weaponization of cyberspace is a key driving force that started with criminal enterprise, but has grown into a much larger context. Exploitation of systems can now be combined with the exploitation of online media. I predict that traditional terrorist methods will be replaced largely due to the immediate attention an amateur can bring to their cause by latching on to a brand name and posting their ideological views via the countless social outlets available to them. Because the press does not traditionally frequent cyber cafe's in remote parts of the world (where western ideology and freedom isn’t necessarily embraced), would-be terrorists will seek more effective means to distribute and influence from whatever rock they're hiding under. Cyberspace offers far less exposure and risk than carrying a cell phone detonator in a busy marketplace. No, it is far easier to tap out a few keystrokes and get your shot at trending, getting linked, liked, and retweeted. In terrorism the goal is messaging, and those with things to say have found their outlet. Whether highly sophisticated abroad, or in the deepest darkest caves, or down in the basement of their parent’s home, the Internet is their soap box.

-Greg

The Changing Face Behind the Keyboard

At my recent RSA presentation, I talked about the evolution of cyber threats over the last decade and the slowly shifting goals and intent of the hacking groups behind them. Most of us remember the romantic hacker vision - the lone college student exploring systems for fun, not profit. Mostly harmless, this quest for learning at the center of the hacker ethic led to tremendous innovation in Silicon Valley and elsewhere. But the advent of online banking in the mid-2000's changed everything. The criminal goal became profit. This created a malware economy, and something I call the "weaponization of cyberspace" - a trend towards making cyber weapons easier and easier for non-programmers to use. Then, around 2005-ish, we started to see organized and wide-scale attacks into military and defense systems that seemed to originate from foreign intelligence. The malware behind these attacks were not altogether different from known toolkits (think Back Orifice 2000) - but far more interesting was the fact these toolkits were custom-made and each attack group seemed to compile their weapons from private source code. It didn't take long for these attackers to branch into commercial space - most specifically heavy industry and energy. This made sense from a national perspective as China's (and others') need to dominate the world energy market is critical to their expansion.


Now, with hactivism, non-state actors are targeting these very same systems. These rogue threats are focusing on manufacturing, defense, the financial sector, and more - organizations traditionally targeted by state-level espionage.

So, what is next?

While attitudes against the state are a common recurring theme in younger people in every nation, they rarely blossom into full-blown terrorism. Yet, that is exactly what is occurring right now. As cyber warfare shifts from a state-level coordinated espionage operation to unstructured personal action, the chance for attacks (both physical and cyber) on citizens and the livelihoods of innocent people increases dramatically. The Internet will play a big part in future terrorist attacks - not just because systems can be hacked, but also because of how the Internet has changed media and journalism. As I detailed in my post on Asymmetric Warfare and Cyber Terrorism last July, remember that terrorism is first and foremost about messaging. Exacerbating the lines of truth, the Internet mediasphere has surpassed all other forms of traditional journalism and has become an information weapon, disseminating propaganda in conjunction with social media campaigns far more effectively than a single actor detonating a car-bomb in Karachi could ever achieve.

I will be giving a webcast version of my RSA presentation next Wednesday (March 14th, 11AM PST) for those who are interested. The RSA registration link is here.

-Greg

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

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