toolsmith: There Is No Privacy - Hook Analyser vs. Hacking Team

Prerequisites

Hook Analyser

Windows OS

Introduction

As we explore privacy in this month’s ISSA Journal, timing couldn’t be better. Since last we convened, the Hacking Team breach has informed us all that privacy literally is for sale. Hacking Team’s primary product is Remote Control System (RCS), “a solution designed to evade encryption by means of an agent directly installed on the device to monitor. Evidence collection on monitored devices is stealth and transmission of collected data from the device to the RCS server is encrypted and untraceable.” While Hacking Team initially claimed their products are not sold to “governments or to countries blacklisted by the U.S., E.U., U.N., NATO or ASEAN” the data dump made public as result of their breach indicated otherwise. In fact, their customers include major players in finance, energy, and telecommunications. Among all the 0-days and exploits in the Hacking Team dump, it was even discovered that they offered UEFI BIOS rootkit to ensure “that it silently reinstalls its surveillance tool even if the hard drive is wiped clean or replaced.” With industry giants willing to seemingly utilize the likes of RCS, we’re left to wonder where the line will be drawn. I long ago assumed there is no line and therefore assume there is no privacy. May I recommend you join me in this gloomy outlook?

Perhaps a little proof may help you come to terms with this simple rule: don’t store or transmit via digital media that what which you don’t want read by anyone and everyone.

To get to the heart of the matter, we’ll assess some Hacking Team “products”, pulled from the public dump, with Beenu Arora’s Hook Analyser. Beenu just celebrated the release of Hook Analyser 3.2 as of 19 JUL. You may recall that I mentioned Hook Analyser via the Internet Storm Center Diary for the Keeping The RATs Out series, we’ll put it through its paces here. Per Beenu, Hook Analyser is a freeware project which brings malware (static & dynamic) analysis and cyber threat intelligence capabilities together. It can perform analysis on suspicious or malware files and can analyze software for crash-points or security bugs. The malware analysis module can perform the following actions:

·         Spawn and Hook to Application

·         Hook to a specific running process

·         Static Malware Analysis

o   Scans PE/Windows executables to identify potential malware traces

·         Application crash analysis

o   Allows you to analyze memory content when an application crashes

·         Exe extractor

o   Extracts executables from running process/s

The Cyber Threat Intelligence module provides open source intelligence where you can search for IP addresses, hashes or keywords. It will collect relevant information from various sources, analyze the information to eliminate false-positives, correlate the various datasets, and visualize the results. 

What better to run Hacking Team binaries through. Let’s begin.

Hacking Team Samples

I pulled four random binaries out of the Hacking Team dump for analysis, sticking exclusively to EXEs. There are numerous weaponized document and media files, but I was most interested in getting to the heart of the matter with Hook Analyser. Details for the four samples follow:

1.       agent 222.exe

a.       MD5: fea2b67d59b0af196273fb204fd039a2

b.       VT: 36/55

2.       agent 1154.exe

a.       MD5: c1c99e0014c6d067a6b1092f2860df4a

b.       VT: 31/55

3.       Microsoft Word 2010 2.exe

a.       MD5: 1ea8826eeabfce348864f147e0a5648d

b.       VT: 0/55

4.       my_photo_holiday_my_ass_7786868767878 19.exe

a.       MD5: e36ff18f794ff51c15c08bac37d4c431

b.       VT: 48/55

I found it interesting that one of the four (Microsoft Word 2010 2.exe) exhibited no antimalware detection via Virus Total as this was written, so I started there.

Hook Analyser

Hook Analyser is stand-alone and runs in console mode on contemporary Windows systems. For this effort I ran it on Windows 7 x32 & x64 virtual machines. The initial UI as seen in Figure 1 is basic and straightforward.

Figure 1 – Hook Analyser UI

For Microsoft Word 2010 2.exe I opted to use Spawn and Hook to Application and provided the full path to the sample. Hook Analyser exited quickly but spawned C:\tools\Hook Analyser 3.2\QR7C8A.exe, with which I repeated the process. The result was a robust output log to a text file named by date and time of the analysis, and an XML report, named identically, of the high-level behaviors of the sample.  A few key items jumped right out in the reports. First, the sample is debug aware. Second, it spawns a new process. Third, Hook Analyser found one trace of a potential PDB/Project at offset 00007F0. When I ran strings against the sample I found c:\users\guido\documents\visual studio 2012\Projects\fake_office\Release\fake_office.pdb, confirming the project and even the developer. I’d have to err on the side of threat related in this scenario, just on project name alone. Further analysis by Microsoft’s Malware Protection Center revealed that it checks for the presence of a legitimate instance of winword.exe on C: or D:, then executes C:\a.exe. As a results, this sample has been classified “threat related”. Based on naming conventions followed by Hacking Team, one can reasonably conclude that C:\a.exe is likely an RCS agent. By the way, Guido, in this case, is probably Guido Landi, a former senior Hacking Team software developer.

You can see the overall output from both reports in a combined Figure 2.

Figure 2 – Hook Analyser results

