Malware News Fortinet’s FortiGuard Labs reports that the Ousaban banking Trojan targets Windows users banking in Spain and Portugal, delivering phishing PDFs

[Khushal]

Content source

https://www.fortinet.com/blog/threat-research/analysis-of-ongoing-ousaban-attacks-targeting-the-iberian-peninsula

In May 2026, FortiGuard Labs identified an attack targeting users in Spain and Portugal involving the banking Trojan Ousaban. This malware has been active in Brazil and is spread through an MSI downloader. The malicious payload involves a DLL file that is run via DLL side-loading or process injection.

Analysis of Ongoing Ousaban Attacks Targeting the Iberian Peninsula | FortiGuard Labs

FortiGuard Labs analyzes a geofenced Ousaban campaign targeting Spain and Portugal with phishing PDFs, steganography, and evasive C2.…

www.fortinet.com

In this campaign, the threat actor primarily targets users in Spain and Portugal. Figure 1 shows how the attack unfolds. The phishing PDF tricks victims into visiting a malicious webpage that scans the user's environment. If they are in Spain or Portugal, the webpage downloads a VBS file to kickstart the next part of the attack. The final payload is an EXE file that is dropped onto the victim’s computer and executed by the VBS script.

 

[Bot]

This FortiGuard write-up is a good example of a “multi-stage” banking trojan delivery chain where each step is meant to reduce detection and narrow in on intended victims.

What stands out in this campaign

• Geo-targeting (“environment scanning”): the landing page checks whether the victim appears to be in Spain or Portugal before delivering the next stage. This helps the attacker keep payload volume lower and avoid wider researcher/AV exposure.
• Scripted staging (VBS): using a VBS file as the launcher is a common way to bootstrap execution and pull down/launch additional components.
• MSI/DLL tradecraft: MSI downloaders and DLL side-loading/process injection are frequently used to blend in with normal Windows behavior and evade simplistic controls that only watch for obvious “malware EXE runs.”

Why DLL side-loading matters defensively
DLL side-loading often abuses a legitimate (or otherwise trusted-looking) executable that loads a DLL from its working directory. If an attacker can place a malicious DLL with the expected name alongside that executable, Windows may load the attacker’s DLL instead of a legitimate one.

Practical implication: blocking “unknown EXEs” alone may not be enough if a signed/legitimate binary is used as the loader.

Practical mitigations (home and small business)

• Treat “PDF → link → download” as high-risk: many modern campaigns avoid macros and instead rely on social engineering to get users to a web stage.
• Reduce script exposure:
  • If you don’t need it, restrict or block Windows Script Host (wscript/cscript) in your environment.
  • Be especially cautious with .vbs/.vbe/.js/.jse attachments or downloads.
• Harden browser and download behavior:
  • Keep browsers fully updated.
  • Don’t run downloads directly from the browser “Downloads” bar—save, verify, then scan.
• Scan suspicious files rather than “trusting the chain”:
  • Submit the downloaded file(s) to VirusTotal and/or your vendor’s sample submission portal.
  • Scan with a reputable AV suite and consider a second-opinion scanner if you suspect compromise.

Practical mitigations (organizations)

• Email/web controls:
  • Block or heavily scrutinize PDFs containing external links/URI actions in high-risk mail flows.
  • Use web filtering to block newly registered domains and known phishing infrastructure.
• Attack Surface Reduction / scripting controls:
  • Microsoft Defender ASR rules (where applicable) can significantly reduce script-based and “living-off-the-land” style execution.
  • Consider WDAC/AppLocker to restrict script interpreters and user-writable execution paths.
• Detect side-loading/injection behavior:
  • EDR detections for unusual DLL loads from user-writable directories (Downloads, Temp, AppData).
  • Monitor process injection patterns and suspicious child-process trees originating from script hosts.

If someone already executed the VBS/EXE

• Disconnect the device from the network to limit credential theft and lateral movement.
• Run full AV/EDR scans and review persistence locations (Startup items, Scheduled Tasks, Run keys).
• Assume banking credentials could be at risk: change passwords from a known-clean device and notify the bank if fraud is suspected.

Sources

• Analysis of Ongoing Ousaban Attacks Targeting the Iberian Peninsula | FortiGuard Labs

 

[Halp2001]

What I find interesting about this campaign is that it doesn’t rely on exotic exploits, but on common PDFs and scripts instead. It reinforces the idea that social engineering remains one of the most effective attack methods, because convincing someone to click is often easier than exploiting a technical vulnerability. Also, seeing Ousaban expand from Brazil to the Iberian Peninsula shows how threat actors adapt their campaigns to different regions.