The Anatomy of the Modern Intrusion

I’ve found modern intrusion reporting to be abundant across the security ecosystem.

Reports describe how the attacker enters the environment, the shape of the traffic captured across monitors, how they employ a given piece of malware, and exactly how it operates to steal credentials or spread through the environment. They then turn into long novels on lateral movement, perfectly captured through network traffic in ELK, enriched with all manner of disk, network, and process data.

Rarely, however, do I believe that telemetry from these highly instrumented environments reflects what an actual modern intrusion looks like.

At $DAYJOB, we don’t have network telemetry—period. We have no way to collect it at scale and absolutely zero insight into what the traffic looks like on the wire, with the exception of point-in-time snapshots of active TCP/UDP connections. Likewise, we don’t have disk forensics, image loads, or other admittedly useful tools when dealing with advanced intrusions.

However, we still end up documenting attacks, catching bad guys, and achieving significant forensic detail despite the uphill battle of being telemetry-poor.

When I refer to the modern intrusion, I am not describing every intrusion or an idealized investigation. I am describing the financially motivated, hands-on-keyboard cases that repeatedly appear in telemetry-poor SMB environments.

These incidents do not arrive as pristine timelines. Evidence expires, logs wrap, systems disappear, and visibility varies from host to host.

A defensible conclusion is not perfect knowledge; it is the explanation best supported by the surviving evidence, known adversary behavior, and the alternatives we can eliminate.

If that makes defenders accustomed to pristine timelines uncomfortable, good. The discomfort is the point.

The recurring method throughout this article is peripheral authentication telemetry: when direct evidence from the compromised host is missing, we examine the authentication artifacts that the adversary’s actions force other systems to record. It is not a substitute for network visibility. It is how a timeline survives when the primary evidence does not.

The clearest way to show how this works is to follow the intrusion in the order it unfolds, beginning with initial access. In the cases that shape this article, adversaries rarely force the front door; they arrive with a credential and walk through it.

Walk In, Don’t Break In

A modern cyberattack isn’t necessarily advanced, doesn’t necessarily employ some novel zero-day, and isn’t necessarily perpetrated by a state-sponsored entity. Instead, modern cyberattacks are often some of the simplest intrusions to date, rehashing variants of the same highly effective playbooks.

The SSLVPN Front Door

Initial access is often the point that we examine most critically in an intrusion—knowing how the adversary entered an environment allows us to patch the holes to prevent reintrusion.

But what does this viscerally look like, especially in the small and medium-sized business (SMB) market segment? Well, it’s a lone SSLVPN appliance with a corporate network sitting behind it.

Maybe it’s backed by LDAP and exposing users’ Active Directory (AD) credentials to the scrutiny of the public internet. Maybe it’s using locally managed users for a handful of remote workers. Maybe it isn’t even using SSLVPN, but it’s still exposed.

Either way, it’s the adversary’s favorite entry point into a network. Rarely are these appliances examined as regularly as their exposure would dictate.

If I told you that your individual host was exposing TCP/3389 (RDP) to the public internet, you might be alarmed to find that out and rapidly patch it. However, in an LDAP-backed SSLVPN deployment, it’s often the case that the exposure surface is roughly tantamount—there are very few additional security controls deployed to prevent the same intrusion vector.

Brute-forcing AD credentials against an exposed RDP machine is roughly tantamount to brute-forcing the credentials of an LDAP-backed SSLVPN. Without additional protections, both can eventually yield access.

A Race Against Retention

In practice, SSLVPN appliances dominate a significant portion of our workloads. Unfortunately, they regularly contain very little in the way of retained authentication logs. In the SMB deployments that reach us, a reasonably busy SSLVPN may preserve only 5 to 30 minutes of locally retained authentication telemetry.

If I asked you right now to produce any log in 15 minutes, could you? Maybe if it was on your direct workstation, sure. If it’s a remote site that isn’t monitored often, or on an appliance you didn’t even know had SSLVPN enabled, that challenge is a race against time.

So how do we deal with analyzing these VPN intrusions? The answer is acute practitioner knowledge and a crafty process of elimination that rapidly drives hypotheses toward their natural conclusions without reaching a direct answer.