I took a different approach with the next sample analysis, specifically agent 222.exe. I first executed the sample, then chose Hook to a specific running process. Hook Analyser then provides a listing of all active processes. Agent 222.exe showed itself with process ID 3376. I entered 3376 and Hook Analyser executed a quick run and spawned GVNTDQ.exe. I reran Hook Analyser, selected 3 for Perform Static Malware Analysis, and provided C:\tools\Hook Analyser 3.2\GVNTDQ.exe. GVNTDQ.exe is simply a new instance of Agent 222.exe. This time another slew of very interesting artifacts revealed themselves.  The “agent” process runs as TreeSizeFree.exe, an alleged hard disk space manager from JAM Software, and runs as trusted given that it is signed by a Certum/Unizeto cert. It also appears to be anti-debugging aware and packed using an unknown packer. The sample manipulates GDI32.dll, the OS’s graphic device interface and

WINHTTP.dll (mapped in memory) with a WinHttpGetIEProxyConfigForCurrentUser call, which provides the Internet Explorer proxy settings for the current active network connection. Remember that privacy you were so interested in maintaining?

Let’s say you’re asked to investigate a suspect system, and you have no prior knowledge or IOCs. You do discover a suspicious process running and you’d like to dump it. Choose Exe Extractor (from Process), reply no when it asks if you’d like to dump all processes, then provide the process ID you’d like extracted. It will write an EXE named for the process ID to your Hook Analyser working directory.

You can also run batch jobs against a directory of samples by choosing Batch Malware Analysis, then providing the path to the sample set.

I’d be remiss if I didn’t use the Threat Intelligence module with some of the indicators discovered with Hook Analyser. To use it, you really want to prep it first. The Threat Intelligence module includes:

·         IP Intelligence

·         Keyword Intelligence

·         Network file analysis

o   PCAP

·         Social Intelligence

o   Pulls data from Twitter for user-defined keywords, performs network analysis

Each of these is managed by a flat text file as described in Beenu’s recent post. One note, don’t get to extravagant with your keywords. Try to use unique terms that are tightly related to your investigation and avoid using broad terms such as agent in this case. I dropped a Hacking Team-related IP address in the intelligence-ipdb.txt file, the keywords Certum, Unizeto, Hacking Team, and RCS in keywords.txt, and Hacking Team in channels.txt. Tune these files to your liking and current relevance. As an example URL.txt has some extremely dated resources from which it pulls IP information, there’s no reason to waste cycles on all of the default list. I ran the Threat Intelligence module as a standalone feature as follows: ThreatIntel.exe -auto. Give it a bit of time, it checks against all the provided sources and against Twitter as well. Once complete it will pop a view open in your default browser. You’ll note general information under Global Threat Landscape including suspicious IPs and ASNs, recent vulnerability data, as well as country and geo-specific threat visualizations. More interesting and related to your investigation will be the likes of Keyword based Cyber Intelligence.  The resulting Co-relation (Bird Eye) view is pretty cool, as seen in Figure 3.

Figure 3 – A bird’s eye view to related Hacking Team keywords

Drill into the complete view for full keyword content results. I updated channels.txt to include only hackingteam and intelligence-ipdb.txt with related Hacking Team IP addresses. While I was unable to retrieve viable results for IP intelligence, the partial results under Social Intelligence (Recent Tweets) were relevant and timely as seen in Figure 4.

Figure 4 – Recent Hacking Team related Tweets per the Threat Intelligence module

There are a few bugs that remain in the Threat Intelligence module, but it definitely does show promise, I’m sure they’ll be worked out in later releases.

In Conclusion

The updates to the Threat Intelligence module are reasonable, potentially making for a useful aggregation of data related to your investigation, gleaned from your indicators and analysis. Couple that with good run-time and static analysis of malicious binaries and you have quite a combination for your arsenal. Use it in good health, to you and your network!

Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).

Cheers…until next month.

ACK

Beenu Arora, @beenuar, Hook Analyser developer and project lead

Volatility 2.3 and FireEye's diskless, memory-only Trojan.APT.9002

If you needed more any more evidence as to why your DFIR practice should evolve to a heavy focus on memory analysis, let me offer you some real impetus.
FireEye's Operation Ephemeral Hydra: IE Zero-Day Linked to DeputyDog Uses Diskless Method, posted 10 NOV 2013 is specific to an attack that "loaded the payload  directly into memory without first writing to disk." As such, this "will further complicate network defenders’ ability to triage compromised systems, using traditional forensics methods." Again, what is described is a malware sample (payload) that " does not write itself to disk, leaving little to no artifacts that can be used to identify infected endpoints." This FireEye analysis is obviously getting its share of attention, but folks are likely wondering "how the hell are we supposed to detect that on compromised systems?"
Question: Why does Volatility rule?
Answer: Because we don't need no stinking file system artifacts.
In preparation for a Memory Analysis with Volatility presentation I gave at SecureWorld Expo Seattle last evening, I had grabbed the malware sample described in great length by FireEye from VirusShare (MD5 104130d666ab3f640255140007f0b12d), executed it on a Windows 7 32-bit virtual machine, used DumpIt to grab memory, and imported the memory image to my SIFT 2.14 VM running Volatility 2.3 (had to upgrade as 2.2 is native to SIFT 2.14). 
I had intended to simply use a very contemporary issue (3 days old) to highlight some of the features  new to the just released stable Volatility 2.3, but what resulted was the realization that "hey, this is basically one of the only ways to analyze this sort of malware."
So here's the breakdown.
The FireEye article indicated that "this Trojan.APT.9002 variant connected to a command and control server at 111.68.9.93 over port 443."
Copy that. Ran vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw netscan and quickly spotted 111.68.9.93 as seen in Figure 1.

