Malware commonly hunts down and kills anti-virus programs

Much of the malware we are processing has the ability to locate and kill anti-virus programs and desktop firewalls. The following malware example illustrates the behavior clearly. There are long strands of code that query through a list of known security software process-names and subsequently sabotage them.

Click for larger image

The means by which the malware detects the security software is by process name. There are long lists of process names that appear in sequence, these nodes are shown on the graphic as label 'A'. Almost all variants of this behavior are similar in structure, even though they are employed across many different and unrelated malware strains.

update:
I took the time to zoom in on one single operation (marked as B. in the following image) from the strand of control flow shown above. The strand shown above contains hundreds of these.



And, here is the disassembly for one operation:

10001A98 BB 5C 65 00 10 mov ebx,0x1000655C // webtrap.exe
10001A9D 53 push ebx
10001A9E E8 C3 25 00 00 call 0x10004066▼ // __imp_MSVCRT.dll!strlen
10001AA0 ASCII: %
10001AA0 : 25 00 %.
10001AA0 : 25 00 00 %..
10001AA3 loc_10001AA3:
10001AA3 59 pop ecx
10001AA4 50 push eax
10001AA5 53 push ebx
10001AA6 8D 4D F0 lea ecx,[ebp-0x10]
//__imp_MSVCP60.dll!?assign@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12
10001AA9 FF 15 8C 50 00 10 call dword ptr [0x1000508C]
10001AAF loc_10001AAF:
10001AAF 8D 45 F0 lea eax,[ebp-0x10]
10001AB2 8D 4D DC lea ecx,[ebp-0x24]
10001AB5 50 push eax
10001AB6 FF 75 E4 push dword ptr [ebp-0x1C]
10001AB9 E8 BB 22 00 00 call 0x10003D79▼ // sub_10003D79
10001ABE loc_10001ABE:
10001ABE 57 push edi
10001ABF 8D 4D F0 lea ecx,[ebp-0x10]
// __imp_MSVCP60.dll!?_Tidy@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAEX_N@Z
10001AC2 FF 15 90 50 00 10 call dword ptr [0x10005090]
10001AC8 loc_10001AC8:
10001AC8 8A 45 0B mov al,byte ptr [ebp+0xB]
10001ACB 56 push esi
10001ACC 8D 4D F0 lea ecx,[ebp-0x10]
10001ACF 88 45 F0 mov byte ptr [ebp-0x10],al
// __imp_MSVCP60.dll!?_Tidy@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAEX_N@Z
10001AD2 FF 15 90 50 00 10 call dword ptr [0x10005090]

What is interesting is that the list of malware to kill is commonly cut and paste around, but the methods used to parse it can vary based on which malware author is developing it. In this instance, the malware author uses the standard template library. This is a good fingerprint that can be used to find other variants of this particular author's work. Data like this can be used as an attribution factor.

Nabbing Conficker with Digital DNA

What follows is a step by step analysis of Conficker using HBGary Responder. The conficker worm represents a significant and current threat. The following analysis was performed against a sample at HBGary's lab. The first step was to obtain a dropper for one of the conficker variants and subsequently infect a 'sacrificial lamb' machine. The sacrifice machines have no network card and the USB ports are blocked as a precaution. There is a secure one-way method to take a physical memory snapshot and pull it from the machine. We resort to such measures when the malware won't execute in a VM. Once the infection was deployed and the snapshot obtained, we simply import the memory snapshot into Responder. The Digital DNA (available in Pro edition and also for the Enterprise via the McAfee ePO integration) detects and weights digital objects based upon a numerical string that is generated for every identified object. In this case, the Digital DNA calculated for one of the VAD tree memory ranges indicates high suspicion.

Click for a larger image

This memory range is subsequently extracted and disassembled / decompiled. Code, data, symbols, and strings are all recovered from the dynamic snapshot. This is an interesting fusion between static and dynamic analysis, given that its a snapshot in time of an actual running instance of the worm. Buffers contain fixed up address data, decoded data, full call stacks, etc. Many arguments can be reconstructed that would not be available in a traditional static file-based analysis. By using memory, for example, we didn't even have to worry about the packer. In this case, the packer has already ran and the malware is sitting in memory fully unpacked. We start our analysis by dragging all the strings to the graphing canvas and sorting them into colored layers.

Click for a larger image

Further analysis is largely graph-driven. Each layer represents a different property or 'factor' of the malware. For example, all of the installation capabilities are put on their own set of layers, while the communications are isolated to a different layer. The sorting to layers takes about 10-15 minutes by hand.

Click for a larger image

Once sorted, I pick off an individual layer - in this case the 'installation and deployment' layer. I toggle off the visibility of all the other layers and just focus on this single layer.

Click for a larger image

