Deconstructing OceanLotus: SPECTRALVIPER and the FireAnt Supply Chain Attack
Just finished reading the latest report on OceanLotus (APT32) and their activities involving SPECTRALVIPER. The fact that they maintained a cyber espionage operation against that Vietnamese construction corporation from mid-2024 all the way to February 2026 is a testament to their persistence.
What caught my eye was the dual-pronged approach: targeting critical infrastructure and hitting stock investors via a supply chain attack. The 'FireAnt' moniker is fitting given how burrowed in they get. Based on the telemetry described, SPECTRALVIPER seems to rely heavily on DLL side-loading and leveraging signed binaries to bypass security controls.
I've been updating our detection rules to account for this type of activity. If you're hunting for similar TTPs, look for anomalous process execution patterns where signed utilities spawn unauthorized shells. Here is a snippet I'm using to spot potential masquerading in our SIEM:
DeviceProcessEvents
| where Timestamp > ago(90d)
| where InitiatingProcessDigitalSignatureIssuer contains "Vietnam" or FileName in ("msbuild.exe", "rundll32.exe")
| where ProcessCommandLine contains "-enc" or ProcessCommandLine contains "http://"
| where ProcessCommandLine !contains "Microsoft"
| project DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, FolderPath
Has anyone else seen indicators of this supply chain vector outside of the Vietnam region? I'm curious if the compromised software vendor had a broader global footprint that might have been exposed before the takedown.
Great catch on the masquerading angle. We actually flagged some similar behavior last month using Sysmon. We focused on Event ID 7 (Image Loaded) looking for unsigned DLLs loading into processes that shouldn't be touching them.
AppData\Roaming\Microsoft\
true
It's noisy, but filtering by the construction sector in our threat feeds helped us narrow it down. The SPECTRALVIPER C2 traffic tries to look like standard HTTPS, but the JA3 fingerprint is usually a dead giveaway.
Supply chain attacks are becoming a nightmare for us. We've moved to a strict allow-listing policy for all third-party updates, but the business pushback is real.
Regarding the script, I'd suggest adding a filter for the 'FireAnt' specific user-agent string if you have it. OceanLotus usually customizes those to blend in with the target's environment. Has anyone successfully isolated the initial dropper? We're trying to determine if it's a macro or an ISO in this specific wave.
From a pentester's perspective, this highlights the failure of perimeter defenses. If the update package is signed, the firewall lets it right in.
One technique that works well for detection is monitoring for powershell logs that include 'System.Reflection.Assembly'. SPECTRALVIPER often uses .NET reflection in memory to avoid disk signatures.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104} | Where-Object {$_.Message -match "Reflection"}
It won't catch everything, but it reduces the false positives compared to general script logging.
Validating Nate's point, if the signature is valid, we look at the timeline. We've seen OceanLotus wait days or weeks before executing the payload to evade analysis. I recommend hunting for suspicious file creations in C:\ProgramData immediately after updates occur.
Get-ChildItem -Path "C:\ProgramData" -Recurse -File -ErrorAction SilentlyContinue | Where-Object {$_.CreationTime -gt (Get-Date).AddDays(-1) -and $_.Extension -eq ".dll"} | Select-Object FullName, CreationTime
Building on Zara's point about dormancy, we need to catch the activation. OceanLotus frequently leverages Windows Scheduled Tasks or WMI events to trigger payloads after the delay. I recommend hunting for tasks created by non-system accounts or using obscure binaries.
Here is a quick PowerShell query to find tasks registered in the last 7 days:
Get-ScheduledTask | Where-Object { $_.Date -gt (Get-Date).AddDays(-7) } | Select-Object TaskName, Author, Actions
This often reveals the "wake-up" call.
Adding to the persistence discussion, enforcing Just-In-Time (JIT) access can effectively disrupt lateral movement, even after activation. We've seen OceanLotus struggle when local admin rights are stripped, forcing them to generate noisy UAC prompts.
To verify no new local accounts were created during that 'burrowing' phase, run this audit check:
Get-WmiObject -Class Win32_UserAccount | Where-Object { $_.LocalAccount -eq $true -and $_.InstallDate -gt (Get-Date).AddDays(-30) } | Select-Object Name, InstallDate
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access