Figure 1

 I was interested in putting timeliner through its paces as it is new to Volatility in 2.3, and was not disappointed. Issued vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw timeliner --output=body --output-file=output.body and spotted 111.68.9.93 in network connections tied closely to a timestamp of 1384212827? Er? That's Unix timestamp. Translated to human readable: Mon, 11 Nov 2013 23:33:47 GMT. Check! See Figure 2.

Figure 2

Clearly PID 3176 is interesting, keep it in mind as we proceed.
The article states that "after an initial XOR decoding of the payload with the key “0x9F”, an instance of rundll32.exe is launched and injected with the payload using CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread."
Ok, so what is PID 3176 associated with? vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw pslist | grep 3176 will tell us in Figure 3.

Figure 3

What, what?! It's rundll32.exe. Mmm-hmm.
Strings can help us for the next step to spot CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread as associated with PID 3176. The Volatility wiki recommends using Sysinternals strings so we can use –q and –o switches to ensure that the header is not output (-q) and that there is an offset for each line (-o), as in strings -q -o WIN-L905IILDALU-20131111-234404.raw > strings.txt. We then convert strings.txt for Volatility with vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw strings -s strings.txt --output-file=stringsVol.txt. Now we can search for strings that include 3176 and the likes of CreateProcessA, along with offsets to see if there are associations. A search immediately produced:
04cfce5a [3176:701f8e5a] CreateProcessA
abd60bd8 [3176:00191bd8] OpenProcess
abd60ae4 [3176:00191ae4] VirtualAlloc
bedd8384 [3176:10002384] WriteProcessMemory
bedd835a [3176:1000235a] CreateRemoteThread
What we've just validated is that PID 3176 (rundll32.exe) shows indications of the five functions described by FireEye.
 Per the article, "inside the in-memory version of the Trojan.APT.9002 payload used in this strategic Web compromise, we identified the following interesting string: “rat_UnInstall”. Gotcha; a quick string search says: bd75bcc0 [3176:0035fcc0] __rat_UnInstall__3176.
The  rat_UnInstall IOC is clearly associated with PID 3176.

Just for giggles, I checked one last point made by FireEye. They stated that "we also found the following strings of interest present in these 9002 RAT samples (excluding the in-memory variant): McpRoXy.exe, SoundMax.dll
I was intrigued by the "excluding the in-memory variant claim", so I did I quick check. I could, as always, be wrong (tell me if I am), buy the dlllist module seems to disagree.
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw dlllist -p 3176 | grep SoundMax.dll produced Figure 4.

Figure 4

When I checked the file system for C:\users\malman\SoundMax.dll, it was indeed present.
While I am operating on the belief that my analysis of  104130d666ab3f640255140007f0b12d matches the FireEye IOCs via Volatility memory analysis alone, dlllist does indicate that the malware drops SoundMax.dll on the file system. I attribute this to the possibility that my "delivery system" was different than the IE 0-day FireEye describes; I had to download the sample and execute it to replicate behavior.

Correction 15 NOV 2013: Ned Moran from FireEye contacted me to let me know that my assumption based on interpretation of the FireEye blogpost was incorrect. 104130d666ab3f640255140007f0b12d is not the diskless version of 9002; at this time FireEye is not providing hashes or sharing that sample at this time. I clearly misinterpreted their post to indicate that 104130d666ab3f640255140007f0b12d was that sample, I was incorrect and I apologize. That being said Ned assured me that I was not out of my mind and let me know "yes, my reading of your methodology is that it would have produced very similar results, the only difference being that had you would not have found the 'SoundMax.dll' string in the diskless version. So, your approach was sound you were just looking at a different sample."

Regardless, we wouldn't need any file system artifacts to confirm the presence of the diskless, memory-only version of Trojan.APT.9002 on a victim system.
Confirmed connection to 111.68.9.93 with netscan:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw netscan 
Confirmed timeline for connection to 111.68.9.93 with timeliner:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw timeliner --output=body --output-file=output.body
Identified rundll32.exe as owner of the suspect PID (3176) with pslist:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw pslist | grep 3176
Used strings as analysis to further confirm:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw strings -s strings.txt --output-file=stringsVol.txt 
Used dlllist to call out SoundMax.dll:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw dlllist -p 3176 | grep SoundMax.dll

One more time, with feeling: Why does Volatility rule? Hopefully, I've helped answer that...again.
Cheers!

toolsmith: EMET 4.0 - These Aren’t the Exploits You’re Looking For

Prerequisites

