During our presentation we covered the lifecycle common to many Advanced Persistent Threat (APT) attacks and then outlined several case studies to illustrate countermeasures organizations have successfully deployed to combat the APT.  The following items were key points we covered during the workshop:

1.       “This can happen to you!” The time to begin preparing for these activities is now, prior to an incident.

2.       Organizations should define remediation success as removing today’s attackers from the environment and improving visibility such that subsequent attacks will be detected more quickly. It is not reasonable to define success as eliminating the APT threat, or as preventing the APT from re-compromising systems in the environment.

3.       Developing a remediation plan is not a one-size-fits-all process. Among other items, successful plans need to consider the attacker’s techniques and capabilities, the organization’s current visibility across their networks and systems, and resource constraints. Organizations can help prioritize remediation activities, given limited time and resources, by considering how each proposed activity helps detect, contain, or respond to the various stages of the attack lifecycle.

4.       MANDIANT has seen numerous organizations succeed at remediating APT intrusions by planning for and executing a remediation event, during which the organization isolates the environment and simultaneously implements several eradication, recovery and hardening activities. This approach generally increases the chance of successful remediation.

• Not following this approach in response to an APT intrusion generally increases the risk that the incident response effort will decline into a “whack-a-mole” situation.  In this type of situation, responders engage in a losing battle of remediating compromised assets as they are identified, while the attacker continues to compromise additional systems with different malware variants. Many organizations begin responding to APT compromises in this manner; which does not ultimately lead to success.
• This approach may not be appropriate in all situations or for other threat actors, however, we have generally seen this approach executed successfully to remediate APT compromises.

5.      The following activities tend to be critical remediation event activities; organizations should prepare for executing these activities prior to an incident.

• Isolating the WAN from the Internet.
• Blocking attackers’ known command-and-control domain names and IP addresses.
• Resetting passwords enterprise-wide (including all Active Directory infrastructure and any compromised accounts on other platforms).
• Rebuilding compromised systems.

These activities have formed the core of remediation event plans successfully executed by numerous MANDIANT clients.

6.       A few of the most critical hardening countermeasures include

• Ensuring Windows local administrator accounts are disabled or their passwords set to unique values on every system.
• Near-term, implementing application whitelisting on critical systems from which attackers can harvest password hashes en masse (e.g. domain controllers, mail servers, file servers).
• Blocking workstation-to-workstation communications using host-based firewalls.
• Patching third-party desktop applications that constitute the attack surface for spear-phishing attacks.

I hope you find the slides useful. If you have any questions regarding my post or from our presentation, please comment below.

I was able to catch several of the keynote and plenary sessions, as well as several breakouts later on. The published conference theme was “Teaming for Dominance” and “Training for Dominance.”  Without public-private collaboration between the entities that are fighting cyber crime throughout the United States victory against determined adversaries is nigh impossible. Also there is a shortage of properly trained professionals for dealing with cyber crime, and only by providing opportunities for training and education could the country pull together and get ahead.  This covered not only continuing adult education and formal training, but also initiatives for college and high school students as well. I was more interested in the secondary themes that I saw emerging in presentation or discussion: indeed there is a need to work together, cultivating defensive strengths through collaboration on intelligence and innovation, be it in education or implementation of the practice of forensics and incident response.

At the management and policy level, I listened to Jeff Stutzman of the DCISE, Alan Paller of SANS, and panel discussions from leaders in the FS-ISAC, DHS, DoD/DCISE and DSIE (all organizations that are responsible for coordinating information sharing across large groups of important organizations). Regardless of specific messaging items, most of these leaders seemed to feel that too much was getting lost in the large scope of the problem set, and the path to real progress was by focusing on a few key components. Mr. Stutzman talked about focusing on education and collaboration, Alan Paller spoke about security leaders who were making an impact by committing to only a few simple items that create real change (rather than succumbing to the temptation of lengthy checklists and guidance documents), and as the panel addressed the need for real-time information sharing, they admitted that basics needed mastering before more complex solutions could be attempted.

Several technical presenters put forth the message that Indicators of Compromise (IOCs) that describe complex forensic artifacts and innovative methods are the key to success in rapidly detecting intruders. Rob Lee talked about the state of modern forensics, and the DFIR community success story that has led to projects such as log2timeline. Rob also spoke about the next step in responder evolution: taking the information routinely found in timelines, and creating abstracted, generic patterns that always identified compromise, rather than always looking at specific signatures in a timeline. If that can be realized, organizations will be able to identify incidents as soon as an intrusion occurs, allowing for almost instant detection. At the conference MANDIANT’s Ryan Kazanciyan, Chris Nutt, and Mary Singh all cited the need for looking beyond simple signatures and traditional investigative paths in their presentations, which covered some of our best practices in IR and Disk Forensics. Several other speakers also cited the need for complex indicators as the key to success in large, noisy modern enterprise environments, and IOCswere mentioned in a variety of presentations and post-presentation discussions.

