Operational guidance for incident handling

Traffic Light Protocol (TLP): CLEAR

Version: 1.0 (stable)

Date: 28 September 2026

Authors:

• Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI)
• Commission de Surveillance du Secteur Financier (CSSF)
• Computer Incident Response Center Luxembourg (CIRCL)
• Governmental Computer Security Incident Response Team (GovCERT)
• High Commission for National Protection (HCPN)
• Institut Luxembourgeois de Régulation (ILR)

Disclaimer

These rulebooks are solely intended to be used as a practical guidance by an entity facing a cybersecurity incident and looking for immediate assistance from the competent authorities and the Computer Security Incident Response Teams (“CSIRT”). They have been written by a joint team of experts of the High Commission for National Protection (“HCPN”), acting in its role as the Agence Nationale de la Sécurité des Systèmes d’Information (“ANSSI”) and as the Governmental Computer Security Incident Response Team (“GOVCERT.LU”), the Computer Incident Response Center Luxembourg (“CIRCL”), the Commission de Surveillance du Secteur Financier (“CSSF”), and of the Institut Luxembourgeois de Régulation (“ILR”), in the context of 14(5) of the Loi du 5 mai 2026 concernant des mesures destinées à assurer un niveau élevé de cybersécurité (“NIS2 Law”), and in accordance with the missions assigned to the HCPN in its role as ANSSI under Article 3, paragraph 1ter, of the Loi modifiée du 23 juillet 2016 portant création du Haut-Commissariat à la Protection nationale.

These rulebooks must not be used as a substitute for any policies or procedures in force at the entities. Neither the HCPN, the CIRCL, the CSSF, nor the ILR can be held liable in the event of malfunction or unforeseen circumstances or for any damages resulting from the use of the guidance.

These rulebooks do not address the legal obligations to be fulfilled by the concerned entities (e.g., file a complaint, notification of incidents to the CSSF, the ILR, and the Commission Nationale pour la Protection des Données (CNPD), etc.).

Rulebook 0 – Triage & Routing

Context and objectives

This “rulebook 0” is intended to be used as a starting point for the entities suffering a cyber-security incident and looking for assistance.

The objectives of this “rulebook 0” are the following:

• Stabilize operations, safely collect key evidence, support forensic analysis, and route to appropriate playbooks.

• Tick mandatory regulatory reporting clocks immediately (NIS2, DORA, sectoral rules as applicable).

• Enable support for malicious cyber-attacks (human errors and system failures are out of scope of these rulebooks).

The subsequent rulebooks, #1 to #8, follow a common chronological flow of steps that are traditionally used in incident resolution:

• Typical initial detection: the observed artefacts that are relevant triggers for the specific rulebook (note that they are indicatives but not exhaustive, not all the artefacts must be encountered to launch a specific rulebook, and several rulebooks may be applicable to an individual incident).

• Immediate response (containment): useful techniques to consider immediately, to prevent contagion and greater damage.

• Investigation steps: useful techniques to further investigate the incident, enabling to look for deeper infection and spot malicious artefacts.

• Remediation: useful techniques to move away from the incident situation and consider the entity to be back in a safe state.

• Evidence keeping: useful techniques to keep evidences for forensics analysis.

• Post-incident activity: useful points to consider when going through the “lessons learnt” process and seek for potential improvement.

• Communication: useful communication consideration, such as specific services to contact.

• Key watchpoints: useful tips to consider when handling the incident, especially for more sophisticated attacks.

For reference, a traditional and complete framework for incident management is often represented in a cycle of 4 phases:

• Preparation,

• Detection and Analysis

• Containment, Eradication and Recovery

• Post Incident Activity

This set of rulebooks only covers parts of this cycle, addressing generic but still practical operational guidance.

First actions

Assign roles

• Name the responsible people to be involved. For example: a leader, a secretary (for meeting minutes and evidence keeping), analysts and communicator.

• Communication / reporting roles for timely and appropriate communication. This function is to be segregated from incident resolution teams (IT, security).

• If a crisis situation is declared, create a secure war-room (physical or virtual). Track participation and decisions. Also, consider engaging the Business Continuity Management (BCM) lead immediately to assess potential business-critical impact.

Look at the first indicators

• Use monitoring and logs to narrow the attack surface.

• Classify: is the event likely human error, malicious, or uncertain?

• Identify impacted assets, systems, users, and third parties.

Staff wellbeing

• Ensure teams are rotated for sustained incidents. Encourage breaks and provide psychological support as needed.

• Keep clear, calm, factual communication to limit stress.

Open a case log & chain of custody

• Use incident management software if available or standardized template.

• For every artifact: log who / what / when / how, compute hash (SHA-256), store originals read-only.

