@sroberts advanced persistent incident responder

Intelligence Concepts - F3EAD

One of the most talked-about intelligence concepts in information security today is F3EAD. Standing for Find, Fix, Finish, Exploit, Analyze, and Disseminate, this is a methodology for combining operations (in this case we’re talking about kinetic ops) and the intelligence process. While the Intelligence Cycle & SANS IR cycle are both useful, they are ultimately academic. If the goal is Intelligence-Driven Incident Response, we need to combine intelligence with ops, and that’s where F3EAD shines.

An Aside: Military Terminology in Security
A fundamental discussion that often comes up when you discuss intelligence (and a lot of other parts of information security) is the use of military terminology. This is a divided issue. The fact is that war is the single oldest and most studied adversarial conflict, and while security doesn’t have the gravity of a military conflict, I do find that the military has much to teach us.


Smallwars Journal F3EAD Diagram

F3EAD is about combining the operations cycle with the intelligence cycle so that they both feed each other. This process rose during the wars Afghanistan & Iraq (the second time) the teams involved were special forces (operations) and traditional all source intelligence teams (intelligence). We’ll break this into two major sections:


  • Find: The F3EAD process starts with targeting, deciding who the focus of the operation is.
  • Fix: Identify where the adversary is.
  • Finish: Use the processed information to complete a predetermined operational objective.

In a kinetic scenario, this process could start with a special operations team deciding to target a high ranking former regime member. Using available intelligence and telemetry, the team locates that target and initiates the operation to capture the target. After the capture, the team may take material related to the capture, including files, computers, and information from interrogations, and pass that to the intelligence team.


  • Exploit: At this point all information developed during the operations section is collected and enhanced. This can be correlated to the collection and processing steps in the intelligence process.
  • Analyze: The analyze process is the same as in the intelligence process: taking the collected information, developing it further, in this case to support the next find, fix, finish cycle.
  • Disseminate: Share the developed intelligence with relevant stakeholders including operations and other intelligence teams.

Following the operation, the intelligence team then begins their cycle based on the outputs from the operations team. This follows the traditional intelligence cycle process, but the key is the expected input and outputs are meant to enable operations. Thus operations enables the intelligence gathering while the intelligence enables further operations. In most cases, this tight coupling isn’t just based on products, but even putting the teams physically in close proximity to enable this synergy.

A Walk Through the F3EAD Cycle

Super Special Forces

Even if you don’t have a team of M-4 wielding SEALs (I know, seems like an oversight), the idea of combining operations with intelligence is the exact goal of that favorite buzz phrase: intelligence driven incident response.


Vendor X releases a new report about a new threat group operating in your vertical. You use this report as the beginning of your targeting.


The vendor report include indicators, which the incident response team uses to identify a group of compromised hosts. In some cases, depending on resources, an incident response team may enhance these.


The incident response team remediates the compromised hosts.


Here’s the key: after the finish/remediation the information collected during the incident response is gathered. This includes the information that started the F3 cycle (in this case the vendor report) but should also include the malware identified during the incident, network captures, information about the infrastructure, & anything and everything identified during the operations piece.


The intelligence team analyzes all the collected information. Their goal is to develop further targeting. A good example would be identifying other IP addresses associated with C2 domains using a tool like PassiveTotal.


The intelligence developed during the Analyze step is disseminated to other stakeholders. This includes the original operations team.

Takeaways from F3EAD

At its core, F3EAD speaks directly to two of the biggest challenges with the rise of the Threat Intelligence concept:

  • How is intelligence converted from data into action?
  • How are the results of security team actions converted into ongoing intelligence?

The first question gets nearly all the attention, and is certainly an interesting concept, but the second one is often the most applicable. Incident Response teams looking to improve often ask where to start with threat intelligence, a feed, a product, etc. In my mind the best answer, addressed by F3EAD, is to start with your own incidents. Teams can find amazing value in mining their past incidents, and at a price that beats any threat intelligence product.

More Resources

Intelligence Concepts - The SANS Incident Response Process

