Peter and I have been busy planning for CanSecWest in a week. The course, Advanced Memory Forensics in Incident Response, is constantly evolving. It has been about a year and a half since Memoryze was released, and just over a year for Audit Viewer. Honestly, it seems a lot longer, but that is not a bad thing. This week my team will be handing over to QA Windows 2003 64-bit support. While that is in testing, Peter will be making improvements to Audit Viewer that you the user have recommended, and he will be verifying everything works correctly with the 64-bit output. The Malware Rating Index (MRI), which is in Audit Viewer, really changes the case studies in the training. For some exercises, we have to turn MRI off because the malware becomes obvious if you know how to use the tool. I expect MRI will evolve a lot over the next six months as we think of news ways to visualize, sort, and search the data as well as identify new pieces of data to collect. If you are curious how visualization and sorting can help, check out how Harlan Carvey and Chris Pogue use it.

We have gotten a lot of great feedback from the user community, but what Windows operating system support or feature would you like see next? Yes, MANDIANT Intelligent Response has a roadmap, but Memoryze allows us to play a little bit. It is really a labor of love. So let us know what you think. You can reach us at peter.silberman or james.butler plus company name.com. We currently support:

- Windows 2000 SP4
- Windows XP SP2 and SP3
- Windows Vista SP1 and SP2 (better installer coming in next release)
- Windows 2003 SP1 and SP2
- Windows 2003 SP2 64-bit (** next release **)

So if you cannot make the training at CanSecWest in a week, Black Hat USA has just opened their training schedule, and we will be there for the weekend and weekday offerings of Advanced Memory Forensics in Incident Response. I hope to see you soon. Keep your eyes open for official update releases of Memoryze/Audit Viewer and Webinars/presentations.

I’ve had the opportunity to lead a number of MANDIANT’s APT investigations recently, and am looking forward to sharing some of my experiences with our audience. One common thread in many of the investigations I have worked is that the APT will use simpler malware, methods, and techniques – until it no longer works and they are forced to break out something a little more advanced from their arsenal.

The attackers will use more sophisticated methods as needed, and can get incredibly advanced and inventive and just “disappear” from the radar of responders if they really have to.  There has been a lot of chatter on the Internet lately about recent attacks and how the malware and the Command and Control channels aren’t very sophisticated.  But why use sophisticated techniques if you don’t have to?

Think about it – if you are a car thief and the car you are going to steal is not locked and has the key in the ignition – why pick the lock and hotwire the car? It doesn’t mean that the thief can’t pick the lock; it just means they don’t need to.  That same thief may be capable of breaking in to a car that has a locked door, a car alarm, the club, and low-jack – and still get away with it if they are advanced enough and really want the car bad enough (think “Gone in 60 seconds“) .  We have seen everything from the very simple – placing malware in a user’s start-up folder (yes, I actually saw this on one of my engagements) – to the pretty advanced – malware that dropped an NDIS driver capable of monitoring and modifying network traffic at the kernel level, implementing its own TCP/IP stack in the kernel, and providing remote access to a machine that would bypass host-based firewalls, IPS…etc.

During the webinar we will talk about the techniques the attackers use and will go into more depth on a few of the case studies in our recently released M-Trends report.

Oh, and you may be asking yourself what the link is between the name of the webinar “Silent But Deadly”, and what we will be discussing.  We have seen evidence of the APT active and undetected in many victim networks for very long periods of time – up to years in some cases.  Hence, the “silent”.  And, while the result of these prolonged intrusions may not be deadly, they can often be costly, which is very bad for business.

We hope to see you on Thursday!

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.

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.

A caveat within MRI I that I want to talk about is Process Path Verification. This rule set is very powerful but there are two ways to define to paths. Neither is documented because currently there is no documentation on MRI.. The first method of specifying a process path is to specify an absolute path such as this:
calc.exe:\windows\system32

MRI interprets this as the only valid path for calc.exe is \windows\system32\calc.exe. However, if I wrote the rule like:
calc.exe:\windows\system32\

MRI would interpret this as calc.exe can be run from any sub directory as long it’s a sub directory within \windows\system32\*

The reason this is important is it gives you flexibility in writing definitions. If I don’t want to specify the exact location of iexplore.exe I can say it needs to be launched from \program files\. This may prove to be too loose, and I may change this behavior going forward. For now you have the flexibility to specify absolute paths or sub paths.

The next “undocumented” tidbit that I want to discuss is within two behaviors. These behaviors actually have the ability to use regex when trying to match up their values. I did not build the regex option into the UI so it has to be manually added to the AuditViewerConfig.xml. The two XML lists that can take regex expressions are IgnoreFilesList, and ProcessSuspiciousHandleList. The regex elements are, IgnoreFileRegex, and HandleRegex. An example IgnoreFileRegex looks like:
<IgnoreFileRegex>mshist.*\\index.dat</IgnoreFileRegex>

This rule specifies that any file matching this regular expression should be ignored when doing process scoring. You can get creative just be careful.

