In a previous article, we discussed what we’d advise an IT or security leader to do before a breach.
Now, for this article, we asked SECFORCE hackers, who are usually on the other end of the breach, what they would recommend to do after a breach?
As a CREST-accredited penetration testing provider with 18+ years of testing experience, SECFORCE knows the difference between fully testing systems post-incident and leaving risks unaddressed.
Depending on the situation, we would recommend that breached organisations use a combination of red, purple, or gold teaming, or a focused round of penetration testing, as appropriate.
To set the scene, imagine (hopefully, this is an imaginary scenario) that you just became aware of clear evidence of a cyber incident significant enough to have compromised part of your environment.
Possibly, malware was deployed. There was likely some kind of communication with an external C2. You are not exactly sure what the extent of the breach is and how bad things got/are going to get.
But no matter what happened, the fact is that someone (an attacker) has gained a foothold in your network, collecting information, executing commands, and potentially leaving behind hidden backdoors.
This is a very scary time to be a security or IT leader. If your executives didn’t pay much attention to security, they are about to become very interested in what you’ve been doing in the last few quarters.
As Someone Responsible for Security, You Have 2 Goals After a Breach
These are:
- Protect the business and make sure that your IT systems can keep working.
- Find out exactly what happened, restore operations, and regain (and communicate) assurance that the breach was contained and remediated.
The first of these (protecting business continuity) will depend mostly on what you did before the breach, e.g., whether your backups are segregated, whether your incident response plan was tested, the integrity of your logs, etc.
However, the second goal (regaining assurance) is still up to you.
What to do after a breach is a challenge that is part technical and part psychological. We help companies bounce back from these kinds of situations all the time.
Here’s a high-level review of the less obvious steps we would advise an IT or security leader to take after a breach is discovered to make our (and their) jobs much easier.
What to Do After a Cybersecurity Breach
Preserve Evidence (Even If It Feels Risky)
Isolate infected systems from your critical assets, but don’t rush to wipe hosts or remove compromised user accounts before you analyse them.
“What?” You might ask, “Just let attackers keep doing whatever they are doing?”
If there’s a ransomware attack and all your systems are encrypted, it's already too late. The focus should be on recovery, identifying how the intrusion happened, and assessing the extent of the attack (for example, whether sensitive data has been exfiltrated).
But in other cases, we recommend holding back on wiping infected hosts for as long as possible, if it is safe to do so.
It all depends on the scenario.
Logs, behaviours, and other evidence that attackers create will tell you what is or was going on. You want to observe evidence of compromise (and preserve it for future analysis) for as long as possible. Compromised hosts can be isolated from the network so they no longer pose a risk.
Taking a slash-and-burn approach to removing or wiping compromised assets can erase vital evidence of known Tactics, Techniques and Procedures (TTPs) and hurt you down the line.
In a previous article, we highlighted the importance of testing your telemetry before a breach happens. After a cybersecurity breach occurs, telemetry really matters.
The more information your endpoint detection and response (EDR), security information and event management (SIEM), and similar tools can pull in the context of an incident, the better you will be able to understand that incident, attribute it, and close it off with minimal business disruption.
With enough data, you should be able to see where the attacker moved to, what accounts were compromised, which privileges were escalated, and - importantly - what the origin of the attack was. The longer you keep infected hosts alive, the more data you get (provided they can be securely isolated from anywhere else).
Don’t Relax Until You Find the Entry Point
You might be familiar with the cyber attack chain (or kill-chain) theory. If not, the basic rundown is that cyber incidents have clear stages from reconnaissance to hands-on keyboard actions.
In a live post-breach scenario, reality is much more mixed up
You could stop what appears to be a primary attack at an early stage, e.g., during RAT deployment, but in reality, you might have just interrupted a secondary infection. A wider attack might still be ongoing, exploiting pathways you have not uncovered.
Attackers' end goals can keep changing, too. Even ransomware compromises and attacks can be preludes to later extortion or insider compromise attempts.
It is impossible to get 100% assurance into what is/is not impacted (e.g., was that DDoS attack a cover for C2 traffic?) after a cybersecurity breach, but the best way to gain reasonable assurance is to fully understand the initial attack vector.
Without addressing how the attacker got in, they, or another threat actor, can exploit the same weakness again.
We are always insistent on tracking down the initial attacker entry point as a priority. Malware or other types of compromise did not appear on your network by magic. If you cannot determine how the attacker got access, the door is still open to them or someone else.
This means investigating various scenarios, for example:
- Was it a phishing attack? If so, how did the malware not get picked up by the compromised device's antivirus?
- Was there an exposed vulnerability? If so, where is it, and can it be patched?
- Did the attacker exploit weak credentials? Are the same credentials (or a variation of them) used elsewhere?
- Were any insiders involved? Was it intentional?
Once you identify and fix the root cause of a breach, it's incredibly important to conduct some level of penetration testing to ensure your new preventive controls work as intended.
Rebuild for Full Assurance
Understanding what happened during a breach is crucial.
This is where uncertainty often arises. If your organisation has excellent visibility into the full context surrounding an event - full logs, endpoint monitoring, forensic capabilities - then it may be possible to trace every action the attacker took.
In that case, security teams can systematically neutralise each point of compromise and ensure all unauthorised access has been removed.
However, in most real-world cases, full visibility is lacking. This means there is always a risk that something was missed.
Besides, there’s always the problem of not knowing what you don’t know. You will never be able to be completely sure whether you are missing something from your attack timeline.
For instance, an attacker may have:
- Created hidden admin accounts.
- Left undetected malware or persistence mechanisms.
- Exploited vulnerabilities that have yet to be identified.
- Used an out-of-band communication channel that you may not monitor.
- Used some kind of execution technique which could be missed by your telemetry.
- Compromised the integrity of your logs.
Without absolute certainty, trusting the network again becomes a challenge.
Since perfect visibility is rare, industry best practices recommend rebuilding critical systems from a clean, known-good state by:
- Restoring from backups that predate the attack and fixing any vulnerabilities they may have introduced. However, note that restoring from backups can leave an organisation vulnerable to the same attack pathway that compromised it in the first place. If you restore a system that had an exploitable vulnerability, that vulnerability remains exploitable.
- Rebuilding compromised systems entirely rather than attempting to "clean" them.
- Resetting credentials and reviewing all access control policies.
This is often the only way to regain full confidence in the integrity of the network. A piecemeal approach (fixing only known issues) runs the risk of missing deeper compromises.
Recover After a Breach with SECFORCE
SECFORCE has over a decade of experience helping organisations rebuild confidence in their IT systems after a breach.
Our team can work with you to understand exactly what happened and test your systems post-breach to ensure that all potential paths to compromise have been secured.
This might mean using a combination of red teaming, purple teaming or gold teaming.
In some cases, a focused round of penetration testing might be sufficient.
Get in touch with us today for a free consultation on the best next steps after a breach.
