What happens after an attacker gets initial access through a drive-by download?

What attackers typically do next after a drive-by download

initial access from a drive-by download is often only the first stage of a broader intrusion. Once a malicious payload lands, attackers usually try to establish a stronger foothold, learn what kind of environment they are in, and turn a one-time browser compromise into repeatable access. That progression can include credential theft, discovery of nearby systems, and preparation for encryption, data theft, or remote control. For a practical map of those follow-on behaviours, the MITRE ATT&CK Enterprise Matrix is a useful reference because it groups the common post-compromise techniques defenders should expect.

A drive-by download matters because it compresses the defender’s response window. What looks like a single endpoint event can quickly become an identity, access, or recovery problem if the malware reaches stored sessions, local credentials, or connected services. The earlier teams recognise that the real objective is often follow-on execution rather than the initial web infection, the faster they can isolate the host and stop the next stage from spreading. In practice, many security teams discover the breadth of the compromise only after the attacker has already used the first foothold to move beyond the original browser session.

How the post-exploitation chain unfolds in practice

After a drive-by download succeeds, the attacker usually wants one of three things: persistence, expanded reach, or monetisation. The exact sequence varies, but the mechanics are familiar. The first task is often to confirm that the initial payload is still alive and to reduce the chance of removal. That may involve installing a service, creating a scheduled task, abusing a startup location, or using a legitimate process to blend in. The next task is to discover what the host can reach. That includes local users, mapped drives, browser-stored credentials, network shares, and any applications already trusted by the device.

At this point, the attacker may extract session tokens, harvest cached secrets, or use the compromised machine to access cloud services already authenticated in the browser. They may also run lightweight reconnaissance to identify privilege boundaries, security tools, and internal systems worth targeting. If the environment is exposed enough, the attacker can pivot from one compromised endpoint into a wider intrusion, sometimes using remote execution, stolen credentials, or additional payloads staged from external infrastructure. MITRE ATT&CK remains the most useful public reference for understanding these chained behaviours because it connects initial access, credential access, discovery, lateral movement, and impact techniques in one model.

• Persistence is about making the foothold harder to remove than the original browser exploit.
• Discovery is about finding valuable accounts, systems, and services before defenders notice.
• Credential access is about turning one infected endpoint into broader trust abuse.
• Impact often arrives later, after the attacker has prepared the environment for theft or disruption.

The important operational point is that drive-by access is rarely the end state. It is the bridge into a second stage, and that second stage is where incident severity usually increases. This guidance breaks down when the payload is quickly contained and the host has no reusable trust, because the attacker then loses the ability to pivot.

Variants, edge cases, and where the usual pattern changes

Tighter browser and endpoint controls often reduce drive-by risk, but they also increase operational overhead, so organisations have to balance user convenience against containment strength. Some drive-by infections remain narrow and are removed before they can do anything more than beacon out, while others become full intrusions because the endpoint held useful sessions, cached credentials, or access to shared systems. The practical difference is not the download itself but what the device was already trusted to do.

One important variation is that not every post-compromise action is overtly malicious at first. Attackers sometimes spend time on reconnaissance and token theft before deploying a visible second-stage payload. In other cases, the malware is only a loader whose purpose is to bring in ransomware, spyware, or remote access tooling later. Guidance on this point is broadly consistent across the industry: a successful download should be treated as a compromise until containment proves otherwise, even if no destructive action is yet visible.

Another edge case is when the browser session itself becomes the target. If the user was already authenticated to email, SaaS, or internal portals, the attacker may not need to steal a password at all. They can abuse an existing session, which changes the response priority from password reset alone to session invalidation, device isolation, and review of recent authentication activity. For teams investigating the downstream effects of browser compromise, CISA advisories are useful because they show the common response patterns and the kinds of follow-on activity defenders should look for after initial access.

The usual pattern changes only when the compromised device has little reach or the access token expires before the attacker can reuse it.

Risk and Threat Considerations

A successful drive-by download is dangerous because it converts a web-based infection into a platform for trust abuse, lateral movement, and secondary payload delivery. The biggest risk is not the initial code execution itself but the attacker’s ability to reuse the host’s authenticated state, local privileges, and network reach before defenders intervene.

Failure mechanism: The compromise becomes material when the attacker steals session material, runs discovery, or launches a second-stage tool from the infected endpoint. That failure chain is well understood in post-compromise tradecraft and is commonly represented across endpoint, credential, discovery, and impact techniques in ATT&CK.

Impact: The result can be expanded access, internal reconnaissance, data theft, ransomware deployment, or a broader incident that outlives the original browser compromise. In identity-heavy environments, a single infected session can also expose other services that trust the same browser context.

Practitioner Guidance

What to prioritise: Treat the infected endpoint as a pivot point, not an isolated browser event. The first questions should be whether the host held reusable sessions, cached credentials, or access to internal resources that could let the attacker move beyond the initial download.

What to verify: Confirm whether the browser, local profile, or device had authenticated access to email, SaaS, VPN, remote admin portals, or cloud consoles. If those trust paths existed, response should include session review and revocation, not just malware removal.

• Isolate the device early if you cannot prove the attacker had no pivot path.
• Review recent authentication activity for unusual reuse of the compromised session.
• Look for second-stage downloads, scheduled tasks, new services, and unusual outbound connections.
• Escalate quickly if the endpoint had access to privileged or high-value accounts.

Common mistake: Teams often focus on the original browser infection and underestimate the attacker’s next move, which is usually to reuse trust that was already present on the device.

Practitioner takeaway: A drive-by download is best treated as the opening move in a compromise chain, and the response should be judged by whether the attacker can still reuse the endpoint’s trust, not by whether the first payload looked small.

Related resources from NHI Mgmt Group

• Why does lateral movement become the critical failure point after an attacker gets valid access?
• What happens when identity blind spots let an attacker move from initial access to ransomware deployment?
• What happens if an attacker gets into a public MLOps UI without deeper system access?
• What happens after attackers obtain access tokens through device code phishing?