Executive Summary

Recently, JUMPSEC’s DART (Detection and Response Team) detected a phishing email targeting a client environment.

The email, written in Thai and containing a MediaFire download link, was identified as suspicious by an incident responder and we kicked off an investigation. Since then, we have established infrastructure to track the threat actor, analysed the novel payload in detail, and identified several IoCs below.

Analysis of the downloaded file revealed previously undocumented techniques used in the delivery chain for the Remcos implant. Most notably, in the delivery chain the loader brackets payload execution between `ipconfig /release` and `ipconfig /renew`. This network ‘blackout’ temporarily disrupts connectivity while the second-stage payload executes, creating a short-lived blind spot that prevents network-based tooling from observing key stages of execution. The crypter family also has its own story, as it currently has no known public attribution.

We track this cluster as “BlackToad”, likely an affiliate of the broader Nigerian e-crime ecosystem that Unit 42 catalogues under “SilverTerrier”, with a crypter, hosting profile, and targeting lures that do not match any previously named SilverTerrier sub-cluster.

An overview of the malware infection chain from an initial phishing to C2.

Phishing email

The phishing email used a financial payment-slip theme, as invoice or payment requests are routine, time-sensitive, and likely to prompt a reaction. In this case, the lure was delivered as an image-based email where the image itself contained a malicious link to an external file-hosting service, allowing the message to appear benign while directing the user to the externally hosted malware.

Figure 1 – The original phishing email.

WinRAR SFX Lure

Upon downloading the file, we see that it is already trying to hide itself by doing some simple file extension masquerading. In Windows machines, by default the file extensions for known file types are hidden, this means that if you add another extension before the real one, files can seem more legitimate than they are. Below, we see the binary having two extensions, “.pdf.scr” – the .scr extension is the malicious one, as .scr (screen saver) files can still be executed the same as .exe files.

Figure 2 – .pdf.scr file extension masquerading 

The binary itself is a WinRAR SFX executable, which is a Self-Extracting archive, when executed, they extract and execute other files embedded within them.

Figure 3 – DetectItEasy report showing the SFX presence 

If we open the .pdf.scr with WinRAR itself, we can see the embedded executables and scripts. Most of these files are just there for show, they don’t actually do anything or have any part in the infection chain.

Figure 4 – Embedded scripts and executables – most are unused 

The VBS Loader

The WinRAR SFX binary loads the “flvs.vbe” script, and as much as vbe usually means encoded, in this case it was just plaintext. However, it was still obfuscated.

The obfuscation was fairly simple to overcome, as the main “Naruto” and “Maynama” calls are just “Chr” calls – and the dead local variables inside of the “Naruto” call are all decoration. The amount of the “Naruto(193)” calls tell us that the only “obfuscation” here is just filler comments and junk function calls filling up most of the script to appear advanced.

Figure 5 – NOP instructions & ESET comment

Stripping out all of the junk function calls, the script collapses to 40 or so lines of real code and we can see a callout to the endpoint security vendor ESET (sorry guys) and the malicious payload execution is in the `XCoX.Run` call.

Figure 6 – Stage 1 VBS executing .das file

Before this call, the “Maynama” variable was building the “cmd.exe” string character by character so that the literal string does not appear in the file. The XCoX.Run function then finally executes the .das file with CMD.

The AutoIt Payload

Looking at the two files that are executed in the script, the “xbkjm.xls” is actually just the AutoIt3 interpreter itself, renamed to a .xls extension, the SHA256 hashes match, so the malware is basically using the legitimate AutoIt3 interpreter to execute the script.

The “wnkfmvql.das” is the actual script that runs, but among this file are two other files that came from the SFX archive, these are “oquhestmf.mp3” and “diniuvw.ikp”. Together, these three files form the body of a custom AutoIt crypter.

First up, the “wnkfmvql.das” is a heavily pumped file, with a total size of 88MB, using a basic Python script which strips #cs/#ce block comments, we can extract the real code behind the garbage and get a 65KB script, below you can see the before and after of the script.

Figure 7 – Before cleaning

Figure 8 – After cleaning

As we can see, the cleaned version is already showing us some initial functionality of the script, including killing itself if the computer’s username is “John”, among other anti-analysis techniques.

Following this, the next thing it does is read a configuration file, after the AV and sandbox checks, we see this line:

Figure 9 – Several IniRead calls to the config file