Windows operating system

.NET Framework 4.0 or higher

Introduction

In classic Star Wars parlance, have you been looking for improved tactics with which to wave off grievous Windows client exploits? Look no further; Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) 4.0 was released to the public on 17 JUN 2013 and quickly caught the attention of security aficionados and general press alike. KrebsOnSecurity even gave EMET full coverage and as always Brian’s quality work is well worth a read for the 101 perspective on EMET 4.0. So much of the basic usage, configuration, and feature set has already been covered or introduced that I’m going to simply refer you to the Kreb’s post as well as Gerardo Di Giacomo’s ThreatMitigation with EMET 4.0 as prerequisite reading material. I work with Gerardo at Microsoft and as with all toolsmith’s I sought insight on the tool in question. As his Threat Mitigation post had just gone live as we talked, I will simply draw a quick summary from there; you can read the rest for yourself. EMET is a “free utility that helps prevent memory corruption vulnerabilities in software from being successfully exploited for code execution. It does so by opting in software to the latest security mitigation techniques. The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an update is not available or has not yet been applied. EMET offers protections for all currently supported Microsoft Windows operating systems, and supports enterprise deployment, configuration, and monitoring.” I will give you the quick bullet list of features but will move quickly to what exploitation mitigations EMET 4.0 offers when tossing attacks via Metasploit against a protected system and applications. Following are feature highlights for EMET 4.0:

·         Certificate Trust: Detect Man in the Middle (MITM) attacks that leverage fraudulent SSL certificates

·         ROP mitigations: Block exploits that utilize Return Oriented Programming exploitation techniques.

·         Early Warning Program: Allows enterprise customers and Microsoft to analyze the details of an attack and respond effectively.

·         Audit Mode: Provides monitoring functionalities for testing purposes.

·         Redesigned User Interface: Streamlined configuration and improved accessibility.

Of note, the Early Warning Program sends information back to Microsoft. If yours is an organization that already does this via other enterprise means, this is already common place behavior, but if your preference is to keep such data in house you can disable Early Warning under the Reporting menu or use System Center Agentless monitoring to forward the telemetry data to an on-premise server that can be later used for forensics or post-mortem. In production environments, you may want to make use of Audit Mode before setting EMET to terminate programs when attacked. Audit Mode instead simply reports the exploitation attempt; helpful for monitoring potential compatibility issues between EMET and protected applications.

  

Installing EMET 4.0

Installing EMET is point-and-click simple. Just download, ensure you have .NET Framework 4.0 or higher installed, accept installation defaults (Use Recommended Settings), and you’re off to the races.

The EMET 4.0 User’s Guide included on the download page is a required read as well. I ran EMET 4.0 on a Windows 7 SP1 Enterprise 32bit VM with .NET Framework 4.0, Java 1.7.0_25, and Firefox 22 (really?).

For testing, enabled the Maximum security settings under Quick Profiles. This sets Data Execution Prevention (DEP) to Always On and Structured Exception Handler Overwrite Protection (SEHOP) to Application Opt Out as seen in Figure 1.

FIGURE 1: EMET deployed and ready

That said, on production systems, take baby steps. You can begin to add other applications than those protected by default (Internet Explorer, Java, Wordpad, Adobe Reader, Microsoft Office, etc.) but as mentioned above and in Kreb’s article, phase apps in to ensure they don’t struggle or crash with the added protection and “avoid the temptation to make system-wide changes.”

EMET 4.0 Mitigations and Blocked Attacks

First up, ye olde heap spray attack. Via Metasploit on my Kali Linux VM, I queued up the Microsoft Internet Explorer Fixed Table Col Span Heap Overflow (MS12-037) module. This module “exploits a heap overflow vulnerability in Internet Explorer caused by an incorrect handling of the span attribute for col elements from a fixed table, when they are modified dynamically by JavaScript code” and utilizes ROP chains as part of the attack. Drawing right from Rapid 7, as they describe heap spray techniques for Metasploit browser exploitation, a heap spray is a way to manipulate memory by controlling heap allocations and placing arbitrary code in a predictable place.  This allows the attacker, when controlling the crash, to trick a program into going to said predictable place and gain code execution. Figure 2 represents the attempted delivery of such an attack via MSF.

FIGURE 2: MS12-037 IE Col Span attack

On the Windows 7 VM, when browsing to my attacker server, http://192.168.220.145:8080/JwJKD1Sjq, via Internet Explorer, EMET immediately responded with an application mitigation, shut down IE and popped a Tray Icon notification as seen in Figure 3.

FIGURE 3: EMET blocks HeapSpray attack

Given that EMET also writes events to the Windows Application Event Log, enterprises are afforded an additional monitoring opportunity as a result. No matter your Windows event collection mechanism, be it Windows Event Collector, Audit Collection Services (ACS), OSSEC, Snare and Splunk, or your preferred method, you can add an alerting mechanism (you may be feeding a SIEM) to give you a heads up when a client machine triggers an EMET event. Regardless, Figure 4 represents the Event Viewer perspective on our attack from Figure 2.

FIGURE 4: EMET event in Event Viewer