• Secure all captured evidence in a dedicated, access-controlled repository.

• Carefully consider that the entity’s infrastructure may be compromised and the reliance on out-of-band communication and storage may be a necessity.

Fast classification to route to the proper rulebook(s)

• Keep as much evidence as possible.

• Onboard experts to assist you, either internally or externally: cyber experts, consultants, and legal counsel, as needed.

• Keep track of all investigative hypotheses and keep them updated over time.

• Frequently (re)assess the attack classification based on the information you collect over time, to ensure the invocation of the most relevant rulebook(s).

• Based on the collected indicators, use the classification table below and invoke the most relevant rulebook(s):

Note: The lists of indicators are non-exhaustive.

Rulebook 1 - DoS & DDoS

Rulebook 2 – Malware

Rulebook 3 - Exploitation of communication channels to gain access

Rulebook 4 - Credential theft & account compromise

Rulebook 5 - Vulnerability exploitation

Rulebook 6 - Insider threat

Rulebook 7 - Data exfiltration

Rulebook 8 - Package compromission & supply chain attack

General guidance and watch points

• Maintain timeline of actions (detection → response → containment → recovery).

• Record all decisions and rationales.

• Confirm that backup data is intact and isolated before any restoration.

• Consider engaging external CSIRT/CERT or cyber-insurance provider early if contractual clauses exist.

• After triage, continue reassessment: re-classify the incident as new evidence emerges.

• Keep all internal and external communications factual, short, and go through legal review if needed.

• After the incident is resolved and as part of the post-incident improvement, update your internal procedures, considering the lessons learnt.

• Consider using external tools and procedures¹ for the proper incident handling and evidence collection.

Rulebook 1 – Denial of Service (DoS) & Distributed Denial of Service (DDoS)

This rulebook covers all the kinds of DoS or DDoS attacks: including overflow or crash attacks, at either the network or application layers.

Typical initial detection

• Sudden or sustained service unavailability or severe latency reported by users or monitoring tools

• Saturated network traffic and connection timeouts

• Anomalies in network traffic, occurring at unusual pace (e.g., handshake failures, SYN/ACK reset or malformed packages, Web Application Firewall (WAF) origin timeouts, spikes in 4xx/5xx errors)

• Outstanding alerts from firewall, load balancer, or Internet Service Provider (ISP)

• Sudden drop in availability of external-facing services (Domain Name System (DNS), Virtual Private Network (VPN), email, web portals)

• Abnormal load on backend components (e.g., web servers or database servers), such as increased Central Processing Unit (CPU) consumption

Immediate response (containment)

• Immediately notify the Business Continuity Management (BCM) function and affected business owners

• Identify the type of attack (i.e., volumetric or non-volumetric)

• Contact the Internet Service Provider(s) (ISP) to turn on traffic filtering. If volumetric attack is already suspected, turn on anti-DDoS services that you subscribed (if any)

• If identification is already done, block (or at least implement rate limits) attacking IP ranges, or geo-block

• Mitigate impact on backend systems and critical services e.g., using for instance connection limits (“connections caps”), lower timeouts, or isolating affected systems

• Divert traffic via Content Delivery Network (CDN) if available

• Activate the crisis communication line if customer-facing portals are affected

Investigation steps

• Perform traffic analysis to determine the origin (geographic² and logical) and nature of the traffic, collect indicators of compromise (IOCs), such as network packet captures (PCAP), edge logs, and patterns (e.g., User-Agent, URI, source ASNs)

• Assess whether the attack is a distraction or part of a multi-vector campaign

• Check if camouflage / obfuscation / data exfiltration techniques are employed at the same time of the attack; if yes, invoke other rulebooks as appropriate

• Identify the business assets that are affected and the bottleneck devices

Remediation

• Review web application firewall (WAF) configurations to mitigate protocol-based attacks, if relevant

• Evaluate the business impact for any countermeasures proposed in response to the incident

• Consider blocking based on geography, deny-lists or IP reputation lists

• Consider blocking high-impact IPs and applying rate limits

• Consider implementing challenge-response mechanisms (e.g., CAPTCHA)

• Consider applying temporary cache rules

• Check if backend services are affected by overload and take action as appropriate

• Consider closely monitoring signs of network disruption to catch changes in the attack techniques (e.g., via Quality of Services (QoS) measures)

• Once stable, gradually remove temporary blocks to validate that the service recovery is effective

Evidence keeping

• NetFlow captures (e.g., short PCAP samples)

• Logs from application servers, firewall, Intrusion Detection System (IDS), Intrusion Prevention System (IPS), Content Delivery Network (CDN), load-balancer and WAF

