Academic Publications

Presentations

The Digital First Aid Kit

The Digital First Aid Kit aims to provide preliminary support for people facing the most common types of digital threats. The Kit offers a set of self-diagnostic tools for citizen, human rights defenders, bloggers, activists and journalists fac ing attacks themselves, as well as providing guidelines for digital first responders to assist a person under threat.

Description	Last update
	2nd September 2014
	2nd September 2014
	2nd September 2014
	2nd September 2014
	2nd September 2014
	2nd September 2014

The Digital First Aid Kit (German Edition)

Description	Last update
	18th March 2015
	26th March 2015

Security Advisories

The latest CIRCL security advisories are published by Vulnerability-Lookup.

Other publications

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)

Why were these rulebooks developed?

The rulebooks were developed in the context of Article 14(5) of the Loi du 5 mai 2026 concernant des mesures destinées à assurer un niveau élevé de cybersécurité (“NIS2 Act”).

Under Article 14(5), following receipt of an initial notification of a significant incident, the competent authority provides the notifying entity with an initial response and, at the entity’s request, guidance or operational advice on the implementation of possible mitigation measures. Such guidance is provided by the competent authority in cooperation with the relevant Computer Security Incident Response Team (“CSIRT”), which may also provide additional technical support at the entity’s request.

The rulebooks are intended to translate this operational guidance into practical and readily usable resources, helping entities facing a cybersecurity incident to rapidly identify and implement appropriate mitigation measures and to facilitate their interaction with the competent authority and the relevant CSIRT.

Who are they intended for?

The rulebooks are primarily intended for public and private sector entities subject to the NIS2 Act. They provide operational guidance for handling cybersecurity incidents, in particular in the context of a significant incident notified to the competent authority in accordance with the notification mechanism established by the NIS2 Act.

They are especially relevant for technical teams, cybersecurity officers and other staff responsible for incident handling and response.

The rulebooks may also serve as a practical reference for other organisations facing a cybersecurity incident or seeking to prepare and improve their incident response procedures.

What do the rulebooks provide?

The rulebooks provide practical, step-by-step guidance for handling specific types of cybersecurity incidents. Each rulebook addresses a particular incident scenario and structures the response across the main stages of incident handling.

Depending on the type of incident, the guidance covers:

• typical initial detection, including common signs, alerts and indicators that may reveal an incident;
• immediate response and containment measures to limit the impact and prevent further compromise;
• investigation steps to assess the scope, origin and consequences of the incident;
• remediation measures to address the causes of the incident and restore a secure environment;
• evidence keeping, including relevant information and technical artefacts that should be preserved;
• post-incident activities to reduce the likelihood or impact of similar incidents in the future;
• communication measures, including communication with affected users, management or other relevant parties; and
• key watchpoints highlighting specific risks or issues requiring particular attention.

The rulebooks are designed as practical reference guides that can be consulted during an incident, enabling technical and incident response teams to quickly identify relevant actions and measures for the specific situation they are facing.

A collaborative and evolving resource

The rulebooks were jointly developed by cybersecurity experts from the HCPN/ANSSI/GOVCERT.LU, CIRCL, CSSF and ILR.

To foster cyber security community feedback and ensure quality over time, the rulebooks are hosted on GitHub in addition to the PDF document. The contributions of cyber security professional are very welcomed and will be considered by the authors in future updates.

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 in the context of Article 14(5) of the Loi du 5 mai 2026 concernant des mesures destinées à assurer un niveau élevé de cybersécurité (“NIS2 Act”), 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.).

Multiple vulnerabilities have been disclosed in Citrix NetScaler ADC (formerly Citrix ADC) and Citrix NetScaler Gateway (formerly Citrix Gateway).

The vulnerabilities include unauthenticated remote code execution, memory corruption, HTTP request smuggling, security-policy bypass, denial of service and TCP Initial Sequence Number (ISN) prediction issues.

Two vulnerabilities, CVE-2026-88771 and CVE-2026-88772, have a CVSS v4.0 base score of 9.5 and can result in remote code execution. According to Citrix and multiple observations from third-parties, exploitation of these vulnerabilities has been observed against unmitigated NetScaler deployments.

Of particular concern, CVE-2026-88771 affects all vulnerable NetScaler ADC and NetScaler Gateway deployments, including appliances using the default configuration. No additional feature needs to be enabled for the vulnerability to be exposed.

CIRCL strongly recommends administrators of affected NetScaler systems to upgrade without delay and to investigate potentially exposed systems for signs of compromise.

Affected Products

The following supported versions are affected:

• NetScaler ADC and NetScaler Gateway 14.1 before 14.1-73.37
• NetScaler ADC and NetScaler Gateway 13.1 before 13.1-64.23
• NetScaler ADC 14.1 FIPS before 14.1-73.37 FIPS
• NetScaler ADC 13.1 FIPS and NDcPP before 13.1-37.279

Secure Private Access Hybrid deployments using NetScaler instances are also affected and the associated NetScaler appliances must be upgraded.

The vulnerabilities concern customer-managed NetScaler ADC and NetScaler Gateway appliances. Citrix-managed cloud services and Citrix-managed Adaptive Authentication are updated by Cloud Software Group.

Vulnerabilities

CVE-2026-88771 — Unauthenticated Remote Code Execution

A remote code execution vulnerability caused by improper input validation can allow an unauthenticated remote attacker to execute arbitrary commands.

Precondition: None. All affected NetScaler ADC and NetScaler Gateway deployments are concerned, including default configurations.

• CWE: CWE-20 — Improper Input Validation
• CVSS v4.0: 9.5
• Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
• Exploitation: Observed in the wild

This vulnerability should be considered the highest priority because exposure does not depend on an optional NetScaler feature being enabled.

CVE-2026-88772 — Memory Overflow Leading to RCE or DoS

A memory overflow vulnerability can result in remote code execution or denial of service.

Precondition: DTLS must be enabled. DTLS is enabled by default on VPN virtual servers unless explicitly disabled.

• CWE: CWE-119 — Improper Restriction of Operations within the Bounds of a Memory Buffer
• CVSS v4.0: 9.5
• Vector: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
• Exploitation: Observed in the wild

CVE-2026-88773 — HTTP Request Smuggling

The vulnerability allows inconsistent interpretation of HTTP requests, resulting in an HTTP request smuggling condition.

Precondition: HTTP functionality must be configured on the affected appliance. This includes Load Balancing, Content Switching, VPN or Authentication virtual servers using HTTP or SSL.

• CWE: CWE-444 — Inconsistent Interpretation of HTTP Requests
• CVSS v4.0: 9.3
• Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N

CVE-2026-88774 — HTTP URL Policy Bypass

Improper use or interpretation of HTTP URL-based expressions can allow configured security or feature policies to be bypassed.

Precondition: An affected HTTP URL-based policy expression must be configured.

• CWE: CWE-16 — Configuration
• CVSS v4.0: 7.0
• Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:H/SI:H/SA:N

CVE-2026-88775 — Memory Overflow in Gateway or AAA Configurations

A memory overflow vulnerability can result in unpredictable behaviour or denial of service.

Precondition: NetScaler must be configured as one of the following:

• Gateway:

  • SSL VPN
  • ICA Proxy
  • CVPN
  • RDP Proxy

• AAA virtual server

• CWE: CWE-119 — Improper Restriction of Operations within the Bounds of a Memory Buffer

• CVSS v4.0: 8.8

• Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N

CVE-2026-88776 — Memory Overflow in Oracle Load Balancing

A memory overflow vulnerability can lead to unpredictable behaviour or denial of service.

Precondition: NetScaler must be configured with a Load Balancing virtual server of type Oracle.

• CWE: CWE-119 — Improper Restriction of Operations within the Bounds of a Memory Buffer
• CVSS v4.0: 8.8
• Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N

CVE-2026-88777 — Memory Overflow in Non-HTTP L7 Services

A memory overflow vulnerability can result in unpredictable behaviour or denial of service.

Precondition: NetScaler must be configured as an LB/CS or CGNAT-LSN/NAT64 device with a non-HTTP Layer 7 protocol feature enabled.

Potentially affected configurations include FTP, RTSP, DNS64 and NAT64 deployments.

• CWE: CWE-119 — Improper Restriction of Operations within the Bounds of a Memory Buffer
• CVSS v4.0: 8.8
• Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N

CVE-2026-88778 — TCP Initial Sequence Number Prediction

The TCP Initial Sequence Number generation mechanism can result in predictable values, potentially weakening assumptions about the integrity of TCP connections.

Precondition: TCP functionality is enabled and Enhanced ISN Generation is disabled.

• CWE: CWE-342 — Predictable Exact Value from Previous Values
• CVSS v4.0: 8.8
• Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:L/SI:L/SA:L

Recommended Actions

CIRCL recommends that administrators upgrade affected NetScaler appliances as soon as possible.

The following versions contain fixes:

Because exploitation of CVE-2026-88771 and CVE-2026-88772 has already been observed, upgrading should not be considered sufficient evidence that an appliance was not previously compromised.

For Internet-facing appliances that were running an affected version, administrators should also:

1. preserve relevant logs and forensic evidence before making significant changes where operationally possible;
2. review NetScaler and external network/security logs for suspicious activity;
3. investigate unexpected configuration, filesystem or process changes;
4. review administrative and authentication activity;
5. review activity from the appliance towards internal infrastructure;
6. use the indicators and detection mechanisms provided by Citrix;
7. follow the organisation’s incident response process if compromise is suspected.

External forwarding of NetScaler logs to a SIEM or other independent logging infrastructure is strongly recommended, as it can provide evidence that remains available if the appliance itself is compromised.

Configuration Checks

Administrators can use their NetScaler configuration to identify whether additional vulnerability-specific preconditions are met.

CVE-2026-88771

No configuration check is required. All affected versions meet the vulnerability precondition.

CVE-2026-88772

Review VPN and virtual-server configurations for DTLS.

For example:

1

add vpn vserver vpn1 SSL 10.0.0.0 443 -Listenpolicy NONE

DTLS is enabled by default in this configuration.

An explicit:

1

-dtls OFF

indicates that DTLS has been disabled for the VPN virtual server.

Also review explicitly configured DTLS virtual servers.

CVE-2026-88773

Review HTTP/SSL Load Balancing, Content Switching, VPN and Authentication virtual servers:

1
2
3
4

add lb vserver <vserver-name> <HTTP or SSL>
add cs vserver <vserver-name> <HTTP or SSL>
add vpn vserver <vserver-name> <HTTP or SSL>
add authentication vserver <vserver-name> <HTTP or SSL>

CVE-2026-88775

Relevant configuration entries include:

1
2

add vpn vserver .*
add authentication vserver .*

CVE-2026-88776

Search for Oracle Load Balancing virtual servers:

1

add lb vserver.*ORACLE.*

CVE-2026-88777

Review configurations using non-HTTP Layer 7 protocols, including:

1
2
3
4
5
6
7
8

add (lb|cs) vserver .* FTP
add service .* FTP
add lb monitor .* FTP
add lb monitor .* FTP-EXTENDED
set lsn group .* -rtspalg ENABLED
add lb vserver .* DNS .* -dns64 ENABLED
add dns policy64
add nat64