I pick through the layer sorting each small island of nodes into a more refined set of layers - moving some to a layer regarding the DLL injection capability, another describing the patch conficker makes to the tcpip.sys driver, etc. This process continues for about an hour as I drill down on connect many nodes on the graph. As I go, I bring up the code view and label functions with bookmarks that will end up in my report. The bookmarking lets me make annotations to the disassembly and the graph that are preserved for reporting purposes.

Click for a larger image

Whenever I dive into a function, I use the built-in dataflow analysis and graph-based decompilation. You can see in the screenshot how all the graph nodes are annotated with the logical conditions required to follow the branch. For example, in the screenshot a loop is detected and the loop control conditions are shown. This is a low level feature.

Click for a larger image

Finally, after about an hour or so, I have built graphs into over a dozen layers describing portions of the conficker worm's code and capability set.

Click for a larger image

When I am finished I auto-generate a report in word format, clean up the edges a bit, and print it to a PDF file. The following link shows a partial report detailing some select areas of the conficker worm.

Responder Report for Conficker (PDF)

Responder is better than IDA Pro for analyzing malware.

Greg's Note: This blog post was made by Martin Pillion, the most senior reverse engineer at HBGary and one of the most skilled RE's I've met. I have crossposted it to Fast Horizon so it would be picked up on the RSS feeds. Martin's assessment of IDA vs Responder is timely and highlights the amount of experience required to look at assembly vs. graphs. Features like proximity browsing lower the bar significantly so that more practioners can help solve hard RE problems.

Responder is better than IDA Pro for analyzing malware. I do not make this statement lightly. I have been reverse engineering code (on and off) since the late 1980s, I am a long time user of IDA Pro (since ~2000), and I have written a fair number of IDA Pro scripts. IDA Pro has been the definitive disassembly tool for nearly 10 years.

Let me also point out that I am an HBGary employee and I certainly have a bias toward the Responder product. I have helped design, architect, and develop the Responder product for many years. During that same time, I often worked with the HBGary Services division to assist customers with reverse engineering malware. I used Responder as much as possible, but often found myself loading up IDA Pro and running both products at the same time. However, in the past several months, Responder has improved to the point that I no longer use IDA Pro at all.

Responder utilizes a different approach to reverse engineering than IDA Pro. Where IDA Pro relies on inspecting large amounts of assembly, Responder relies on a more visual, graph based approach.

Responder displays information visually and is navigated based on relationships. Responder has a feature called 'Proximity Browsing' that allows you to expand a graph based on the cross references to or from the currently selected node. This makes it easy to quickly locate related code and visually examine those relationships. IDA has a popup dialog to list xrefs, but you must click each xref individually to examine it (time consuming).

Responder uses the color of xref lines to indicate what kind of xref it is. Grey for data xrefs, black for block xrefs, and red for call xrefs. Node shapes can indicate function starts, ends, regular blocks, data, comments, or bookmarks. Node color is used to organize graphs and is determined by layer. Layers are similar to the layer concept in Adobe Photoshop.

IDA Pro relies on WinGraph32 to perform graphing and it is clearly a secondary feature in the tool. There is support for a limited set of graph based analysis features, mainly built around flow chart and call flow graphing. The UI also leaves a lot to be desired... it is not possible to modify an existing graph, instead you must go back the text based UI and regenerate an entirely new graph.

Responder lets you "Collapse" a graph node. A Collapsed node is an entire function, instead of a single block of disassembly. You can Proximity Browse from a collapsed node and you will expand only call xrefs, with additional nodes also being collapsed functions. Using this feature you can quickly identify the purpose of main functions and label them appropriately.

Responder can also perform "Data Flow" tracing. Data Flow tracing allows Responder to follow the movement of data through a function, even if it is moved to a memory address (like the stack) and later moved into a register. This means that Responder can follow stack variables on functions with frame pointer omission.

Data Flow tracing is powerful and Responder utilizes it every time you rename an instruction operand. This means that your custom labels may show up later in the function and be used in a way that you did not realize. Data Flow tracing will track multiple levels of dereferences and indirections, memory addresses, registers, and even logical manipulations.

These are just a few of the features make Responder better than IDA Pro for malware analysis. I discuss others and also expand on the technologies behind each feature in future blogs. Ultimately, the primary work flow of a reverse engineering is one of organizing and understanding data. Responder enables me to do this with malware faster than I would be able to using IDA Pro.

- Martin

Server-class Analysis Now Possible with Responder