• Maintain timeline and decisions in the incident case log

Post-incident activity

• Identify and patch services that are prone to be leveraged during DDoS attacks (e.g., DNS, Network Time Protocol (NTP) or other amplification vulnerabilities)

• Review your IT architecture to look for resiliency improvement opportunities

• Consider deploying CDN with Anycast routing and caching capabilities, load balancers, multi-region redundancy, and separation of critical and non-critical services

• Perform dependency mapping by identifying all public-facing services (web, Application Programming Interfaces (APIs)), entry points (public IPs and ports), as well as associated CDN, DNS, and authentication mechanisms

• Review alert thresholds and monitoring dashboards for early detection

• Consider subscribing to anti-DDoS services

• If your external communication means were impacted, look for alternate solutions

• Consider including DDoS attacks in your Business Continuity Plan (BCP) / Disaster Recovery Plan (DRP)

Communication

• Coordinate with ISP / hosting provider

• Inform customers and business partners

Key watchpoints

• Application-layer DoS may evade traditional detection mechanisms and volumetric defences may not be reliable

• Attacks may occur on multiple layers (L3/L4 + L7) simultaneously

• Techniques used by attackers shift rapidly and adapt to the defence responses (cat and mouse game)

• Similar campaigns may reappear within days; keep monitoring heightened for a defined period

• Confirm no persistent compromise remains once traffic stabilizes (e.g., injected web shell, backdoor)

Rulebook 2 – Malware

This rulebook applies to all kinds of malware, used for a variety of purposes, such as:

• Data theft and surveillance: infostealers, spyware, keyloggers, etc.

• Remote access and control: remote access trojans (RAT), backdoors, rootkits, abuses RMM tools, etc.

• Destruction and extortion: ransomware, wipers, etc.

• Propagation and distribution: viruses, worms, trojans, botnets, etc.

• Resource exploitation: crypto miners, adware, logic bombs, etc.

Typical initial detection

• Unusual file extensions (.locked, .crypt, etc.)

• Unintended files renaming observed

• Antivirus (AV) or Endpoint Detection and Response (EDR) alerts

• Suspicious process execution

• Outbound connections or beaconing activity to suspicious or known Command & Control (C2)

• Persistence artifacts (services, tasks, Windows Management Instrumentation (WMI))

• Sudden inaccessibility of files or performance issues observed

• Ransom note discovered in end-user directories or shared drives

• Abnormal pop-ups or locked screens observed by users

Immediate response (containment)

• Decide on the strategy based on the malware impact: either keep the system running or power off; knowing that keeping power on preserves memory for forensic analysis and may enable the extraction of the encryption key (in case of ransomware), while powering off may limit the immediate damage and may avoid propagation

• Isolate affected systems from the network immediately (e.g., disconnect network cables, disable Wi-Fi, isolate at switch / Network Access Control (NAC) / hypervisor level)

• In case a ransomware has already impacted the availability of infected systems, notify the Business Continuity Management (BCM) function for potential business impact

• Block suspected domains and IPs

• Change credentials used on infected devices and monitor accounts

• Disable administrative shares and remote access (e.g., Server Message Block (SMB), Remote Desktop Protocol (RDP)) to limit lateral movement

• Prevent spread by disabling scheduled tasks and tools usually used in lateral movement (e.g., PsExec)

• If ransomware is suspected, disconnect backup systems from the network immediately and temporarily suspend automated backups to prevent encryption spread or tampering

• Check integrity of offline copies

Investigation steps

• Create forensic copies for analysis: at first acquire key artifacts by relying on the EDR if available, and perform full disk acquisition (e.g., using “dd” tool) on critical workstations (entry point, domain controllers, attacker pivot)

• Identify initial point of infection (e.g., specific end-user laptop) and initial vector (e.g., phishing, RDP access, exploited vulnerability, etc.)

• In case of ransomware, determine encryption scope, identify ransomware strain (to check for decryptors) and persistence artifacts³

• In case of ransomware, investigate the firewall logs to determine potential data exfiltration

• Review logs for lateral movement, privilege escalation or indicators of persistence

• Use threat-intelligence sources to look for known indicators (e.g., hashes, domains)

• Assess if other rulebooks apply (e.g., Rulebook 3 – Phishing for initial infection, or Rulebook 7 – Data Exfiltration if leaks suspected)

Remediation

• Entities should not pay the ransom (if any is requested) — it does not guarantee recovery and may breach sanctions law

• Before restoring, apply latest patches / updates and perform Antivirus (AV) and Endpoint Detection and Response (EDR) scan

• Restore infected systems from trusted sources (e.g., clean backups or gold images), and keep them disconnected from the network at first and check file integrity

