edit: clean up prose in vbs trojan writeup

LasCC · LasCC · commit e7362f9c615c · 2026-03-20T07:30:17.000-04:00
diff --git a/src/content/blog/malware-analysis-brazilian-vbs-trojan.md b/src/content/blog/malware-analysis-brazilian-vbs-trojan.md
@@ -1,14 +1,14 @@
 ---
 title: "Dissecting a Brazilian Multi-Stage VBScript Trojan Dropper"
-description: "Deep dive technical analysis of a multi-stage VBScript malware targeting Portuguese-speaking users, featuring heavy obfuscation, staged payload delivery via hidden IE COM objects, and Windows Task Scheduler persistence"
+description: "Technical analysis of a multi-stage VBScript malware targeting Portuguese-speaking users, with heavy obfuscation, staged payload delivery via hidden IE COM objects, and Windows Task Scheduler persistence"
 pubDate: "2026-03-16"
 featured: true
 category: "Malware Analysis"
 ---
 
-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.
+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 !).
+Quick disclaimer: 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 !
 
@@ -58,22 +58,22 @@ sha256: 9b1a2b025f5f9fcc13eec998aee04a640b3d2cf944b636ee3b2016e5e8167b5f
 md5: 7e14bca371b09b68040ceb378b502915
 ```
 
-Inside the ZIP we find **two files**:
+Inside the ZIP we find two files:
 
 | File | Size | Type |
 |------|------|------|
 | `Comprovativo_Março_12-03-2026-fVFLCFw.vbs` | 5.4 MB | VBScript (ASCII text) |
 | `Comprovativo_Março_12-03-2026-fVFLCFw` | 47 MB | PE32 executable (GUI) Intel 80386 |
 
-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.
+So 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.
+The VBS file is 5.4 MB and 10,116 lines long. That's absurd for a VBScript. Let's see why.
 
 ```bash
 wc -l extracted_payload.vbs
@@ -88,11 +88,7 @@ RSFCRKdhIooxNaEznecGcNDdOBSADSJqwZPEINsXlwrOnA = UhiSmA1(89) + UhiSmA1(121) + Uh
 WDkNVKiTqLpLFMkAgRGKvIBARvndsEFxPtDWlGWZJMhKIh = UhiSmA1(106) + UhiSmA1(79) + UhiSmA1(117) + ...
 ```
 
-**96.4% of the file is junk code.** Out of 10,116 lines, only **~424 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
+96.4% of the file is junk code. Out of 10,116 lines, only ~424 lines are meaningful. The rest is random variable names (30-45 characters long) assigned to garbage string concatenations. It's padding, meant to make your eyes glaze over when you open the file, slow down sandboxes, and throw off AV pattern matching.
 
 ### The Obfuscation Layer - `UhiSmA1()`
 
@@ -108,7 +104,7 @@ Function UhiSmA1(rpidscSPL2)
 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.
+This is functionally equivalent to `Chr(N)` — it maps ASCII codes (32-126) to their character representation through a lookup string instead of calling `Chr()` directly. The reason: `Chr()` concatenation chains are a well-known VBS obfuscation indicator that AV signatures flag on, so routing through a custom function sidesteps that.
 
 ### Deobfuscation
 
@@ -141,7 +137,7 @@ Sub IQQQDNlBYiabSN...()
 End Sub
 ```
 
-First thing it does: creates a **`.lnk` shortcut** in `%APPDATA%` pointing back to itself. This is a basic persistence mechanism.
+First thing it does: creates a `.lnk` shortcut in `%APPDATA%` pointing back to itself. Basic persistence.
 
 ### Step 2: Move .lnk to Startup Folder via Scheduled Task
 
@@ -169,12 +165,7 @@ Sub thCdGRXkYWmHai...()
 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**.
+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`), has no execution time limit (`PT0S`), and is named with just a dash and the current second (`-42`, `-17`, etc.) to blend in. Now the malware survives reboots.
 
 ### Step 3: Generate the C2 URL
 
@@ -188,7 +179,7 @@ The C2 server is at **`http://18.230.59.64/`** -> an AWS IP in the **São Paulo
 
 ### 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:
+The script dynamically generates a second VBS file and writes it to `%TEMP%\{random}.vbs`, line by line, interspersed with more junk code padding:
 
 ```vbscript
 Set fso = CreateObject("Scripting.FileSystemObject")
@@ -201,7 +192,7 @@ For i = 1 To 40 : writer.WriteLine randomVar & " = " & Chr(34) & randomString &
 ' ... 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.
+The stage 2 payload gets padded with junk code at write time. Obfuscation all the way down.
 
 ### Step 5: Schedule Stage 2 Execution
 
@@ -223,7 +214,7 @@ Function mWWtQEHQcbKJBSu...(vbsPath)
 End Function
 ```
 
-Another **hidden scheduled task**, this time running `wscript.exe` with the stage 2 VBS as argument. Triggers 10 seconds later.
+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
 
@@ -240,7 +231,7 @@ Loop
 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 1 sits in a loop polling 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.
 
 ---
 
@@ -269,12 +260,7 @@ 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
+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. IE traffic blends in with normal browsing on network monitors, it automatically inherits the system's proxy settings, and the COM interface is less commonly hooked by security tools than the usual HTTP libraries. It's a surprisingly effective trick for 2026.
 
 I was able to access the C2 while it was still live and confirmed what the response looks like:
 
@@ -286,7 +272,7 @@ 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 !).
+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
 
@@ -343,13 +329,9 @@ Function downloadPayload(url, savePath)
 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
+The download uses HTTP Range requests to pull the file in ~1MB chunks. No single request is large enough to trigger size-based heuristics, the pattern looks like a normal download manager to any proxy watching, and some IDS won't bother reconstructing the full file from partials.
 
-After download completes, it creates the **signal folder** in `%TEMP%` to notify stage 1.
+After download completes, it creates the signal folder in `%TEMP%` to notify stage 1.
 
 ### Call Chain Obfuscation
 
@@ -363,32 +345,32 @@ 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.
+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`), which further confirms Brazilian authorship.
 
 ```
 SHA256: 046b7c23ec7b8649bae879c341cbeba120f26e04a89190a8f458e35702fee5e8
 Size:   75 MB (131,575 lines)
 Type:   ASCII text (obfuscated VBScript)
 ```
 
-Key capabilities found after deobfuscating the code:
+After deobfuscation, here's what's inside:
 
 | Capability | Details |
 |-----------|---------|
-| **MD5 Hashing** | Full VBScript MD5 implementation (`equiparmosWT`) - used to build victim machine fingerprint for C2 |
-| **AV Detection** | WMI query: `SELECT displayName FROM AntiVirusProduct` via `SecurityCenter2` |
-| **OS Fingerprinting** | `SELECT Caption, Version, BuildNumber FROM Win32_OperatingSystem` |
-| **Hardware Fingerprinting** | `SELECT SerialNumber FROM Win32_BIOS` + `Win32_BaseBoard` + GPU PNPDeviceID via WMI |
-| **Network Check** | `Win32_NetworkAdapterConfiguration Where IPEnabled = True` |
-| **Process Enumeration** | `Select * from Win32_Process Where Name = 'wscript.exe'` |
-| **DLL Drop + Exec** | Downloads DLL from C2-provided URL, executes via hidden `%APPDATA%\.cmd` batch -> `rundll32.exe` |
-| **HTTP Download** | Uses `WinHttp.WinHttpRequest.5.1` with chunked range requests and retry logic |
-| **Startup Persistence** | `WScript.Shell.SpecialFolders("Startup")` |
-| **Scheduled Tasks** | `Schedule.Service` with `PT10M` execution limit |
-| **Signal Folders** | Creates `propugne.php` and `porfies.php` in `%TEMP%` |
-| **Self-Cleanup** | `DeleteFile` / `DeleteFolder` to cover tracks |
-
-This is the **actual banking trojan loader** -> it fingerprints the system, checks for AV, beacons to its own C2 (separate from Stage 2's C2), receives a DLL URL and entrypoint, then drops and executes the final payload via `rundll32.exe`. The 15-minute sleep (`WScript.Sleep 15 * 60 * 1000`) between C2 retries shows it's designed for stealth over speed.
+| MD5 Hashing | Full VBScript MD5 implementation (`equiparmosWT`) - used to build victim machine fingerprint for C2 |
+| AV Detection | WMI query: `SELECT displayName FROM AntiVirusProduct` via `SecurityCenter2` |
+| OS Fingerprinting | `SELECT Caption, Version, BuildNumber FROM Win32_OperatingSystem` |
+| Hardware Fingerprinting | `SELECT SerialNumber FROM Win32_BIOS` + `Win32_BaseBoard` + GPU PNPDeviceID via WMI |
+| Network Check | `Win32_NetworkAdapterConfiguration Where IPEnabled = True` |
+| Process Enumeration | `Select * from Win32_Process Where Name = 'wscript.exe'` |
+| DLL Drop + Exec | Downloads DLL from C2-provided URL, executes via hidden `%APPDATA%\.cmd` batch -> `rundll32.exe` |
+| HTTP Download | Uses `WinHttp.WinHttpRequest.5.1` with chunked range requests and retry logic |
+| Startup Persistence | `WScript.Shell.SpecialFolders("Startup")` |
+| Scheduled Tasks | `Schedule.Service` with `PT10M` execution limit |
+| Signal Folders | Creates `propugne.php` and `porfies.php` in `%TEMP%` |
+| Self-Cleanup | `DeleteFile` / `DeleteFolder` to cover tracks |
+
+This is the actual banking trojan loader. It fingerprints the system, checks for AV, beacons to its own C2 (separate from Stage 2's C2), receives a DLL URL and entrypoint, then drops and executes the final payload via `rundll32.exe`. The 15-minute sleep (`WScript.Sleep 15 * 60 * 1000`) between C2 retries tells you this thing is patient. It's not in a rush.
 
 ### Stage 3 C2 Protocol - Full Reversal
 
@@ -501,7 +483,7 @@ Size:   47 MB
 
 ### What It Actually Is
 
-After static analysis with Ghidra and `pefile`, this binary turns out to be a **legitimate, unmodified Microsoft Visual Studio 2003 self-extracting cabinet installer**, not a trojanized payload.
+After static analysis with Ghidra and `pefile`, this binary turns out to be a legitimate, unmodified Microsoft Visual Studio 2003 self-extracting cabinet installer. Not trojanized at all.
 
 ```
 CompanyName:      Microsoft Corporation
