State Sponsored Intrusion: Incident Response Checklist

This guide walks you through building an incident response checklist specifically for a suspected state-sponsored intrusion. You’ll learn what to include at each phase—preparation, detection, containment, eradication, recovery, and post-incident—so your team can act quickly and methodically when the stakes are highest. The checklist is designed to be practical, adaptable, and focused on the unique challenges of advanced persistent threats (APTs).

What You’ll Need

• An inventory of your critical assets, including servers, endpoints, and data repositories.
• Access to your organization’s incident response plan (or a willingness to create one).
• A list of key contacts: internal IT/security staff, legal counsel, executive leadership, and external incident response firms.
• Logging and monitoring tools (SIEM, EDR, network capture) that you can query.
• A secure communication channel (e.g., encrypted chat) for the response team.
• A chain-of-custody form for preserving evidence.
• Backup and recovery procedures, including offline or immutable backups.

Step-by-Step

1. Prepare in advance. Before an incident, define what constitutes a “state-sponsored� indicator—such as known APT tactics (e.g., living off the land, dual-use tools, long dwell times). Establish a clear escalation path and a pre-approved list of external experts you can call. Test your communication channels and ensure key personnel have 24/7 contact numbers.
2. Confirm the suspicion. When you first suspect a state-sponsored intrusion, do not panic. Validate the initial alert by checking logs, correlating with threat intelligence feeds, and looking for additional signs (e.g., unusual lateral movement, credential dumping, or persistence mechanisms). Document everything you see, including timestamps and user accounts involved.
3. Activate the incident response team. Assemble the core team: incident commander, lead analyst, communications lead, legal counsel, and a representative from executive management. Assign roles based on your checklist. If you lack internal expertise, contact your external incident response retainer immediately—do not wait until the situation worsens.
4. Preserve evidence. Begin collecting forensic evidence while minimizing disruption. Take memory captures, disk images, and network captures from affected systems. Maintain a chain of custody for all evidence. Avoid running tools on compromised systems that could alter timestamps or overwrite data. Use a forensic workstation to analyze copies, never the originals.
5. Contain the intrusion. The goal is to stop the attacker from moving further. Isolate affected systems from the network, but do not power them off—you’ll lose volatile evidence. Change credentials for any accounts that may have been compromised. Block known malicious IPs and domains at the firewall. Consider taking critical systems offline if they are actively being used to exfiltrate data.
6. Eradicate the threat. Once contained, remove the attacker’s presence. This includes deleting malware, removing persistence mechanisms (e.g., scheduled tasks, registry keys, service accounts), and resetting all credentials that the attacker may have accessed. Rebuild affected systems from clean images if possible. Verify that no backdoors remain by scanning for known indicators of compromise.
7. Recover and restore. Bring systems back online in a controlled manner. Restore data from backups that are known to be clean—preferably offline or immutable backups. Monitor restored systems closely for any signs of re-infection. Implement additional monitoring during the recovery phase, as attackers often re-enter through previously used or new vectors.
8. Conduct post-incident review. After the dust settles, hold a lessons-learned meeting. Analyze what went well and what didn’t. Update your incident response checklist based on gaps you identified. Share threat intelligence with relevant industry groups or government agencies if appropriate. Ensure that any legal or regulatory reporting requirements are met.

Common Mistakes

• Waiting too long to escalate. State-sponsored intrusions are fast-moving; a delay of even a few hours can mean massive data loss. When in doubt, escalate.
• Powering off affected systems. This destroys volatile evidence like memory and running processes. Instead, isolate the system from the network while keeping it powered on.
• Not preserving evidence properly. Failing to document chain of custody can make evidence inadmissible in court or useless for attribution.
• Changing credentials before capturing evidence. Resetting passwords too early can lock out the attacker, but it also destroys evidence of their activities. Capture what you need first.
• Assuming a single intrusion is the whole story. State-sponsored actors often maintain multiple access paths. After removing one, check for others.
• Neglecting to communicate with legal and PR. A breach of this magnitude has legal and reputational implications. Keep them informed from the start.

Tips

• Use a threat intelligence feed that includes APT indicators to help validate your suspicion.
• Create a decision tree for when to call in external help—don’t rely on gut feeling.
• Practice your checklist with tabletop exercises at least twice a year. This ensures everyone knows their role.
• Keep an updated asset inventory—you can’t protect what you don’t know exists.
• Document everything in a central incident log, even if it seems trivial. It will be invaluable during the post-incident review.
• Consider legal implications early. State-sponsored intrusions may involve national security concerns; consult with counsel about disclosure obligations.

Troubleshooting

If your checklist doesn’t go as planned, here are common issues and how to handle them:

• You can’t confirm the intrusion. If you’re unsure, treat it as a real incident. The cost of false alarm is lower than the cost of ignoring a real APT. Escalate to your incident response team and continue investigating.
• Containment fails. If the attacker persists despite your efforts, expand containment—take more systems offline, revoke more credentials, and consider disconnecting from the internet entirely. Call in external experts without delay.
• Evidence is corrupted. If you accidentally altered evidence, note it in your documentation and continue. You may still have enough for analysis, but be transparent about the issue.
• You discover the intrusion is larger than initially thought. This is common. Reassess scope, notify leadership, and adjust your containment strategy. Don’t try to hide the scale—it will only make things worse.
• You lack the tools to perform forensic analysis. If you don’t have the expertise, don’t attempt deep forensics. Secure the evidence and hand it to a professional firm.

Frequently Asked Questions

How do I know if an intrusion is state-sponsored?

Look for indicators like advanced techniques (zero-day exploits, custom malware), long dwell time, targeting of specific individuals or data, and use of infrastructure that matches known APT groups. However, attribution is difficult; focus on the behavior, not the label.

Should I contact law enforcement?

In many jurisdictions, reporting a suspected state-sponsored intrusion is mandatory, especially for critical infrastructure. Consult your legal counsel early. They can guide you on reporting to agencies like the FBI or your national CERT.

Can I just wipe the affected systems and restore from backup?

That’s part of eradication, but it’s not enough. You must also identify how the attacker got in, remove all persistence, and change credentials. Otherwise, they’ll come back.

How long does a state-sponsored intrusion response take?

It varies widely—from weeks to months. The containment phase can be quick, but full eradication and recovery often take a long time because you need to ensure the attacker is completely out.

What if the attacker is still active during the response?

Your priority is to contain. Isolate systems, block network paths, and change credentials. If you can’t contain quickly, consider taking the entire network offline temporarily.

Do we need to notify affected customers or partners?

That depends on your legal obligations and the data involved. Work with legal and PR to determine the right timing and wording. Transparency is often best, but only after you have a clear picture.

Related

• Git-Based CMS Without Database or Build Step?
• AI and Tech Stocks: How Much of Your Portfolio?
• Apple Silicon Chip Size: Performance, Power, Heat