The CISO’s Guide to Advanced Attackers: Verify the Alert

By Mike Rothman

All the discussion so far in our CISO’s Guide to Advanced Attackers has been of preparation for the main event. The bell rings when an alert fires and it’s time for your incident response process to kick in. But as we have seen through our adversary analysis and intelligence gathering, “advanced attackers” present some unique challenges. In particular, they significant resources and time, which makes them difficult to deter – even if you successfully block one attack or stop a specific exfiltration, there will be more. A lot more.

As usual we depend on process as the key to dealing with advanced attackers. But this class of adversaries requires you to put a premium on analyzing malware to isolate the root cause of the attack, looking for indicators to identify additional compromised devices, and then trying to piece together the bigger picture of the attack.

React Faster and Better, CISO Style

Let’s turn back the clock and review some of the Incident Response Fundamentals we introduced a few years ago. The process remains largely the same, but you are likely to need some of the data sources covered in React Faster and Better and some of the analysis techniques presented in the Malware Analysis Quant process maps to deal with advanced attackers’ tactics.

If you weren’t worried enough about this, remember that your perceived success as CISO is directly correlated to your ability to respond effectively to incidents and keep your organization out of headlines. You don’t need a SIEM to do that correlation, by the way.

During the Attack

Once the alert sounds it is time to figure out whether the attack is legitimate, what it looks like, and the proper escalation path (if necessary). Here are the general steps in that effort:

  1. Gather information: For an investigator to make heads or tails of anything, your first tier needs to collect some information. Things like who triggered the alert and what systems and devices were involved. Were you notified by a third party (not a good sign)? Could you find an alert (perhaps one that was ignored) around the time period of the attack? You are trying to get a feel for whether this is an operational failure or something designed to evade your defenses.
  2. Escalate: Next you decide how far up the chain of command this needs to go. If there are critical systems involved (those on your list of things where compromise would be bad), then your spidey senses need to start tingling and you need the big guns involved. The escalation scenarios must be defined and agreed on ahead of time so your first tier responders know what to do and when.
  3. Size up: Once your second tier (or even third tier) responders are involved, the key is determining the scope of the situation. Was this a total compromise? Does extensive lateral movement indicate potential exfiltration? You need to know what you might be dealing with, and to assemble a list of the stuff you really need in order to investigate the incident.
  4. Initial Containment: Depending on your initial assessment of the situation you may need to quarantine devices, step up monitoring, or remove the device’s access to sensitive data. As with escalation, the initial set of containment actions should be documented in a playbook, with documented approval from all stakeholders, to ensure containment steps are not held up by bureaucracy.

At this point you should have initial defenses in place and a feel for whether you are dealing with folks who know what they’re doing. If the attack doesn’t seem sophisticated or coordinated you can probably just wipe the machine and move on, hopefully using it as a teaching moment so the user doesn’t do something stupid again. Is it a risk to just wipe and move on? You bet! You lose any ability to seriously analyze the attack, but part of the CISO’s job is to allocate resources to the stuff that matters. Being able to tell the difference between an advanced attacker, an operational failure, and a stupid user error becomes a key determinant of success in the job, along with resource allocation.

If there is a chance that you are dealing with an advanced attacker (or something else is pushing you to do a broader investigation), you will start working through a more detailed forensics process. That means quarantining the affected devices, taking forensic images, and working to determine the root cause of the attack. That requires you to dig into the malware and determine how the devices were compromised, then assess the extent of the damage.

Digging for the Root (Cause)

Malware analysis is a discipline all its own. We have documented the entire process in Malware Analysis Quant, but CISO types rarely fire up BackTrack or ship file up to malware sandboxes, so here is what you need to make sure the right stuff is happening to identify the root cause of a compromise.

  1. Build Testbed: It is rarely a good idea to analyze malware on production devices connected to production networks. So your first step is to build a testbed to analyze what you found. This is mostly a one-time effort but you will always be adding to the testbed, with the evolution of your attack surface. There are services that can do this as well, without the hardware investment.
  2. Static Analysis: The first actual analysis step is static analysis of the malware file to identify things like packers, compile dates, and functions used by the program.
  3. Dynamic Analysis: There are three aspects of what we call Dynamic Analysis: device analysis, network analysis, and proliferation analysis. To dig a layer deeper, first observe the impact of the malware on the specific device, dynamically analyzing the program to figure out what it actually does. Here you seek insight into memory usage, configuration, persistence, new executables, and anything else interesting associated with execution of the malware. This is managed by running the malware in a sandbox. Once you understand what the malware does to a device you can begin to figure out its communications paths. This includes command and control traffic, DNS tactics, exfiltration paths, network traffic patterns, and other clues to identify the attack. Finally you need to understand whether and how the malware spreads, which we call proliferation analysis. Look at the kind of reconnaissance it performs, along with any other clues that indicate the malware is running rampant in your environment.
  4. The Malware Profile: Finally we need to document what we learned from the analysis, which we package up into a malware profile. The profile lists the indicators of compromise we constantly talk about.

Next you need to determine the extent of the damage, which means taking the indicators defined in the malware profile and mining your security information to see how many devices have similar infections. Then you can start determining how deeply the adversary is in your environment and whether you’re dealing with an exfiltration.

As we discussed in Mining for Indicators, over the next few years big data analytics will have a major impact on how you search for these indicators within your environment, but its short-term impact will be minimal. So in the meantime we need multiple tools (endpoint protection consoles, SIEM, network behavior tools, configuration management systems, vulnerability scanners, etc.) to search for specific indicators. Having to integrate the data from all these tools manually is a pain in the backside, but remember that job #1 is to determine the root cause and extent of the compromise. As messy as that may be.

Not to beat a dead horse here, but all the stuff mentioned above is focused on figuring out how the malware in your environment works, what it does, and how to find it. Effectively leveraging threat intelligence in your security program can get you ahead of these reactive investigation fire drills, by keeping a lookout for indicators before you have a widespread outbreak. In the worst case you will find compromised devies before you get called by the FBI or your payment processor. In the best case you will have mitigations in place to actually block the attack. That’s why we are such fans of threat intelligence for mature security organizations.

Seeing the Big Picture

Before you roll up your sleeves to fix things you need to take a step back and get a bigger picture of whether you’re dealing with a coordinated attack. We know it’s hard to maintain the discipline to look strategically and consider non-obvious links between various attacks, as opposed to just fixing things and moving on. But in our experience playing “response whack-a-mole” can be very dangerous when with advanced attackers because once they determine you have found them they usually move deeper into your environment to maintain presence. Deciding how best to break the kill chain to provide the best opportunity for favorable remediation is non-trivial. Fortunately it’s our next topic…

No Related Posts

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.