For LSN/CGNAT configurations, administrators should pay particular attention to FTP ALG configuration.

CVE-2026-88778

Check whether Enhanced ISN Generation is disabled:

1

show ns tcpparam | grep "Enhanced ISN Generation"

A result containing:

1

Enhanced ISN Generation: DISABLED

indicates that the vulnerable configuration precondition may be met when applicable TCP-based virtual servers are configured.

Administrators affected by CVE-2026-88778 should also apply the TCP configuration changes recommended by Citrix.

Incident Response Considerations

Due to the reported exploitation of the two remote-code-execution vulnerabilities, CIRCL recommends treating vulnerable Internet-exposed NetScaler appliances with additional caution.

Where an appliance was exposed to untrusted networks while vulnerable, organisations should consider performing a compromise assessment rather than relying exclusively on successful installation of the security update.

In particular, successful patching prevents subsequent exploitation of the corrected vulnerabilities but does not remediate persistence or other changes potentially introduced before the update.

References

• CIRCL - Information Bundle
• Citrix Support
• CISA

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 27th September 2026

CIRCL and Horesca have been informed of a phishing campaign targeting customers of hotels in Luxembourg. A significant number of hotel guests have received fraudulent messages through different communication channels, including WhatsApp messages containing malicious URLs.

The phishing messages are particularly convincing because they include information related to legitimate hotel bookings. This increases the likelihood that victims will trust the message and engage with the fraudulent website or communication channel.

The apparent objective of the campaign is to trick hotel customers into making payments to an actor-controlled account or payment infrastructure.

Observed Activity

Victims have reported receiving messages that appear to reference real hotel reservations. These messages may include booking-related information that is accurate or sufficiently close to a legitimate reservation to appear trustworthy.

The phishing messages typically contain a URL and encourage the recipient to take action, such as confirming a reservation, updating payment details, or completing a payment.

At this stage, CIRCL assesses that the information used in the phishing messages may originate from data associated with services operated by myLighthouse, a platform used in the hotel and hospitality sector.

The exact origin of the data exposure is currently unclear. Possible scenarios include, but are not limited to:

• a vulnerability affecting a service or integration;
• abuse or compromise of one or more hotel accounts;
• unauthorised access to or exfiltration of booking-related data;
• misuse of legitimate access to hotel or booking-management systems.

The investigation by Lighthouse has not yet clearly established the precise source of the data used in the phishing campaign.

Impact

The campaign may affect hotel customers who have made legitimate bookings in Luxembourg (not limited) and who receive fraudulent communications referencing those bookings.

Potential impacts include:

• financial loss due to fraudulent payments;
• disclosure of personal or payment-related information;
• loss of trust in hotel communication channels;
• increased workload for hotels, financial institutions, and incident response teams.

Recommendations for Hotel Owners and Operators Using myLighthouse

CIRCL recommends that hotels using myLighthouse take the following actions as a priority:

1. Reset credentials

   • Reset passwords for all accounts associated with myLighthouse.
   • Ensure that passwords are unique and not reused across other services.

2. Enable and enforce multi-factor authentication

   • Enable MFA for all accounts where available.
   • Lighthouse has announced enforcement of MFA as of 1 June.
   • Hotels should verify that MFA is active for all relevant users and accounts.

3. Review account access

   • Review active users and remove accounts that are no longer required.
   • Check whether any unexpected or unauthorised accounts have access.
   • Review access rights and apply the principle of least privilege.

4. Inform customers about legitimate payment procedures

   • Clearly communicate the official payment methods used by the hotel.
   • Remind customers that unexpected payment requests received through WhatsApp, SMS, or unofficial channels should be treated with suspicion.
   • Provide customers with a trusted contact point to verify payment requests.

5. Monitor for suspicious activity

   • Monitor customer reports of phishing attempts.
   • Review logs, where available, for unusual access patterns.
   • Report suspicious URLs and related indicators to CIRCL.

Recommendations for Victims and Hotel Customers

If you receive a message via WhatsApp, SMS, email, or another channel that refers to your hotel booking and asks you to click a link or make a payment, CIRCL recommends the following:

1. Do not click on the URL

   • Do not open links contained in suspicious or unexpected messages.
   • Do not enter personal, booking, or payment information on websites reached through such links.

2. Verify directly with the hotel

   • Contact the hotel using contact details obtained from the official hotel website or your original booking confirmation.
   • Do not rely on phone numbers, links, or contact details provided in the suspicious message.

3. If you interacted with the phishing site

   • Contact your bank or financial provider immediately.
   • Notify them that you may have been targeted by payment fraud.
   • Follow their instructions regarding card blocking, transaction monitoring, or chargeback procedures.
   • Notify the policy if you want to fill a complain.

4. Preserve evidence

   • Keep the suspicious message, phone number, URL, screenshots, and any payment details.
   • These elements can help incident responders and service providers limit the impact of the campaign.

Reporting Phishing URLs to CIRCL

CIRCL welcomes reports from users, victims, hotels, and service providers.

Phishing URLs can be submitted to Lookyloo at https://lookyloo.circl.lu/capture

When submitting a URL, please mark the capture as phishing. This helps CIRCL and partners analyse the infrastructure, identify related campaigns, and support takedown or mitigation actions to reduce the impact on victims.

Indicators of Compromise

Indicators may vary depending on the hotel, the communication channel, and the infrastructure used by the threat actor.

A MISP event https://misppriv.circl.lu/events/view/10a94632-a0a1-4062-a3a5-95fe321ae045 is available with all the indicators collected from the reported cases.

The threat actor appears to rotate phishing URLs frequently and also changes the phone numbers used to send WhatsApp messages, making static blocking and indicator-based detection more difficult.

Hotels and victims are encouraged to report phishing URLs and related artefacts to CIRCL for analysis.

Conclusion

This phishing campaign is notable because it uses legitimate booking-related information to increase credibility and pressure victims into making fraudulent payments.

Hotels using myLighthouse should urgently reset credentials, ensure MFA is enabled and enforced, review access rights, and communicate clearly with customers about legitimate payment methods.

Customers who receive suspicious booking-related messages should not click on links, should verify requests directly with the hotel, and should contact their financial provider immediately if they engaged with the phishing site or made a payment.

CIRCL continues to collect reports and encourages the submission of phishing URLs through Lookyloo to support analysis and mitigation.

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 1st June 2026

Successful exploitation allows unauthenticated remote code execution. Active exploitation has been confirmed in the wild, both worldwide and in Luxembourg.

CIRCL strongly recommends immediately initiating a full incident response procedure for all Ivanti EPMM instances, including compromise assessment and log review.

As EPMM is a mobile endpoint management solution, a compromise of the EPMM server can result in severe impact, including full control over managed devices, lateral movements and access to sensitive data.

Affected Version

Previous version under EoL might be also affected by the vulnerability.

Network Indicator

• Reviewing for post-exploit activity

Detection and Forensic

Ivanti published a detection script Exploitation Detection RPM package. We strongly recommend to do further detection and analysis beside the scripts provided by Ivanti.

References

• Security Advisory Ivanti Endpoint Manager Mobile (EPMM) (CVE-2026-1281 & CVE-2026-1340)
• Analysis Guidance Ivanti Endpoint Manager Mobile (EPMM) CVE-2026-1281 & CVE-2026-1340
• CVE-2026-1281
• CVE-2026-1340

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 9th February 2025

After gaining initial access, the malicious threat actor deployed malware designed to scan affected environments for sensitive credentials and exfiltrate these. The second version included a destructive payload capable of deleting the user’s home directory.

The threat actor specifically targeted GitHub Personal Access Tokens (PATs), API keys for major cloud service providers—including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure as well as credentials related to software distribution channels.

Detection

• Review all the npm packages installed by reviewing package-lock.json, yarn.lock and similar files. Don’t forget to search recursively.
• A list of compromised package is available at https://github.com/wiz-sec-public/wiz-research-iocs/blob/main/reports/shai-hulud-2-packages.csv.
• Be careful with cached version in directory which could contain malicious packages.
• Check for the hashes of the malware sample linked below.

Remediation

• Immediately rotate all developer credentials and API keys.
• Ensuring MFA is enabled on all developer having access to repositories and systems for software deployment.
• Review access logs and CI pipelines if they have been modified.

Malware Sample

• 62ee164b9b306250c1172583f138c9614139264f889fa99614903c12755468d0
• f099c5d9ec417d4445a0328ac0ada9cde79fc37410914103ae9c609cbc0ee068
• a3894003ad1d293ba96d77881ccd2071446dc3f65f434669b49b3da92421901a

Network Indicator

• http[:]//bun[.]sh/install[.]ps1

Known affected software in Luxembourg

We received notifications about affected users and GitHub repositories. To date, the impact has been minor, affecting only a limited number of organisations in Luxembourg. We are actively monitoring the situation.

References

• Datadog The Shai-Hulud 2.0 npm worm: analysis, and what you need to know
• StepSecurity Shai-Hulud: Self-Replicating Worm Compromises 500+ NPM Packages
• Unit42 “Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack (Updated November 26)
• CISA Widespread Supply Chain Compromise Impacting npm Ecosystem
• GitLab GitLab discovers widespread npm supply chain attack
• WIZ
• CIRCL Malicious Packages on vulnerability-lookup
• CSSF Supply-chain attack using NPM packages

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 28th November 2025

This TR applies to a wide range of F5 products, including BIG-IP iSeries and rSeries hardware, as well as BIG-IP (TMOS), Virtual Edition (VE), BIG-IP Next, and BIG-IQ software.

We strongly recommend reviewing all your deployed BIG-IP products and applying the recommendations from the vendor as mentionned in K000156572: Quarterly Security Notification (October 2025).

Known affected software in Luxembourg

A significant number of BIG-IP devices were discovered in Luxembourg, and notifications have been sent to the ISPs and available contact points.

Based on the information available from the disclosure, we have not found any compromised or abused systems. Many of the vulnerabilities are related to potential Denial-of-Service (DoS) attacks, which should also be monitored. We also recommend looking closely at your logs.

References

• F5 - K000156572: Quarterly Security Notification (October 2025)
• CIRCL - F5 - K000156572: Quarterly Security Notification (October 2025 - CVE Allocated)
• CIRCL - RULEZET.org - Threat Hunting Methodology: F5 Security Incident (K000154696)
• CISA - ED 26-01: Mitigate Vulnerabilities in F5 Devices

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.1 - TLP:CLEAR - Second version - 16th October 2025 - RULEZET bundle added
• Version 1.0 - TLP:CLEAR - First version - 15th October 2025

These vulnerabilities apply to on-premises SharePoint Servers only. SharePoint Online in Microsoft 365 is not impacted.

CIRCL advises initiating an incident response procedure, reviewing all logs, and especially scrutinizing any potential compromise to other internal infrastructure in addition to the Microsoft SharePoint Server.

Recommendations

• Review the Microsoft Customer guidance for SharePoint vulnerability CVE-2025-53770
• Assume the system has been compromised, because large‑scale exploitation occurred before the patch was released.
• Rotate the current key materials on your exposed Microsoft SharePoint Server.
• Trigger an incident response procedure, reviewing all logs, and especially scrutinizing any potential compromise to other internal infrastructure in addition to the Microsoft SharePoint Server.