Handle enough SSLVPN intrusions and the subnets start to look the same. 10.212.134.200. 192.168.1.200. Recognizing which appliances those SSLVPN DHCP pools belong to is exactly the kind of intuition repeated case exposure develops.

For the rest of us, addresses from these pools overwhelmingly point to FortiGate and SonicWall SSLVPN sessions in my casework, respectively. There is no fault in not knowing that—in many security environments, the SSLVPNs are well instrumented, well monitored, and raise a clean alert when a login originates from an unexpected source IP address.

But for that small market segment that cannot afford or chooses not to instrument the SSLVPN, well, we as security practitioners still need to understand the intrusion even in the shadow of doubt.

The core and visceral principle of all this is that we need to be right more often than not, because the same businesses that cannot afford monitoring on their SSLVPNs are the ones that cannot afford to pay for expensive IR services.

Reconstructing the Missing Login

We may validate our understanding of an intrusion by looking at peripheral logs. They may not capture the malicious authentication, but they may capture an alert or other network telemetry tied to the DHCP-assigned intruder IP address.

On certain devices, even a logout event helps. It can untie the session from its DHCP address and reveal the original source IP. Fragments like these let us form and test hypotheses within the telemetry windows we still have.

From Inference to Defensible Claim

The conclusion is sometimes expressed as, “It’s an SSLVPN intrusion because I said so.” That’s glib shorthand, not the actual method. The defensible claim is that an SSLVPN intrusion best fits the surviving evidence, known device behavior, and the alternatives we have eliminated.

Unless modern IR firms have figured out a way to resurrect telemetry on a device with narrow log space that’s spinning due to raw internet noise, that is the standard the evidence permits—and it remains one of our most defensible tenets nonetheless.

Stop, Enumerate, and Listen

Start From Known Compromise

It’s insufficient for us to simply ground ourselves entirely in the initial access vector, though. And frankly, we never begin there. The most cohesive way to build an effective timeline is to start from a known compromise event, and work backward from that point.

If you’re in incident response, that point is often handed to you.

If you work at an MDR, sometimes the known compromise point is simply too late in the process—that known compromise point is an alert for ransomware deployment. My point is that different cybersecurity disciplines start at different points of the race, and we generally all need to finish at the same time to prevent catastrophic damage, especially to small and medium-sized businesses.

So the adversary has creds; they’re often non-privileged. Sometimes they aren’t provisioned in AD at all—a local firewall user simply facilitating access to the environment.

Enumeration Makes Noise

What is the first thing that almost every adversary, universally and without fail, does when they get access to an environment? Enumerate.

This presents one of the more concrete indicators for us as practitioners. Adversary enumeration toolkits all behave slightly differently, but they scream at you on a timeline. A ton of ANONYMOUS LOGONs from SSLVPN DHCP pools? You’re looking at SharpShares or other share enumeration tooling.

An nmap workstation name screaming through the 4625 events leaves little ambiguity: it’s Nmap.

Sometimes we’re fortunate enough that the first interaction is access to a workstation and the execution of Angry IP Scanner, SoftPerfect NetScan, or similar tooling. I say best-case scenario because it means the adversary has already moved into a vector where we have telemetry on them.

Maybe not advanced network telemetry or disk forensics, as most small and medium-sized businesses cannot afford this instrumentation. But instead, we have standard Windows telemetry and forensic techniques to construct a cohesive picture of what happened shortly after network ingress.

The Names That Do Not Belong

The other pattern we often see manifest when looking at aggregated Security.evtx logs is simply the emission of an odd workstation name. Maybe a WIN-VI96OVQI4I6 pops up in the logs somewhere.

If everything in the environment is carrying a WKS-123 style naming scheme, this sticks out like a sore thumb when it hits any conventional EVTX logon timeline. If you’re not checking workstation names, you absolutely should be.

Either way, I beg practitioners to adopt this singular core rule, battle-tested and written in blood:

For containment purposes, an adversary with local-network access must be treated as an adversary with credentials.

Whether they possess credentials at this exact moment is largely academic; there are a million practical ways to obtain them, including NTLM relay, Responder, packet sniffing, or sheer brute force. If they don’t have credentials right now, they will shortly.

Elevate and Escalate

Credential Harvesting Is Predictable