We then see several `IniRead` calls against that file,  “oquhestmf.mp3” is the script’s configuration file. AutoIt’s `IniRead` function doesn’t care what the file is called, it parses whatever it is pointed at. Opening the file confirms this, as the first 600 lines are padding, but buried in this mess is a single INI section that the script actually reads.

Figure 10 – The INI config itself

Reading this top down gives you an idea of how the operator wired the chain together. AuEx and ExE_c are the two filenames we already know, the script and the AutoIt interpreter. `RP` (probably meaning “Real Payload”) points to diniuvw.ikp, which we’ll dig into next. `stpths=%userprofile%` and `Dir3ctory=sorq` tells the stages where to drop a persistent copy. `Key=WindowsUpdate` is the Run-key which is registered in the registry, and finally, `H-Hord` is a 60 byte double hex encoded blob that was originally going to seed the payload encryption (more on this in a moment).

The `diniuvw.ikp` file is the interesting one, opening it in Sublime Text just shows what seems to be invalid hex:

Figure 11 – diniuvw.ikp file, containing invalid hex

However, checking the cleaned AutoIt script once again reveals why this is. The characters are replaced by the script in the `MainPE` function.

Figure 12 – StringReplace function

Note the commented `_Crypt_DecryptData` function, it seems like the operator commented out the actual decryption call. This could mean the crypter itself comes with it disabled, or there is an option to disable it if this is a crypter that is sold online.

Either way, decoding the PE file is easy with a simple Python script:

Figure 13 – Decoding the PE file with a simple Python script

Using DetectItEasy, we can see the decoded binary is a 509KB native file, not packed or obfuscated, making config extraction easy.

Figure 14 – Viewing the decoded Remcos Pro implant in DetectItEasy

By viewing the strings in the binary, we can clearly see multiple mentions of “Remcos” along with “BreakingSecurity.net” which is the site where Remcos is sold.

Figure 15 – String entries mentioning Remcos

Decrypting the Remcos config 

Following the decoding of the PE file, we can load the Remcos binary into IDA, and hunt for the function that decrypts the config which is embedded in the resources section of the binary, this is simple to find as we can just search strings for “SETTINGS” and find the cross referenced function that handles loading the settings resource.

Figure 16 – The settings loader function

Following that, the settings/config is decrypted using RC4 only. The function for that is shown below

Figure 17 – Decrypting the settings/config resource using RC4 with a fixed key

