The Ousaban Infection Flow: From Phishing PDF to VBS Downloader to Stolen Banking Tokens

What stands out in the Ousaban infection flow is not that it starts with a PDF. It is that the PDF is only the first trust handoff. The public reporting I found says the campaign uses phishing PDFs and a VBS downloader to target Iberian banking users, with stolen banking tokens as the end goal. That is enough to matter even without a full malware teardown: the chain moves from a human-readable lure to script execution to token theft, which is exactly where a lot of endpoint and identity controls break down in practice.

My read is straightforward: this is not just a mail security issue, and it is not just a browser issue. It is a chain issue. If you only block one file type, or only train users to distrust attachments, you miss the step that actually turns a click into account access.

Why this campaign matters to developers and defenders

For defenders, the Ousaban flow is a reminder that “attachment delivered” is not the same as “attachment contained.” A PDF can be a delivery vehicle, a script can be a loader, and a stolen token can outlive a password reset.

For developers, especially anyone building banking, fintech, or identity-adjacent systems, this is a warning about assuming bearer tokens are low-risk because a user still “knows their password.” If an attacker gets a usable session token, the password may never come into play again. The application sees a valid token and grants access.

So the useful question is not “Did the phishing email look convincing?” The useful question is “What happens after the user opens the file, and what still works if a token is stolen?”

What the reporting says about the Ousaban flow

The public report is thin, but the chain is still useful because each stage points to a different control failure.

Phishing PDF as the initial lure

The PDF is the social-engineering entry point. I would not overread the format itself. PDFs are common because users trust them, mail gateways often allow them, and they fit a simple pretext: invoice, notice, delivery document, account update, and so on.

Technically, the PDF does not need to exploit a parser bug. It only needs to get the user to take the next step, often by opening a link, downloading a file, or running something that feels normal in the moment. The report does not spell out the exact PDF contents, so I would treat that part as unknown.

VBS downloader as the next-stage loader

This is the part I care about most. A VBS downloader is a classic way to move from one lure to a second-stage payload. The loader does not need to be fancy if the environment allows script hosts to run freely.

On Windows, that usually means wscript.exe or cscript.exe, and sometimes nearby living-off-the-land tools depending on how the operator wants to blend in. If your environment treats those binaries as harmless, you are leaving a broad execution path open.

The banking-token theft goal

The reporting says the campaign is aimed at banking tokens. That usually means something more valuable than a one-time password guess. If the attacker can steal a session token, device token, or other bearer artifact, they may be able to act as the victim without knowing the password.

That changes the defensive model:

• passwords can be rotated
• tokens often need explicit revocation
• MFA helps, but stolen post-authentication tokens can still be abused until they expire or are invalidated

If the campaign is really focused on token theft, then the issue is not just login compromise. It is session compromise.

Where the infection chain likely gets its power

User trust in document files

The first source of power is plain old habit: people open documents.

A PDF looks passive. It looks like evidence, not code. That mental model is wrong. A document can be a delivery wrapper for a browser redirect, a scripted payload fetch, or a prompt to install or enable something. The attacker is counting on the user treating the file as content, not as a step in a kill chain.

Script-based execution on Windows

The second source of power is Windows script execution. VBS is old, but that is often the point. It is built in, it is understood by the OS, and in many environments it is not watched as closely as PowerShell or obvious malware binaries.

That makes it useful as a loader. The attacker gets a lightweight execution mechanism without dropping a large executable immediately. The loader can fetch, stage, decode, or launch the next payload.

Token theft versus simple credential capture

The third source of power is that tokens are operationally sticky. A password can be changed while a token remains valid. A login event can look normal while a session is already hijacked. If malware steals a token after authentication, the attacker may bypass the controls the victim thinks are protecting them.

I would rank the risk like this:

1. token theft and session abuse
2. script execution on endpoints
3. the PDF lure itself

The lure is how they get in. The token is how they keep moving.

What is confirmed and what still needs verification

Confirmed by the source material

What the public report supports directly:

• Ousaban is being described as using phishing PDFs
• a VBS downloader is part of the chain
• the target set is Iberian banking users
• the campaign’s end goal is banking-token theft

That is the minimum confirmed picture.

Inferred from the campaign pattern

What I think is likely, but not confirmed in the source material:

• the PDF is acting as a social-engineering trigger rather than a standalone exploit
• the VBS file is probably a staging loader rather than the final payload
• token theft likely means session or authentication artifact theft, not just password capture
• the chain probably depends on endpoint environments where script hosts are not tightly constrained