Impact

It can result in the full compromise of the Microsoft SharePoint Server.

Exploitation

Exploitation has been confirmed and has been seen worldwide, including in Luxembourg.

Detection

Monitor and search logs for POSTs to /_layouts/15/ToolPane.aspx?DisplayMode=Edit which is the trigger for the known payload.

Review the Microsoft SharePoint Server for the presence of the spinstall0.aspx file.

A scanning approach (available as a bash script) and a set of indicators are detailed in an article from eye.security.

In addition, a set of indicators are available on the original article https://research.eye.security/sharepoint-under-siege/.

A MISP event with the indicators is also available with the following UUID: d9da16a2-8444-45cb-8bb4-d27abf23a261 (CIRCL) and 59ed4725-5f2a-4844-8dc4-e6926dbcb5ce (Microsoft) which includes detection rules for Microsoft Sentinel and Microsoft Defender XDR.

Affected Systems

• Microsoft - Microsoft SharePoint Enterprise Server 2016 - Version: N/A
• Microsoft - Microsoft SharePoint Server 2019 - Version: 16.0.0 < 16.0.10417.20037
• Microsoft - Microsoft SharePoint Server Subscription Edition - Version: 16.0.0 < 16.0.18526.20508

Credits

• Thanks to https://research.eye.security for the discovery.

References

• Original vulnerability - CVE-2025-49706
• CVE-2025-53770 (GCVE-0-2025-53770) - Deserialization of untrusted data in on-premises Microsoft SharePoint Server allows an unauthorized attacker to execute code over a network.
• SharePoint 0-day uncovered (CVE-2025-53770)
• Scanning - Nmap script to detect a Microsoft SharePoint instance version
• Disrupting active exploitation of on-premises SharePoint vulnerabilities

Timeline

• 2025-07-20 06:03 - Customer guidance for SharePoint vulnerability CVE-2025-53770 MSRC Blog Microsoft Security Response Center
• 2025-07-18 18:00 - Initial discover of the ASPX payload by https://research.eye.security.

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.3 - TLP:CLEAR - References updated
• Version 1.2 - TLP:CLEAR - Clarification for key materials and links fixed - 22nd July 2025
• Version 1.1 - TLP:CLEAR - Second version including updates and new scanning script - 21st July 2025
• Version 1.0 - TLP:CLEAR - First version - 20th July 2025

This report details ongoing phishing campaigns specifically targeting organisations utilizing Microsoft 365, with a primary focus on Office 365 tenants where Multi-Factor Authentication (MFA) is not enforced. Attackers leverage sophisticated social engineering tactics and convincing phishing pages to harvest user credentials. Successful compromise of accounts without MFA allows attackers immediate access, leading to potential data exfiltration, business email compromise (BEC), internal spear-phishing, and deployment of further malicious payloads. This report outlines the attack methodology, observed indicators, potential impact, and critical mitigation strategies, emphasizing the urgent need for MFA deployment.

Attack Vector and Methodology

The primary attack vector is phishing emails, often crafted to bypass standard email security filters. The methodology typically follows these stages:

1. Reconnaissance (Optional but Common): Attackers may gather information about target organisations, including employee names, roles, and M365 usage, often from public sources like LinkedIn or company websites or just MX lookup on the targeted domain.
2. Lure / Phishing Email:
   • Themes: Common lures include fake security alerts (e.g., “Unusual sign-in activity,” “Password expiry”), notifications about shared documents, voicemail notifications, storage quota warnings, or urgent requests from “IT support” or “management.”
   • Sender Spoofing: Attackers may spoof internal email addresses, trusted third-party services, or Microsoft itself.
   • Content: Emails often contain urgent calls to action, instructing the recipient to click a link to verify their account, view a document, or prevent account suspension.
3. Phishing Page:
   • The link in the phishing email redirects the victim to a fake Microsoft 365 login page.
   • These pages are often pixel-perfect replicas of the legitimate Microsoft login portal, making them difficult for untrained users to distinguish.
   • Domains used for phishing pages are often typosquatted versions of legitimate domains or hosted on compromised websites.
4. Credential Harvesting:
   • The victim enters their M365 username and password into the fake login page.
   • These credentials are then captured by the attacker.
5. Account Access & Exploitation (No MFA):
   • Since MFA is not enabled, the attacker can immediately use the harvested credentials to log into the victim’s M365 account.
   • Common post-compromise activities include:
     • Email Reconnaissance: Searching for sensitive information within emails and attachments.
     • Setting up Mail Forwarding/Redirection Rules: To silently exfiltrate incoming emails or monitor communications.
     • Business Email Compromise (BEC): Sending fraudulent emails from the compromised account (e.g., requesting wire transfers, changing payment details).
     • Internal Spear-Phishing: Using the compromised account to send phishing emails to other employees or trusted contacts, leveraging the inherent trust.
     • Data Exfiltration: Accessing and downloading files from OneDrive, SharePoint, and Teams.
     • Further Compromise: Planting malware or attempting lateral movement (less common in pure credential phishing but possible).

Observed Activity / Indicators of Compromise (IoCs)

Organisations should monitor for the following indicators:

Email-based IoCs:

• Emails with urgent subject lines or calls to action related to account security or document access.
• Sender addresses that are slight variations of legitimate Microsoft or internal domains (e.g., microsft.com, micosoftonline.com, company-support.com).
• Poor grammar or unusual phrasing in email content.
• Hyperlinks that, when hovered over, reveal URLs not associated with Microsoft or the organisation.
• Emails requesting direct credential entry on a linked page.

Login and Account Activity IoCs (within M365 Audit Logs):

• Logins from unusual or geographically improbable IP addresses or countries.
• Multiple failed login attempts from an IP followed by a successful login.
• Logins using legacy authentication protocols (if not explicitly blocked).
• Creation of unexpected mail forwarding rules or inbox rules (especially those that delete or move messages).
• Changes to account recovery information (e.g., phone number, alternate email).
• Unexpected sharing of files or folders from OneDrive or SharePoint.
• Mass deletion of emails or files.
• Sent items containing phishing emails or suspicious replies from the compromised account. We advise to closely monitor notification from partners receiving phishing emails from your domain name and existing Office365 accounts.

Network IoCs:

• DNS lookups to known phishing domains or newly registered domains.
• Outbound connections to suspicious IP addresses from user workstations after potential credential entry.

Impact

Successful exploitation of M365 accounts without MFA can lead to severe consequences:

• Data Breach: Unauthorized access to sensitive company data, customer information (PII), financial records, and intellectual property stored in emails, OneDrive, and SharePoint.
• Financial Loss: Through BEC attacks, invoice fraud, or unauthorized wire transfers.
• Reputational Damage: Loss of customer trust and damage to the organisation’s brand.
• Operational Disruption: Interruption of business processes due to account lockout, data deletion, or system compromise.
• Compliance Violations: Potential breaches of data protection regulations (e.g., GDPR, HIPAA) leading to fines and legal action.
• Further Compromise: The compromised M365 account can be used as a launchpad for further attacks against internal systems or external partners.

Mitigation / Recommendations

The most critical mitigation is the enforcement of Multi-Factor Authentication.

Immediate and Essential Actions:

• Enforce MFA:
  • Prioritize enabling and enforcing MFA for ALL M365 accounts, especially administrative accounts. Use strong MFA methods like authenticator apps (e.g., Microsoft Authenticator) or FIDO2 security keys. Avoid SMS-based MFA if possible due to susceptibility to SIM swapping.
  • Utilize Microsoft Entra ID (formerly Azure AD) Conditional Access policies to enforce MFA based on risk, location, or device compliance.
• User Training and Awareness:
  • Conduct regular phishing awareness training for all employees.
  • Train users to identify suspicious emails, verify sender addresses, and scrutinize URLs before clicking.
  • Establish a clear procedure for reporting suspected phishing emails.

Technical Controls and Best Practices:

• Disable Legacy Authentication: Protocols like POP3, IMAP, SMTP AUTH are often targeted as they may bypass MFA. Block legacy authentication protocols via Conditional Access policies or per-protocol settings.
• Review and Harden M365 Security Settings:
  • Regularly review M365 audit logs for suspicious activities.
  • Configure alerts for critical events (e.g., suspicious sign-ins, creation of mail forwarding rules).
  • Implement M365 Advanced Threat Protection (ATP) / Microsoft Defender for Office 365 for enhanced email filtering and link protection (Safe Links, Safe Attachments).
• Password Policies: Enforce strong, unique passwords for all accounts. Encourage the use of password managers.
• Email Security Gateways: Utilize robust email security solutions with anti-phishing capabilities.
• Implement DMARC, DKIM, and SPF: To help prevent email spoofing of your domain.
• Principle of Least Privilege: Ensure users and administrators only have the permissions necessary for their roles. Regularly review privileged accounts.
• Incident Response Plan: Have a well-defined incident response plan for handling compromised accounts and data breaches. This should include steps for isolating affected accounts, investigating the breach, and remediation.

Examples

Here we will present some anonymized samples. All the name and company details abused by the attackers are valid and the emails come from the real email addresses from your contacts. This is why this attacks are so extremely dangerous.

Examples: Emails with a Phishing Link

Subject: #L125673547: <Company Name>

Content:
<Phishing Link>
Sincères salutations, mat beschte Gréiss, Best regards,

Subject: Votre facture - Compte 30031798047374-3772733 Architect <Company Name> vom 06.03.25

Content:
<Phishing Link>
Cordialement,
<Name & Company Address>

Examples: Emails with a RMM Tool Link

Subject: MISE EN DEMEURE

Content:
Madame, Monsieur

Je me permets de vous écrire en ma qualité d'avocat représentant les intérêts de mon client, qui m'a mandaté pour défendre ses droits à l'encontre de votre société concernant des impayées.
Malgré plusieurs relances, la somme due pour les services rendus conformément au contrat n'a toujours pas été effectuée.

Par la présente, Nous vous prions de bien vouloir prendre connaissance de la mise en demeure ci-jointe et procéder au règlement intégral à la réception de ce courrier, à défaut de quoi nous serons contraints d'engager toutes les procédures judiciaires nécessaires à la défense des droits de mon client.

<Link: Download RMM Tool>

Cordialement.
Avocat à la Cour

Subject: ATTENTION - FACTURE IMPAYEE

Content:
Bonjour Monsieur, Madame,

Sauf erreur de notre part, après consultations de nos comptes, nous constatons que nous n'avons toujours pas reçu le paiement de la facture ci-jointe malgré nos relances.

<Link: Download RMM Tool>

Nous vous prions de bien vouloir effectuer le paiement dans les meilleurs délais.

Cordialement
<Name & Company Address>

Conclusion

Phishing attacks targeting Microsoft 365 tenants remain a persistent and evolving threat. Microsoft is still not enforcing by default the multi-factor authentication. Organisations that have not implemented Multi-Factor Authentication are at significantly higher risk of account compromise, leading to potentially devastating consequences. The immediate enforcement of MFA, coupled with robust security practices and ongoing user education, is paramount to defending against these attacks and safeguarding organisational assets. Ignoring this critical security layer is no longer an option in the current threat landscape.

8. References (Optional)