Another example includes the Mandatory ASLR mitigation. Address space layout randomization (ASLR) randomly arranges the positions of key data areas, to include the base of the executable, as well as position of libraries, heap, and stack, in a process's address space. Note that, as indicated in the EMET User’s Guide, EMET’s mitigations only become active after the address space for the core process and the static dependencies has been set up. Mandatory ASLR does not force address space randomization on any of these. Instead, Mandatory ASLR is intended to protect dynamically linked modules, such as plug-ins. When I browsed my Metasploit instance configured with the Internet Explorer CSS Recursive Import Use After Free module (MS11-003) enabled Internet Explorer was again terminated as seen in Figure 5. 

FIGURE 5: EMET Mandatory ASLR notification

Last but not least, I tested the Certificate Trust (Pinning) feature by manipulating the pinned certificates for login.live.com. EMET 4.0 protects the likes of Live, Yahoo, Skype, Twitter, Facebook and Office 365 by adding extra checks during the certificate chain trust validation process, with the goal to detect man-in-the-middle attacks over an encrypted channel. By default, EMET pins the certificate for a website to the good, trusted Root CA certificate; login.live.com is pinned to Baltimore CyberTrust Root, Verisign, GlobalSign Root CA, and GTE CyberTrust Global Root, as these are the Root CA certificates that are expected to have issued a certificate for login.live.com. I arbitrarily removed these and imported a Thawte Windows Trusted Root Certificate (trusted by Windows). This resulted in EMET sounding off with another “I don’t think so” as seen in Figure 6.

FIGURE 6: EMET trusts you not

As Thawte is clearly not the Root CA that issued the certificate for login.live.com, EMET flagged the SSL cert. By pinning the right certificates’ websites to their expected Root CA certificates, you can detect scenarios where a certificate is fraudulently issued from a compromised Root CA or one of its intermediates.

For you command line fans, you can choose to utilize EMET_Conf.exe. You’ll need to set C:\Program Files\EMET 4.0 in your PATH statement if you wish to call EMET_Conf.exe from any prompt. EMET_Conf.exe allows you to add applications, list those already added, list enabled mitigations and trusts, as well as remove, modify, import/export, and configure.

Remember, for those of you with enterprise deployment responsibilities, EMET can be deployed and configure with System Center Configuration Manager (SCCM), and EMET system and application mitigation settings can be configured via Group Policy.

In Conclusion

The release of version 4.0 brings EMET squarely in sight for users who may have been hesitant to utilize or deploy it. Now’s the time to investigate and engage (wait, that’s Star Trek). EMET 4.0 adds a layer of protection that friend, and EMET’s #1 fan, TJ O’Connor refers to as “creativity in defense”; I'll give him the closing comments:

"All too often the balance of creativity favors the attacker. Attackers overcome difficult exploit mitigation strategies by hurdling over them with creative attack strategies. Attackers have succeeded with creative techniques like heap-spraying, ROP Gadgets, SEH Overwrites, or ASLR partial over-writes. EMET 4.0 returns the balance of creativity to the defender. Instead of looking for fixed known signatures of attack, EMET 4.0 looks for the adversary trying to hurdle over the mitigation strategy. Because of this, EMET can identify a novel attack and stop it without previous knowledge of the attack. Its the most overlooked game changer in a defense strategy." 

Remember, test and tune before going full tilt boogie but know that EMET adds defense-in-depth for one host or an entire enterprise, even in the face of 0-days.

Ping me via email if you have questions (russ at holisticinfosec dot org).

Cheers…until next month.

Acknowledgements

Gerardo Di Giacomo, Security Program Manager, Microsoft Security Response Center (MSRC) Software Security Incident Response team

toolsmith: Visual Malware Analysis with ProcDOT

 

Prerequisites/dependencies

Process Monitor

GraphViz

Windows or Linux operating system

Introduction

As I write this I’m sitting in the relative darkness of the HolisticInfoSec lab listening to Random Access Memories, the new release from Daft Punk, and literally freaking out over what Time magazine’s Jesse Dorris has glowingly referred to as a “sound for which the word epic seems to have been invented.” Follow me as I step way out on a limb and borrow from Dorris’ fine review to create a musical allegory for this month’s topic, ProcDOT. Dorris describes a “world in which the bounties of the past, present and future have been Tumblr’d together into a stunning data blur.”[1] I will attempt to make this connection with what ProcDOT’s author, CERT.at’s Christian Wojner, refers to as “an absolute must have tool for everyone's lab.” This is a righteous truth, dear reader; those malware analysts amongst you will feast on the scrumptious visual delight that ProcDOT creates.

We’ve not discussed visualization tactics in quite a while (March 2010) but read on, the wait will be justified. ProcDOT, as described in Christian’s March 2013 blog post, correlates Windows Sysinternals Process Monitor log files and PCAPs to an investigation-ready interactive graph that includes the animation of a malware infection evolution based on activity timelines.

Christian gave me the full picture of his work creating ProcDOT to be shared with you here.

