Attacking Your Incident Response  

Many incident responses are conducted with traditional digital forensics approaches. While there’s a time and a place for those processes, the reality is often these should be after-action tasks, not first responses. Of far more value is what we’ll call the “attacking your incident response” approach.  

Attacking Your Incident Response In Action 

Let’s explore how this approach works in a real-world scenario based on situations we’ve seen. 

Event origin:

You get a call from the first person to arrive at the office. They state “nothing works” so you begin to rally the network engineer to check. Before he gets there, you receive a few more calls that range from “email doesn’t work” to the dreaded “what is this Readme.txt file on my desktop.”  

Critical events like this may happen a couple times in your career, possibly never if you are good and lucky. I have had the unusual opportunity for these events to be something that I see dozens of times a year. With my background as an offensive security practitioner and my time doing incident response, let me share with you some of the tips and tricks I have found to use the knowledge of the attackers against them.  

Identifying the issue:

The first step in any incident is to identify exactly what is happening. Get statements from those who have reported strange events, begin taking an inventory of systems that are already known compromised, and mark any critical services that appear to not be included. See if there are any commonalities or differences. These may help identify a starting place.  

Identifying the perimeter:

Not only how well you know your environment, but how can somebody see it from the outside?  Try dns dumpster, amass, what’s your actual list of ips, any cloud tenants, etc.  

Exploring what is easy to find first, think DNS enumeration. What are known assets the organization has from the public? Use tools to investigate that attack surface, such as Shodan or Censys. Start a vulnerability scanner like Nessus or OpenVAS. We like to use services like dehashed to check for known password breaches then test the users and passwords that we find against any visible login portals.  

If you’ve found something that looks bad, that is the first place we want to start checking.  

Exploring what is less obvious:

Review every ip address and domain name you own but may not be obvious that you do, even and especially the ones you believe are not in use. The same methods as above will apply. Make sure to check every possible http/https. Run a tool like ZAP against any locally hosted web apps to find vulnerabilities and search for directories that are public and shouldn’t be (you might even find a web shell).  

For the cloud side, all of the standard infrastructure checks may apply, but you will have great results looking from the authenticated side. IAM reports, privilege changes, and VPC changes are a great place to start there.  

Why Attacking For Defense 

Why are we doing this? Why are we attacking our infrastructure in such a critical time? These are all checks that can be done rather quickly. We find that in over 70% of breaches we are able to identify the vulnerability used to enter the network within a couple hours. This allows us to pinpoint where to begin the investigation internally, as well as patching the holes that would allow the attackers to get back in.  

Traditional Digital Forensics vs Attacking Your Incident Response 

Having covered what attacking your incident response entails, let’s examine two approaches to dealing with an incident.  

Digital Forensics:

You identify a ransomware attack. You begin taking note of what systems and users are affected. You check the domain controller. It is encrypted. However, you are still able to look at logs. You notice there was a service account domain admin logged in kicking off powershell processes. You follow the powershell back to several workstations and servers. You take this list, begin extracting logs, taking disk images, and memory captures of these systems. It will likely take days to dissect all of this data. Then you may find that all these machines were accessed from a development test web server that was forgotten about. You access that server, take an image, memory capture, and logs. You see that they were able to get a sql injection on that web server and spawn a web shell. They then used this to gain access to the system and dump credentials of an admin account everyone had forgotten. Now we are multiple days in, assuming we work very quickly, just now finding out how they got in, what patient zero was, and how to prevent them from getting back in. 

This is a long time for an attacker to have persistence and is costly to your business or organization to be without access.  

Attacking the Incident Response:

You identify that it is a ransomware attack. You know your external footprint, so you began scans and search shodan for the known ip addresses. You immediately see high CVSS vulnerabilities on a web server. You launch ZAP at it and quickly identify a likely SQL injection. Checking the logs on that system, you discover this is the attack path. You find multiple addresses exploiting sql on that system.  

Notice how much more quickly this method yields awareness of the attack path and therefore allows for much more rapid remediation, limiting downtime for your systems and securing your network much more quickly. Thinking like an attacker has saved us tons of time, and our customers millions of dollars.  

Conclusion

There is a time and need for the traditional forensics-based incident response methodology in almost every engagement. However, by thinking out of the defensive box, approaching your IR like an attacker, you might improve your outcome.  

– Tanner Shinn, Principal Security Engineer