It’s almost never the Domain Administrator account out of the gate. That’s boring and uninspired. Also often entirely unnecessary. Instead, it’s Secretsdump.py firing quietly against a few hosts. Or lsassy snagging credentials via a staggeringly recognizable but mangled call to comsvcs.dll #+000024 (the ordinal entry point for MiniDump). Mimikatz and LaZagne have mostly fallen out of fashion.

Cached credentials on endpoints facilitate lateral movement, and occasionally simply yield Administrator credentials themselves.

Defender may or may not alert, and may or may not block aspects of the write/read through the SMB pipe. The resulting telemetry is ambiguous because Defender doesn’t provide us with a clear answer, and event 5145 auditing is often not enabled or spins Security logs so fast that by the time the alert arrives, the telemetry is no longer available.

Either way, this credential harvesting pattern is painfully predictable. So much so that it’s worth hunting for itself.

In truly ambiguous cases where the adversary has managed to blend in with the background noise of the environment during initial access and enumeration, the credential exfiltration patterns present in process telemetry can reveal the intrusion. The authentications they employ stand as a reasonable pattern in the face of ambiguity.

Remember, we’re working on a hypothesis— disproving one access vector or narrowing the points of interest is critically useful to our overall conclusion.

Tooling Narrows the Possibilities

So how exactly do we approach this—or rather, what does identifying the adversary’s tooling of choice let us as practitioners do to verify capabilities? Well, it helps narrow our information set even further.

For instance, if you’ve achieved full coverage on all domain-joined workstations in the environment, and you do not observe Impacket executing on one of those hosts, what does this tell us about the adversary? This is a coalescing point that investigators regularly miss.

If the adversary does not have an interactive session and is moving laterally, they implicitly have local network access.

We cannot observe the host in question, but we’ve effectively narrowed our information set substantially by verifying the adversary’s toolkit. Think about it. If an adversary has an RDP session on a box or is using some RMM to achieve command execution, this would be concisely and neatly captured in your process telemetry.

Maybe the binary is renamed; maybe it’s executing in an unusual way. Impacket and NetExec, however, both use Python as their runtime, and the number of small and medium-sized businesses truly employing Python regularly is incredibly limited.

This isn’t our sole point in any of these investigations—again, we’re chipping away at the data to reach a conclusion.

DCSync as Confirmation

From there, the next step, a DCSync firing off quietly into the night, is optional. We see it a lot—enough that it should be mentioned, but by the time we’ve caught the DCSync, the adversary has already likely tattled on themselves through other telemetry sources, so this regularly serves as a “dead to rights” moment rather than any groundbreaking discovery in a case.

Coincidentally, if you start your investigation on the domain controller and see DCSync, you’re often fast-tracked to an answer.

Lateral Movement 101

I’m not going to break down how to detect lateral movement; it’s been done to death. Dump 4624 events and RDP logs, compare and timeline, and you’ll get there eventually. If they’re blown away, get creative—adversaries rarely purge event logs across an entire domain, and as we discussed before, one of those workstations likely picked up the broad enumeration of shares in the environment.

Follow the Fatal Funnel

Instead, I think it’s useful to unpack the methodology behind how adversaries move laterally. Not… the literal sense. PSExec, NetExec, etc. No, I’m talking about the adversary tendency to move toward Tier 0 infrastructure and how it relates to our telemetry deficit.

Workstations are rarely the terminal objective in these intrusions. They may contain data or credentials. They may even themselves be a foothold. But no matter the malware, no matter the access, the adversary is going to move toward the domain controller or file server.

What does this mean? If we’re in a telemetry deficit on an endpoint that we suspect the adversary co-opted to gain a foothold (say, Security logs have spun), then we can move up the chain to look at the domain controller.

Domain controller logs are wiped? File server time. Rinse and repeat—Tier 0 infrastructure is coveted by adversaries, and this presents a fatal funnel for us as security practitioners to exercise additional scrutiny.

Establish the Normal Cadence

If you work in the small and medium-sized business segment long enough, you get a feel for when an Administrator login is authentic versus malicious. And you might be asking yourself what that even means.

Most of these organizations are administered by an MSP, and that MSP often has its own branded account. If you look at authentication history, even over a small subset of a day or two captured in the Security.evtx logs, you can get a feel for what a natural cadence looks like for users in the environment.