ProcDOT is the result of two ideas Christian had over the last few years. Initially he was thinking about the benefits of correlating Process Monitor logs with PCAP data to simple line charts with time and peaks as well as the ability to define tags for specific data situations. Sometime later, at the end of a malware investigation for a customer, he came to the point where he wanted to explain the characteristics of the underlying infection and depict the interaction of the malware's components as part of his final report. Christian found that a simple verbal description was both massively inefficient and insufficient at the same time (I confirm this shortcoming as well). Christian’s thinking moved to the “big picture” in terms of a graph with nodes for the relevant objects as files, registry keys, etc. and edges for actions between them.

He then took the time to experiment with the Process Monitor logs he’d captured while trying to strip them down to the relevant content. This content he then manually converted to fit the input format of AT&T’s Graphviz as chosen as a renderer for graphing. And there it was; a picture can tell a thousand words. It immediately became easy to understand all the aspects of the infection in one glance, even without any verbal explanation. That said, the manual activities to get to this result took about 50% of Christian’s time during report generation and he had not yet included PCAP data at this point.

As the high potential of this approach proved itself obvious, Christian started to think about a tool that might take advantage of all this potential while bringing behavioral analysis a step further and making it accessible to non-malware analysts. Thus was born the ProcDOT project.

As ProcDOT is now close to its first official release it is actually possible to automatically generate such a graph within seconds while also considering the information in an optionally supplied PCAP file correlating them with the Process Monitor logs. ProcDOT’s infection evolution animation capabilities also eradicates the downside of older graphing techniques lacking the ability to effectively visualize the aspect of time.

Christian’s road map (future think) for ProdDOT includes:

·         Export capabilities for the graph

·         Consider and provide much more information of PCAP data

·         Time and context-dependent ranges of frames/events

·         Customizable color themes

·         Notes and tags

·         Better GUI support of filters

·         Session related filters

This is a tremendous project and I look forward to its long life with ongoing support. As we run it through its paces I am quite certain you’ll come to the same conclusion.

ProcDOT Preparation

Christian has provided good documentation, including some easily avoided pain points that are worthy of repeating here. Process Monitor’s configuration needs to be tuned to ensure ProcDOT compatibility.

In Process Monitor:

·         Under Options, disable (uncheck) "Show Resolved Network Addresses"

·         Via Options à Select Columns, adjust the displayed columns

o   To not show the "Sequence Number" column

o   To show the "Thread ID" column

Figure 1 exemplifies the correct Process Monitor configuration.

Figure 1: Process Monitor configuration to support ProcDOT

ProcDOT also needs to know where its third party tool dependencies are fulfilled.

In ProcDOT, under Options:

·         Choose your Windump/Tcpdump executable as a fully qualified path

·         Choose your Dot executable (dot.exe) as fully qualified path

Figure 2 shows my ProcDOT configuration as enabled on a 64-bit Windows 8 analysis workstation running the 64-bit version of ProcDOT. Keep in mind that the ProcDOT project releases a version that runs on Linux as well.

Figure 2: ProcDOT tool path configuration

ProcDOT visualization

I worked with a couple of different samples to give you a sense of how useful ProcDOT can be during runtime analysis. I started with a well detected Trojan dropper (Trojan/Win32.Qhost) from a threat-listed URL courtesy of Scumware.org, “just another free alternative for security and malware researchers,” to trace interesting behavior when executing 3DxSpeedDemo.exe on a victim system. The MD5 for this sample is 20928ad520e86497ec44e1c18a9c152e if you’d like to go get it for yourself. Alternatively, if you’d like to avoid playing with malware and just want the Process Monitor CSV and related PCAP, ping me via email or Twitter and I’ll send them to you. I ran the malicious binaries on a 32-bit Windows XP SP3 virtual machine, capturing the related Process Monitor CSV log and the PCAP taken with Wireshark, then resetting to a clean snapshot for each subsequent analysis. You need to ensure that you save your default Process Monitor .PML file to .CSV which is easily done by selecting Save, choosing All Events and the CSV format. I copied the .PCAP and .CSV files from each run to my workstation and created visualizations for each.

Loading ProcDOT and readying it for a visualization run is simple. In the UI, select the appropriate CSV from Procmon-CSV field and PCAP from the Windump-File field. Note that the selection window for Windump-File defaults to Windump-TXT (*.txt); simply switch to Windump-PCAP (*.pcap) unless you actually generated text results. Check the no paths and compressed boxes, and hit Refresh.

This will generate an interactive graph, but you won’t yet see results. You now must select the Launcher, ProcDOT will analyze the Process Monitor file, then ask you to select the first relevant process. This is typically the malicious executable (double-click it) you executed on your virtual machine or intentionally compromised system; again, 3DxSpeedDemo.exe for my first run, as seen in Figure 3.

Figure 3: ProcDOT malicious process selection

Hit Refresh one more time and voila, your first visualization.

A few ProcDOT navigation tips:

1)      Hold CTRL and roll the scroll wheel on your mouse to zoom in and out.

2)      Hold your left mouse button while hovered over the graph to move it around in the UI.

3)      Double-click an entity to zoom in on it.