With this information, the key length and the key itself which we obtain from the settings resource, we can again use a simple Python script to decrypt the config, and read it in plaintext, below, the “settings.bin” is the encrypted resource, and the “settings.dec” is the decrypted version (the first byte 0x77 is the key length (119 in decimal), and the 119 bytes after it is the key itself.

Figure 18 – The config resource before decryption

After running our Python script to decrypt the config, we can clearly see the C2’s, the mutex, and more mentions of Remcos

Figure 19 – The decrypted config, clearly showing the ddns.net, duckdns.org, and ddnsfree.com C2’s along with the mutex.

The Network Blackout 

Rewinding back to the cleaned flvs.vbe script, the most interesting part of this script is towards the bottom of it.

Figure 20 – Cleaned and annotated flvs.vbe script, where the “network blackout” happens

The script uses char encoding to build out “cmd.exe”, if we convert the numbers from decimal to ASCII, we see it converts directly to “cmd.exe”, this is done to evade static detection of “cmd.exe” being used.

Figure 21 – Decimal values converted to ASCII, displaying “cmd.exe”

After building the “cmd.exe” and putting it into the “Monyaka” variable, the script then uses XCoX.Run to execute `ipconfig /release`, which is used to disconnect from the internet, then execute the AutoIt script using the AutoIt3 Interpreter. This technique has been observed in at least one prior NanoCore RAT campaign.

This works because cloud reputation lookups need to phone home and are unable to do so while the internet is down. The most suspicious actions all happen with no network connection, and by the time the ipconfig /renew runs, the script execution is finished.

Tracking the Threat Actor 

By extracting the self-signed TLS certificates that were embedded in the Remcos configuration, we verified that both certificate fingerprints have not been observed or any publicly scanned host using Censys and Shodan. Remcos’ C2 server most likely only completes TLS handshakes with victims that perform the Remcos auth sequence.

However, the config does show us three separate C2 domains, all on different Dynamic DNS providers, using the same port:

All three domains resolve to the same IPv4 address. This is a redundancy measure, if one provider suspends the domain, the remaining two can maintain C2 connectivity.

Pivoting on these three domains reveals two additional samples communicating with the same infrastructure, both submitted to VirusTotal on 07-05-2026.

IMG00090878900.pdf.scr & slip002030002002.JPG.scr both use the same extension masquerading technique seen in our sample, and the latter sample shared the “SLIP” prefixed naming convention, confirming this is an active multi-target campaign rather than an isolated incident.

The IPv4 address itself belongs to AS29465 (MTN Nigeria Communication Limited), geolocation data indicates this is in Onitsha, Anambra State, Nigeria. MTN Nigeria is a mobile carrier, not a hosting provider. This indicates that the actor is not renting server infrastructure but instead running the C2 behind their own mobile internet connection, which directly exposes their potential physical location. The C2 likely uses port forwarding to do this.

VirusTotal’s passive DNS data confirms the infrastructure is actively rotating across MTN Nigeria’s IP pool while remaining in the same geographic area.

The connection with these IP addresses is clear when viewing the relations in VirusTotal, once again, we can see the three domains and a communicating file that matches the name of our original sample.

Figure 22 – VirusTotal relations showing the 102 IP being connected to this campaign

Further Investigation & Cluster Attribution 

While the operator sits within the broader Nigerian e-crime ecosystem that Unit 42 tracks under the name “SilverTerrier”, the clusters cryper, network blackout technique, travel/hospitality-like targeting, and Pfcloud bulletproof hosting do not match any previously published SilverTerrier sub-cluster, nor any other publicaly documented Nigerian Remcos clusters reviewed during this research.

VirusTotal passive DNS for the main 197.210.55.170 IP address shows one historical resolution: atelilian99.ddns.net – flagged 15/92 on 11-08-2023. On its own, this overlap is weak because MTN Nigeria assigns dynamic IPs that get recycled across subscribers. However, the connection gets reinforced when we look at the Pfcloud hosting IP (45.156.87.226), which has resolved to our operators three domains in early May. We can see that they also shared that server with crazydns.bumbleshrimp.com – a domain which VirusTotal data shows communicating files as primarily focusing on utilising travel and hospitality-themed lures.

Figure 23 – VirusTotal relations showing multiple travel and hospitality-themed lures

This targeting profile matches a campaign documented by Agoda Engineering as “BoredFluff”, which tracked GuLoader-to-Remcos infections targeting hotel staff through fake guest enquiries. That same report lists both atelilian99.ddns.net & peurnick24.bumbleshrimp.com as BoredFluff C2 infrastructure, and now we see subdomains on the same providers co-hosted with our operators’ domains on the same bulletproof hosting node. The shared infrastructure is most likely a deliberate choice, not a coincidence of dynamic IP rotating.

On the basis of these IOCs found during the intial analysis and further investigation, we are tracking this cluster as “BlackToad”. The name combines the signature network blackout technique with the toad themed C2 naming conventions.

Indicators of Compromise 

File Hashes:

C2 Domains/IPs/Ports:

TLS Certificate Fingerprints:

Remcos Configuration:

Registry Entries:

Persistence Directory:

Conclusion 

This intelligence positions this campaign as a likely continuation or affiliate of the BoredFluff cluster. What makes this sample worth documenting is not the payload as Remcos is well-understood, but the delivery around it. The ipconfig /release network blackout is a simple yet effective technique to evade cloud-based detection mechanisms and costs the operator only two lines of VBS scripting. The fact that it works by design rather by an exploit or something else makes it difficult to distinguish from routine network troubleshooting.

The AutoIt crypter wrapping the payload is similarly novel. The [S3tt!ng] INI schema, substitution-hex encoding scheme and 88 MB comment wall obfuscation do not match any publicly known loader family, and the commented-out _CryptDecryptData calls suggest the crypter supports RC4/RC2 encryption but the operator chose not to enable it.

For defenders, the most actionable takeaway is the infrastructure pattern. Provided defender block ASN ranges used by these operators, a Nigerian operator on a mobile ISP that is routing traffic through Pfcloud bulletproof hosting is unlikely to be able to gain initial access. The strongest tracking indicator is the Remcos license hash (which is in the IOC listings below), persists across every payload built with that license and is easy to extract from the decrypted config. Organisations that encounter samples matching these indicators should check for activities that are consistent with Remcos capabilities: Keylogging, Credential Harvesting, Clipboard Monitoring, and File Exfiltration.

Detect, respond, analyse and share