• Microsoft: Set up multifactor authentication for users
• Microsoft: How to investigate a compromised email account

Significance for Luxembourg

We observed more than 48 organisations with M365 account compromised in the past 7 days starting from 21st May 2025.

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 21st May 2025

Ce document décrit une attaque de type Malspam ciblant les entreprises via des e-mails frauduleux exploitant des outils de gestion et de surveillance à distance (Remote Monitoring & Management - RMM). Les attaquants trompent les destinataires en leur faisant cliquer sur un lien malveillant, déguisé en facture, qui installe un outil RMM sur leur système. Comme ces outils sont des applications légitimes, ils contournent les antivirus et permettent aux attaquants d’obtenir un accès distant complet.

Une fois l’accès établi, les attaquants renforcent leur contrôle en installant des outils RMM supplémentaires, en diffusant des e-mails malveillants et en modifiant les paramètres du système. Leur objectif principal est d’exploiter les stations de travail compromises – souvent celles des comptables ou responsables financiers – pour intercepter les codes PIN des cartes à puce et exécuter des transferts frauduleux, entraînant des pertes financières considérables.

Ce document propose une analyse détaillée du mode opératoire, des risques encourus et des mesures de protection recommandées pour se prémunir contre ces attaques.

Impact au Luxembourg

Ces dernières semaines, plusieurs organisations et particuliers nous ont signalé des demandes inhabituelles de leurs banques, telles que :

• « Voulez-vous vraiment effectuer 10 transactions pour un total de 30.000 EUR vers l’étranger ? »
• « Voulez-vous vraiment exécuter un virement de 1.000.000 EUR vers l’étranger ? »

Ces transactions sont réelles et ont été initiées par des attaquants, qui ont pris le contrôle du système bancaire de la victime en installant des outils de gestion et de surveillance à distance (RMM).
L’infection initiale se fait par des attaques de phishing et de spear-phishing, comme décrit ci-dessous.

Mode opératoire

1. L’attaquant envoie un e-mail frauduleux contenant une fausse facture en pièce jointe.
2. La pièce jointe est en réalité un lien qui télécharge un outil RMM sur l’ordinateur de la victime.
3. Si la victime clique sur le lien, l’outil RMM est installé sur son système.
4. L’antivirus ne détecte pas l’outil RMM comme malveillant, car il s’agit d’une application légitime.
5. L’attaquant obtient un accès distant total au système et peut capturer le code PIN des cartes à puce utilisées pour l’authentification bancaire.
6. L’attaquant exécute ensuite les actions suivantes :
   • Installation d’autres outils RMM pour assurer un accès persistant.
   • Envoi d’e-mails frauduleux aux contacts du carnet d’adresses de la victime.
   • Analyse approfondie du système compromis.
   • Modification des paramètres système pour atteindre ses objectifs.
   • Exécution de transactions financières frauduleuses.

Exemples récents

Objet : Recouvrement de facture impayée – Facture no FACT#062024 et FACT#072024 datée du 15/06/2024

Monsieur, Madame,

La présente communication concerne la facture no FACT#032024 et FACT#042024 au montant total de 32.857€ qui Recouvrement de facture impayée – Facture no FACT#062024 et FACT#072024 datée du 15/06/2024. Vous trouverez en annexe une copie de la facture pertinente.

Comme vous le savez, nous vous avons fourni le delai de recouvrement du dossier R1184521. Or, malgré le rappel effectué le 15/06/2024 à laquelle une lettre de relance a été envoyée, nous constatons que la facture demeure impayée, et ce, bien que nous ayons rempli toutes nos obligations.

Ainsi, nous vous prions de nous faire parvenir un chèque certifié au montant de 32.857€ à l’ordre de notre entreprise dans les 10 jours de la réception de la présente mise en demeure. Le chèque devra être transmis au notre adresse. À défaut, une demande en justice pourrait être déposée contre vous, sans autre avis ni délai.

Soyez avisé que nous considérerons de bonne foi tout mode alternatif de règlement proposé. Nous sommes d’avis qu’il est dans l’intérêt de tous que cette situation puisse être réglée à l’amiable. En ce sens, nous vous invitons à communiquer avec nous si vous désirez discuter de la présente mise en demeure.

Nous vous invitons à ignorer la présente lettre si le paiement a été effectué avant la date de réception de cette communication.

VEUILLEZ AGIR EN CONSÉQUENCE.                                 

Mesures de protection

Pour prévenir ces attaques de type Malspam (e-mails malveillants contenant des liens menant à des logiciels indésirables), une approche de sécurité multicouche est indispensable. Voici quelques mesures efficaces :

1. Sécurisation des e-mails

• Filtres avancés – Utilisation de passerelles sécurisées et de filtres anti-spam.
• Désactivation du téléchargement automatique des pièces jointes.
• Analyse et sandboxing des liens – Vérification des URL en temps réel.
• CIRCL propose un service en ligne gratuit pour analyser les pièces jointes des e-mails: pandora

2. Sensibilisation et formation des utilisateurs

• Campagnes de sensibilisation – Former les employés à ne pas cliquer sur des liens suspects.
• Survol des liens avant de cliquer pour vérifier leur destination.
• Simulations de phishing – Tests réguliers pour entraîner les employés à détecter les e-mails frauduleux.
• CIRCL propose un service en ligne gratuit pour l’analyse des URL: lookyloo

3. Protection des postes de travail et du réseau

• Filtrage des URL malveillantes – Blocage des domaines frauduleux via un proxy ou un outil de sécurité.
• Whitelisting des applications – Seules les applications autorisées peuvent s’exécuter.
• Solutions avancées de détection (EDR/NGAV) – Surveillance et blocage des comportements malveillants.

4. Authentification et protection contre l’usurpation d’identité

• Mise en place de DMARC, DKIM et SPF – Protection contre le spoofing d’e-mail.
• Surveillance des noms de domaine – Enregistrement de variantes pour prévenir l’usurpation.
• Configuration correcte du DNS - voir TR-92.

5. Gestion des accès et principe du moindre privilège

• Restriction des droits utilisateur – Pas de droits administrateurs sans nécessité.
• Authentification renforcée – Vérification des actions sensibles.
• Désactivation des macros et de l’exécution automatique des scripts.

6. Autres bonnes pratiques

• Mises à jour régulières des logiciels et du système d’exploitation.
• Désactivation des extensions de navigateur non essentielles.

7. Surveillance et réponse aux incidents

• Surveillance via SIEM – Détection des comportements anormaux.
• Plan de réponse aux incidents – Isolement rapide des appareils compromis.

Que faire en cas de compromission ?

• Déconnecter immédiatement l’ordinateur compromis du réseau (y compris le Wi-Fi !).
• Contacter votre équipe de réponse aux incidents ou CIRCL.
• Informer l’équipe IT pour une surveillance renforcée.
• Identifier d’autres systèmes potentiellement touchés.
• Avertir vos contacts de ne pas ouvrir de liens provenant de votre entreprise.
• Former le personnel à détecter ces attaques.
• Déclarer la violation à la CNPD dans les 72 heures si des données personnelles sont compromises.

Contre-mesures efficaces

Les solutions inefficaces proposées par certains prestataires IT

Un simple scan antivirus est insuffisant, car :

• Les outils RMM légitimes ne sont pas détectés comme malveillants.
• Des portes dérobées peuvent rester actives.
• L’attaquant peut rétablir son accès rapidement.

Les bonnes pratiques à adopter

• Déployer une solution EDR et mettre en place une liste blanche des outils RMM.
• Utilisez LuxTrust Mobile ou LuxTrust Scan au lieu d’une carte à puce pour vous authentifier (voir la documentation LuxTrust)
• Retirer la carte à puce du lecteur lorsqu’elle n’est pas utilisée.
• Mettre en place une validation à deux personnes pour les transactions bancaires.
• Activer des facteurs d’authentification supplémentaires.
• Choisir une banque qui effectue une vérification des bénéficiaires.

Récupération après compromission

• Contacter immédiatement la banque pour tenter de bloquer les transactions frauduleuses.
• Déposer une plainte auprès de la police.
• Contacter CIRCL pour une analyse approfondie.
• Réinstaller complètement le système compromis.
• Surveiller les accès à distance (RDP, VPN, etc.).
• Réinitialiser tous les mots de passe.
• Activer l’authentification à deux facteurs (2FA).
• Renforcer la formation des employés.

Conclusion

Un simple scan antivirus ne suffit pas. Pour une récupération complète, il est nécessaire de réinstaller totalement le système affecté.

IoC

Voir l’événement MISP UUID 5f7819de-5656-4063-a76a-a39253ee5154, disponible sur l’instance MISP pour le secteur privé.

Classification du document

TLP:CLEAR – Diffusion libre sous réserve du respect des droits d’auteur.

Révision

• Version 1.0 - TLP:CLEAR - Première version - 26 février 2025

Dieses Dokument beschreibt eine Malspam-Attacke, die sich gegen Unternehmen richtet, indem betrügerische E-Mails versendet werden, die Remote-Monitoring & Management (RMM)-Tools ausnutzen. Die Angreifer täuschen die Empfänger dazu, auf einen schädlichen Link zu klicken, der als Rechnung getarnt ist und ein RMM-Tool auf ihrem System installiert. Da diese Tools legitime Anwendungen sind, umgehen sie Antiviren-Erkennungen und ermöglichen den Angreifern vollständigen Fernzugriff.

Sobald der Zugriff erlangt ist, eskalieren die Angreifer ihre Kontrolle, indem sie zusätzliche RMM-Tools zur Persistenz installieren, Malware über E-Mails verbreiten und Systemeinstellungen ändern. Besonders kritisch ist, dass sie kompromittierte Arbeitsstationen – oft von Buchhaltern oder Finanzverantwortlichen – ausnutzen, um Smartcard-PINs abzufangen und betrügerische Überweisungen auszuführen, was zu erheblichen finanziellen Verlusten führt.

Dieses Dokument bietet eine detaillierte Analyse des Modus Operandi, der Risiken und der empfohlenen Schutzmaßnahmen zur Abwehr solcher Angriffe.

Bedeutung für Luxemburg

In den letzten Wochen haben wir mehrere Berichte von Organisationen und Einzelpersonen erhalten, die verdächtige Anfragen von ihren Banken gemeldet haben, wie zum Beispiel:

• „Möchten Sie wirklich 10 Transaktionen im Gesamtwert von ca. 30.000 EUR ins Ausland ausführen?“
• „Möchten Sie wirklich eine Transaktion über 1.000.000 EUR ins Ausland ausführen?“

Diese Transaktionen sind echt und wurden von Angreifern ausgeführt, die Zugriff auf das Bankensystem des Opfers erlangt haben, indem sie legitime Remote-Management- und Monitoring-Tools (RMM) installiert haben.
Die Erstinfektion erfolgt über Phishing- und Spear-Phishing-Angriffe, wie unten beschrieben.

Modus Operandi