• Invalidate tokens cached on infected hosts

• Although restoration is often the preferred option, it may not be always possible; in this situation, remove artifacts or tools (e.g., registry keys, tasks) used for persistence purpose

• Re-enable network connectivity gradually, while monitoring for indicators of re-infection

• Verify proper operation of restored systems before reintroducing them to production

Evidence keeping

• Keep ransom note, a sample of encrypted files and a sample of the malware

• Before wiping any system, create disk images

• Collect logs (Windows Event Viewer, Sysmon, EDR, network captures), use automation for collection where possible

• Collect volatile data (e.g., memory dumps) from infected machines before power-down (if feasible)

• Document timeline of actions, decisions, and containment steps in the case log

Post-incident activity

• Patch vulnerabilities and entry vectors used in the attack

• Reset credentials (especially admin accounts)

• Consider using “tiered credential rotation”

• Consider reviewing the Group Policy Objects (GPOs) to harden endpoints

• Consider reviewing the configuration of remote management tools (e.g., RDP) and look for potential security improvements

• Consider enabling Multi-Factor Authentication (MFA) for all administrator and remote access

• Consider reviewing endpoint security posture and look for security improvements

• Consider segmenting the internal network

• Consider improving the employees’ awareness

• Consider deploying application whitelisting and EDR behavioural rules

Communication

• Alert IT and Security Operations Centre (SOC) teams immediately

• Inform affected users if their accounts were involved

Key watchpoints

• Beware of double extortion attacks (i.e., data theft and encryption)

• Malware may act as dropper only, pre-positioning attackers for future malicious acts, so watch for dormant second-stage payloads (e.g., triggered scheduled tasks) or abnormal network traffic or system behaviour

• Before recovery steps, validate all recovery sources as infections may re-trigger from persistent devices or offline backups

• Cloud storage or synchronization services can re-propagate infected content if not sanitized

• For ransomware attacks, consider referring to additional specialized guidance⁴

Rulebook 3 – Exploitation of communication channels to gain access

This rulebook applies to all kinds of successful exploitation of communication channels, for instance: phishing, smishing (SMS phishing), vishing (voice phishing), quishing (QR code phishing), pretexting (e.g., CEO fraud), Business Email Compromise (BEC), etc.

Typical initial detection

• User reports suspicious email or link

• User reports suspicious SMS

• Anomalous email activity (auto-forwarding, mass mails)

• Alerts of credentials being re-used

• Reports from other entities, third-parties, Computer Emergency Response Teams (CERTs) or Threat Intelligence feeds indicating an ongoing campaign targeting similar entities

• Detection from email gateway or Security Information and Event Management (SIEM) showing exploitation of communication channels indicators

• Reported fake websites or login portals imitating the entity’s own websites or login portals

Immediate response (containment)

• Identify malicious domains and URLs and block them in proxy, email gateways and spam filters

• Purge the email from all user mailboxes via administrative search-and-remove

• Reset credentials of impacted user and invalidate active sessions (e.g., OAuth tokens, browser sessions)

• Check for unintended auto-forwarding rules and remove them

• Check endpoints of affected users for malware or credential stealers (run an Endpoint Detection and Response (EDR) scan)

• If internal domains are spoofed, consider blocking the delivery from external sources using these spoofed internal domains

• Keep evidence (e.g., copy of original emails and headers) before deletion

• If multiple users reported identical messages, consider that a large-scale campaign is on-going and notify the Security Operations Centre (SOC) and the Management

Investigation steps

• Due to volume, investigations may not always be performed duly; keep processes simple and prioritised

• Analyse the email headers to check sender authenticity, the message’s path and any trace of anomalies

• Don’t click on the payloads or URLs, however inspect them in a safe sandboxed environment to determine the malicious intent (e.g., credential harvesting, malware delivery, scam, OAuth token abuse).

• Identify the users’ interactions (e.g., click, download, open) and the related impacts

• Correlate Indicators of Compromise (IoCs) (e.g., IP, domain, hash, email subject) with other alerts and external sources (e.g., Threat Intelligence feeds, warning from CERTs)

• Examine the phishing page⁵ to identify all involved parties, such as an initial redirector, or credentials posted to another website

• Collect any artifacts you can fetch (e.g., phishing kit, Telegram ID/key, etc.)

Remediation

• Check with external sources (e.g., Threat Intelligence feeds, warning from CERTs) if other similar phishing kits or campaigns are on-going and block them

• Ensure that your email security settings (i.e., Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), Domain-based Message Authentication, Reporting & Conformance (DMARC)) are in line with leading security practices

• Reset or rotate credentials and tokens for all confirmed victims