An example HandleRegex looks like:
<HandleRegex>*:.*-7$:mutant:known conficker mutant</HandleRegex>

It breaks down like this:
Process: Regular Expressions : handle type: description

It breaks down like this:
Process: Regular Expressions : handle type: description

This allows you to get more out of your suspicious handles definitions.

Finally, I’d like to take a second to reiterate something I stated at DC3. The “Verify Digital Signatures” option in Memoryze and Audit Viewer wizard can ONLY be run when doing live memory. It is not possible to enable it when doing dead memory analysis. Which means the address scoring is not possible on dead memory, behavioral analysis still works on dead memory. If you are going to acquire memory, please run live analysis jobs as well as acquisition. This way you get the most information possible off the machine. The second thing I wanted to reiterate is that verify digital signatures is great, it really helps potentially speed up an analyst’s job. However, we are only verifying the digital signatures exist and are valid on disk. We are not verifying the module in memory hasn’t been modified. If a userland rootkit exists (again shame on the authors) then we won’t report that. It’s important to remember this. Verifying modules in memory short of doing rootkit detection is not a trivial task. The windows loader is a beast, a behemoth it does a lot to make verification in memory to disk is very hard (not impossible). Thanks again for all the interest in M-Trends, Audit Viewer and Memoryze. As always feedback is always appreciated.

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.

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!

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.

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.”

My talk will discuss the Advanced Persistent Threat.  I will be walking attendees through APT intrusions from compromise to remediation.  Throughout the talk, I will provide a few demos and will dive deep into the forensic techniques our investigators use in the field.

I’ll even be showing a sneak peek of the M-TRENDS report that provides statistics and intelligence gathered by MANDIANT investigators on all Advanced Persistent Threat cases we have worked.  A lot of hard work has gone into developing this report and its data so it’s sure to enlighten even the most experienced APT investigators.  More on M-TRENDS to come so stay tuned to the blog and our website.

If you’re lucky enough to call Miami home, or will be at the [S4] conference, shoot me an email to talk shop while I am down there.   kris.harms (at) MANDIANT (dot) com

See you there!