HBGary has been lifting some heavy iron, testing a variety of large memory configurations over the last few weeks. The latest version of HBGary Responder now sets the milestone: 64 gigabytes physical memory analysis - a sizeable snapshot indeed. This makes Responder a server-class product. This is an important step forward for HBGary, as the Digital DNA and malware analysis capabilities can now be applied against critical servers in the Enterprise. Large memory footprints can be found on server class machines running Windows Vista, 2003, and 2008. Ensuring servers remain free of rootkits and malware is crucial for regulatory compliance. A case in point, Visa recently announced that PCI compliance was being revoked for both RBS WorldPay and Heartland, due to malware intrusions and subsequent breach of security. Early detection of an intrusion can prevent data theft, as malware typically infects a system and remains there for quite some time. A recent data-breach study by Verizon (spanning over 4 years and 500 intrusions) reports that over 70% of victim companies had been compromised for over a year before the intrusion was detected. FISMA, PCI-DSS, and HIPPA all mandate various forms of intrusion detection to help limit the scope of damage caused by an intrusion. Sound defense in depth strategy advocates that Enterprises monitor server memory for zero-day malware and rootkits.

SMM Rootkit: Old, Obscure, and Unnecessary

Be mindful that you don't overreact to the 'new' SMM exploit (properly, reported by Loic Duflot, a very accomplished low level hardware researcher, at the recent cansecwest conference). The exploit itself is really a documented 'feature' of the Intel 5100 Memory Controller chipset, and has been a known issue with SMM for quite some time. See the 5100 data sheet:

In order to make cacheable SMM possible, the chipset must accept EWB’s and must absorb IWB data regardless of the condition of the SMMEM# pin. The Intel® 5100 MCH Chipset will not set the error bit EXSMRAMC.E_SMERR in this case. Because of this, care must be used when attempting to cache SMM space. The chipset/platform cannot protect against processors who attempt to illegally access SMM space that is modified in another processor’s cache. Any software that creates such a condition (for example, by corrupting the page table) will jeopardize the protective properties of SMM.

You might ask why it hasn't received more attention until now? Stated simply, such low level tactics are simply unnecessary for a real rootkit to be effective. Remember that you need to be in ring-0 (kernel) before you can even attempt installing into 'ring -1', and being at ring 0 is plenty of privilege for even the most stealthy of rootkits.

There are other reasons that an SMM rootkit is best left to the science fair: to make one that is effective across more than a select hardware platform, you would need to invest boat loads of development dollars in testing. At worst, someone might build an SMM rootkit that works on a well-known and distributed model of laptop and post that for publicity - but the real criminals don't build stuff like this, nor do they have to.

The majority of malware threats today are, in fact, usermode. The bad guys simply don't need to go any lower to get their work done. Remember, the lower you go, the less re-usable code you can leverage. That is, lower means no libraries, no API's. Lower means you write all the device, memory, and hardware logic yourself. It approaches the complexity of device driver development and operating system design. This all translates into expensive and non-ubiquitous. Malware avoids this development cost by simply installing itself like any other program, re-using the existing API's and libraries under windows that already provide network access, memory management, file access, and the like.

The modus operandi of real malware authors is: Write once, use many times. An SMM rootkit is a really neat science experiment and excites technical curiosity, but such an approach is not useful in practice. Let's stay focused on our Day Job, tackling real threats.

Digital DNA - Numerical Expressions to Describe Malware Behaviors

HBGary unveiled Digital DNA today at the Infosec Conference in Orlando. (I wasn't able to make it down to the show, although I had planned to be there. Last minute stuff and I had to jet back to the West Coast.) The engineering team has been working on Digital DNA for months. In a nutshell, we have automated the reverse engineering of loaded modules in the physical memory snapshot and generate Digital DNA (DDNA) based on the collected data (millions of data points). All of these data points are codified in way that allows them to be matched against rules. The Digital DNA system will "sequence" a software program or document and generate trait-codes based on the behaviors and schematic artifacts found in the software or document. Each trait has a complex rule (think regular expression with boolean logic) associated with it, and if the rule matches the trait is considered "expressed". Expressed traits are concatenated together to make a "sequence". We chose to do it this way because the final DDNA sequence looks and smells like a hash, even though it's not actually a hash at all. But, customers are used to managing hashes, thinking about hashes, and cut-n-pasting hashes - so a hash it would be.

Digital DNA is based on the reverse engineered behaviors, not the specific compilation or packer used with the malware. You can pack the same malware with three different packers and it will still produce the same Digital DNA. Two similar programs will produce similar DDNA. Here is an example of two versions of Rustock.B.



Interestingly, the technology can identify digital objects. Here is an example of tracking Intellectual Property with it.



Digital DNA is a Big Idea. For now, HBGary is going to focus it on detection of zero-day malware threats. We have over 2,000 traits in the DDNA genome currently, and will probably have many more soon. We sort all the traits into Factors, Groups, and Subgroups, defining a "genome" of behaviors that are common to malware. This part plays into a weighting system. I will blog more about this over the coming weeks - dinner is calling.