Getting away from the abstract to something a bit more distinctly DFIR we get to the (in)famous SANS Incident Response Process. The basis of SANS 504: Incident Response & Hacker Techniques this process attempts to codify the typical incident process into key steps. This is an essential process that helps form a cogent understanding of the incident process, but it’s limitations need to be just as well understood.

SANS Incident Response Process

SANS Incident Response Cycle

  • Preparation: Getting ready for incident response, creating documentation, building tools, etc.
  • Identification: This is about the first moment where the victim becomes aware an attack has occurred, hopefully by an internal process or alert. Hopefully not thanks to Brian Krebs or the FBI.
  • Containment: Containment is the processes of keeping further damage from occurring. This could involve deploying patches, blocking C2 access, or pulling a systems power cord out of the wall.
  • Eradication: In a malware centric response this is about remediating compromised hosts, removing implants, etc.
  • Recovery: Recovery is the process of restoring all business functions, such as bringing a compromised server back online.
  • Lessons Learned: The most commonly forgotten aspect lessons learned is about asking the question “How can we do better next time?” and avoiding the same mistakes twice.

A Walk Through the SANS Incident Response Process

Super crazy insane threat map gif

The SANS IR Process focuses on a typical malware based event, focused on a single threaded incident and response. For this case we’ll walk through a typical remote access trojan based incident.


Strategic preparation includes deployment of sensors, development of processes, system & network hardening, etc. For a malware incident such as this tactical preparation includes deployment of signatures based on known indicators and heuristics.


Malware is most commonly identified in one of two ways. The ideal is before or right at the moment of deployment, generally speaking using a wire-line product like FireEye or an intrusion detection system like Snort.


In my experience this is the number one action that teams ignore. Teams often respond to malware incidents by jumping straight to eradication. In most cases that’s because containment requires manual intervention. The best teams are able to programatically & remotely contain individual systems as well as entire subnets. This is a powerful capability and worth the effort.


This is the religious battle of the group. Some people trust AV to get rid of malware, but I come from the school of burn it down, wipe, and reload. Most malware is removable, but take a look at Kaspersky’s Equation report and see how you feel.


If you take the AV approach then once your antivirus runs and quarantines the malware I suppose you consider things recovered. If you choose to take my approach recovery tends to come from setting up a new system and restoring from backups.

Aside: Make sure the backups themselves are clean as well. Nothing is worse than reintroducing an infection by restoring a malicious PDF or reinstalling a RAT.

Lessons Learned

After an incident the key is taking any and all information learned and putting it to further use (this is a nascent threat intelligence process). The importance can’t be over stated.

Fool me once, shame on you. Fool me twice, shame on me.

Malware analysis leads to new indicators and new detection. After action reports can show gaps in detection. Thus beginning a new preparation phase. This often happens in the form of an After-action Report.

Takeaways from SANS Incident Response Process

This process is a solid, basic understanding of the incident process that makes it easy to frame the common actions of an incident. As responders get more advanced this process starts showing flaws since an incident response can’t be so rigid. Organizations never have a preparation stage, always being under attack and never able to call a time out to get their house in order. Stages like containment, eradication, and recovery often run concurrently. The process is malware centric, and becomes difficult to apply to other forms of incidents.

The other issue with the traditional SANS IR process was developed before the beginning of intelligence driven incident response. It has no integration with external intelligence sources or dissemination. It’s useful in the short term, but we can do better.

More IR Cycle Reading

Maltego Transforms for the Lazy


While I certainly didn’t plan to release this post the same day Paterva released their latest update, Maltego Chlorine, it’s a happy coincidence. It’s a great day to go download fresh Maltego hotness and start writing some transforms!

Maltego is one of the most unusual tools in the information security space. While there are dozens of vulnerability scanners and piles of reversing tools, there’s nothing else like Maltego short of spending $$$ on Palantir. If you’re not familiar, check out this HakTip by Revision3 on Maltego 101. Don’t worry, I’ll wait.