It doesn’t mean the adversary can’t control those accounts. But if system administrator activity is largely carried out by adm-user style usernames or accounts branded with an IT company, and suddenly the Administrator user begins authenticating to the domain controller remotely, there may be more to the story.

Corroborate at the Destination

Likewise, adversaries often tattle on themselves when it comes to lateral movement to the domain controller. Many modern credential extraction tools don’t bestow the adversary with a plaintext password. Instead, the adversary is given NTLM hashes to authenticate with.

In the right context, this pass-the-hash activity generates a fairly recognizable telemetry pattern: a type 3 logon using NtLmSsp with a KeyLength of 0.

This is not proof by itself—zero-length session keys occur in benign authentication flows—but it becomes useful when the source, account, timing, workstation field, and surrounding lateral-movement activity agree. ANONYMOUS LOGON is an important exclusion; it is not evidence of PTH. I’ve found this SigmaHQ rule to be useful.

Pass-the-hash detection is often low-fidelity; don’t deploy it broadly. Instead, use it to shape your intuition about an intrusion. Pass-the-hash rarely defines the source of the intrusion, but instead corroborates your intuition as a practitioner. Keep in mind that certain authentication software or RMM tools can also produce significant cascades of PTH-style events. Use your best judgment.

The takeaway from the above should be fairly clear, however—when there is a telemetry deficit, you do not simply give up and conclude that the adversary has pulled off a caper. Instead, you examine peripheral authentication telemetry to gain insight into how the adversary has moved.

Chief concern is a workstation firing an alert? The peripheral authentication telemetry might be the domain controller capturing event 4776 in its Security.evtx to handle AD authentication for that workstation.

Exfiltration Station

Exfiltration is where our methodology tends to fall apart a little bit. If we’re asking, “Did exfiltration occur?” this means several things:

• We have no visibility into adversary actions from the EDR side—so implicitly, we were unaware of a system’s existence in the network.
• Or the exfiltration occurred via, for example, SMB, and we’re probably not going to recover exactly what was taken.

When More Auditing Means Less Evidence

“But Mike, we have 5145 events!” someone might exclaim. However useful 5145 events are in the grand scheme of cases, I can explicitly assure you that they’ve eradicated more useful Security telemetry in the small and medium-sized business segment than they’re worth.

If you’ve solved a case with 5145 events, that’s great. However, in environments capturing, say, 128 MB of Security logs and retaining nothing in a SIEM, 5145 events are the bane of my existence.

Execution Evidence Is Not Exfiltration Scope

If the first time we ask, “Did exfiltration occur?” is after the relevant host and network evidence has expired, we are usually too late to answer with precision. Exfiltration so often reveals itself clearly on a surviving timeline that its occurrence is rarely the hardest question.

The pragmatics of “how much data?” or “what was stolen?” are not so clear. But s5cmd, rclone, WinSCP, and similar tools all show up in the usual places: Amcache, SRUM, Jump Lists, or Registry cache files. These are documented to death because, unfortunately, a lot of cycles have been burned in incident response pursuing this very question.

This might seem like a concise section, and that’s deliberate—you either have the instrumentation that makes exfiltration easier to detect or you don’t and you’ve lost the opportunity.

Forward Unto Ransomware

The intrusion pattern examined in this article commonly ends with ransomware. The affiliate or brand is irrelevant—they’re all doing the same thing. A criminal’s promise to delete stolen data is not a verifiable control and should never be treated as one. There is no honor among thieves.

Impact Collapses the Evidence Surface

From a practitioner perspective, dealing with ransomware deployment can be painful. Probably not as painful as the end user’s experience, but painful nonetheless.

This typically means that the adversary has met all objectives (obviously). Many times it indicates that data exfiltration was missed somewhere in the intrusion chain. Unfortunately, this cycle is also when adversaries begin to engage in anti-forensic techniques such as event log clearing.

If you’re (un)lucky enough, the hypervisor estate has been encrypted. The peripheral authentication telemetry we spoke about earlier has been obliterated in unbootable virtual machines, and the footprint of systems observable to you has rapidly degraded.

It is often the case that when ransomware deployment has been observed, all IOCs have materialized in the precise form in which they will forever be recorded in an incident. Restated, once the encryptor fires, that’s all you’re getting.

Work Backward From Impact