1. Der Angreifer sendet eine betrügerische geschäftliche E-Mail mit einer gefälschten Rechnung als Anhang.
2. Der Anhang ist tatsächlich ein Link, der ein Remote-Monitoring- & Management-Tool (RMM) herunterlädt.
3. Wenn das Opfer den Link anklickt, wird das RMM-Tool auf seinem System installiert.
4. Antivirus-Software erkennt das RMM-Tool nicht als bösartig, da es sich um legitime Anwendungen handelt.
5. Das RMM-Tool gewährt dem Angreifer vollständigen Fernzugriff auf den Computer des Opfers, wodurch er die mehrstufige Smartcard-PIN erfassen kann.
6. Der Angreifer führt dann folgende Aktionen durch:
   • Installation weiterer legitimer RMM-Tools zur Aufrechterhaltung des Zugriffs.
   • Versenden infizierter E-Mails an Kontakte im Adressbuch des Opfers.
   • Analyse des kompromittierten Systems.
   • Modifikation von Systemeinstellungen zur Erreichung seiner Ziele.
   • Durchführung betrügerischer Finanztransaktionen.

Aktuelle Beispiele (Französisch)

Objet : Recouvrement de facture impayée – Facture no FACT#062024 et FACT#072024 datée du 15/06/2024

Monsieur, Madame,

La présente communication concerne la facture no FACT#032024 et FACT#042024 au montant total de 32.857€ qui Recouvrement de facture impayée – Facture no FACT#062024 et FACT#072024 datée du 15/06/2024. Vous trouverez en annexe une copie de la facture pertinente.

Comme vous le savez, nous vous avons fourni le delai de recouvrement du dossier R1184521. Or, malgré le rappel effectué le 15/06/2024 à laquelle une lettre de relance a été envoyée, nous constatons que la facture demeure impayée, et ce, bien que nous ayons rempli toutes nos obligations.

Ainsi, nous vous prions de nous faire parvenir un chèque certifié au montant de 32.857€ à l’ordre de notre entreprise dans les 10 jours de la réception de la présente mise en demeure. Le chèque devra être transmis au notre adresse. À défaut, une demande en justice pourrait être déposée contre vous, sans autre avis ni délai.

Soyez avisé que nous considérerons de bonne foi tout mode alternatif de règlement proposé. Nous sommes d’avis qu’il est dans l’intérêt de tous que cette situation puisse être réglée à l’amiable. En ce sens, nous vous invitons à communiquer avec nous si vous désirez discuter de la présente mise en demeure.

Nous vous invitons à ignorer la présente lettre si le paiement a été effectué avant la date de réception de cette communication.

VEUILLEZ AGIR EN CONSÉQUENCE.                                 

Schutzmaßnahmen

Die Verhinderung solcher Malspam-Angriffe (bösartige Spam-Mails mit Links zum Herunterladen von Malware) erfordert einen mehrschichtigen Sicherheitsansatz. Nachfolgend effektive Schutzmaßnahmen:

1. E-Mail-Sicherheitsmaßnahmen

• Erweiterte E-Mail-Filter – Nutzen Sie sichere E-Mail-Gateways und Spam-Filter, um Malspam-E-Mails zu blockieren.
• Automatisches Herunterladen von Anhängen deaktivieren – Verhindern Sie, dass E-Mail-Clients verlinkte Dateien automatisch herunterladen.
• Link-Sandboxing & URL-Analyse – Implementieren Sie Sicherheitslösungen, die Links in Echtzeit analysieren.
• CIRCL bietet einen kostenlosen Online-Dienst zur Analyse von E-Mail-Anhängen an: pandora

2. Benutzerbewusstsein & Schulung

• Sensibilisierungskampagnen – Schulen Sie Mitarbeiter darin, keine unbekannten Links zu klicken.
• Links vor dem Klicken überprüfen – Mitarbeiter sollten Links vor dem Klicken mit der Maus überfahren.
• Phishing-Simulationen – Regelmäßige Tests zur Erkennung verdächtiger E-Mails.
• CIRCL bietet einen kostenlosen Online-Dienst zur Untersuchung von URLs an: lookyloo

3. Endpunktschutz & Netzwerksicherheit

• URL-Blockierung & Web-Filter – Einsatz von Web-Proxies und Sicherheitstools zum Blockieren bösartiger Domains.
• Anwendungs-Whitelisting – Nur genehmigte Anwendungen dürfen ausgeführt werden.
• Erweiterter Endpunktschutz (EDR/NGAV) – Erkennung und Blockierung von Malware.

4. E-Mail-Authentifizierung & Schutz vor Spoofing

• DMARC, DKIM und SPF implementieren – Schutz gegen E-Mail-Spoofing.
• Markenschutz & Domain-Monitoring – Registrierung ähnlicher Domains zur Phishing-Prävention.
• Korrekte DNS-Konfiguration - siehe TR-92

5. Zugriffskontrolle & Prinzip der minimalen Rechte

• Einschränkung von Benutzerrechten – Keine Admin-Rechte ohne triftigen Grund.
• Zusätzliche Authentifizierung – Verifikation für externe Links oder Downloads.
• Deaktivierung von Makros & Skript-Autoausführung.

6. Allgemeine Sicherheitsmaßnahmen

• Regelmäßige Software- und OS-Updates.
• Unnötige Browser-Plugins deaktivieren.

7. Reaktion auf Vorfälle & Monitoring

• SIEM-Überwachung – Erkennung ungewöhnlicher Aktivitäten.
• Vorfallreaktionsplan – Infizierte Geräte schnell isolieren.

Maßnahmen bei einer Kompromittierung

• Sofortige Trennung des betroffenen PCs vom Netzwerk (auch WLAN!).
• Kontaktieren Sie Ihr Incident-Response-Team oder CIRCL.
• IT-Team zur verstärkten Überwachung informieren.
• Untersuchung möglicher weiterer betroffener Systeme.
• Warnung an Kontakte, keine Links aus E-Mails Ihres Unternehmens zu öffnen.
• Schulung der Mitarbeiter zur Wachsamkeit.
• Meldung an die CNPD innerhalb von 72 Stunden bei Datenpannen.

Effektive Gegenmaßnahmen

Unwirksame Lösungen durch IT-Dienstleister

Ein mehrfacher Virenscan reicht nicht aus, da:

• Legitime RMM-Tools nicht erkannt werden.
• Versteckte Hintertüren oft unentdeckt bleiben.
• Angreifer schnell wieder Zugriff erlangen.

Erfolgreiche Maßnahmen

• EDR-Lösung implementieren und RMM-Tools auf eine Allowlist setzen.
• Verwenden Sie LuxTrust Mobile oder LuxTrust Scan anstelle einer Smartcard zur Authentifizierung (siehe LuxTrust-Dokumentation)
• Smartcard aus dem Leser entfernen, wenn sie nicht benutzt wird.
• 4-Augen-Prinzip bei Überweisungen einführen.
• Zusätzliche Authentifizierungsfaktoren aktivieren.
• Eine Bank wählen, die Empfänger prüft.

Wiederherstellung nach einer Kompromittierung

• Sofort die Bank kontaktieren, um betrügerische Überweisungen zu stoppen.
• Strafanzeige bei der Polizei erstatten.
• CIRCL kontaktieren, falls IT-Sicherheitsberatung benötigt wird.
• Das kompromittierte System vollständig neu installieren.
• RDP-Zugriff überwachen.
• Alle Passwörter zurücksetzen.
• Zwei-Faktor-Authentifizierung (2FA) aktivieren.
• Mitarbeiter sensibilisieren.

Fazit

Ein einfacher Virenscan löst das Problem nicht. Zur vollständigen Bereinigung muss das betroffene System komplett neu installiert werden.

IoC

Siehe MISP-Ereignis UUID 5f7819de-5656-4063-a76a-a39253ee5154, verfügbar auf MISP für den privaten Sektor.

Dokumentklassifikation

TLP:CLEAR – Freie Verbreitung unter Beachtung des Urheberrechts.

Revision

• Version 1.0 - TLP:CLEAR - Erste Version - 26. Februar 2025

This document outlines a malspam attack targeting businesses through fraudulent emails that exploit Remote Monitoring & Management (RMM) tools. The attackers deceive recipients into clicking a malicious link disguised as an invoice, which installs an RMM tool on their system. Since these tools are legitimate applications, they evade antivirus detection, granting attackers full remote access.

Once access is gained, the attackers escalate their control by installing additional RMM tools for persistence, spreading malware via email, and modifying system settings. Critically, they exploit the compromised workstation—often belonging to accountants or financial officers—to capture smart card PINs and execute fraudulent wire transfers, resulting in significant financial losses.

This document provides a detailed breakdown of the modus operandi, risks, and recommended preventative measures to mitigate the threat posed by such attacks.

Significance for Luxembourg

Over the past few weeks, we have received multiple reports from organizations and individuals regarding suspicious inquiries from their banks, such as:

• “Do you really want to execute 10 transactions totaling approximately 30,000 EUR abroad?”
• “Do you really want to execute a transaction of 1,000,000 EUR abroad?”

These transactions are real and executed by attackers who have gained access to the victim’s banking system by installing legitimate Remote Monitoring and Management (RMM) tools.
The initial infection occurs through phishing and spear-phishing attacks, as detailed below.

Modus Operandi

1. The attacker sends a fraudulent business email containing a fake invoice as an attachment.
2. The attachment is actually a link that downloads a Remote Monitoring & Management (RMM) tool.
3. If the victim clicks the link, the RMM tool is installed on their system.
4. Antivirus software does not detect the RMM tool as malicious since these are legitimate applications.
5. The RMM tool grants the attacker full remote access to the victim’s computer, allowing them to capture the multiline smart card PIN.
6. The attacker then:
   • Installs multiple other legitimate RMM tools for persistence.
   • Sends infected emails to contacts in the victim’s address book.
   • Analyzes the compromised system.
   • Modifies system configurations to achieve their objectives.
   • Executes fraudulent financial transactions.

Recent Examples (French)

Objet : Recouvrement de facture impayée – Facture no FACT#062024 et FACT#072024 datée du 15/06/2024

Monsieur, Madame,

La présente communication concerne la facture no FACT#032024 et FACT#042024 au montant total de 32.857€ qui Recouvrement de facture impayée – Facture no FACT#062024 et FACT#072024 datée du 15/06/2024. Vous trouverez en annexe une copie de la facture pertinente.

Comme vous le savez, nous vous avons fourni le delai de recouvrement du dossier R1184521. Or, malgré le rappel effectué le 15/06/2024 à laquelle une lettre de relance a été envoyée, nous constatons que la facture demeure impayée, et ce, bien que nous ayons rempli toutes nos obligations.

Ainsi, nous vous prions de nous faire parvenir un chèque certifié au montant de 32.857€ à l’ordre de notre entreprise dans les 10 jours de la réception de la présente mise en demeure. Le chèque devra être transmis au notre adresse. À défaut, une demande en justice pourrait être déposée contre vous, sans autre avis ni délai.

Soyez avisé que nous considérerons de bonne foi tout mode alternatif de règlement proposé. Nous sommes d’avis qu’il est dans l’intérêt de tous que cette situation puisse être réglée à l’amiable. En ce sens, nous vous invitons à communiquer avec nous si vous désirez discuter de la présente mise en demeure.

Nous vous invitons à ignorer la présente lettre si le paiement a été effectué avant la date de réception de cette communication.

VEUILLEZ AGIR EN CONSÉQUENCE.                                 