• Monitor post-incident activity on affected accounts for at least 72 hours, in particular check in logs if malicious downloads, macros or fileless payloads are executed

Evidence keeping

• Keep the original malicious communication, including the headers

• Collect mail server logs and user mailbox export

• Screenshots of phishing pages⁶, if safely captured in a sandbox

Post-incident activity

• Consider improving the user awareness on social engineering communication focusing on recognizing suspicious messages and reporting procedures

• Strengthen email gateway rules, condition access/ Multi-Factor Authentication (MFA), OAuth and third-party app approval flows and sandboxing

• Consider conducting a phishing campaign exercise for training evaluation

• If a proxy is deployed, verify that SSL/TLS termination is enabled and that request methods are properly logged (the ability to identify “POST” requests is particularly valuable)

• Evaluate the SPF configuration

Communication

• Notify impacted users promptly, explaining the steps they must take (password reset, token revocation, vigilance)

• Escalate to Top Management if multiple users are targeted

• Consider making a communication to all employees about an on-going deceptive/malicious communication campaign

Key watchpoints

• Beware of phishing attempts looking to gather OAuth tokens, these may be used to bypass password resets

• Attackers may collect compromise access now, and reuse later

• Mobile users are increasingly targeted via SMS (i.e., smishing) or messaging applications (i.e., vishing)

Rulebook 4 – Credential theft & account compromise

This rulebook applies to all the types of theft of credentials or compromise of accounts, including for instance: session hijacking, pass-the-hash attack, pass-the-ticket attack, brute forcing, password spraying, Kerberoasting, credential dumping (LSASS), etc.

Typical initial detection

• Unusual login activity (geographic anomalies, impossible travel, unusual token usage)

• Unintended bypass of Multi-Factor Authentication (MFA)

• Privilege escalation alerts

• Unusual activities detected on mailboxes or cloud services, such as outstanding downloads, unintended permission changes, creation of new rules/delegates, or multiple failed logins or brute-force detections

• Alerts from other entities, Computer Emergency Response Teams (CERTs) or Threat Intelligence Feeds of identified compromised accounts in the entity’s domains

• Suspicious OAuth or Application Programming Interfaces (API) token usage, in particular outside of the corporate IP range

Immediate response (containment)

• Force logoff and password reset of compromised accounts

• Terminate compromised sessions and revoke associated tokens

• Notify the Security Operations Centre (SOC) and the Identity and Access Management (IAM) team to monitor for potential reuse or reauthentication attempts, used in password spraying attacks

Investigation steps

• Identify entry vector (e.g., phishing, brute-force, token theft)

• Review access logs

• If MFA was by-passed, understand how (e.g., application-based attack or phishing relay) and determine whether the first rogue IP that logged in was also a phishing website

• Check for lateral movements and privilege escalation

• Check for persistence mechanisms, such as new MFA devices, new application accounts or passwords, tokens with long expiration date, unintended delegated mailbox access

• Review logs of Endpoint Detection and Response (EDR) and affected components for credential dumping tools

• Look for potential privilege-escalation events or newly created accounts

• Look for unintended OAuth consents and API tokens, to detect potential unauthorized application integrations

• Look for malicious mail rules

Remediation

• Consider the scale of the impact and resetting passwords, API keys and tokens as appropriate

• Consider implementing conditional access (e.g., MFA, geo-fencing), in particular for sensitive, administrator and remote access

• Review the roles in the identity directory (e.g., Active Directory (AD)) and remove unauthorized privileges

• Apply patches on affected components and/or apply mitigation measures to avoid new capture of credentials or tokens

• Implement detection rules to detect ongoing or renewed attacker activity — such as repeated login attempts or the creation of new unauthorized sessions — even after credentials are changed

• Primarily for cloud hosted email platforms, remove malicious application permissions and clean up mail forwarding/filtering rules

Evidence keeping

• Authentication logs (e.g., Active Directory (AD), Identity Provider (IdP), Virtual Private Network (VPN))

• Endpoint Detection and Response (EDR) logs

Post-incident activity

• Consider hardening the password policy and enforcing MFA at large scale

• Review the use of service accounts and Application Programming Interface (API) keys, and look for security improvement opportunities

• Review and look for improvements in Identity and Access Management (IAM) policies and permissions

• Consider raising awareness among users about phishing and credentials hygiene

• Consider implementing detection use cases based on behavioural analytics and automated risk-based conditional access

Communication

• Notify impacted users promptly and advise them to verify their other accounts for reuse risks

• Inform Security Operations Centre (SOC) and IT

• Inform Management and legal / compliance departments if sensitive data was accessed, altered or exfiltrated

Key watchpoints

• Token-based attacks may not be impacted by password reset attempts

