By Todd Hacke
The moment you realize you are experiencing a network-based breach, you may not know what to do. Minute one, hour one, day one, what should a technical team do to respond to a breach while it’s still in play?
While having a full incident response plan, a trained response team, and well-placed log repositories are optimal, in our experience many organizations are not well-prepared.
If you do not have your incident response plan in place and you are in day 1 and 2 of the breach, take our advice:
RECOMMENDATION ONE: Limit the ability of the attacker to access your network
First and foremost we strongly recommend limiting/removing the ability of the attacker sending packets into your network. This action aims to stop the attack not only at the endpoint but network-wide. If you or a member of the team identify an IP address/block of IP addresses that are generating malicious traffic, create an explicit deny rule for all communication to or from that IP address at the firewall. This is a great interim step to control the attack while still maintaining the integrity of the forensic evidence on the endpoint; which should be collected to determine root cause.
For bonus points, and to really thwart non-sophisticated attackers who do not possess a vast attack network, deny the entire country that the malicious traffic is originating from (*please note this is not a viable step in all cases, however, it is not uncommon for attackers to utilize infrastructure and identifiers from very obscure locations. This can often be used as a tool to end the attack and prevent it in the future*). It is also a good idea to limit the ability of any critical infrastructure that does not explicitly need access to the internet communication to the internet. This step is a combination of best-practice type behavior and protecting critical assets from further attack.
- Block IP addresses utilized by known threats at the edge of the network (Firewall)
- Block entire countries if no legitimate business need exists
- Deny servers and critical infrastructure the ability to directly communicate with the internet (nullify any outbound connections)
RECOMMENDATION TWO: Eliminate the files that caused the infection
Another common step in cyber intrusion remediation is removing the infected files from the system. This seems like a no-brainer at the surface, remove the files that caused the infection. We additionally recommend identifying the application/service/protocol that presented the initial vulnerability and seek to modify these shortcomings to prevent future attacks. These actions could include deleting known-bad files, disabling unused or high-risk services (such as those that transmit in plain-text), removing software or applications that present little business use, and updating/installing an industry standard anti-malware application. These actions will all help quell future attacks.
To take this remediation action a step further, there are many advanced threat detection appliances that aim to prevent malicious files from ever entering the system to begin with. If the organization is experiencing systemic or sustained attacks that appear to be walking past traditional definition-based anti-malware controls, it would be worth exploring these threat detection appliances through a compromise assessment. Specifically, we suggest reviewing appliances within the four major attack vectors being utilized by attackers today: Network, Application, E-mail and Endpoint. For more information visit the HALOCK Compromise Assessment page.
- Find and remove the file(s) responsible for the attack
- Delete or disable the process/protocol used to launch the attack
- Remove the service/application that created the vulnerability
RECOMMENDATION THREE: Remove the affected devices from the environment
The most instinctive of the remediation steps also happens to be one of the more complicated matters in incident response. Removing the infected asset(s)/file(s) and returning the asset(s) to a known-good state is a reasonable goal for the majority of incident response plans. It is important to note, however, that deleting files, powering down a system to replace the hard drive, or restoring the system to a previous version will destroy forensic evidence that can be used to determine root cause. In many cases capturing this forensic information prior to restoring the system is the only way to determine what happened. This forensic collection process is also the cornerstone for any/all legal action taken as a result of the attack.
Be sure to acquire a complete forensic image of the computer (if at all possible) before returning the system to a ‘business as usual’ state. This includes collecting all the information contained on the endpoint while observing Order of Volatility. Be sure to maintain positive control of the evidence and log everything in an appropriate Chain of Custody form to maintain the integrity of the evidence. If the organization does not have a process in place for collecting and logging evidence, HALOCK can assist with workforce training via Computer Incident Response First Responder Training. In the unfortunate event of a live incident, contact HALOCK for immediate assistance with Computer Forensic Investigations at our Incident Response Hotline 800.925.0559.
- Collect ‘images’ of the volatile system data, RAM, and the hard disk; if at all possible
- Power off the device and disconnect it from the network (only after imaging!)
- Restore affected devices to a known-good state via backups or snapshots
These cyber security incident remediation steps are a good start to recovering from an attack. Limiting the ability of an attacker to communicate, removing the system from the environment, and addressing the vulnerability are relatively standard, effective steps to getting back to business. Remember, if you run into trouble, you can always call us.