Fortunately, working back from ransomware deployment can be quite easy if event logs haven’t been eradicated. If no alerts have fired prior to then, they damn well better be now. An alert is a tangible bite point for us to frame an incident on and work backward from.

We mostly employ the series of techniques we’ve observed above; timelining an incident that ultimately ended in ransomware is often the easiest because we have no ambiguity. If Administrator deployed ransomware via C:\Users\Public\win.exe on the domain controller, there’s little left to question about which account the adversary controlled.

The path they took through the environment thereby becomes much easier to reconstruct, especially if the adversary hasn’t successfully completed their anti-forensic measures. Consequently, to me, ransomware deployments are poignant inflection points; the mystery of the intrusion has been lost, the affiliate is known, and thereby with enough aggregate data, the tooling is known and consequentially tractable in telemetry.

When the Playbook Names Itself

A concise example: if an encryptor is executed from C:\ProgramData\win.exe sitting next to C:\ProgramData\ssh\, the case has solved itself without a glance at telemetry. The intrusion was via a… notorious SSLVPN appliance; cloudflared was the follow-on tooling used to maintain persistence.

Telemetry manifests as RDP connections over TCP/3389 from the host with the SSH folder, or as localhost authentications to the target machine if it’s the domain controller itself. Somewhere else in that estate is an ADUsers.csv indicating which system they first touched.

The playbook is methodical and unchanging, and the answer is often trivially discernible at that point.

Key Takeaways

• The modern intrusion is repetitive by design. The financially motivated actors in this corpus reuse access methods, tooling, and movement patterns because those methods continue to work. Novelty is not a prerequisite for impact.
• Telemetry does not fail gracefully. Logs wrap, systems disappear, and high-volume auditing can destroy the retention window investigators actually need. More telemetry is only useful when the environment can preserve and retrieve it.
• Local-network access is credential compromise for containment purposes. Whether the adversary has credentials at the moment of discovery is less important than the number of reliable ways the environment gives them to obtain those credentials.
• Tooling constrains behavior. Enumeration tools, Impacket, NetExec, RDP, RMM software, and credential-access techniques leave different artifacts because their implementations require different interactions. Understanding those requirements lets us infer what must have happened even when direct execution telemetry is missing.
• Peripheral authentication telemetry preserves the timeline. VPN-assigned addresses, workstation names, authentication pairs, logon types, domain-controller validation, account cadence, and movement toward Tier 0 systems can reconstruct activity that the compromised host no longer records.
• A defensible conclusion is not a claim of perfect knowledge. It is the explanation that best fits the surviving evidence, known adversary behavior, and the alternatives the investigation has eliminated. Confidence should match the evidence, but uncertainty is not a reason to abandon the conclusion.
• Threat intelligence must become institutional memory. Indicators and playbooks cannot remain domain knowledge held by one or two practitioners. An organization that does not preserve what its investigators learn forces every future responder to rediscover it under pressure.

Conclusion

Modern incident-response doctrine often presents an intrusion as a timeline waiting to be recovered. Collect the right logs, normalize the events, and the adversary’s path will reveal itself. That timeline exists in reports because someone already did the difficult work of reconciling the gaps. It rarely exists that cleanly in the environment itself.

Real investigations are asymmetrical. One host retains process telemetry while another has already wrapped its Security log. The VPN knows an authentication occurred but no longer remembers who performed it. The domain controller records the credential validation without explaining why the request existed.

Each source holds a fragment, and none of them is obligated to preserve the fragment long enough for us to arrive.

The answer is not to pretend those gaps do not exist, nor is it to declare the intrusion unknowable. Start from what is known, work backward and outward, identify the behaviors the adversary’s tooling requires, and examine the systems forced to participate in those behaviors.

Compare the result against the environment’s normal cadence. Eliminate explanations that cannot fit. State what remains, and state the uncertainty honestly. That is the work.

Experience matters because repeated contact turns noise into landmarks. A VPN pool, a workstation name, an authentication pair, or an unexpected Administrator logon carries meaning only when someone has seen the pattern enough times to understand its place in the larger intrusion. That intuition is not magic, and it should not remain personal. It must be documented, challenged, refined, and made available to the investigators who follow.

Telemetry scarcity changes the confidence and wording of a conclusion; it does not eliminate our ability—or our responsibility—to reach one. The timeline may be incomplete. The investigation does not have to be.