4)      Right-click an entity for details. Hit ESC to remove the highlighting.

At the bottom of the UI if you click the film click, ProcDOT will move into playback mode and step through each process as they were captured. Remember our mention above of infection evolution animation capabilities that give you the ability to effectively visualize the aspect of time? Bingo.

Check out the Legend under help (?) for the breakdown on the symbols used in graphing.

As I played back the Win32.Qhost infection, Frame 91 jumped out at me where Thread 1168 of the cmd.exe process (PID 1828) wrote data to the hosts file as seen in Figure 4.

Figure 4: ProcDOT captures Win32.Qhost writing to the hosts file

Oh snap! I love malware that does this. I jumped back to my malware VM, re-executed the malware, and captured the hosts file from C:\Windows\System32\Drivers\etc.

Figure 5 gives you an immediate sense of who the players are in this little vignette.

Figure 5: You want me to login where?

The IP address 91.223.89.142 is indeed in the Russian Federation but is not the appropriate A record for odnoklassniki.ru, or mail.ru, or vk.com, or ok.ru…you get the idea. I find it ironic that a seemingly Russian perpetrator is targeting Russian users as Eastern Bloc cybercriminals favor spreading their little bits of joy beyond their own borders. Just sayin’.

The Zbot sample I analyzed (MD5: 58050bde460533ba99d0f7d04eb2c80a) made for great network behavior analysis with ProcDOT. I can’t possibly capture all the glorious screen real estate here, but Figure 6 should give you an idea of all the connections spawned by explorer.exe.

Figure 6: ProcDOT network analysis

So many avenues to explore, so little time. Take the time, it’s a rabbit hole you definitely want to go down. There’s so much value in ProcDOT for malware analysts, incident responders, and forensicators. Paint a picture, cut to the quick, “the bounties of the past, present and future” await you in a “stunning data blur” created by ProcDOT. See Figure 7 for enough proof to motivate you to explore on your own.

Figure 7: A stunning data blur…

In Conclusion

We’ve covered some truly kick@$$ tools already this year; Violent Python, SET, Redline, and Recon-ng put ProcDOT in some major company, but if I were able to vote for Toolsmith Tool of the Year in 2013, ProcDOT would be right at the top of my list. The current release is a still an RC, if you find any bugs let Christian know. The roadmap is solid so I am really looking forward to the stable releases soon to come. In particular, export capabilities for the graph will be a big step. Again, sample CSVs and PCAPs are available on demand.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

---

[1] Dorris, J. (2013, MAY 27). Robots, rebooted. electro-pop duo daft punk's triumphant new record. Time,181(20), 60.

Bredolab author jailed, rehash of Bredolab analysis

Just read that the Bredolab botnet author was sentenced to 4 years in prison in Armenia.
In July 2010, when Bredolab was in it's heyday I used Netwitness Investigator to do analysis of a Bredolab-infected host. In honor of Georgy Avanesov's arrest, following is a reprint of the resulting toolsmith article. Bredolab samples and PCAPs available upon request via email or @holisiticinfosec. Netwitness is now in version 9.7.5.4, so some of the guidance and how-to herein may have changed.

Prerequisites

Windows operating system (XP/2003 or later)

Introduction

As I write this month’s column I’m on a plane returning from the 22^nd Annual FIRST Conference in Miami. As always, in addition to a collection of the world’s finest computer incident response teams, there were a select number of vendors. I will be honest when I admit that I typically avoid conference vendor booths unless the swag is really good, but some of my favorites were in attendance including Mandiant and Secunia. When I noticed the NetWitness booth I was reminded of the suggestions I’d heard suggesting NetWitness Investigator as a toolsmith topic. During Robert Rounsavall’s FIRST presentation, Forensics considerations in next generation cloud environments, he made mention of the fact that the Terremark teams make use of NetWitness offerings on their high throughput network capture platforms. Incident responders, network analysts, and security engineers typically can’t get enough of good network capture tools; the reminder triggered by the NetWitness booth presence clearly indicated that the time had come.

Specifically, NetWitness Investigator is part of a suite of products offered by NetWitness that are designed to capture network traffic and use the resulting data for business and security problem analysis. Others include Administrator, Decoder, Concentrator, Broker, Informer, and the NwConsole. Most NetWitness applications are commercial offerings, but Investigator is freely available and quite useful.

Installing and configuring NetWitness Investigator

Installation is point and click simple. Accept defaults or modify installation paths as you see fit. You will need to register the Computer ID generated for the host on which you’re installing that is generated as part of the license key. Provide a valid email address; you’ll be sent a link to activate your installation for first use.

Keep in mind that by default NetWitness Investigator does phone home for new updates and will reach out to the NetWitness web service to offer you the most recent FAQs, News and Community posts in the

Welcome page. If you prefer otherwise select Edit, then Options, and uncheck Automatically Check for Updates as well as Allow Investigator to Reach Internet.

If you don’t have WinPcap installed you will be prompted to do so; WinPcap 4.1.1 is bundled with the installation package.

Under View be sure to enable the Capture Bar as it will present a Capture icon and Collection selector at the bottom of the NetWitness Investigator UI.