I’ve used Maltego for years to do infrastructure research and visualizing logs, but I wanted it to do more. I needed to start writing transforms. But where to get started? Transforms typically start two places: the Canari Framework or the MaltegoTransform-Python library. I started with the latter.

MaltegoTransform-Python Based Transforms

The MaltegoTransform-Python Library (from here out called MTP) is a quick way to prototype Maltego transforms in Python. As a trade-off, this requires manual setup within Maltego and provides basically no redistribution. MTP doesn’t address new entity types either. Still, in my mind this is the best place to get started and it makes writing usable transforms in 10 lines of Python a snap.

Each transform is a single Python script (either with a main() method or just a straight procedural script). A basic transform reads in an entity as a command line argument, creates a transform object, adds entities to the transform object, and returns the transform object as XML. That’s it.

MaltegoTransform-Python Imports

In typical Python magic, a quick import/from is all it takes to load the library from your Python path. I leave MaltegoTransform.py in the same directory as my transforms. Most of the time the MaltegoTransform object is all you need since it automatically invokes the MaltegoEntity class). The MaltegoEntity can be useful in advanced cases, though.

Setup Transform

For a basic transform, the magic happens in the MaltegoTransform object. It represents the collection of entities (nodes for the graph theory types) that the transform creates.

Add Entities

The whole idea of building a transform is taking the source entity (the entity you run the transform on) and transforming it into some other connected entity. For example, you transform an IPv4Address using a reverse DNS look-up to a Domain entity. This can be one entity transformed to one entity or one entity transformed to many entities.

Transform Output

At that point, you return the MaltegoTransform and that’s it. The returnOutput method outputs the transform information as XML.

Maltego translates the new XML data into new entities on the graph. That’s a transform. And you didn’t even have to touch any XML yourself.


Every so often, things go wrong and it’s important to be able to let the user know. MTP supports transform exceptions, addException & returnOutput, which work just like addEntity & returnOutput.

FreeGeoIP Geolocation Transform

All these pieces are great, but a full example helps. This transform takes an IPv4Address entity, requests the geolocation data from FreeGeoIp.net, and returns a Location entity.

What does this look like?

FreeGeoIP Transform example

A couple of notes:

  • If you want to use this transform, you’ll need the Python Requests library. You should have it installed anyway as a Python developer.
  • Make sure the MaltegoTransform-Python library is in the same directory as the freegeoip-geolookup.py script. It can’t transform without it!
  • If you want to use this transform in Maltego, (and of course you do) you’ll have to register the transform manually. This is that manual bit I mentioned above. It basically specifies what application to use to run the transform (/usr/bin/python in this case) as well as a path to the transform script itself. It’s confusing for a bit but makes sense after a time or two.

Paterva’s Developer Resources

On February 3rd, 2015, Paterva stood up a Developers Portal with resources to help people get started. This jump-started my development and should be anyone’s first stop (after this post of course) for basic as well as advanced topics. I hope the Paterva team keeps expanding this site, although it’s already a wealth of knowledge.

But what about…?

Other options exist if you want to build transforms. MTP is great for basic transforms and prototyping, but most transform writers will need some of the more advanced options.

Canari Framework

Canari is a rapid transform development framework for Maltego written in Python.

Billing itself as the most advanced & easy-to-use, Canari is a framework for creating and distributing complex Maltego transform sets by eliminating much of the boilerplate. Canari supports a variety of programming languages for building transforms, custom entity creation, local and remote transforms (running transforms on a server instead of off your local machine), as well as distribution so a team of analysts can share them.

Creating packages of complex transforms has a lot going on, and that makes it difficult to be both easy-to-use and advanced at the same time. MTP is great for prototyping transforms; Canari isn’t. MTP would be a terrible way to create polished packages for distribution; Canari excels at that. Neither one is better or worse. They are both ideal for different use cases. SniffMyPackets, a pcap analysis suite, and Malformity, a malware analysis package, are ideal uses of Canari and powerful systems for any analyst.

TDS & Remote Transforms