Prevention Strategies

Preventing such malspam attacks (malicious spam containing hyperlinks to download malware) in a corporate environment requires a multi-layered security approach. Below are effective prevention strategies:

1. Email Security Measures

• Advanced Email Filtering – Use secure email gateways and spam filters to detect and block malspam emails before they reach inboxes.
• Disable Auto-Download of Attachments – Prevent email clients from automatically downloading linked files.
• Link Sandboxing & URL Analysis – Implement email security solutions that scan and analyze hyperlinks in real-time before users click them.
• CIRCL proposes a free online service for scanning email attachments: pandora

2. User Awareness & Training

• Security Awareness Campaigns – Educate employees on not clicking unknown or unexpected links, even from seemingly trusted sources.
• Hover Over Links Before Clicking – Teach employees to hover over hyperlinks to preview URLs before clicking.
• Phishing Simulation Training – Conduct regular phishing tests to train employees on recognizing suspicious links.
• CIRCL proposes a free online service for investigating urls: lookyloo

3. Endpoint Protection & Network Security

• URL Blocking & Web Filtering – Use web proxies and security tools to block known malicious domains.
• Application Whitelisting – Restrict the execution of unapproved applications to prevent malware from running.
• Endpoint Protection Software – Deploy next-gen antivirus (NGAV) and Endpoint Detection & Response (EDR) to identify and block malware from executing.

4. Email Authentication & Domain Protection

• Implement DMARC, DKIM, and SPF – These email authentication protocols help prevent email spoofing and domain impersonation.
• Brand Protection & Domain Monitoring – Monitor for domain spoofing attempts and register similar domains to prevent phishing.
• Correct DNS configuration - see TR-92

5. Access Control & Least Privilege Principle

• Restrict User Privileges – Users should not have admin rights unless absolutely necessary.
• Additional Authentication – Enforce authentication and verification for accessing external links or downloading software.
• Disable Macros & Auto-Execution of Scripts – Prevent execution of malicious scripts embedded in documents.

6. General: Secure Software & Patch Management

• Regular Software & OS Updates – Ensure all systems, browsers, and email clients are patched to prevent exploitation.
• Disable Unnecessary Browser Plugins – Reduce attack surface by removing unneeded browser extensions.

7. Incident Response & Monitoring

• SIEM (Security Information and Event Management) – Implement real-time monitoring to detect unusual email traffic patterns.
• Incident Response Plan – Have a response team and strategy ready if employees fall victim to malspam, including isolating infected devices and removing malware.

Actions during a Compromise

• Disconnect the affected PC from the network immediatly (Don’t forget WiFi).
• Talk to your local incident response team.
• If this doesn’t exist, do not hesitate to contact CIRCL to discuss the case and be prepared to receive an action plan.
• Inform your IT team to increase monitoring and the vigilance level.
• Investigate for potential other PC affected.
• Warn all you contacts, clients, customers and alike to not click on links in emails send by your organization.
• Teach all your staff about the issue and make them vigilant
• There are legal obligations in case of compromised infrastructure, e.g. to inform CNPD within 72 hours and any victims of a data breach. CIRCL will give you recommendations if necessary.

Mitigation Strategies

Ineffective Solutions from ICT Providers: What Does NOT Fix the Problem

Some service providers attempt to mitigate the issue by running multiple antivirus scans on the infected system. If no further malware is detected, they conclude that the system is clean.

However, this approach is ineffective because:

• Attackers install legitimate RMM tools that antivirus software does not flag.
• It is nearly impossible to detect all backdoors left by the attackers.
• If this approach is followed, attackers will regain access quickly and continue fraudulent activity.

Effective Mitigation Steps

• Implement an Endpoint Detection and Response (EDR) solution and enforce an allowlist for RMM tools used within the organization.
• Use LuxTrust Mobile or LuxTrust Scan instead of a smart card to authenticate (see luxtrust documentation).
• Remove the multiline smart card from the reader when not in use.
• Use 4-eyes principles for wire transfers.
• Enable additional authentication factors for multiline banking (e.g., phone-based authentication).
• Select a bank that actually checks wire transfer recipients.

Remediation After a Compromise

If an organization falls victim to this attack, the following actions must be taken:

• Contact immediately the bank of your organisation and the destination bank to block the fraudulent wire transfer.
• File a complaint with the local police or the “service de police judiciaire”.
• Contact CIRCL if you need technical support or advice related to IT security incidents.
• Reinstall the compromised system from scratch.
• Monitor Remote Desktop access. Attackers may exploit existing RDP access to escalate privileges or move laterally within a network. Evidence of such activity can often be found in Event Logs.
• In severe cases, all systems within the organization may need to be reinstalled.
• Revoke and reissue all banking certificates.
• Reset all passwords.
• Implement Two-Factor Authentication (2FA) wherever possible.
• Educate employees on cybersecurity best practices to prevent future incidents.

Conclusion

A simple virus scan does not resolve this issue. To fully mitigate the attack, the affected system must be completely reinstalled.

Organizations should closely monitor their ICT service providers to ensure proper remediation is performed.

IoC

See MISP event uuid 5f7819de-5656-4063-a76a-a39253ee5154, available on MISP for the private sector.

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 26th February 2025

Many organizations maintain a broad portfolio of domain names, acquired for branding, strategic planning, or defensive purposes. However, a significant portion of these domains often remains unused or lacks proper DNS configurations, leaving them vulnerable to exploitation. One particularly critical oversight is the absence of DNS SPF (Sender Policy Framework) TXT records, which are essential to controlling the sources from which emails for a domain can be legitimately sent. This document highlights the risks associated with improperly configured domains and provides actionable recommendations to mitigate such vulnerabilities.

Unused domains can refer to domains registered by an organization but not actively used. They can also include domains that are utilized for other services, such as HTTP/web services, without the need to send emails.

Problem Statement

Attackers frequently exploit domains without SPF records or other DNS-based email authentication mechanisms. These misconfigured or dormant domains can become avenues for phishing, spamming, or distributing malware under the guise of legitimate organizational communication. Recipients, seeing a recognizable domain, may trust the malicious email, leading to financial losses, reputational damage, and compromised security for both the recipient and the originating organization.

Recent Examples

In recent incidents, attackers have exploited unused or poorly configured domains belonging to various organizations. Common scenarios include:

1. Sending phishing emails that appear to originate from legitimate-looking email addresses tied to the organization.
2. Targeting partners, suppliers, or customers with malicious links or fraudulent invoices.
3. Compromising recipients’ systems by leveraging the trust associated with the recognizable domain name.

These examples demonstrate the importance of ensuring that all domains in an organization’s portfolio are properly secured and configured, regardless of their current usage status.

Understanding SPF Records

SPF records are a type of DNS TXT record that specifies which mail servers are authorized to send emails on behalf of a domain. For example, the following SPF record:

v=spf1 include:mail.example.com -all

• v=spf1: Indicates the SPF version being used.
• include:mail.example.com: Specifies the authorized mail server(s).
• -all: Indicates that all other servers are unauthorized.

If a domain lacks an SPF record, any mail server can claim to send emails on its behalf, making it susceptible to spoofing.

Recommendations

To safeguard your organization’s domain portfolio and reduce the risk of abuse, follow these best practices:

1. Inventory All Domains

   • Maintain an updated inventory of all domains owned by the organization, including inactive and defensive registrations.

2. Implement SPF Records

   • Configure SPF records for all domains, even those not actively in use.
   • Example for a domain with no legitimate email traffic:

     v=spf1 -all
     

     This record explicitly denies any mail servers from sending emails on behalf of the domain.

3. Extend Protections with DKIM and DMARC

   • Use DKIM (DomainKeys Identified Mail) to sign emails, ensuring their integrity.
   • Implement DMARC (Domain-based Message Authentication, Reporting, and Conformance) to provide instructions on handling authentication failures. Example DMARC policy:

     v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
     

4. Monitor DNS Configurations

   • Regularly audit DNS records for accuracy and completeness.
   • Utilize tools or managed services to detect and mitigate unauthorized use of domains.

5. Educate Stakeholders

   • Raise awareness among IT staff and decision-makers about the importance of securing all domains.
   • Include DNS management in your organization’s cybersecurity training and policies.

References

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. Available here
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. Available here
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). Available here

Conclusion

Unused or misconfigured domains represent a significant security risk for organizations. By proactively managing your domain portfolio and implementing robust email authentication mechanisms like SPF, DKIM, and DMARC, you can prevent attackers from exploiting your domains and protect your organization’s reputation and stakeholders. Addressing these issues is not just a technical necessity but a critical component of responsible cybersecurity management.

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.1 - TLP:CLEAR - Updated version to clarify the meaning of unused domains - 23rd January 2025
• Version 1.0 - TLP:CLEAR - First version - 21st January 2025

The risk is greatly reduced if access to the management web interface is restricted to trusted internal IP addresses, adhering to best practice deployment guidelines.

This issue impacts PAN-OS versions 10.2, 11.0, 11.1, and 11.2. Cloud NGFW and Prisma Access are not affected.

Impact

• CAPEC ID: CAPEC-115
• CAPEC Description: Authentication Bypass

Exploitation

Palo Alto Networks observed threat activity exploiting this vulnerability against exposed management web interfaces.

Problem Type

• CWE ID: CWE-306
• CWE Description: Missing Authentication for Critical Function

Affected Systems

Palo Alto Networks Products

• Cloud NGFW: Not Affected, All versions unaffected.
• PAN-OS:
  • Affected Versions:
  • 10.2.0 versions up to but not including 10.2.12-h2
  • 11.0.0 versions up to but not including 11.0.6-h1
  • 11.1.0 versions up to but not including 11.1.5-h1
  • 11.2.0 versions up to but not including 11.2.4-h1
  • Unaffected Versions: 10.1.0 and all versions that include the fix. (See solution section)
• Prisma Access: Not Affected, All versions unaffected.

Mitigation and Solutions

Workarounds

The primary mitigation is to restrict access to the management interface to only trusted internal IP addresses. Review these resources for more information:

• Palo Alto Networks LIVEcommunity article: https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431
• Palo Alto Networks official documentation: https://docs.paloaltonetworks.com/best-practices/10-1/administrative-access-best-practices/administrative-access-best-practices/deploy-administrative-access-best-practices

If you have a Threat Prevention subscription, you can block attacks using Threat IDs 95746, 95747, 95752, 95753, 95759, and 95763 (Applications and Threats content version 8915-9075 or later).

Solutions

The issue is fixed in:

• PAN-OS 10.2.12-h2
• PAN-OS 11.0.6-h1
• PAN-OS 11.1.5-h1
• PAN-OS 11.2.4-h1
• All later PAN-OS versions

Additional fixes are available for other commonly deployed maintenance releases, including:

• PAN-OS 11.2: 11.2.0-h1, 11.2.1-h1, 11.2.2-h2, 11.2.3-h3
• PAN-OS 11.1: 11.1.0-h4, 11.1.1-h2, 11.1.2-h15, 11.1.3-h11, 11.1.4-h7
• PAN-OS 11.0: 11.0.0-h4, 11.0.1-h5, 11.0.2-h5, 11.0.3-h13, 11.0.4-h6, 11.0.5-h2
• PAN-OS 10.2: 10.2.0-h4, 10.2.1-h3, 10.2.2-h6, 10.2.3-h14, 10.2.4-h32, 10.2.5-h9, 10.2.6-h6, 10.2.7-h18, 10.2.8-h15, 10.2.9-h16, 10.2.10-h9, 10.2.11-h6