You can also pre-define the interface from which you’d like to capture via the Options menu as described above.

Using NetWitness Investigator

The NetWitness Investigator (NI) Welcome Page provides useful FAQ; read it as you get underway.

NI allows you to either capture data directly from the host network interfaces, including wireless adapters, or import network captures from other sources and its use is built around Collections. The free version of NI doesn’t offer Remote Collections as they are specific to retrieving data gathered by other NetWitness commercial offerings. That said you can create Local Collections.

Ctrl + L will pull up the new Local Collection UI, you can also click Collection, then New Local Collection from the menu bar or click the create icon from the Collection toolbar.

I called my collection bredolab (you’ll learn why shortly) and will refer to it hereafter.

Once you create a collection right-click it then connect to it.

You know have two options, capture or import.

Capture

To capture, use the Capture Bar, select the already-created Collection or create a new by collecting the Capture icon first. Once you click the Capture icon NI will capture network data until you click the Capture icon again to halt the process.

Import

Right-click the already-created Collection to add data via the Import Packets options.

Configuring NetWitness Investigator

Select a PCAP file from your local file system, and click Open.

I worked primarily with imported PCAPs, though testing NI’s capture capability proved successful. I did find that in resource-limited virtual environments capturing network traffic with NI causes fairly significant VM grind.

As I was testing NI in the toolsmith lab a golden opportunity to put it though its motions presented itself via the SANS ISC Diary. The Lenovo support site had been discovered to be compromised and propagating the Bredolab Trojan via an embedded IFRAME. As I had literally just been to the Lenovo site to update my laptop BIOS (I had not experienced the malicious behavior) I was pleased with the near real-time relevance and the opportunity to check NI against a new sample. The CyberInsecure article called out the exact malware URL that the IFRAME pointed to (hxxp://volgo-marun.cn/pek/exe.exe) so I grabbed it immediately via my malware sandbox VM. After firing up Wireshark on my VM server, I executed exe.exe (great name) and captured the resulting traffic.  I imported the resulting bredolab.pcap (email me if you’d like a copy) into NI and compared results against details provided in the Lenovo compromise article. While this is a really small PCAP it serves well in exemplifying NI features.

Claim: The malware “receives commands from C&C server with domain sicha-linna8.com”

Validation: Check. Right out of the gate we can see sicha-linna8.com as part of the Collection Navigation view, under Hostname Aliases.

Bredolab sample collection navigation

Left-click the hostname alias result to drill into it.

Right-click it to evoke bonus functionality such as SANS IP History, SamSpade, and CentralOps.

Drilling in the Hostname Alias entry reduces the Service Type findings to just HTTP and DNS traffic which is useful as they are the primary services of interest with this sample. As seen in Figure 2, we can drill further into the single referenced DNS session. The resulting Session view, using the Hybrid option, shows us both a thumbnail view and session details. Further Content options are presented in the lower pane with additional functionality such as, were it relevant, rebuilding instant messaging (IM) and audio, as well as mail and web content reconstruction. The Best Reconstruction option is tidy; it organizes into the three packets for the DNS session represented as the two request packets (as hex) and the response from server.

DNS session content

You can make use of Google Earth as well, if installed. But be sure to default your private IP addresses to your local latitude and longitude. As if we hadn’t already imagined or determined it so, sicha-linna8.com is attributed to the Russian Federation (RU).

Click the Google Earth icon in the Session view.

Satellite imagery does a fair job of bearing that out, although, but unless I’m mistaken Figure 4’s reference pointer looks to be more like China.

Google Earth view of DNS request domain location

Now, I’m just being silly here, but again NI justifies my being so with its capabilities.

As mentioned above, the malware “receives commands from C&C server”. Hmm, that sounds like a bot. Duh, ok Russ, prove it. Navigate back to the Collection summary via the URL window, scroll down to the Querystring reference and click [open]. See, I told you so.

Hello, I’m a bot

That would be the HTTP GET equivalent of calling home to the mothership and requesting mission orders. As if action=bot and action=report weren’t enough for you, the fact that the Filename reference in Figure 5 is also controller.php really help you reach a reasonable conclusion.

By the way, Trend Micro’s Bredolab summary (not specific to this sample) will give a good understanding of its behavioral attributes, but there should be no surprises.

There are endless additional features including the use of breadcrumbs to help you leave a trail as you navigate through large captures, excellent reporting capabilities, as well as the ability export sessions to a file (PCAP, CSV, XML, HTML, etc.) or a new or different collection.

If you click Help, you’ll be offered the 168 page NetWitness Investigator User Guide, which will do this tool far more justice than I have. Consider it required reading before going too far down the rabbit hole on your own.

In Conclusion

There’s much more that I could have covered for you regarding NetWitness Investigator, would time and space have allowed it, but hopefully this effort will get you cracking with this tool if you haven’t already partaken.

NetWitness Investigator is really slick and I’m pleased enough with it to declare it a candidate for the 2010 Toolsmith Tool of the Year to be decided no later than January 2011.

Check it out for yourself and let me know what you think.

Cheers…until next month.