Those are reasonable inferences, but they should stay in the inference bucket until you have malware samples, telemetry, or a vendor advisory that says the same thing.

Practical defensive checks for endpoints and mail pipelines

Mail filtering and attachment handling

If I were hardening a mail path for this kind of campaign, I would focus on the handoff from attachment to execution.

• detonate PDFs in a sandbox before delivery to the inbox
• flag or quarantine PDFs that contain external links, embedded files, or unusual launch actions
• strip or rewrite risky attachment delivery patterns when your business can tolerate it
• watch for repeated delivery of invoices, notices, or account-themed PDFs from newly registered or low-reputation domains

The point is not to block every PDF. The point is to make it harder for a PDF to become a launch pad.

Script execution controls and logging

This is where I would spend most of the defensive budget.

If your telemetry supports it, hunt for document readers spawning script hosts. A PDF reader should not normally launch wscript.exe or cscript.exe.

Example KQL for Microsoft Defender for Endpoint:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("wscript.exe", "cscript.exe", "mshta.exe")
| where InitiatingProcessFileName in~ ("Acrobat.exe", "acrord32.exe", "chrome.exe", "msedge.exe", "outlook.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc

A suspicious hit would look like this in shape, even if the exact names differ in your environment:

2026-07-01T09:14:22Z  LAPTOP-17  Acrobat.exe  wscript.exe  "wscript.exe C:\Users\...\AppData\Roaming\invoice.vbs"

That is the kind of parent-child chain I would want alerted, not just logged.

Also useful:

• Sysmon process creation logging
• script block logging where applicable
• command-line auditing
• application control or allowlisting for script hosts in high-risk endpoints

Browser, banking, and token hygiene

If the campaign objective is banking tokens, your app and identity layers matter too.

• use short-lived tokens where possible
• make revocation actually effective
• bind high-risk sessions to device or risk signals when practical
• avoid treating password reset as complete compromise response
• log token reuse, impossible travel, and session duplication
• require step-up auth for sensitive actions even after login

If you run a banking or fintech workflow, test whether stolen session state can be used after logout or password change. If the answer is yes, you have a containment problem.

How to test your own environment safely

Review alerting for PDF delivery chains

Start with mail and gateway telemetry.

Look for:

• repeated PDF delivery from the same sender pattern
• PDFs delivered shortly before a script host launches
• users who open a PDF and then immediately download or execute a second file
• attachment names that imitate invoices, delivery notices, or bank correspondence

This is safe to do with logs alone. You do not need live malicious samples to see whether your pipeline is blind.

Look for VBS execution and parent-child process anomalies

If you have EDR or Sysmon, review the last 30 days of process ancestry.

A practical hunting rule is:

• parent process is a PDF reader, browser, email client, or archive tool
• child process is wscript.exe, cscript.exe, mshta.exe, powershell.exe, or rundll32.exe
• command line references a user profile path, temp path, or downloaded file

If you want a local Windows check with event logs, this is a safe starting point:

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-Sysmon/Operational'
  Id      = 1
} | Where-Object {
  $_.Message -match 'wscript.exe|cscript.exe|mshta.exe'
} | Select-Object -First 20 TimeCreated, Id, ProviderName

If that returns nothing, that is fine. It may mean you are clean, or it may mean your logging is incomplete. Either way, it tells you something.

Validate whether token reuse is possible after compromise

Use a throwaway test account and your normal admin controls. The safe test is not “can I steal a token?” The safe test is “can I invalidate one?”

What to verify:

1. log in with a test account
2. establish a normal session
3. revoke the session through your admin or user control path
4. confirm the old session stops working immediately
5. confirm your logs record the revocation and any later reuse attempt

If the old session still works, then a stolen token can probably keep working too. That is the behavior I would fix first.

Why I would fix the loader path first

If I had to choose one place to spend time, I would fix the loader path before anything else.

Why? Because the PDF lure is cheap to change, but the script execution step is where the campaign becomes operational. Once the attacker gets a loader running, they can repackage the lure, swap payloads, and iterate quickly. Blocking or constraining script hosts, especially in user-facing contexts, raises the cost of the whole campaign.

That is why I would prioritize:

1. mail filtering and sandboxing
2. blocking or alerting on document-to-script execution
3. token revocation and session-hygiene controls

If you get those three right, Ousaban-like chains become much harder to turn into account compromise.

Further reading and source note

• CyberSecurityNews report via Google News — the public report used as the source seed for this post.

Source note: I could confirm the campaign shape from the supplied public reporting, but I did not verify a vendor advisory, sample hashes, or a full malware analysis write-up from a primary source in the material provided.