I have no idea? I don’t have a TDS aside from the public one. If I was working with a bigger team, all using Maltego, I’d invest in one but for now my experience is too limited to speak to them. They make it easy for everyone to work off a unified set of transforms & packages, ease the need to manually setup lots of Maltego instances, and centralize credentials and API keys. Paterva provided a great site to help developers make the most of remote transforms. I can say I do use the Malformity TDS hosted transforms for PassiveTotal and they were easy to setup, wickedly fast, and highly useful.

Transform Hub

The Transform Hub is one of banner features of the Chlorine release and will be game changing for a lot of users. Local transforms can be cumbersome and Canari improves that, but Transform Hub seeks to this even easier by including everything in Maltego itself. This makes it easy to install and configure transforms.

In Conclusion

Is this the absolute best way to build transforms? Probably not, but I did name this Maltego Transforms for the Lazy. This is a great way to prototype new transforms and go from 0 to demo as efficiently as possible. I’ve just started writing transforms and I’m already having success pulling data into Maltego I’d have never imagined. Go for it, and share what you build, there’s a lot to build on.

Intelligence Concepts - The Intelligence Cycle

I can’t talk about important intelligence concepts for security without talking about the grand daddy, the original: the Intelligence Cycle. This should be great discussion fodder for anyone who has to talk to someone who claims they’re selling some form of Threat Intelligence product, given in most cases they seem to be using the phrase in place of the word smart. Intelligence vs smart couldn’t be farther from the truth.

The Intelligence Cycle

Intelligence Cycle

That’s it. Six steps described in six sentences, all pretty straight forward and clear. How could this get so misconstrued?

The Intelligence Cycle in Incident Response

For the last two or so years the security industry has been all about Threat Intelligence with almost no idea what the word intelligence actually means. Companies using the word intelligence are trying to say something involves an intelligent concept. Some of these technologies are innovative and beneficial, but they aren’t intelligence. The desire is to cash in on the current (and ambiguous) threat intelligence trend and thus everything is intelligence.

Both intelligence in the Intelligence Process sense and the smart sense are valid, but have distinctive connotations. The problem is marketing and a desire to cash in on the threat intelligence trend has resulted in vendors manipulating potential customers by confusing these meanings.

Vendors are selling data feeds, management platforms, actor reports, vulnerability centric reports, and tools, but none of these are intelligence. In every case they are a piece, often important pieces, but not a whole. The whole of threat intelligence takes tools, data sources, people, and processes dedicated to collecting in all those inputs and contextualizing them by working through the intelligence process.

A Walk Through the Intelligence Cycle

I track groups for my own interest and work through this cycle often. In this case we’re going to walk through this cycle the way I would for one of the more infamous groups out there; the infamous Comment Crew aka APT1.


First we have to set the parameters of what questions we’re trying to answer. When I’m doing my personal research I generally have two goals:

  • A general understanding of a group such as their goals.
  • Any indicators of compromise that could help me identify this group.


Collection is the process of gathering as much information as you can that can help answer the questions posed in direction. My first thought with groups like is to create a series of search terms or known data point to start our collection of of.

Aside: The most difficult data point to gather at the start of an investigation is all the potential reference terms for a specific group. Comment Crew is also called Soy Sauce, ShadyRat, WebC2, GIF89a, APT1, Comment Panda, and their Military Unit Cover Designator Unit 61398, all depending on who you ask. At this point each vendor has their own name, and each “fight club” often has their own designator as well. I’m stunned how often I’ve missed information about an actor just because I was too focused on the wrong name.

From there we have a couple common sources:

  • Google
    • It’s amazing what you can find going through articles & blog posts. You’ll want to store all the, though watch out; the current tech media is rife with republishing all over the place.
  • Vendor Information
  • Re-Analyzing Information

The collection process continues until exhausted, either based on content or on time.


At this point you have a mountain of data. Processing is taking all this data and putting it into useful formats for further analysis. This is all about consistency and ease of analysis. This is one of the toughest problems in the security space right now and has resulted in a lot of competing solutions (CRITs, MISP, ThreatConnect, ThreatQuotient, and dozens of home grown systems).

