Incident Response Quick Reference

Standardize Without Sluggishness

This topic works best as a practical framework: clear enough for decision-making and concrete enough for execution.

In Incident Response Quick Reference, the goal is to record choices that teams can execute consistently and repeatably.

This ensures this chapter remains not theory, but a usable compass for consistent execution.

Immediate measures (15 minutes)

• Use this page to prioritize measures and convert them into a backlog.
• Link each measure to an owner, deadline, and demonstrable evidence.
• Repeat periodically based on risk, changes, and incident lessons.

Why this matters

The core of Incident Response Quick Reference is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Web incidents

SQL Injection detected

Detection: - WAF alerts on SQL patterns (UNION SELECT, OR 1=1, '; DROP) - Unusual database errors in application logs (syntax errors, type mismatches) - Suspicious strings in URL parameters or POST bodies in access logs - Unexpected database queries in slow query logs - Data that does not match expected application logic

First response: 1. Isolate the vulnerable application -- place it behind a strict WAF rule or take it offline 2. Analyze web server access logs and WAF logs to identify the exact injection point and all requests from the attacker 3. Check whether data has been exfiltrated -- audit database query logs, check for INTO OUTFILE, LOAD_FILE(), or stacked queries 4. Patch the vulnerability -- replace string concatenation with parameterized queries at the identified injection point 5. Perform a full audit of the database contents to determine if data has been modified, deleted, or exfiltrated

Reference: Web 01 (SQL Injection prevention), Web 12 (Input-output validation)

XSS payload found

Detection: - Stored <script> tags or event handlers in database records containing user input - Content Security Policy (CSP) violation reports in your logging - User reports of unexpected behavior (redirects, pop-ups) - Unknown JavaScript in DOM inspections - Suspicious outbound requests from the browser to unknown domains

First response: 1. Remove the malicious payload immediately from the database or storage medium 2. Determine the scope -- which pages, users, and sessions were affected? Check CSP reports and access logs 3. Implement or tighten Content Security Policy headers (script-src without unsafe-inline) 4. Audit all input fields in the application for the same vulnerability -- if one field is vulnerable, others likely are too 5. Invalidate active sessions of potentially affected users and inform them about the incident

Reference: Web 02 (XSS prevention), Web 11 (Security headers), Web 12 (Input-output validation)

Compromised credentials

Detection: - Impossible travel alerts -- the same user logs in from geographically impossible locations within a short time - Sudden spike in failed login attempts followed by a successful login - Credentials found on paste sites, dark web monitoring alerts, or Have I Been Pwned notifications - Login activity at unusual times or from unknown IP addresses - MFA bypass attempts or unusual MFA enrollments

First response: 1. Force an immediate password reset for the affected account and all accounts with the same or similar password 2. Revoke all active sessions and tokens -- OAuth tokens, API keys, refresh tokens 3. Enable MFA if not already active, or re-register MFA if the attacker may have manipulated it 4. Audit all actions the account has performed since the suspected compromise date -- files, emails, permission changes 5. Check whether the account was used to perform lateral movement or establish persistence

Reference: Web 10 (Authentication hardening), Network 07 (Credential protection)

Network and AD incidents

Ransomware / malware detection

Detection: - Antivirus or EDR alerts on known malware signatures or suspicious behavior - Files with unknown extensions or encrypted files not created by the user - Ransom notes on the file system or as background image - Command-and-control (C2) traffic to known malicious IP addresses or domains - Unusually high CPU or disk usage (encryption process)

First response: 1. Isolate the affected system from the network immediately -- unplug the cable, turn off Wi-Fi, but do NOT shut down the system (evidence in memory) 2. Preserve forensic evidence -- create a memory dump and a disk image before changing anything 3. Check the status of backups -- are they intact, offline, and not also encrypted? Test a restore on an isolated system 4. Determine the scope -- which other systems communicated with the infected system? Check EDR telemetry and network logs 5. Identify the malware variant and the initial access point to stop further spread and investigate appropriate decryption options

Reference: Network 01 (Preventing initial access), Network 02 (Detection and evasion), Network 09 (Detecting persistence)

Unwanted network movement detected

Detection: - Unusual use of admin tools (PsExec, WMI, WinRM) from non-admin workstations - Event logs with unexpected type 3 (network) or type 10 (RemoteInteractive) logons - Authentication patterns deviating from normal behavior -- accounts logging into systems they normally don't access - SMB traffic between workstations (peer-to-peer, not via servers) - New services or scheduled tasks created on remote systems

First response: 1. Isolate all confirmed and suspected compromised systems from the network 2. Assess whether the KRBTGT account has been compromised -- if suspected, plan a double KRBTGT password rotation 3. Rotate credentials of all accounts used on affected systems -- including service accounts and local admin accounts 4. Implement emergency network segmentation to block further lateral movement (isolate critical systems and domain controllers) 5. Analyze the incident path -- determine the starting account, affected systems, and required remediation actions (reconstruct identity and permission path)

Reference: Network 06 (Stopping lateral movement), Network 07 (Credential protection), Network 15 (Network segmentation)

ADCS anomaly detected

Detection: - Unusual certificate enrollment requests -- especially templates that allow ENROLLEE_SUPPLIES_SUBJECT - Changes to certificate templates that did not go through change management - Certificate requests from unexpected accounts or for unexpected principals - ESC patterns in audit logs (Event ID 4886, 4887) -- bulk enrollments or requests with SAN attributes - Unauthorized CA configuration changes

First response: 1. Immediately revoke all suspicious certificates issued after the suspected compromise time 2. Audit all certificate templates for misconfigurations -- focus on ESC1 through ESC16 patterns and restrict ENROLLEE_SUPPLIES_SUBJECT 3. Verify the integrity of the CA itself -- has the CA private key potentially been exfiltrated? Have unauthorized issuing CAs been added? 4. Tighten enrollment permissions -- remove unnecessary enrollment rights and require CA manager approval on sensitive templates 5. Enable certificate audit logging if not already active (Event ID 4886/4887/4898/4899) and actively monitor for new anomalies

Reference: Network 08 (ADCS hardening)

Phishing incident (confirmed)

Detection: - User reports clicking on a suspicious link or entering credentials - Email gateway alerts on suspicious attachments or URLs detected after delivery - Suspicious login activity shortly after a phishing campaign (new location, new device) - Mail flow rules or forwarding rules unexpectedly created - OAuth app consent grants not initiated by the user

First response: 1. Quarantine the phishing email in all mailboxes -- use message trace to identify all recipients and remove the email organization-wide 2. Determine who clicked the link or opened the attachment -- correlate with proxy logs, mail gateway clicks, and endpoint telemetry 3. Force password reset and session revocation for all users who entered credentials or clicked the link 4. Scan endpoints of affected users for malware, suspicious processes, and unauthorized persistence mechanisms 5. Check for post-compromise activity -- inbox rules, OAuth grants, forwarding rules, and unauthorized access to sensitive data

Reference: Network 01 (Preventing initial access), Network 13 (Email and DNS hardening)

DNS integrity incident

Detection: - Users are redirected to wrong websites or see certificate warnings - DNSSEC validation errors in resolver logs - Unexpected changes in NS records, A records, or MX records that did not go through change management - DNS query logs showing responses with unexpected IP addresses - Monitoring alerts on domain registrar changes

First response: 1. Verify the integrity of your DNS records directly at the registrar -- log in and check NS, DS, and contact details 2. Check all DNS records (A, AAAA, MX, CNAME, NS) for unauthorized changes and restore to known good values 3. Flush DNS caches on all internal resolvers and instruct users to flush local DNS caches 4. Enable DNSSEC if not already active, or verify the DS/DNSKEY chain if DNSSEC is already active 5. Activate registrar lock (clientTransferProhibited, clientUpdateProhibited) and enable MFA on the registrar account

Reference: Network 13 (Email and DNS hardening)

Data exfiltration detected

Detection: - Unusually large volume of outbound traffic, especially to external IP addresses or cloud storage - DNS tunneling patterns -- high volume of TXT queries or long subdomain labels to unknown domains - Large uploads to file sharing services or unknown endpoints outside business hours - DLP alerts on sensitive data leaving the network - Unexplained increase in bandwidth on specific endpoints

First response: 1. Block the identified egress channels immediately -- firewall rules, proxy blocks, DNS sinkholing 2. Identify the scope -- what data, how much, from which systems, to which destinations, and over what time period 3. Preserve network captures and logs as forensic evidence -- PCAP, flow data, proxy logs, DNS logs 4. Assess whether a legal reporting obligation applies (GDPR: 72 hours for personal data) and initiate the legal procedure 5. Investigate the initial compromise point -- data exfiltration is almost always a late stage in a broader incident

Reference: Network 10 (Preventing tunneling), Network 15 (Network segmentation and firewalling)

Cloud incidents

Cloud credential leaked (AWS/Azure/GCP)

Detection: - GitHub secret scanning alert or similar tooling that detected credentials in code - Unusual API calls in CloudTrail, Azure Activity Log, or GCP Audit Log -- especially from unknown IP addresses - Unexpected cost spikes or billing anomalies (cryptomining, resource provisioning) - New IAM users, roles, or policies not created via IaC or change management - API calls from regions where the organization does not normally operate

First response: 1. Revoke or deactivate the leaked key or credential immediately -- not just rotate, but permanently revoke the current key 2. Audit the complete activity log (CloudTrail/Activity Log/Audit Log) from the moment the credential was created or leaked 3. Check for persistence mechanisms the attacker has left behind -- new IAM users, backdoor roles, Lambda triggers, extra access keys 4. Rotate ALL secrets the compromised principal could access -- not just the leaked key, but everything the account had access to 5. Implement preventive measures -- remove the credential from the code/repository, switch to short-lived credentials (IAM roles, workload identity)

Reference: Cloud 02/03/04 (AWS/Azure/GCP hardening), Cloud 13 (Secrets management)

Container breakout / Kubernetes compromise

Detection: - Unexpected processes at host level started from a container context - Suspicious Kubernetes API server calls -- privilege escalation, secrets reading, pod creation in kube-system namespace - Containers running with privileged: true, hostPID, or hostNetwork not in the expected configuration - Unexplained changes in RBAC configuration or new ClusterRoleBindings - Admission controller logs showing anomalous pod specifications

First response: 1. Isolate the affected node -- cordon and drain the node in Kubernetes, block network access at the infrastructure level 2. Audit the RBAC configuration -- check ClusterRoleBindings and RoleBindings for unauthorized privilege escalation 3. Inspect all running pods on the affected node and in the cluster -- look at images, security contexts, volume mounts, and service account tokens 4. Review admission controller and audit logs for the full time window of the suspected compromise 5. Check whether the attacker gained access to Kubernetes secrets, service account tokens, or the etcd datastore

Reference: Cloud 05 (Container hardening), Cloud 11 (Kubernetes hardening)

Supply chain / CI/CD compromise

Detection: - Unexpected pipeline runs or pipeline configuration changes not initiated by team members - Build artifacts that do not match expected checksums or signatures - Unknown or modified dependencies in lock files (package-lock.json, Pipfile.lock, go.sum) - Suspicious commits in build configuration files (Jenkinsfile, .github/workflows, .gitlab-ci.yml) - Secret scanning alerts in CI/CD environments or unexpected outbound connections during builds

First response: 1. Halt all deployments immediately -- no more code to production until integrity is verified 2. Audit all pipeline configurations and recently modified build files for unauthorized changes 3. Verify the integrity of all build artifacts -- compare checksums, check signatures, and rebuild from known good source code 4. Review all access rights to the CI/CD environment -- service accounts, deploy keys, webhook secrets, and integration tokens 5. Check whether compromised artifacts have already been deployed and plan a rollback to a known good version

Reference: Cloud 06 (CI/CD pipeline hardening), Cloud 12 (Infrastructure as Code security)

Communication checklist

For every security incident, the communication chain must be activated immediately. Use this checklist to ensure nothing is overlooked:

• Internal: Inform CISO / management
• Legal: Consult privacy officer / DPO
• External: Report to Data Protection Authority within 72 hours when personal data is involved
• External: Inform NCSC for critical infrastructure or significant impact
• Documentation: Maintain a timeline from the moment of detection -- who, what, when, which actions
• Communication: Determine if and when affected users or customers are informed
• Preservation: Ensure forensic evidence is secured before systems are restored

← Previous Implementation Priority Matrix Next → Compliance & Governance