• Attackers often use automation for persistence (e.g., scheduled tasks)

Rulebook 5 – Vulnerability exploitation

This rulebook applies to all kinds of vulnerabilities: web application vulnerabilities, API exploitation, known exploited vulnerabilities (KEV), configuration flaws exploitation, memory and binary exploitation, etc.

Typical initial detection

• Unusual behaviour of systems or applications (e.g., error, crashes, defacement)

• Unusual Application Programming Interface (API) calls or access to data

• Unusual number of Web Application Firewall (WAF) or Security Information and Event Management (SIEM) alerts (e.g., spikes in 4xx/5xx error messages)

• Reverse or web shells were observed or suspected to be used

• Abnormal page volumetry (rendered page size / requests per IP)

• Abnormal behaviour in logs (e.g., access logs)

Immediate response (containment)

• Isolate affected systems or applications

• Identify the vulnerable path and kill-switch it

• Consider disabling exposed API endpoints

• Consider deploying or updating blocking WAF rules based on observed attack patterns

• Notify the Business Continuity Management (BCM) function if critical systems or applications are affected

• Keep logs and snapshots before patching or rebooting systems

• Monitor for lateral movement from the web hosting systems to internal networks

Investigation steps

• To identify the exploited vulnerability, review web, API and systems access / error logs and reverse-proxy logs

• Check if the vulnerability was introduced by a recent change, by checking the source code (e.g., use “diff” command between recent deploys)

• Look for web shells (e.g., unusual server-side scripts (PHP, Python, Ruby, Node.js, ASP.NET (or other) files))

• Inspect active network connections and running processes for signs of unauthorized outbound traffic or reverse shells

• Check files integrity by comparing hashes with baseline (if available), and verify timestamps for unexpected modifications

• Look for traces of persistence, such as new or modified scheduled tasks, system services or startup scripts

• If possible, perform a memory analysis to detect fileless malware or injected code that does not exist on disk

• Determine whether attackers accessed, altered or exfiltrated (sensitive) data (invoke Rulebook 7 – Data Exfiltration if suspected)

Remediation

• Patch vulnerable components or, if not possible, consider disabling

• Rotate secrets / credentials (e.g., tokens, API keys, database credentials)

• Remove shells and implants

• After cleaning steps, consider rebuilding the entire stack where the compromised application is hosted

• Conduct a full vulnerability scan and validate remediation of exploited paths

• Re-enable services progressively, under close monitoring

Evidence keeping

• Full HTTP logs, access / error logs and WAF alerts

• System and application layers logs (if any)

• Keep images of the stack where the application is hosted (e.g., container, virtual machine)

• “diffs” of the system hosting the compromised application

Post-incident activity

• Consider hardening the deployment pipeline and ensuring security review / security testing is part of the development lifecycle

• Consider improving (or at the very least enabling) API authentication and rate-limits

• Consider performing a full code review if custom development

• Consider improving access and input validation controls

• Consider implementing Server-Side Request Forgery (SSRF) and deserialization guards

• Consider conducting improving the security review practice, such as regular penetration testing, vulnerability scans and source code reviews

Communication

• Alert the development team and/or infrastructure team accordingly to the attack vector

• Notify business owners of any application downtime or user impact

• Inform Management and legal / compliance departments if sensitive data was accessed, altered or exfiltrated

Key watchpoints

• Exploits often lead to data theft: assume exfiltration until disproven

• Attacks may exploit business logic flaws, not just technical bugs

Rulebook 6 – Insider threat

This rulebook applies to situations where an insider (e.g., employee, consultant), having genuine access to the entity’s systems, leverage the granted access to perform malicious actions.

Typical initial detection

• Unusual access to sensitive data

• Unusual large outbound traffic

• Unusual traffic outside working hours

• Complaints or warnings from Human Resources (HR) department

• Unauthorized use of administrative tools or privilege escalation attempts

Immediate response (containment)

• Restrict user access thanks to need-to-know and least-privilege principles

• Monitor ongoing activities, using approved tools and procedures, in respect of applicable laws and internal policies

• Notify HR, legal, and third-party if affected

• Suspend access (at least temporarily), if risk of data theft or sabotage is suspected

Investigation steps

• Collect access history, behavioural anomalies and recent changes in permissions or roles

• Keep evidence, in respect of applicable laws and internal policies, for further (forensics) analysis

• Use secure communication channels for inquiries with involved stakeholders

• Perform intent analysis (e.g., looking at disciplinary sanctions, internal business changes, departures, etc.) and leverage threat intelligence

Remediation

• Suspend or, at least, limit access if threat is confirmed

• Use psychological support in case of internal conflict or distress