CVSS Metrics

CVSS v4.0 (Highest Risk Scenario)

• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:N/SA:N/AU:N/R:U/V:C/RE:H/U:Red
• Base Score: 9.3
• Base Severity: CRITICAL
• Scenario: The risk is highest when you allow access to the management interface from external IP addresses on the internet.

CVSS v4.0 (Restricted Access Scenario)

• Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/AU:N/R:U/V:C/RE:H/U:Red
• Base Score: 5.9
• Base Severity: MEDIUM
• Scenario: If you configure restricted access to a jump box that is the only system allowed to access the management interface, you greatly reduce the risk of exploitation because attacks would require privileged access using only those IP addresses.

Credits

• Palo Alto Networks thanks our Deep Product Security Research Team for discovering this issue internally from threat activity.

References

• CVE-2024-0012 and CVE-2024-9474
• Palo Alto - Privilege Escalation (PE) Vulnerability in the Web Management Interface versus : Authentication Bypass in the Management Web Interface
• Palo Alto Networks Advisory
• WatchTowr Labs Analysis
• Unit 42 Analysis

Timeline

• 2024-11-18T14:20:00.000Z: CVE-2024-0012 assigned, vulnerability identified and fixed.
• 2024-11-15T22:00:00.000Z: FAQ about indicators of compromise answered.
• 2024-11-14T22:18:00.000Z: Severity of PAN-SA-2024-0015 bulletin raised due to observed threat activity.
• 2024-11-11T01:03:00.000Z: Added instructions to find devices with an internet-facing management interface discovered in scans.
• 2024-11-08T13:00:00.000Z: Initially published as PAN-SA-2024-0015.

Additional Information

Configuration Notes

The risk is highest if the management interface is configured to enable access from the internet or untrusted networks either:

• Directly or,
• Through a data plane interface that includes a management interface profile

The risk is greatly reduced by limiting access to the management interface to only trusted internal IP addresses.

Use the following steps to identify recently detected devices:

1. Visit the Assets section of Customer Support Portal at https://support.paloaltonetworks.com (Products → Assets → All Assets → Remediation Required).
2. Devices with an internet-facing management interface discovered in scans are tagged with PAN-SA-2024-0015. A last seen timestamp is shown in UTC. If no such devices are listed, scans did not find any devices with an internet-facing management interface within the last three days.

CISA ADP Information

• CISA Known Exploited Vulnerabilities (KEV):

  • Date Added: 2024-11-18
  • Reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2024-0012

• SSVC Metrics:

  • Timestamp: 2024-11-19T04:55:47.202753Z
  • ID: CVE-2024-0012
  • Options: Exploitation: active, Automatable: yes, Technical Impact: total
  • Role: CISA Coordinator
  • Version: 2.0.3

NVD Information

• NVD Description: An authentication bypass in Palo Alto Networks PAN-OS software enables an unauthenticated attacker with network access to the management web interface to gain PAN-OS administrator privileges to perform administrative actions, tamper with the configuration, or exploit other authenticated privilege escalation vulnerabilities like CVE-2024-9474. The risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses according to our recommended best practice deployment guidelines. This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, PAN-OS 11.1, and PAN-OS 11.2 software. Cloud NGFW and Prisma Access are not impacted by this vulnerability.

• NVD CVSS v3.1 Metrics:

  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
  • Base Score: 9.8
  • Base Severity: CRITICAL

Linked CSAF Documents

• CISA:
• ICSA-24-338-02 - Siemens RUGGEDCOM APE1808 devices
• NCSC-NL:
• ncsc-2024-0451 - Kwetsbaarheden verholpen in Palo Alto PAN-OS

GitHub Advisory

• GHSA-mw9x-2qwv-599p

Vulnerability Lookup Bundles

• Palo Alto - Privilege Escalation (PE) Vulnerability in the Web Management Interface versus : Authentication Bypass in the Management Web Interface
  • Description: This bundle highlights the relationship between CVE-2024-0012 and CVE-2024-9474. It notes they are often used in a chain to gain superuser access to PAN-OS systems
  • Related Vulnerabilities: CVE-2024-0012, CVE-2024-9474

Vulnerability Sightings

The vulnerability has been observed and discussed in various sources, including:

• Infosec.exchange user posts (multiple)
• Projectdiscovery Nuclei Template
• MISP Instance (MISP/3c19819c-1dac-4ef2-bfed-be5efa7e0123)
• Feedsin.space (https://feedsin.space/feed/CISAKevBot/items/2704493)
• Mastodon posts (multiple)

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 20th December 2024

Affected Products

• Vendor: Fortinet
• Product: FortiWLM
• Versions:
  • 8.6.0 through 8.6.5 (inclusive)
  • 8.5.0 through 8.5.4 (inclusive)

Vulnerability Class

• CWE-23: Relative Path Traversal
• CWE-94: Improper Control of Generation of Code (‘Code Injection’)

Impact

Successful exploitation of this vulnerability could lead to the execution of arbitrary code or commands on the affected system.

Technical Analysis

Attack Vector

• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged

CVSS Metrics

CNA CVSS Score

• CVSS v3.1 Base Score: 9.6
• CVSS v3.1 Base Severity: CRITICAL
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): None (N)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality Impact (C): High (H)
• Integrity Impact (I): High (H)
• Availability Impact (A): High (H)

CISA ADP CVSS Score

• CVSS v3.1 Base Score: 9.8
• CVSS v3.1 Base Severity: CRITICAL
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): None (N)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality Impact (C): High (H)
• Integrity Impact (I): High (H)
• Availability Impact (A): High (H)

CISA ADP SSVC

• SSVC Version: 2.0.3
• SSVC ID: CVE-2023-34990
• Timestamp: 2024-12-19T00:00:00+00:00
• Options:
  • Exploitation: None
  • Automatable: Yes
  • Technical Impact: Total
  • Role: CISA Coordinator

Mitigation

• Upgrade to FortiWLM version 8.6.6 or later.
• Upgrade to FortiWLM version 8.5.5 or later.

References

• Fortiguard Advisory
• NIST NVD CVE Details
• GitHub Security Advisory
• GSD Vulnerability ID

Additional Sightings

Mastodon

• https://infosec.exchange/users/mttaggart/statuses/113676180752563416
• https://infosec.exchange/users/cve/statuses/113673904010874634
• https://infosec.exchange/users/screaminggoat/statuses/113674791142313324
• https://infosec.exchange/users/screaminggoat/statuses/113674904259060282
• https://infosec.exchange/users/adulau/statuses/113674914309627637
• https://infosec.exchange/users/screaminggoat/statuses/113674927052267535
• https://infosec.exchange/users/screaminggoat/statuses/113675208676939403
• https://cyberplace.social/users/GossiTheDog/statuses/113674232166302816
• https://social.circl.lu/users/circl/statuses/113674370374104492
• https://infosec.exchange/users/edwardk/statuses/113679655471686245
• https://infosec.exchange/users/jbhall56/statuses/113679787983720927

Bluesky

• https://bsky.app/profile/nimblenerd.social/post/3ldnubko4bc2n
• https://bsky.app/profile/nimblenerd.social/post/3ldnuagu2lw2e
• https://bsky.app/profile/nimblenerd.social/post/3ldnuh5j6z72k
• https://bsky.app/profile/potato.software/post/3ldnuipavmq2c
• https://bsky.app/profile/hackingne.ws/post/3ldnwrxvui22v
• https://bsky.app/profile/nimblenerd.social/post/3ldogmyckhc2e
• https://bsky.app/profile/bolhasec.com/post/3ldnrh54g5i2b
• https://bsky.app/profile/nihonmatsu.bsky.social/post/3ldnrwzdzps2b
• https://bsky.app/profile/nidouille.bsky.social/post/3ldnywp2izk2f
• https://bsky.app/profile/jbhall56.bsky.social/post/3ldnyyoiymc2g

News

• https://thehackernews.com/2024/12/fortinet-warns-of-critical-fortiwlm.html
• https://www.darkreading.com/vulnerabilities-threats/fortinet-addresses-unpatched-critical-rce-vector

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 20th December 2024

This document outlines recommended practices for notifying Computer Security Incident Response Teams (CSIRT) and Computer Emergency Response Teams (CERT) when organizations plan to conduct red teaming, penetration testing, or other cybersecurity exercises. It highlights the importance of communication, coordination, and technical readiness to detect and differentiate simulated attacks from real threats.

Who

The guidelines are applicable to organizations (in Luxembourg or abroad) performing security exercises that involve simulated attacks on production or critical infrastructure, especially those that could trigger alerts in national or sectoral CSIRTs and CERTs.

Why

• Reducing Misinterpretation: Why notifying CSIRTs/CERTs is essential to avoid misinterpreting simulated attacks as real threats, potentially disrupting incident response processes.
• Enhancing Collaboration: The role of CSIRTs/CERTs in monitoring and threat intelligence and how advance notification strengthens collaboration but also improve existing detection mechanisms.

Notification

What to Notify

• Scope and objectives of the exercise. We don’t require a lot of details just a minimal description with the parties involved.
• Timeframe (start and end) and schedule of testing activities in UTC.
• Technical indicators and selectors to facilitate the detection by CIRCL.
• A contact person or organisation if we have any question or specific issues during a potential detection.

When to Notify

• We recommend to notify us at least one week in advance before the scheduled testing activities start.

Technical Recommendations

Indicators and Selectors

• Techniques for tagging or otherwise marking payloads and simulated malicious infrastructure to aid in detection.
• It is recommended to assign a randomly generated unique tag (such as a SHA256 hex value or even YARA rule for detecting the payload) to be embedded in malicious payloads, scripts, or even in the headers of infrastructure components.
• Classification such as exercise:generic="red-teaming" in the exercise taxonomy is recommended if a detection is shared after the timetrame period of the exercise. In case of detection in the wild, CIRCL will tag and share the information with reporting parties if it’s publicly detected.

References

• NIST SP 800-115 Technical Guide to Information Security Testing and Assessment

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 12th November 2024

Summary

In today’s digital landscape, protecting user data is essential for every organization. When public data leaks expose customer credentials, it is critical to respond promptly to mitigate risks. This document outlines why CIRCL sends notifications about such leaks and explains the procedure we expect organizations to follow. The goal is to safeguard both the organization’s infrastructure and its customers, while ensuring compliance with legal requirements and maintaining trust.

Motivation

We believe it is both necessary and beneficial for any organization to be informed about public data leaks involving their customers. The main objectives are:

• To protect the organization’s sensitive information and assets.
• To help safeguard the customer’s personal data and prevent further misuse.

Procedure

When CIRCL receives information about leaked credentials affecting user accounts for services in Luxembourg, we are committed to promptly informing the impacted service owners. Typically, we compile and share relevant information with the identified contact of the organization. This process relies heavily on the accuracy of WHOIS data, emphasizing the importance of keeping this information current.