Between informational sessions on the latest cyberspace issues, stop by MANDIANT’s booth (#51) to speak with our knowledgeable staff and gain insight into how we differ in response to cyber security incidents. Don’t forget to grab a souvenir stress ball once we have answered all your questions!

Booth Staff:

• Kevin Albano – Consultant
• Michael J. Graven – Director
• Tim Treat – Program Manager

You can find details about the VM on the project summary page on Google Code. You can also get the VM via the downloads page.

The VM is still a work in progress. I would like to add additional applications, especially those that use different application frameworks, but the applications that are there should work. I really hope that some people at the conference will get excited about the project and contribute some additional content that can be included on the 1.0 release.

If you would like to contribute some effort or a vulnerable application or just have some comments / criticism, I’d love to hear from you at chuck.willis (at) mandiant (dot) com.

I will be speaking about this project at the OWASP AppSec DC Conference. I hope to see you there!

Chuck

Overall, I think that the paper has some very interesting data and statistics. As Chris Wysopal at Veracode pointed out, it provides some good evidence to back up the seemingly common sense idea that white box testing (where the testers have access to source code, design documents, and internal resources) is more likely to find certain issues than black box testing. I believe that this is the case for most, but not all, types of issues. Again, the study appears to support this notion by showing that some issues types (such as Insufficient Authorization) are more likely to be found by black box testing.

I think that this study validates the approach that Mandiant takes toward conducting web application assessments. We always try to convince our clients to let us use both black box and white box techniques. When combined, these approaches allow us to find and validate different types of issues in different ways and provide better coverage in less time. It also allows us to easily eliminate false positives through manual testing.

A couple words of caution when reading the WASC paper, however. First, the titles of some of the tables and graphs are correct, but could be misinterpreted. For example, P. 9 is titled “The probability to detect the most risky vulnerabilities in Web applications (% Sites BlackBox & WhiteBox)”. What this figure is showing is the percentage of web sites tested with the different techniques which were found to have the issue shown, not the likelihood of actually detecting the issue if it exists.

So, it could be that only 44% of the sites subjected to white box testing had Credential/Session Prediction issues, in which case the white box technique was “perfect”. It could also be that 88% of those sites had the issue and the white box technique only found half of them. In all, this study did not appear to look at “false negatives” in determining what issues were missed, which is understandable since that is very difficult to account for in a study of this type.

The other word of caution I would propose is that there is no mention at all in the document of false positives, making it unclear how many of the findings included in the study were real issues in the sites tested. False positives can be very common when using automated processes, including external web application scans and source code scans. I would expect that the black box statistics in the paper would have accounted for false positives to some degree since manual effort was included, but that is just an assumption.

In summary, a great study with some good numbers, but I’d take them all with a grain of salt and use them as trends and ballpark figures rather than as ground truth.

Chuck

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.

The position is in the San Francisco, CA Bay area. Resumes to recruiting@mandiant.com. Find the full description at http://mandiant.com/jobopenings/FEDS0800.htm

So far, I have incorporated some intentionally vulnerable web applications, along with old versions of phpBB and WordPress. I plan to keep adding applications as time allows up until the conference when the first version will be released. I also hope that my talk will spur some interest and get some people to contribute additional applications. In addition to “standard” web applications, I would like to include some applications with AJAX and Adobe Flash client interfaces.

I will post again when the project is available for download. If you have a vulnerable web application you would like to see incorporated or are otherwise interested in helping out with the project, I’d love to hear from you at chuck.willis (at) mandiant (dot) com.

I also recommend that anyone interested in web application security attend the OWASP AppSec DC Conference. The conference is Thursday November 12 – Friday November 13th, looks to have a ton of great content lined up, and is very reasonably priced ($395 for two days). I speak on the first day and you can find details about my talk here.

Chuck

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.

The talk is made up of two completely different perspectives in the battle against malware. Ero is the CRO at  Virus Total (also a researcher with Zynamics). Virus Total processes tens of thousands of pieces of malware a day. Virus Total’s perspective is very unique; few if any companies process the amount of malware Virus Total processes. Ero will give you statistics on what Virus Total is seeing, such as the trends in packing, how many samples it processes and information about families it is tracking. This will be the first time these statistics will be made public.

I will be speaking from MANDIANT’s perspective. Our perspective differs from Virus Total in that we only deal with very high value targets and very specific custom written malware. It is no secret that MANDIANT is on the forefront of fighting the Advanced Persistent Threat (APT). Daily we are collecting and analyzing malware that has never seen the light of day. We have never given out details about the individual pieces of malware we’ve collected, and furthermore we’ve never given out statistics on how our overall collection of APT malware behaves. In this talk, you will receive all kinds of good information, such as what percentage of APT outbound communication is encrypted vs. plain text, or what percentage of APT is actually persistent on the host vs. run once. Some of the statistics I’ll be releasing may be very surprising, but also very enlightening.

Our talk will conclude with Ero and I doing our best  Ollie the Weatherman interpretation of where we think malware will evolve over the next year or two, and what we can do about it. I’m excited to give this talk because it’s a step away from what Ero and I usually present, and the content is so unique. If you’re unable to attend the conference look for the slides on our website. Hope to see you there! If you want to meet up for a beer, e-mail me peter.silberman@mandiant.com.

• examine the details of three pieces of malware we encountered while conducting PCI responses,
• survey typical weaknesses in point-of-sale systems, and
• recommend detection and mitigation techniques.

The broadcast is on Thursday, September 10 at 2:00 p.m. EDT (11:00 PDT, 18h00 GMT).

You can sign up here.

We’ll be taking questions before and during the presentation. Send us mail at contact@mandiant.com, or use the chat function during the webinar.

Every time I came into the Alexandria Virginia office, I was immediately wishing I could spend more time there.  Not only to work on challenging cases, but to learn.  The professionals that work here are top notch and I find myself gaining knowledge from every one of them.  To a certain extent, it is like coming home as many on the MANDIANT team are friends and past colleagues from the Air Force Office of Special Investigations (AFOSI) and my work as a government contractor.

MANDIANT is leading the way in information security services, incident response, and forensics.  The solutions that are being thought up here are beyond the cutting edge as many of them have never even been truly considered.  For example, we have a program called the Threat Identification Program (TIP).  MANDIANT consultants are using their product in combination with extensive indicators of compromise list compiled over many years to help organizations identify potential intrusions already in their organizations that they have not been able to find.  How can you claim to secure something you are not sure is already secure in the first place?  This type of forward thinking is needed to help protect businesses and organizations in the future.  Similar to detecting cancer, it better to detect it early before it gets out of hand.

MANDIANT strives to improve information security by sharing lessons learned in open forums.  Just this past week, I attended GFIRST teaching several forensic classes for the SANS Institute in addition to speaking twice.  Joining me at GFIRST were fellow MANDIANT colleagues David Ross, Scott Roberts, Wendi Rafferty to name just a few.  I attended David Ross’s talk in which he described techniques to perform process differentiation to find malware and evil left by hackers.  He was accomplishing this across 30,000 hosts in an enterprise environment.  Incredible.  He was utilizing MANDIANT’s MIR product and his experience as a consultant in multiple front-line incident response engagements to create new capabilities that seemed impossible just a few years ago.

From moving between Wendi’s Advanced Persistent Threat presentation to hearing about Scott’s experiences working in a security operation center for his customer it was clear that MANDIANT has not only been learning through their experiences, they were also giving back to the information security community.  This is the mark of a wonderful group.

MANDIANT’s dedication to improving the security space, community involvement, and responding to some of the most difficult information security incidents makes the decision to join the MANDIANT team an easy decision.

Rob Lee

Director

rob.lee@mandiant.com