@@ -514,7 +496,7 @@ InternalName:    sfxcab
 OriginalFilename: sfxcab.exe
 ```
 
-The version info block is **accurate**, this is a genuine `sfxcab.exe` Microsoft SFX installer from the VS 2003 era (compile timestamp: 2005-06-01).
+The version info block checks out. It's a genuine `sfxcab.exe` Microsoft SFX installer from the VS 2003 era (compile timestamp: 2005-06-01). They just bundled it in the ZIP to make the archive look more legitimate, like a real software package.
 
 ---
 
@@ -629,11 +611,11 @@ flowchart TD
 
 ## 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.
+Whoever built this knows what they're doing. The filesystem polling for IPC, the hidden IE COM objects, the chunked downloads, the two-phase C2 with hardware-keyed victim provisioning... this isn't someone copy-pasting from a tutorial.
 
-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()` / `zoMcM()` Chr() wrappers are a nice touch though, avoiding direct `Chr()` concatenation patterns that most AV signatures look for.
+That said, the 96% junk code padding is a double-edged sword. Yeah, it buries the real logic, but it also inflates the VBS to 5.4MB, which is weird enough on its own to be a detection signal. The `UhiSmA1()` / `zoMcM()` wrappers for `Chr()` are smarter. Most AV signatures flag on `Chr()` concatenation chains, so routing through a custom lookup function dodges that entirely.
 
-The Stage 3 C2 protocol is notably sophisticated, a two-phase registration+provisioning model where the server maintains a victim registry keyed by a hardware-derived MD5 fingerprint. The server will only dispatch a DLL URL to fingerprints it recognizes, making it impossible to obtain the final payload without a registered victim machine. At time of writing, the C2 endpoint at `3.135.194.95` is still live and accepting beacons.
+The part that impressed me most was the Stage 3 C2. The server maintains a victim registry keyed by a hardware-derived MD5 fingerprint, and it will only dispatch a DLL URL to fingerprints it recognizes from a prior GET registration. You can't just curl the endpoint and get the payload. At time of writing, the C2 at `3.135.194.95` is still live and accepting beacons.
 
 If you see any S3 links with Portuguese filenames showing up in your inbox... maybe don't click them.
 