During the tradeshow, we spoke with a variety of representatives from different parts of government. Polling attendees showed that no one particular threat stood-out, but most attendees felt this was the year threat awareness went mainstream. Panelists talking about Information Sharing and Analysis Centers (ISACs) echoed this idea: that the time was now for automating the sharing of threat intelligence. In support of that idea, I was fortunate enough to be able to participate in a Birds of a Feather discussion session about potential for automating information sharing in the DCISE, and presented on OpenIOC and potential uses in creating a method of automated information sharing for threat intelligence.

Several of the DIB contractors that we spoke to talked about how they were making detection a top priority. The debate over prevention versus detection is still lively and undecided in many circles, but more and more vendors are focusing on detection as a critical need. It was encouraging hearing a lot of resonance with themes that we have long believed in:

• the ability to describe complex indicators of compromise is necessary for success,
• sharing threat intelligence is critical for the evolution of defense,
• and that belief in rapid detection as a top priority is gaining ground

I hope that the lessons learned, and discussions had at the conference, empower the responders who work with DC3 in the coming year. And that collectively we can help solve the ever-growing needs for better detection and threat intelligence sharing across so many critical sectors of the enterprise.

If you attended DC3 I’d love to hear your take on the conference and themes you noticed from presenters and attendees. If you were unable to go, slides from the MANDIANT presenters will be up soon.

• Do mass malware families share enough common attributes across families? Example, does conficker share code with waledac? If so, is it enough so that we could consider them members of a sub family. Also maybe proving they were written by the same author(s) or group of authors.
• Do mass malware families share code amongst APT samples? Example, this could mean that we find samples of subseven that match some of our APT backdoors (again just an example).

 
These two questions alone are very interesting because the results could indicate some author of a mass malware sample is also authoring malware for targeted attacks.
 
But we didn’t stop there. We also wondered:

• Do rootkits from rootkit.com have very high similarities to rootkits found by MANDIANT and out in the wild?
• Do APT samples of family A share enough in common to be also classified as part of family B? We can draw a lot of interesting conclusions if this is the case.

 
These are all interesting questions, but we had a lot of disappointments when doing the research and some ah ha moments where we thought about theories and realized why some wouldn’t be true. We also had some finds that we were surprised with, specifically regarding APT. We’ll be sharing the results on April 14th at 4:45. It should be fun. Our talk has a lot of diagrams, a lot of IDA screen shots, and a great video that Ero made.
 
If you can’t make it to Barcelona, we will be posting our slides and a follow up blog post. Stay tuned! I also have recently updated the slides for Advanced Memory Forensics in Incident Response for Black Hat USA to include an APT case study and a ton of additional information on observing the behavior of malware in memory.

The talk is going to be interactive. And dammit I don’t care if you don’t want to interact with me. I’m both very convincing, persistent and well…charming! You will feel compelled to join in on this talk. I promise. I know this because I’m bringing bribes… And yes, I’m bringing what you are thinking.

This talk will contain a brief intro to memory analysis, a FAQ etc. We are not going to waste much time on the nitty gritty since most people are not interested in how we chop off the last 12 bits to get a physical offset from a virtual address. I know, you just fell asleep a little.  During this talk I will make a case for why memory analysis is important. I will pull from pervious APT investigations where disk analysis failed and had to be used in conjunction with memory analysis. Finally, we will discuss MANDIANT’s Malware Rating Index (MRI). We will finish with real APT incident demos where I’ll walk through the investigation of an infected system with APT.

Now, a little more about MRI. MRI is a huge update to Audit Viewer.  Instead of going after a fish (malware) with a hook (signatures), I’m going after fish (malware) with a drag net (MRI). The goal of this feature is twofold. First it is going to  help pinpoint specific processes that should be investigated further while attempting to eliminate some of the non-suspicious processes and get them out of the analyst’s way. It’s also designed to try and make APT detection easier. A lot of work went into looking at our samples and how they behave etc, and coming up with definable behaviors that trap those little creatures. MRI is made up of two components. The first component is a definable behavior rule set that is completely customizable. It is made up of three different types of rules:

• Process Path Verification – allows users to define what processes should be launched from what directories. This triggers on malware that copies and names itself after svchost or other system processes to subdirectories within system folders. For example a default rule is that svchost can only be executed from \windows\system32. Any time we see it running from somewhere else we flag the process.
• Process User Verification – allows users to define what processes should be running under what users.  This triggers on malware spawning svchost for purposes of unmapping image bases or hiding dlls within spawned svchost. So, for example, if malware copies itself to system32\dllcache and then names itself svchost.exe, you can define a rule saying svchost.exe should be running as local service, network service, or system. When Audit Viewer see svchost running as administrator it gets flagged.
• Process Handle Inspection – this allows you to define specific rules pertaining to malware or generic behavior. For example a default rule is to flag svchost or iexplore anytime it has a process handle to cmd.exe. There is just no good reason for this to _EVER_ happen. You can also define rules based on specific malware, for example if a3c mutant is present then flag the process as being infected with sality.

All of these features are configurable from the UI by going to operations -> Configure MANDIANT MRI.

The second component of MRI is a process address space scoring mechanism. We will be releasing an update to Memoryze at DC3. The new release will contain bug fixes as well as a new feature called “Verify Digital Signatures.” When this parameter is turned on memoryze will perform a “digital signature check” on all loaded modules. This can only be enabled on live memory analysis. The digital signature check verifies the module on disk is digitally signed. We do a bunch of math and use our Least Frequency of Occurrence to trust modules that aren’t signed but occur in more than X% of processes. Where X is defined by the user. We won’t flag or catch modified binaries in memory. So if a rootkit is doing userland hooking (it should be ashamed) we won’t know about it because we are checking disk to determine if it is digitally signed. There are a lot of reasons why we can’t verify in memory digital signatures.  It might make an interesting blog to detail all the reasons. With that said, this new feature gives us a good working idea of how much of the loaded modules in the process address space are signed and therefore trusted. It’s had fantastic results thus far. I’ve been using it on old incidents to see if we could have sped up results using these new methods. The answer seems to be yes in a lot of cases.

After DC3 I’ll have more blogs detailing how you can use and write better rules for MRI. But for now there will be a default distribution that you can use and modify. Again, like always, Audit Viewer is open source and free. Which means you can see the logic and rules behind MRI. Memoryze is and will stay free.

If you are going to be at DC3 and want to grab a beer I will be there from Sun (night)-Weds. Unfortunately I’m going to be missing all the great talks on Thurs so I can leave to compete in the Tough Guy Challenge. You are more than welcome to join at this race in Northern England. As I understand it there are still some open slots! See everyone at DC3!

I know you’re wondering,  ‘Should I be interested in this talk?’ The answer is unequivocally yes. First, you get to hear my and Ero’s angelic voices, which alone is worth the price of admission (free).

Second, this talk runs the gamut of information. Ero will discuss volume, how much VirusTotal sees on a day-to-day basis. He will also cover popular families (I bet you can’t guess which is the most popular, and no it doesn’t start with my and end in doom). Ero will also discuss obfuscation, what trends Virus Total is seeing, what kinds of packers, etc.

I will discuss the Advanced Persistent Threat, specifically speaking about the malware these attackers leave behind. I will discuss how the malware commonly behaves, what it can look like, and why it’s so hard to catch these guys.

You will get interesting statistics like what percent of APT backdoors are detected by any engine VirusTotal supports. You might also see a statistic like what percent of APT uses encryption when communicating.

We’ll cover information that can be interesting to a network administrator trying to protect his company, a CSO who wants to understand the threat landscape better, forensicators who are trying to catch these guys, malware analysts who are curious about behavior, and those who just want to hear our voices!

Hope you guys can join us for a good time, I know Ero and I really enjoyed giving this talk at Source Barcelona and are looking forward to doing it again.

You can sign up for the webinar here.

We’ve gotten around to uploading the slides.  They include all the statistics we came up with for this talk. When you review the slides take a look at slide 16 “Complexity of Mydoom” and slide 17 “Complexity of Kraken.” These two slides depict control flow graphs of the popular malware Craken and MyDoom.  Notice how much functionality is crammed into these binaries. As an Anti Virus company that’s a lot of data and bytes to work with to generate a successful signature.

Now look at slide 44 “Sample BA”, it’s the control flow graph of an APT sample. Notice some differences? Our hope is this talk gets people thinking about the different types of threats, different malware families make to organizations, as well as the clear differences between APT and mass malware.

With this fix, our current technique to reconstruct what Meterpreter sent or received does not work. The Metasploit project has broken that ability successfully (something we expected). Our detection will evolve, and HD discussed some ideas he had to make detecting the Meterpreter binary harder. Currently, MSFF can still be used to identify the injected binaries in a process’s address space. The Meterpreter binary contains too much code and has too many features to effectively hide in memory. If and when HD patches the reflective loader to scrub Meterpreter’s binary data, we’ll update MSFF with some fix, more as a proof concept than anything else, to continue to identify the injected DLLs. Hope everyone’s recovered from Vegas!

A huge thanks go to Ping, Nikita, Jeff Moss, Val Smith and HD for putting the Metasploit track together. It was not easy, but it went great. A huge thanks to the defcon speakers, who were very flexible.

M-unition will focus on techniques and tools to identify and analyze indicators of compromise on a host or throughout an entire enterprise. While much of the content will leverage the tools and techniques we use, it is our desire to build upon others doing similar work in the community. At M-unition, we will share information to combat a whole host of problems. No pun intended.