Day Zero. Nobody Knows Yet.
It started with an email.
Not a suspicious one. Not a badly written phishing attempt with broken English and a mismatched domain. A well-researched, properly formatted message that appeared to come from a logistics vendor your procurement team had worked with for three years. The sender’s name was correct. The email thread referenced a real contract. The attached invoice was a PDF that looked exactly like every other invoice in the accounts payable queue.
One employee clicked. One credential prompt appeared. One password was entered.
The attacker had what they came for.
No malware was dropped. No exploit fired. No alarm triggered. The endpoint ran its usual processes. The SIEM ingested its usual logs. The dashboard showed its usual green.
Day zero of a 127-day intrusion looked exactly like a normal Tuesday.
What follows is not a hypothetical. It is a composite of the attack patterns documented in post-incident reports, forensic investigations, and threat actor profiles from organizations including Mandiant, CrowdStrike, and Microsoft — assembled into a single timeline that reflects how the majority of significant enterprise breaches actually unfold in 2025.
Read it as if it’s happening in your environment.
Because statistically, a version of it probably is.
Day 1–3: Foothold and First Look Around
What the Attacker Is Doing
The stolen credential is tested quietly. Not against your primary login portal — where failed attempts might trigger lockout policies — but against secondary services. VPN. Webmail. Remote access tools. Development portals. The attacker is mapping which services accept the credential before committing to any of them.
One works: a VPN gateway that doesn’t enforce MFA for contractor accounts. The credential belongs to a third-party vendor who had legitimate access during a project that concluded six months ago. The account was never deprovisioned.
Initial access is established at 11:34pm on a Sunday — when analyst attention is lowest and alert queues will be reviewed by a fresh team in the morning.
The first action is pure observation. Using built-in Windows tools — net user, net group, nltest — the attacker queries the Active Directory environment. How many domains? How many privileged groups? Which accounts have domain admin? Where are the file servers? What does the network topology look like?
Nothing is executed that isn’t already on the system. Nothing touches disk that a legitimate admin wouldn’t touch. The queries are indistinguishable from routine IT administrative activity.
What Your Security Stack Is Seeing
The VPN authentication event is logged. It’s a valid credential authenticating from an IP address that hasn’t been used before — but the IP is a commercial VPN service, which generates hundreds of similar events daily across your user population. The authentication succeeds. The event is processed.
The AD queries are logged in Windows Event Logs. They’re the same event IDs your helpdesk generates every morning. No rule fires on valid AD queries from a connected session.
The alert queue for Sunday night is clean. Monday morning triage finds nothing of note.
Day 4–14: Reconnaissance at Scale
What the Attacker Is Doing
The environment is now being mapped systematically — but slowly, carefully, and using only legitimate tools.
BloodHound — a legitimate AD auditing tool that is equally valuable for attack path planning — is run entirely in memory using a PowerShell implementation. It queries LDAP for every user, group, computer, and trust relationship in the domain. Within four minutes, it produces a complete attack path map: the shortest route from the compromised contractor account to domain administrator, identified and ranked by exploitability.
The map shows three viable paths. The most direct: a service account with domain admin privileges that was created during a server migration two years ago and never cleaned up. Its password hasn’t been rotated in 847 days. If it can be reached and its credentials extracted, domain admin is one step away.
File shares are enumerated. The attacker is looking for specific content: configuration files that contain credentials, spreadsheets with password lists, documentation that reveals internal architecture, and any data that indicates the organization’s most valuable assets and where they’re stored.
A finance team shared drive is found to be accessible from the compromised session. It contains payroll data, board presentation materials, and a spreadsheet titled “acquisition_targets_confidential_2025.xlsx.”
The attacker notes the location. They don’t touch it yet.
What Your Security Stack Is Seeing
BloodHound’s LDAP queries generate event IDs that appear regularly in every Active Directory environment. The query volume is elevated slightly above the baseline for that session — but the session belongs to a “contractor account” that has been dormant for six months, so there is no established baseline for it.
The file share access is logged. The contractor account has legitimate read permissions to the finance drive — a permission that was granted during the original project engagement and never revoked. The access looks authorized because it is authorized.
No rules fire. The dashboard is clean. It has been eleven days.
Day 15–28: Credential Harvesting
What the Attacker Is Doing
The target is the service account with domain admin privileges identified during reconnaissance. To reach it, the attacker needs to move to a system where that account has recently authenticated — because LSASS memory retains credential material for accounts that have logged in.
A workstation is identified that the service account touches as part of its automated operations. The attacker moves to it laterally using the compromised contractor credential and SMB — the same protocol your file sharing runs on. The connection looks like a file access event.
On the workstation, comsvcs.dll — a legitimate Windows DLL present on every system — is invoked via Task Manager to dump LSASS memory to disk. This is a native Windows operation. No third-party tool touches the system.
The dump file is read. The service account’s NTLM hash is extracted.
The hash is passed directly — no cracking required — to authenticate to the domain controller. Pass-the-hash, using a legitimate protocol (SMB), with a legitimate account’s credential material, to a system the account is authorized to access.
Domain administrator access is achieved on day nineteen.
Additionally, the attacker uses Kerberoasting — requesting a Kerberos service ticket for a second high-privilege service account and extracting it for offline cracking. The ticket is encrypted with a password set four years ago. It cracks in six hours on commodity GPU hardware. A second set of domain admin credentials is now in the attacker’s possession.
Two paths to domain admin. One known. One as backup.
What Your Security Stack Is Seeing
The lateral SMB connection is logged. The source is the contractor’s session. The destination is a workstation the account is technically authorized to access. No rule fires on authorized SMB connections.
The LSASS dump via comsvcs.dll generates a Process Access event (Event ID 10 in Sysmon, if deployed). It's a medium-confidence indicator — comsvcs.dll has legitimate uses. The event would require correlation with the prior lateral movement and the subsequent authentication anomaly to be meaningful. Viewed in isolation, it's a low-priority alert. It's triaged as inconclusive and closed.
The Kerberoasting service ticket request is logged in the domain controller’s Kerberos events. Kerberoasting has a known signature — service ticket requests for accounts with Service Principal Names, from accounts that don’t normally request them. If a specific detection rule for this pattern exists and is tuned to the current environment, it fires. In many environments, it doesn’t.
The dashboard shows two closed low-confidence alerts and nothing else. It has been nineteen days.
Day 29–60: Silent Expansion
What the Attacker Is Doing
With domain admin credentials, the environment is now fully accessible. But the attacker doesn’t rush. Speed creates noise. The objective is to expand quietly, establish persistence that will survive discovery, and position for the final objective — without triggering the kind of anomalous activity that forces early detection.
Active Directory is modified. A new user account is created — svc_monitoring_backup — with a name designed to blend into the service account naming convention the organization uses. It's added to the Domain Admins group. The creation event is timestamped at 2:17am on a Saturday, when change activity is lowest and Monday morning triage will be the first review.
Persistence is established in four locations:
- A scheduled task on two domain controllers, configured to re-establish the backdoor account if it’s ever disabled
- A WMI subscription that executes a PowerShell beacon on system startup across three critical servers
- A Golden Ticket — a forged Kerberos ticket signed with the domain’s krbtgt hash, valid for ten years, independent of any account password changes
- A web shell installed on an internet-facing application server that hadn’t appeared in the last vulnerability scan because it was provisioned outside the standard deployment process
The attacker now has four independent paths back into the environment. Discovering and closing one doesn’t close the others. Complete eviction requires finding all four simultaneously — which requires knowing all four exist.
Data mapping continues. The finance drive identified in week two is accessed systematically. Not all at once — file access events at volumes that match the normal usage pattern for that share, spread across multiple sessions, generating nothing that crosses a threshold.
The acquisition targets spreadsheet is read. The payroll data is catalogued. M&A planning documents are identified and staged in the C:\Windows\Temp directory of a rarely-monitored server — a common staging location that blends into the noise of legitimate Windows operations.
What Your Security Stack Is Seeing
The new service account svc_monitoring_backup generates a user creation event in AD. Creation events for service accounts are common and frequently generated by legitimate automation. The naming convention matches your existing patterns. The event is logged.
The scheduled tasks are created using schtasks.exe — a native Windows binary. Task creation events are high-volume in most enterprise environments. The specific tasks created by the attacker are not distinguishable from legitimate tasks without reviewing their content.
The WMI subscriptions are persistent. WMI subscription creation is logged by Sysmon if deployed with the appropriate configuration. Most environments either don’t have Sysmon deployed or don’t have WMI persistence detection enabled.
The Golden Ticket exists only in the attacker’s toolkit. It leaves no trace in your environment until it’s used.
The web shell on the unmonitored application server generates no alerts because the server generates no logs to your SIEM.
Day 60. The dashboard is clean. Four persistence mechanisms are operational. Domain admin credentials are in the attacker’s possession.
Day 61–110: Exfiltration Begins
What the Attacker Is Doing
The staged data begins moving. Not all at once. Not to an obvious destination.
The attacker has observed that the organization’s legitimate backup traffic averages 3–5GB per day to approved cloud storage endpoints. The exfiltration is designed to match: 2–4GB per transfer, via HTTPS on port 443, to an attacker-controlled S3 bucket with a domain name registered to resemble a legitimate cloud services provider.
The transfers happen at 6:15am — when backup jobs run and outbound HTTPS traffic to cloud storage is expected and high-volume. The exfiltration traffic is visually indistinguishable from backup traffic in volume, timing, port, and protocol.
Over 49 days, the following is exfiltrated:
- Complete payroll records for all 2,400 employees
- Board presentations from the past 18 months
- M&A target research and valuation models
- Customer contracts and pricing data
- Source code for two internal applications
- IT architecture documentation including network diagrams and system inventories
Total: approximately 340GB, transferred in 2–4GB increments across 49 sessions.
No single session triggers a volume threshold. No destination IP appears on a threat feed. No protocol is unusual. The exfiltration looks, from every metric the detection stack measures, exactly like routine business operations.
What Your Security Stack Is Seeing
HTTPS traffic to cloud storage is expected and high-volume. Without a comprehensive approved cloud endpoint list and active comparison of destinations against it, the attacker’s S3 bucket is indistinguishable from your legitimate cloud storage traffic.
The DLP controls, if deployed, are configured to detect specific data patterns in outbound traffic. Compressed, encrypted archives don’t match those patterns. The data leaves in formats that bypass the specific rules that were configured.
110 days in. 340GB of your most sensitive data is in the attacker’s possession. Your dashboard has been clean for 110 consecutive days.
Day 111–127: Discovery — By Someone Else
What the Attacker Is Doing
The attacker has achieved their primary objectives. The data is exfiltrated. The persistence is established. They continue low-level monitoring of the environment — watching for internal communications about the acquisition targets they’ve identified, tracking email for information about upcoming board decisions.
They’re not in a hurry to leave. The environment is comfortable, well-mapped, and still completely unaware of their presence.
What Discovers the Breach
Not your SOC. Not your SIEM. Not your EDR. Not your DLP.
A threat intelligence vendor, monitoring dark web forums and criminal marketplaces as part of their subscription service, identifies a listing offering a data package containing identifiable attributes of your organization’s payroll data. They notify your security team through their automated alerting service.
The notification arrives at 9:47am on a Wednesday — 127 days after initial access.
The breach was not detected. It was disclosed.
The Forensic Timeline: What Was Always There
The incident response team spends the next three weeks reconstructing what happened. Every step of the timeline was recorded somewhere in your log infrastructure.
The VPN authentication on day one: in the VPN logs. The AD reconnaissance queries: in Windows Event Logs. The LSASS dump via comsvcs.dll: in Sysmon logs (where Sysmon was deployed). The Kerberoasting ticket request: in domain controller Kerberos logs. The backdoor account creation: in AD audit logs. The scheduled task persistence: in Windows Task Scheduler logs. The WMI subscriptions: in WMI Activity logs. The exfiltration sessions: in proxy logs and VPC flow data.
Every single step. Logged. Timestamped. Available.
Never correlated. Never surfaced. Never acted on.
The logs told the complete story of a 127-day intrusion. Nobody read them until the story was already over.
What Would Have Stopped It — At Each Stage
Understanding the attack timeline is only valuable if it changes what you build. Here’s the specific control, at each stage, that would have interrupted the chain.
Day 1 — MFA on all remote access, no exceptions. The contractor account authenticated without MFA because the VPN gateway had a legacy exception for third-party vendor accounts. One policy change eliminates this entry point entirely. Not a sophisticated control. Not an expensive one. A policy decision that was never made.
Day 4–14 — Identity governance that catches dormant accounts. The contractor account had been inactive for six months. An automated identity review process — or even a quarterly manual audit — would have deprovisioned it before it was available to the attacker. The attack surface didn’t need to exist.
Day 15–28 — Detection of Kerberoasting and LSASS access. Both techniques have known signatures. Kerberoasting generates detectable LDAP and Kerberos event patterns. LSASS access via comsvcs.dll generates a Process Access event. Detection rules tuned to these techniques in this environment would have fired and, if acted upon within hours, would have stopped the intrusion before domain admin was achieved.
Day 29–60 — Behavioral anomaly detection on the new service account. svc_monitoring_backup was created at 2:17am on a Saturday and immediately added to Domain Admins. An alert rule on new privileged account creation — or a UEBA system that scored this action against the baseline of normal account creation activity — would have surfaced this event as high-priority within hours of occurrence.
Day 61–110 — Egress monitoring with approved destination comparison. The exfiltration used HTTPS to a cloud storage endpoint that was not in the organization’s approved cloud service catalog. A proxy configuration that compares outbound cloud storage destinations against an approved list would have flagged the attacker’s S3 bucket on the first transfer. 49 sessions over 49 days would have been one.
Any single one of these controls, properly implemented and acted upon, changes the outcome.
Not all five. Any one.
The Single Most Important Takeaway
This attack wasn’t advanced. The attacker didn’t use a zero-day. They didn’t defeat your security controls with sophisticated evasion techniques. They used tools that came pre-installed on your systems, credentials that were already in your environment, and timing that blended into your operational rhythms.
They succeeded because of gaps that existed independently:
- A deprovisioned account that wasn’t deprovisioned
- A VPN policy that didn’t enforce MFA
- Detection rules that didn’t fire on known techniques
- Log correlation that never happened
- An egress comparison that was never configured
None of these gaps required advanced security capability to close. They required operational discipline — sustained attention to the basics that most security programs acknowledge but don’t systematically execute.
The 127-day timeline is not a story about a sophisticated attacker. It’s a story about the compounding cost of small, fixable gaps in an environment where nobody was checking whether the gaps existed until someone else found what came through them.
Your environment has gaps. Every environment does.
The question is whether you find them before the attacker does — or whether you find out about them the same way this organization did: at 9:47am on a Wednesday, in a notification from someone who wasn’t supposed to be watching.
Your Next Move
The attack described in this blog succeeded at every stage because of gaps that continuous, proactive security operations would have closed — or at least surfaced — before they became catastrophic.
→ Read next: No Alerts Doesn’t Mean No Threats — It Means You’re Blind — because 127 days of clean dashboards while an intrusion is active is not an edge case. It’s the average.
→ Want to know which steps of this attack chain your environment would have caught — and which it wouldn’t? A red team assessment walks the same path described in this blog against your live environment, measures exactly where detection fires and where it doesn’t, and gives you a prioritized remediation plan based on what an actual adversary found. Let’s talk.