• Change shared passwords and rotate Application Programming Interfaces (API) keys that the insider could have accessed

Evidence keeping

• Collect end-user computer logs (e.g., email activity, file access), in respect of the Law

• Communication with HR, legal, or management about the case

• Role history within the entity

• Maintain strict access control to investigative data (“need-to-know” principle)

Post-incident activity

• Consider enhanced background screening procedures

• Consider implementing user behaviour analytics (UBA)

• Consider reviewing the Data Loss Prevention (DLP) policy and related measures

• Consider enforcing stronger segmentation, based on need-to-know and least-privilege principles, and role-based access

Communication

• Continuously communicate with legal, compliance, HR, and management

• Limit information sharing to those strictly required (“need to know” principle) to protect confidentiality

Key watchpoints

• Do not confuse malicious acts with negligence

• Personal motives are common

Rulebook 7 – Data exfiltration

This rulebook applies to situations where entity’s data is exfiltrated, without authorization.

Typical initial detection

• Unusual access to sensitive data

• Unusual large outbound traffic

• Unusual traffic outside working hours

• Suspicious (obfuscated) outbound traffic

• Alert from Endpoint Detection and Response (EDR) or threat intelligence resources

• Sudden large file transfers

• Long dwell

• Data Loss Prevention (DLP) or proxy alerts indicating sensitive data movement outside of approved channels

• Data discovered outside traditional channels (e.g., Telegram, web forums, press, or other media)

Immediate response (containment)

• Decide on the strategy based on the sensitivity and leakage impact: either block or monitor

• Monitor or isolate suspected compromised systems, ensuring forensic integrity is preserved

• Limit or block suspected exfiltration channels (e.g., Secure File Transfer Protocol (SFTP) or Hypertext Transfer Protocol Secure (HTTPS) to unusual Autonomous System Numbers (ASNs) or cloud platform)

• Disable remote access (e.g., Virtual Private Network (VPN), Secure Shell (SSH)) on suspect compromised accounts and machines

• Monitor for Command and Control (C2) traffic

• Perform full disk acquisition (e.g., using “dd” tool)

Investigation steps

• Check for persistence traces (e.g., scheduled tasks, web shells, “Living Off the Land” (LOTL) use)

• Identify exfiltrated data and volume

• Build a timeline

• Determine dwell time and entry point (e.g., exploited vulnerability)

• Look for locations used for data staging (e.g., temporary folders, shared drives, cloud synchronization directories)

• Check systems that can be used for lateral communication (e.g., email, chat, and collaboration platforms)

Remediation

• Remove attacker persistence (e.g., web shells, implants, scheduled tasks)

• Consider restoring the whole IT infrastructure, or at least the part that is for sure compromised

• Consider resetting all the credentials and tokens (i.e., user accounts, technical accounts, administrative accounts, etc.), including long-lived and cloud-integrated tokens

• Consider using “tiered credential rotation”

• Consider reviewing the Data Loss Prevention (DLP) policy and related measures

• Consider segmenting access (e.g., Zero-Trust and least-privilege principles)

Evidence keeping

• Network captures, proxy logs, system images

• Any log evidencing a staged attack (e.g., relying on collaboration, chat or email)

• DLP and Cloud Access Security Broker (CASB) alerts

Post-incident activity

• Patch all entry vectors (e.g., VPN, email, apps)

• Consider implementing a threat-hunting practice

• Consider deploying detections mechanisms for LOTL and unusual outbound traffic

Communication

• Escalate to Top Management, legal, and compliance

• Coordinate with Data-Protection Officer (DPO), if personal data was exfiltrated (c.f., General Data Protection Regulation (GDPR))

Key watchpoints

• Exfiltration may be stealthy and encrypted (e.g., sent to common cloud services, and chunked in small packets)

• Advanced attackers may use fileless techniques and hide in legitimate processes (LOTL)

Rulebook 8 – Package compromission & supply chain attack

This rulebook applies to situations where an attack leverages third-party dependencies (e.g., software packages, libraries, open-source codes, firmware, etc.) to compromise the entity’s systems.

Typical initial detection

• Unusual alerts following a software or firmware update, or the integration of a new third-party package

• Failures in hash validation or use of unexpected certificates used to sign packages

• Outbound traffic to abnormal domains

• Endpoint Detection and Response (EDR) alerts on newly updated binaries, installers or side-loaded Dynamic-Link Libraries (DLLs)

• Permission abuse of an application or integration (e.g., observed via unexpected OAuth / Single Sign On (SSO) consent or expanded scopes)

• Unusual requests originating from third-party services (e.g., API calls to unusual domains)

• Software behaviour not in line with the intended design (i.e., Software Bill of Materials (SBOM) drift)