I end up processing my data into a lot of formats. For things like reports and articles I initially process them into JSON files per article. From there I push my data (Note: I’m saying data, not intelligence yet) into two primary places; my personal instance of CRITs intelligence management system and a git repository where I keep my processed JSON, CSV, and Markdown files. Maltego for graphical analysis. I also keep all my raw, but processed files around in case I need to manipulate them differently later.


Now we have the necessary collection of data processed into a consistent manner and we’re ready to go back and address those original questions.

  • A general understanding of a group such as their goals?
    • This is what the long form reports tell us. And for a case like this we’re looking for confirmation from more than one source. We learn this group is about attacking military related targets, trying to gather information that will support their national defense.
  • Any indicators of compromise that could help identify Comment Crew?
    • At this point you have thousands of indicators, IPs, hashes, malware, domain names, etc. The key for analyzing these isn’t just having them, but having them in useful formats. This means formatting (we’ll get into that in dissemination) but also deconfliction, making sure that you understand the context of the indicators you have.

Aside on Deconfliction: Plenty of pieces of malware beacon to well known sites/IPs to make sure they’re connected to the Internet. You don’t want to report (Google DNS) is a malicious IP. At the same time identifying a malware characteristic found in 100% of a groups malware is great, unless it’s also found in 100% of all PE files (MZ).

That’s the basic analysis process. My products for something like this generally include a couple paragraphs to answer the first question, to be continually updated, and a group of files detailing the second set of indicators. I could use on one of the major standards for that, such as STIXX or OpenIOC, but given at this point they’re both difficult to work with and not well adopted I find its easier to stick with open file types like Markdown, JSON, CSV, etc.


The next to last step is dissemination to stakeholders. In a case like this I’m the stakeholder, so I don’t need things disseminated as this is a reference set for me. In the event I was building this for someone else this is the point where I’d pass them information.

If I was disseminating this data there are things to consider:

  • Different stakeholders will need a different format of product
    • Engineers and analysts will want indicators in easy to work with formats (like JSON & CSV). Managers and directors will want shorter briefs, often in prose, and probably as PDFs. Always consider your audience in how you share your data.
  • Operational security of intelligence matters
    • The TLP method helps, but you have to make sure people will follow through with this. You don’t want to do all this work compromised group you’re analyzing.


The feedback step is the simplest part of this whole cycle: Did you answer the questions posted during direction to the stakeholders satisfaction? If yes does this lead to new questions/direction? If no how does this lead to generating a better question or a new series of collections?

This is a tough one to stomach. If you’re the stakeholder you’re answering to yourself, which makes it difficult to be honest in your assessment. If the stakeholder is someone else this is their chance to judge your work. Brutal honesty with yourself throughout the process is the answer.

The other key piece of feedback is how application of the new intelligence you’ve developed results in even more data. Say you deploy a snort rule for a network string and you get a hit, all the information you can gather around that hit is data to include during the collection phase of your next cycle. We’ll talk even more about this integration in my next post on F3EAD.

Takeaways from the Intelligence Cycle

The intelligence cycle isn’t something that gets used day in and day out in DFIR work, but is becoming more and more critical to always have running in the back of your head. Whether evaluating new tools or vendors its important to understand that intelligence isn’t just data, it’s data processed in a rigorous way to ensure a balanced, well contextualized product. This is to make sure you’re making good decisions, not following whatever data is in front of you.

More Reading

APT is a Who not a What... And Why it doesn't Matter

A small number of topics get intelligence driven incident responders incredibly frustrated:

  • Using intelligence to mean smart (I’ll share more about that later this week)
  • Bad attribution based on incomplete information and bad assumptions
  • Misuse of the term APT (in most cases by marketing departments)

Advanced Persistent Threat remains the buzzword of choice for vendors, but it’s used incorrectly, and lots of people know that and don’t say anything. As a result I want to go on the record and correct a couple key misnomers.

APT is a Who

