Blackhat Europe, State Of Malware: Family Ties
Written by Peter Silberman
Ero and I will be in Barcelona presenting at Blackhat Europe 2010. Our talk is called State of
Malware: Family Ties. This talk focuses on malware families. We thought about interesting research we could do in the same vein as our last talk, State of Malware: Explosion of the Axis of Evil. We decided to look at malware families.
There’s a lot to gather from malware families, from a mass malware perspective looking at conficker, bagel, waldeac, storm worm, rustock, etc. Equally important is examining APT families. MANDIANT tracks over 20 different families. Each family means something different to us. When we see one family at a client site, we might immediately pull Indicators of Compromise (IOC) for other APT families that are closely related. If we find another group, we might quickly start figuring out what was exfiltrated because we know that group and its actors are solely there to move information out. A lot can be extracted from the families we track and that is why clustering malware into families from a targeted perspective is so important.
Ero and I wonder about a few things:
- 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.
Tags: Advanced Persistent Threat, APT, blackhat, MANDIANT
Malware Behaving Badly: Preview
Written by Peter Silberman
Hope everyone on the northern east coast is staying warm during snowpaclypse. Since I can’t go anywhere I figured now is the right time to write about an upcoming webinar I am giving with Michael Graven.
The webinar entitled Malware Behaving Badly is on Thursday, February 18, at 2:00 p.m. EST. The webinar title is a cute play on my DOD Cyber Crime (DC3) talk where I first introduced Malware Rating Index (MRI) into Audit Viewer (which is available for download).
If you saw my DC3 talk or viewed the slides and are wondering, “hey is this the same talk?” the answer is…well a little bit. The webinar will build off of a lot of the behaviors and theories I discussed at DC3. We will be addressing new behaviors as well as looking at APT vs Mass Malware behaviors. I’ve added two new configurable behaviors to MRI and did enough research to scrap a third. I’ll share those as well as give more real world examples of how malware exposes itself in memory.
For example the below listing shows the keylogger, the process and the file handle that process has. The file handle is actual the log file the key logger is writing too.
| Keylogger Name | Process | Log File |
| Klog | System | \Klog.txt |
| Advanced Keylogger | Explorer | \WINDOWS\Help\dsclientsock.hlp |
| Spector Pro | Explorer | \WINDOWS\system32\avoxnot\BEC7CA9645B2AF87DEEACD53B38B223FEE1C605C.zup |
If you didn’t catch my DC3 talk and didn’t understand the slides this is a good time to get an updated version of the talk. I’m going to focus on malware behavior, what it does when it’s installed that makes it stand out in memory. We will cover APT and Mass Malware, and specifically where we see their behaviors intersect. Some of these behaviors are horribly simple, i.e. flag svchost launched from directories other than \windows\system32. Some are as simple but may not be as obvious, for example flag svchost, or iexplore if they have a process handle to cmd.exe. These are rules that should never be true.
When discussing rules, I use that term loosely. Basically in Audit Viewer you now have the option to configure all this information. If you go to Operations -> Configure Malware Rating Index you can configure all these things and a few more not mentioned in this post but mentioned in the webinar. We will wrap up the webinar like always with a live demo. Live demos are the most fun really, it’s like NASCAR except it’s just reputation not lives on the line.
I hope you can join us, it should be fun.
If you would like to learn more in-depth about how physical memory analysis works, use Memoryze and Audit Viewer, understand MRI, or write your own malware rules, join Jamie and I at the CanSecWest training. CanSecWest specializes in technical, hands-on classes with an extremely low student-teacher ratio.
Tags: APT, Audit Viewer, CanSecWest, Fresh Prints Malware Behaving Badly, Malware Behaving Badly, Malware Rating Index, Memoryze, MRI, webinar
Combat the APT by Sharing Indicators of Compromise
Written by Matt Frazier
At MANDIANT, we value human intelligence – ground-truth, intelligent decision-making and adapting to your enemy’s tactics. Since expert humans can’t be everywhere, we’ve built a means to exchange enough ground-truth and decision-making so security experts can spend more energy applying expertise, less time parsing and pruning stale datasets and leverage their expertise across organizations and between compromises.
Historically, compromise data has been exchanged in CSV or PDFs laden with tables of “known bad” malware information – name, size, MD5 hash values and paragraphs of imprecise descriptions supplemented by ad-hoc exchanges between targets.
MANDIANT, inspired by field pressures, operation after operation, imagined a way to exchange not only indicators of specific compromises but structures which formalize the human-intelligence of decision-making, rules, exceptions, and ongoing adaptability. Our Indicators of Compromise (IOCs) were shaped operationally detecting real-world threats. We help our clients detect the APT right now, and they’re exchanging information about it using IOCs.
Conventional compromise datasets consist of table after table of immediately-stale data capturing few, if any, relationships. An Indicator of Compromise (IOC), however, is a Boolean decision tree that discriminates an indicator from a false-positive, theory from ground truth. What’s more, when you discover an exception or extension to a well-known-IOC you can describe it concisely and proactively, authenticate its source and re-evaluate your existing data to detect new instances of old compromises. This way, as a threat group adapts to your detections, you retain an IOC’s identity and maintain the value of intelligence shared with other targets over time.
Importantly, IOC is industry-standard XML so you already have tools and a community of experts who can comprehend, transform, and leverage new data immediately. Unlike many XML standards however, it’s simple – developed operationally with an eye toward staying adaptable, transformable, and scalable. IOC describes relationships which indicate compromise – this makes the format resilient to new data formats, data sources and decision engines.
At DoD CyberCrime 2010 MANDIANT will formally release this format and tools to leverage it in your investigations today. We’ll have full coverage of the release on M-unition – stay tuned.
Tags: APT, humint, MIR, sizzle, xml
DOD Cyber Crime: New Audit Viewer/Memoryze
Written by Peter Silberman
MANDIANT is going to be at DOD Cyber Crime this year. Jamie and I have both been heads down for many weeks now working on some pretty cool stuff. We are starting to come up for air and what that means for you is updates to Memoryze and Audit Viewer. We will be releasing new versions of each that coincide with DC3. I, along with many of my co-workers, will be presenting and attending. My talk abstract is very ambiguous so I thought I’d take a brief second to discuss both the talk and the changes to Audit Viewer and Memoryze.
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!
Tags: APT, Audit Viewer, DC3, DOD Cyber Crime, malware, Malware Rating Index, MANDIANT, Memoryze, MRI
. 21 Jan 10 | Conferences | Comments (0)
M-Trends: Advanced Persistent Threat Malware
Written by Wendi Rafferty
There are a lot of reports in the news about the types of malware being utilized by the Advanced Persistent Threat (APT) attackers. Our upcoming release of M-Trends will go into great detail about the types of malware, its capabilities, and how the attackers leverage a variety of malware throughout a breadth of victim organizations to accomplish very specific goals. Over the next week, the MANDIANT blog will feature excerpts from our upcoming M-Trends report that illustrate just how difficult it is to identify APT techniques.
The most significant commonality of APT malware is that it hides in plain sight. It avoids detection by using common network ports, process injection and Windows service persistence. Every piece of APT malware cataloged by MANDIANT initiated only outbound network connections. No sample listened for inbound connections. So, unless an enterprise network is specifically monitoring outbound network traffic for APT-related anomalies, it will not identify the APT malware outbound beaconing attempts.
A few of the most poignant stats about APT malware are listed below:
APT Malware:
- Average File Size: 121.85 KB
Most Common APT Filenames:
- svchost.exe (most common)
- iexplore.exe
- iprinp.dll
- wiinzf32.dll
APT Malware avoids anomaly detection through:
- Outbound HTTP connections
- Process injection
- Service persistence
APT Malware Communication:
- 100% of APT backdoors made only outbound connections
- 83% used TCP port 80 or 443
- 17% used another port
Because APT malware is so difficult to detect, simple malware signatures such as MD5 hashes, filenames, and traditional anti-virus methods usually yield a low rate of true positives. M-Trends will provide detailed information about how exactly organizations can posture themselves for success when fighting attackers with such specialized and sophisticated capabilities.
If you’d like to register for a copy of “M-Trends,” drop us a note at info(at)mandiant(dot)com otherwise, keep your eyes peeled to our blog and http://www.mandiant.com for the official release of “M-Trends.”
Special Thanks to Peter Silberman, the MANDIANT malware analysis team, and product engineers for their work in developing this information.
Tags: Advanced Persistent Threat, APT, M-Trends, malware analysis
. 15 Jan 10 | General | Comments (0)
M-Trends: The Advance of the Persistent Threat
Written by Wendi Rafferty
The Advanced Persistent Threat (APT) is an advanced persistent reality! It’s all over the news. Everyone seems to be either talking about it or affected by it. MANDIANT defines the APT as a group of sophisticated, persistent, and coordinated attackers that have been systematically compromising U.S. government and commercial computer networks for years. The vast majority of APT activity observed by MANDIANT has been linked to China.
MANDIANT has over seven years experience conducting Advanced Persistent Threat (APT) intrusion investigations for the U.S. government, the defense industrial base and commercial organizations. During that time, we’ve learned many things, and we want to share our lessons learned with the security community. A team of our APT experts has been working diligently on a report that we call “M-Trends.” M-Trends focuses on what the APT attackers do and how they do it.
Some highlights from “M-Trends” include:
- The APT isn’t just a government problem; it isn’t just a defense contractor problem; and it isn’t just a military problem. The APT is everyone’s problem.
- No target is too small, or too obscure, or too well-defended. No organization is too large, too well-known, or too vulnerable. It’s not spy-versus-spy espionage. It’s spy-versus-everyone.
- Classic “prevent and detect” techniques do not effectively counter the APT. The attackers can easily defeat normal defenses. They successfully evade anti-virus software, network intrusion detection and under-equipped incident responders. They use sophisticated techniques to conceal their presence: hiding malware on their target’s own hosts and exfiltrating data in its own network traffic. A staggering 100% of APT malware identified by MANDIANT made ONLY outbound connections from victim networks, 83% of which used TCP port 80 or 443.
- The APT’s goals are twofold:
- to steal information to achieve economic, political and strategic advantage.
- to establish and maintain an occupying force in their target’s environment, a force they can call on at any time. When the APT wants additional data from a target, they don’t need to re-establish a presence. They simply call on their existing assets, locate, steal and exfiltrate the data they need.
We will introduce “M-Trends” at a launch party during the 2010 DoD Cyber Crime conference in St. Louis, MO. The report authors will be there to answer your questions and share their knowledge. If you’ll be in St. Louis stop by and see us on Wednesday, January 27 from 6- 9 in the Crystal Ballroom at the Renaissance Grand.
Register for a copy of “M-Trends” and keep your eyes peeled to our blog and http://www.mandiant.com for the official release of “M-Trends.”
Tags: Advanced Persistent Threat, APT, M-Trends
. 14 Jan 10 | General | Comments (0)