Immediate response (containment)

• For all the systems, freeze the deployments and disable the auto-updates

• At network level, move affected hosts, containers and build agents (i.e., the worker machines that execute the Continuous Integration / Continuous Delivery (CI/CD) jobs) to quarantine

• Block the observed Indicators of Compromise (IoCs) (e.g., domains, IP addresses, hashes, certificates)

• Restrict the outbound traffic of affected systems to a small allowlist of trusted software-update endpoints

• Revoke or rotate affected (or suspected to be affected) secrets and tokens

• Disable suspicious OAuth and SSO integrations

• Require an additional authentication challenge (beyond the initial login) for administrators

• Inform the Security Operations Centre (SOC) and the Business Continuity Management (BCM) function of the incident, to seek for additional technical and business impact

• Look for vendors or maintainers’ advice

Investigation steps

• Identify the compromised components; in particular note the affected versions and install times

• List all the subsequent assets at risks, including those installed, updated, or used by the compromised components

• Verify digital signatures and compare hashes with trusted sources

• Validate certificate chain and revocation

• Look for full process descendant chains (i.e., children processes, grandchildren processes, etc.) originating from affected installers

• Review the CI/CD logs, the artifact repository records and SBOMs for potential traces of alteration

• Audit logs to identify potential token abuse or data access

• Hunt for traces of persistence (e.g., services, scheduled tasks, Windows Management Instrumentation (WMI), etc.)

• Check for traces of lateral movement, privilege escalation and exfiltration

• Verify the authenticity and integrity of upstream update channels and sources (e.g., golden images, Mobile Device Management (MDM) baselines, mirrors, update proxies like Windows Server Update Services (WSUS)) by validating signatures, certificate chains/revocation, and digests

• Keep a timeline and take note of remediation decisions and actions

Remediation

• Put the compromised packages in a blocklist and remove them from the registries and caches

• Patch with clean updates or roll back to last know clean versions

• Rebuild, or redeploy or replace the compromised components, using trusted sources

• Recreate the impacted systems

• Rotate or invalidate, as appropriate, the secrets, API keys, certificates, signing keys, SSH keys, SSO / OAuth refresh tokens, etc., potentially exposed to the attack

• Remove the persistence artifacts (e.g., services, scheduled tasks, Windows Management Instrumentation (WMI), etc.)

• Perform integrity checks, check packages execution in sandboxes and increase the monitoring sensitivity (temporarily)

Evidence keeping

• Take snapshots of compromised Virtual Machines (VMs) and take capture of memory on key affected hosts

• Keep copies of the malicious components (e.g., installers, packages, containers, certificate chains, etc.)

• Keep a list of the instructions used to produce the malicious components (e.g., URL of repositories, applied patches, required packages, compiler, commands, etc.) and the traces of who / what built it and when

• Keep logs of EDR, endpoints, CI/CD, artifact registries, proxies, access, etc.

• Capture network traffic of key affected systems

• Keep trace and a timeline of the communications with the vendors or the maintainers

Post-incident activity

• Consider enforcing the source verifications, for instance via verified SBOMs and attestations

• Consider implanting private registries and update proxies (rather than connecting directly to the Internet) together with a source allowlist

• Consider using “tiered credential rotation” and reducing the lifetime of tokens for third-party access

• Consider reviewing CI/CD hardening controls and look for potential improvements (e.g., only accept components with valid signatures, Multi-Factor Authentication (MFA) for privileged access to the pipeline, least privilege principle, enforce isolation for runners (i.e., not privileged, destroyed after each build, segregated as much as possible))

• Consider implementing a careful strategy for deployments (e.g., “canary” releases and staged rollouts with rollback mechanisms)

• Consider ongoing controls over third‑party components, verifying software authenticity with digital signatures, and limiting connections to known certificates only where appropriate

• Consider improving the vendors and maintainers’ risk review, including contract security clauses and “kill-switch” rights (i.e., possibility to disable product, or update or data flow, on the entity’s end)

• Consider monitoring exfiltration via tunnelling techniques

Communication

• Coordinate with the Security Operations Centre (SOC) and IT teams

• Contact the vendors or the maintainers for IoCs, patches, advice and root cause analysis

• Inform business owners and clients if appropriate

Key watchpoints

• Beware of stolen certificates, which are commonly used, and prevent relying solely on code signing

• Beware of auto-update feature that can lead to new infection

• Third-party application may have excessive access rights

• Beware of long dwell time and potential second‑stage payloads

• Attackers often target build systems; therefore, isolation and monitoring are key

• Offline and immutable backups are key to recover

Glossary (generated via artificial intelligence tools)