On Friday morning 23 October, Vanden Broele noticed suspicious activity on the servers behind eSignFlow, the digital signature module that more than 120 Belgian cities and municipalities use to have documents signed. By midday the application was offline. By Saturday evening the hole was closed and eSignFlow was back online, with some restrictions (VRT NWS).
According to CEO Bram Van Impe, what leaked was mostly metadata: a person's name linked to a signed document, and that document's title. No signatures were placed in anyone else's name. On paper, a modest leak.
Then Peer and Genk asked their residents to be extra careful with unexpected emails, texts and phone calls asking for personal data, payment details, passwords or codes. Anyone receiving a payment request for a GAS 5 fine should check that the bank details match those of their own municipality. Hasselt and Leopoldsburg issued similar warnings (ICT Magazine).
A real name next to a real document title is exactly what makes a fake payment request believable. The intrusion was over by Saturday. The phishing it feeds has barely started.
Nobody outside knows how they got in
How the attacker got into eSignFlow hasn't been made public. ICT Magazine writes about "misused access", and Vanden Broele says it closed that access, replaced all access keys and integrations, blocked the attacker's known IP addresses, and reported the incident to the Centre for Cybersecurity Belgium, the Data Protection Authority and the police. I won't guess at the vector. It also matters less than you'd think.
The way in keeps moving. Mandiant's M-Trends 2026 puts exploits first, at 32% of the intrusions where a vector could be identified, and voice phishing second, at 11%. Email phishing "now represents a fraction of its former share" (Help Net Security on M-Trends 2026). Attackers didn't give up on people. They picked up the phone, because a live conversation is much harder for an automated control to stop than an email.
You can make it harder
Keep doing the prevention work. MFA, patching, awareness training, mail filtering and supplier reviews all raise the cost of getting in, and I'm not arguing against any of it.
But look at how one well-documented group opens. According to the joint CISA and FBI advisory on Scattered Spider, the actor calls the help desk posing as an employee and asks for a password reset or for MFA to be moved to a new phone. Other times it's a SIM swap, or a stream of push prompts until someone taps "approve" to make them stop (CISA AA23-320A). A well-trained help desk makes that harder. It can't make it impossible, because the help desk exists to help people who've lost access.
The eSignFlow case adds a second problem. Residents and employees can now be phished with data taken from a supplier their organization doesn't control. No amount of training at the town hall changes what already left a third party's server.
So the honest planning assumption is that someone will get in. The question is what happens in the minutes after.
The minutes after the door opens
They're short. CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time, from the first compromised host to the next system, at 29 minutes in 2025. The fastest it observed was 27 seconds, and in one intrusion data started leaving within four minutes of initial access (CrowdStrike).
Mandiant sees the same compression. When one group breaks in and hands access to another, the median time between the two fell from more than eight hours in 2022 to 22 seconds in 2025. Global median dwell time, meanwhile, rose to 14 days (Help Net Security on M-Trends 2026).
The attacker moves in minutes, and on average the defender finds out two weeks later. A security operations center (SOC) can't close that gap by reading tickets faster. The detections have to fire on the first attempt, at the step where the attacker actually is.
Threat actors run playbooks
Attack groups are not random. They specialize, and they repeat what works.
MITRE ATT&CK describes Scattered Spider as a native English-speaking cybercriminal group active since at least 2022. It started with CRM providers, outsourcing firms, telecoms and tech companies, then moved into gaming, hospitality, retail, managed service providers, manufacturing and finance. Its goal is admin access in identity and cloud platforms such as Okta, AWS and Office 365 (MITRE ATT&CK G1015).
What it does after the help desk call is documented step by step in the CISA advisory. It registers its own MFA device (T1556.006) and installs a legitimate remote access tool (T1219). It searches SharePoint and internal documentation for credentials, VPN instructions and backup details (T1213.002, T1552.001), and steals browser session data (T1539). It moves into cloud instances, some of which it creates itself (T1021.007, T1578.002). It stages data, sends it to MEGA or Amazon S3 (T1567.002), and in the latest update to the advisory encrypts VMware ESXi servers with DragonForce ransomware (T1486).
Almost none of that needs malware a signature would catch. CrowdStrike reported that 79% of its detections in 2024 were malware-free: hands-on-keyboard work with valid accounts and legitimate tools (CrowdStrike).
Every step still leaves a trace. A new MFA device registered minutes after a help desk password reset is a detection. A remote management tool appearing on a laptop that never had one is another. So is a user account suddenly reading half of SharePoint, or a large upload to a consumer cloud storage service. If one of them fires and reaches an analyst in time, the chain breaks long before the ransomware.
Test the whole chain
Most organizations test pieces. A phishing simulation in spring, a perimeter pentest once a year, a review of detection rules when someone has time. Each one is useful. None of them tells you whether your SOC would see Scattered Spider, or the group that targets your sector, working through its whole chain on a Tuesday afternoon.
That's the gap we built C7ATTACK for. We follow what threat actor groups are actually doing and rebuild their chains as attack scenarios, more than 1,000 of them by our own count. They run the group's procedures in your environment, step by step, without the live malware. For each step you see whether a detection fired, whether it reached someone, and where the chain should have been stopped. You fix what was missed and run the same chain again to prove the fix holds.
C7ATTACK can't tell you how eSignFlow was breached, and it won't stop a convincing phishing call. It shows which steps of a known chain your SOC would catch, which is the part you can still change.
Where to start
Pick the two or three groups that actually go after organizations like yours. Their chains are public in MITRE ATT&CK and in advisories like CISA's. For each step, write down which detection should fire, where the alert lands, and who would act on it within the first 30 minutes. The steps where nobody can answer are your coverage gaps, and that list is more useful than another month of debating how they'll get in.
If you want to run that exercise with real threat-actor chains on your own environment, book a demo.
Kenneth Hansen is Marketing Director at Crimson7, which builds C7PLATFORM for threat-led adversary simulation (C7ATTACK) and threat hunting (C7DEFEND).