We expect the organization to take the following steps:

• Reset the leaked passwords for the affected accounts.
• Inform their customers about the breach, advising them to reset passwords on other services where they may have used the same credentials.
• Investigate potential abuse of leaked accounts, for instance by analyzing login activity for unusual IP addresses or patterns.
• Notify the CNPD within 72 hours if there is evidence of unauthorized access to accounts, as required by GDPR. Such incidents are classified as data breaches and must be reported accordingly.
• Improve Authentication and Auditing if MFA (Multi-factor authentication) is available, we recommend to enable MFA for the users accessing the organization’s infrastructure.

Rationale

While we understand the operational and financial implications of handling security notifications, prioritizing data protection is essential for both the organization and its customers. As the CERT for Luxembourg’s private sector, operating under NIS regulations, our goal is to minimize the economic and reputational damage of security incidents while ensuring regulatory compliance.

Here are the key reasons why this approach is critical:

• Legal Obligations: Organizations have a legal duty to protect customer data. Unauthorized access must be reported to the CNPD within the 72-hour window required by GDPR. Failing to do so can lead to significant legal penalties.

• Customer Trust: Customers are more likely to trust notifications from their service provider rather than from a third-party CERT. Direct communication from the organization can reassure users and prompt them to take action, such as resetting their passwords. Additionally, the organization can automate mass password resets and provide tailored guidance, further reducing risks to its infrastructure and customers.

• Direct Contact Limitations: In many cases, the leaks lack customers’ email addresses and contain only user names, limiting our ability to notify users directly. Organizations, however, have this access and can communicate with their customers more efficiently and effectively.

• Proactive Security: Organizations should take immediate actions such as resetting passwords, notifying users, and conducting forensic investigations into potential breaches. Early and decisive action helps identify compromised accounts and limits further exposure, improving overall security posture. Incorporating these steps into regular risk assessments and technical controls is a proactive way to ensure readiness for potential incidents.

In conclusion, we believe that involving organizations in the communication process with their customers is the most effective strategy. This ensures compliance with legal obligations, maintains customer trust, and allows for a more comprehensive investigation of potential risks to the organization’s infrastructure.

References

• TR-46 - Information Leaks Affecting Luxembourg and Recommendations

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 29th August 2024

At the time of writing, most people have probably heard about the massive Windows outage caused by a faulty kernel driver in Falcon Sensor, a CrowdStrike software. On Friday, July 19, 2024, a software configuration update designed to target newly observed malicious artifacts used in cyberattacks prevented several million Windows machines to boot. How can a configuration file crash an OS? Because the real issue is not the configuration file itself, but the kernel driver using it. Let’s take a quick, non-technical tour of the potential reasons behind this situation, how it is addressed in the Linux kernel, and what you as users or customers can do to avoid such issues.

Developing Kernel Drivers is Hard

Kernel drivers allow code to be executed at the kernel level without modifying the kernel itself. This method is used by several software developers for the purposes of low level interactions, such as connecting to specific hardware, firewalling, and security monitoring. Bugs in these drivers are often critical, as they may be exploited by attackers or lead to a denial of service of the operating system.

Creating flawless code is a significant challenge for any developer. Most drivers are still developed in C or C++, which are powerful but complex and not inherently memory-safe languages. Moreover, achieving full code coverage through thorough testing of kernel drivers can be difficult due to the complexity of tracing a running kernel. These challenges, along with other factors such as dealing with undocumented kernel structures, closed-source kernels, and legacy code, can unfortunately lead to bugs and security vulnerabilities.

While we respect third-party companies, some may have less rigorous code review and development processes compared to OS kernel developers. This is a common issue in the software industry, where the focus may sometimes be on rapid feature development rather than code quality or stability. Consequently, as long as third-party companies continue to rely on kernel drivers, the risk of kernel panic (A kernel panic is a safety measure in an operating system, triggered by a critical error from which it cannot safely recover, causing the system to halt or restart) is likely to be higher compared to the risk from the OS kernel itself. Robust testing and advanced development practices are essential to mitigate these risks, but completely eliminating such errors remains a challenging task.

Can This Happen to Linux?

Kernel panics can occur on any operating system. However, the Linux kernel has been moving away from relying on third party kernel drivers. How is this being achieved? The answer is eBPF (Extended Berkeley Packet Filter). This technology enables code to run within the Linux kernel without the need to modify kernel source code or load kernel modules. A full explanation of how eBPF works is beyond the scope of this post; if you’re interested in learning more, please refer to the references section.

The power of eBPF lies in the fact that the code executed is not machine code but bytecode, which is interpreted by a virtual machine running in the kernel. Before execution, the bytecode is subjected to a code verifier that checks for any potential programming mistakes that could impact kernel functionality. Since every eBPF program has a maximum number of instructions it can execute (no endless loops are possible), the verifier can check every single instruction. If the verifier detects issues, it will reject the bytecode, preventing it from being loaded into the kernel. This mechanism aims to ensure that faulty code never reaches the kernel, so the only component that may fail is your userland application trying to load eBPF code—a clever way to avoid kernel panics, don’t you think?

Of course, no software is entirely free from bugs, and eBPF sub-system is no exception. While it is true that bugs can occur, the current design and verification process make the likelihood of eBPF bytecode causing a kernel panic extremely low.

Why Not eBPF on Windows?

Microsoft is currently working on bringing eBPF to Windows, and you can track their progress in the ebpf-for-windows repository. However, it’s important to note that it is still far from offering the same functionality as eBPF on Linux. This limitation restricts its use to specific networking tasks, leaving out critical areas such as performance monitoring and security tracing. For security vendors, these capabilities are essential for building robust and feature-rich products. As a result, they are likely to continue using traditional kernel drivers until eBPF for Windows meets all their requirements.

What Do We Do at CIRCL?

At CIRCL, we are strong advocates of open source. Consequently, we are investing time and resources to provide an open-source alternative to monitoring products for Linux. Introducing Kunai, a security monitoring tool for Linux written in Rust and powered by eBPF.

Inspired by Sysmon for Windows, we developed this project to offer a similar experience for Linux users. Like its Windows counterpart, Kunai monitors various system events, including binary and script execution, shared objects being loaded, network connections, and many other events that can be used to build robust threat detection and hunting scenarios. It also tracks security events generated by any Linux container technology, allowing users to monitor activities within their containers. Additionally, it features a rule engine for creating powerful detection and log filtering primitives. Furthermore, it can be integrated with any Threat Intelligence Provider, enabling real-time, IoC (Indicators of Compromise) based scanning .

Although Kunai is primarily designed for threat detection and hunting, it can also be a valuable ally for forensic analysis on Linux systems. Its logs provide detailed insights into the full activity of a given process, which is crucial for understanding what happened on a system.

If you have any security monitoring needs for your Linux hosts, consider giving Kunai a try. Don’t hesitate to open issues on GitHub or reach out to us if you encounter problems or want to contribute to its improvement.

What You Can Do as a Customer?

As a customer, you have the power to choose the best solutions and should thoroughly understand and review the technologies you use. Failing to do so can lead to vulnerabilities (including potential outages) in your infrastructure, making you partly responsible for any issues that arise. It is essential to have a robust technology and product evaluation process. If you find a vendor or technology that meets most of your requirements but falls short in some areas, request a roadmap to address these gaps and ensure your needs are fully met. As a general rule, running third-party kernel drivers should be avoided when viable alternatives are available.

If any product requires kernel drivers, a good evaluation metric is to check whether these drivers are implemented in a memory-safe language such as safe Rust. In addition to its memory safety capabilities, safe Rust enforces a number of good programming practices by design and provides strong guarantees about the code. This ultimately improves the overall quality of critical code running inside the kernel. Even though Rust is very attractive for kernel level applications, it will likely be necessary to use unsafe Rust (similar to C/C++), but its use should be minimized to the strictest extent possible. It is worth noting that while kernel code implemented in Rust will not prevent kernel panics, it will provide most of the Rust guarantees and inherently reduce the risk.

Conclusions

Kernel panics have existed for ages and will continue to occur. However, operating system developers take this issue very seriously. While alternatives to relying on traditional C or C++ written kernel modules exist, such as using a safer programming language or another technology like eBPF, some software providers may prefer the conventional approach, likely because developing something from scratch using a completely different method can be too costly. In such cases, remember that as a user or customer, it is your responsibility to push for improvements or opt out of such practices if you do not agree with them.

References

• CIRCL Technical Report
• CrowdStrike Windows Outage
• CrowdStrike Linux Kernel Crash

eBPF

• What is eBPF
• Wikipedia: eBPF
• BPF kernel documentation
• eBPF verifier

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 22nd July 2024

Vulnerable Version And Products

• Latest version of CrowdStrike Falcon Agent on Windows

Fixes and workaround

• Boot Windows into Safe Mode or the Windows Recovery Environment
• Navigate to the C:\Windows\System32\drivers\CrowdStrike directory
• Locate the file matching C-00000291*.sys, and delete it.
• Boot the host normally.

We received reports that only the Windows Recovery Environment mode works, as the driver still seems to be loaded in safe mode.

Detection and investigative assessment (before the latest patch/release from CrowdStrike)

• Windows system stuck in a boot loop. There is a blue screen where the mention is “What failed: csagent.sys”.

The “buggy” driver has the following hashes:

• MD5 - 1618cd13c5263720ec958c3b24b9d1c8

• SHA-1 - cb8a27c7347d19bc0b23093a99816dfd8240dbc5

• SHA-256 - ad492bc8b884f9c9a5ce0c96087e722a2732cdb31612e092cdbf4a9555b44362

• SSDEEP - 384:bIy44Wo45c59r/qQqu1QhSn88MyU64guxkP5O84VLv8xB0+Cn:9495c59rSQBG8CJxfexBl0

• TLSH - T1EF03B83AFA108F99D071C0F7D9370B9EB394AD9C2B8257A37A5DBB3D48B55180DC046A

• Virustotal reference

• MISP event with the “buggy” file available in the MISP OSINT feed

CrowdStrike-themed malware/phishing campaigns

There are ongoing CrowdStrike-themed malware/phishing campaigns such as this malware sample using fake updates..

Known affected software in Luxembourg

• Impact currently unknown in Luxembourg but impact seen at least in US, Australia and India.

References

• CrowdStrike Falcon Sensor Windows Crashes
• CrowdStrike Technical Details on Today’s Outage
• CIRCL Learning from the Recent Windows/Falcon Sensor Outage - Causes and Potential Improvement Strategies in Linux with Open Source

Classification of this document

TLP:CLEAR information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.0 - TLP:CLEAR - First version - 19th July 2024
• Version 1.1 - TLP:CLEAR - Recovery versus safe mode from users + clarification of the BSOD - 19th July 2024
• Version 1.2 - TLP:CLEAR - IOC of the buggy driver added + MISP reference - 19th July 2024
• Version 1.3 - TLP:CLEAR - Updated TR after the CrowdStrike updates - 20th July 2024
• Version 1.4 - TLP:CLEAR - CrowdStrike-themed malware/phishing campaigns - 21st July 2024
• Version 1.5 - TLP:CLEAR - Learning from the recent outage reference added - 23rd July 2024