My second job after college was working for Mandiant (Now FireEye Services as a Security Consultant. This was a great job where I learned a ton and that was because I worked with such a skilled team. The team that started Mandiant primarily came from the United States Air Force Office of Special Investigations; a team that handled, among other things, some of the first nation state level computer intrusions of the Internet era such as Solar Sunrise, Moonlight Maze, and Titan Rain.

This was a weird time, because (like today) attacks weren’t just aimed at military targets but commercial targets as well. AFOSI, as well as other government intelligence & defense groups, investigated using open source and classified methods. For operational security, this leads to classified intelligence.

This classified intelligence was a problem. While the Defense Industrial Base has people with clearances who can handle classified data, other companies, without cleared people, came under attack as well. These DoD/IC teams wanted to help, but couldn’t disclose classified information. They came up with a compromise: sharing indicators and information without disclosing the actual actor behind it. Instead they just referred to the actor using a pseudonym: The Advanced Persistent Threat. Specifically APT, supposedly coined by Colonel Greg Rattray, was a couple groups of actors primarily operating out of mainland China and believed to be members of the People’s Liberation Army. We now know these groups today as APT1, Anchor Panda, and Elderwood, as well as other private designations.

APT is a term to refer to Chinese espionage without saying Chinese espionage. Full stop.

APT is not a What

Compromised companies often make a statement after their incident that the attacker is an advanced persistent threat. This leads to the same tired observations by security pundits:

As our research team reveals in our Hacker Intelligence Initiative Report, some APTs are relatively simple to execute. ~ Amichai Shulman


Advanced wasn’t right because the initial gambit was almost always a low-tech spear phishing attack. Persistent wasn’t really accurate because it wasn’t the attackers who made things persistent; it was the inability of organizations to read their own logs for anomalies that allowed the breaches to continue over long timeframes. ~ Robert Richardson

Robert is correct in this case. APTs aren’t advanced or persistent, at least not necessarily. But that’s because the term wasn’t meant to describe how the attacks occurred, but who the attacker was. The APT term could have been “Actor Potato” or “Group1” or any other codename imaginable.

APT is not a description of an actor based on the sophistication of their techniques, as people often note there’s often little that’s advanced. They aren’t universally persistent; while some groups will linger for months or years, others use smash and grab tactics. The fact is the same: APT is a codename for a who, that who being Chinese espionage, not a description of an attacker based on methods or techniques.

So why doesn’t it matter?

This rant, and even I can call it a rant, isn’t out of nowhere. Today Kaspersky released a report about the Carbanak APT: A financially motivated attacker operating all over the world(Report: Carbanak_APT_eng.pdf). I have no doubt that this is a great paper worth reading. I have no doubt the group they describe is using some interesting, even advanced, techniques. Perhaps they even stay in an environment for a long period of time, persisting if you will. But I am 100% certain this is a misuse of the term APT.

APT has moved away from its original definition, from a term of art to a term of marketing. It’s not descriptive, except to say that the solution has to include hundreds of thousands of dollars in professional services, endpoint monitoring, intelligence portals, and feeds with millions of indicators. Words change, and there is no doubt at this point that APT means what marketing says it does, but I think security practitioners can help.

We need a better and honest taxonomy for referring to these attackers. I’ll kick things off with:

  • State Sponsored Espionage (What we now call APT)
  • Financially Motivated Criminals
  • Nationalist Activists
  • Criminal Activists (So called Hactivists)

Beyond just having a better taxonomy we need to work alongside marketing departments to use accurate, descriptive terms instead of overloaded buzzwords. It may be an uphill fight, but a worthwhile one. I welcome the chance to collaborate with others who care about this.

-The security community has difficult problems on its hands. Seemingly the harder we work to stop threats the more come up. We’re already dramatically understaffed as an industry ( Leviathan Security Group: Analysis of Cloud vs. Local Storage: Capabilities, Opportunities, Challenges). The last thing we need, the last thing we can afford, is to make our own lives more difficult by abusing overloaded terms to generate fear, uncertainty, and doubt.

A Little Extra

I’ve been working on tool I think could be useful in situations like this. While it’s not ready for prime time yet here is a little preview: