TL;DR I dive into an SEO poisoning campaign delivering the Bumblebee loader, analyse a trojanised MSI pretending to be NirSoft software, and explore DLL sideloading in depth — including a hands-on look at export forwarding with a malicious
version.dll.
Scrolling through X, I came across this post that mentioned SEO poisoning affecting various software vendors and delivering the Bumblebee loader. This was later reported on by multiple sources, including BleepingComputer. Curious, I wanted to begin unpacking how this attack chain worked to see what I could learn along the way, so I picked a site at random and began the journey. This isn’t a full teardown; a JoeSandbox link with full IOCs and config is halfway down. I mainly wanted to document some curiosities I found along the way.
SEO POISONING
Search Engine Optimisation (SEO) poisoning refers to the manipulation of search engine results to promote malicious websites. As Check Point¹ explains, attackers abuse SEO algorithms — keyword stuffing, typosquatting, and shady backlinks — to push malicious sites higher in search results.
Threat actors are hoping to trick end-users into installing malicious software from these websites. The software often masquerades as the legitimate software the user was searching for and may even install the original software alongside the malicious code.
The software I chose to investigate was Wireless Network Watcher, offered by NirSoft (https://nirsoft.net). Results for ‘wireless network watcher download’ on Google show the legitimate NirSoft website as the first hit and does not show the malicious domain on the first page. DuckDuckGo shows the malicious domain second, and Bing shows the malicious domain third, however these may display differently to others.
Notably, Microsoft’s own Copilot recommends this malicious site as ‘official’ — a stark reminder of how even AI tools can be misled by poisoned results.
Browsing to this URL in a virtual machine displays a website almost identical to the original. Hovering over the download button shows that this file will be downloaded from hxxps://hub28[.]shop
Wireless_Network_Watcher.msi
Clicking ‘download’ gives us a file named Wireless_Network_Watcher.msi with a SHA256 hash of 8F424F4D327CB1032A0D6679D6D42AC44614131ECABD544244D03808C8B32E30. As expected, we see a wall of red on VirusTotal.
MSI files are structured Windows Installer packages, unlike .exe files which are general executables that can run any code, including custom installers. Windows uses the Windows Installer service to execute .msi files. Various tools exist to inspect the structured contents of an .msi file, such as Orca and LessMSI to name a few.
The Extract Files section shows us that there are actually three files contained within. The table view will also show additional information such as CustomAction and InstallSequence — this information is sometimes relevant if threat actors have hidden additional commands.
If your goal is to simply dump the packaged contents, this can be done with LessMSI or even with 7zip.
Extracting these three files and recording their hashes gives us the following information:
PS C:\Users\bfake\Downloads\research\SourceDir\ApplicationInstallationFolder_11 > Get-ChildItem -Path .\ -File | ForEach-Object { Get-FileHash -Path $_.FullName -Algorithm SHA256 } | fl
Algorithm : SHA256
Hash : 473D17E571D6947CE93103454F1E9FE27136403125152B97ACB6CAD5CC2A9AC7
Path : C:\Users\bfake\Downloads\research\SourceDir\ApplicationInstallationFolder_11\icardagt.exe
Algorithm : SHA256
Hash : A09923899B318848D44DC706CCC1D3489A383B9AF0921351134D14A152A7925B
Path : C:\Users\bfake\Downloads\research\SourceDir\ApplicationInstallationFolder_11\version.dll
Algorithm : SHA256
Hash : 885DD208CD794FF755E15DE13CA2918B2A60BFB98D4449216E774929BB21A583
Path : C:\Users\bfake\Downloads\research\SourceDir\ApplicationInstallationFolder_11\WNetWatcher.exe
DLL Sideloading (version.dll)
DLL Sideloading, as explained by VMRay², “(also known as DLL hijacking or DLL search order hijacking) is an attack method where a malicious DLL is placed in a location where a legitimate application expects to find a trusted DLL. When the application runs, it mistakenly loads the attacker’s DLL instead of the legitimate one.” The order in which the system attempts to load DLL’s is hardcoded in Windows.
WNetWatcher.exe is the legitimate software that the victim searched for. Executing the .msi file will legitimately install this application and it will function as expected, however the malicious component to this sample lies in the first and second files (icardagt.exe and version.dll).
icardagt.exe If you recognise the executable name or you’ve searched the SHA256 in VirusTotal, you might have noticed that this is a legitimate executable present on almost every Windows host and is signed by Microsoft. Searching the web, you will see that this is the Windows CardSpace User Interface Agent — an older Microsoft identity solution.
version.dll You might recognise this filename from C:\Windows\System32 but make no mistake, this is not the same file. Searching this SHA256 hash in VirusTotal gives us another red wall of detections.
DLL Sideloading
Why then is icardagt.exe dropped to the system when the .msi file is launched? The answer is DLL sideloading. The threat actor needs a way to have the malicious code present in version.dllto be loaded and executed on the target system. Interestingly, both _WNetWatcher_ and _icardagt_ are vulnerable to DLL sideloading with the same .dll (version.dll).
When the .msi installer is executed, both executable files will be launched. There are slight differences in the manner of which they are executed as indicated by their InstallExecuteSequence. It is more likely that version.dll will be DLL sideloaded into icardagt.exe as this process will run with SYSTEM privileges.
For the full IOC’s and configuration of this Bumblebee sample, please check out this awesome sandbox result from JoeSandbox: https://www.joesandbox.com/analysis/1694844/0/html
DLL Sideloading (Research — Side Quest turned Main Quest)
I spent a lot of time at this point actually doing some DLL sideloading myself, both as a refresher and also as a point of learning from an attacker perspective.
Identifying the sideloading opportunity
By far the easiest way to do this is to utilise the HijackLibs project, which has already pre-identified the issue within icardagt.exe.
For the sake of learning ourselves, we can fire up Procmon from SysInternals and filter for both the process name and the target dll. On the first line, we see icardagt.exe launched from C:\Users\bfake\Downloads\research\SourceDir\ApplicationInstallationFolder_11.
We can see above that version.dll is loaded from C:\Windows\System32\version.dll. Looking at the MS documentation, we identify that if we place our own version.dll in the folder from which the application loaded, the application will load our dll before searching System32.
Building a proxy DLL I tried and failed at this point to build a small c application that pops a MessageBox when the .dll is sideloaded, similar to this blogpost, but not even the GPT’s could save me with this task. My red team friends will probably find it amusing, but what I learned here, however, was actually really interesting to me. I learned the art of DLL export forwarding.
When I first created a version.dll with just a DllMain that popped a MessageBox, the target binary (icardagt.exe) loaded the DLL, but failed silently — the message box never appeared, and the sideloading seemed broken.
The original version.dll (in System32) exports multiple functions, and the target binary imports some of these directly (e.g., VerQueryValueW, GetFileVersionInfoW, etc.). If my fake version.dll did not implement or forward these required exports, any calls to them would crash or silently fail — preventing the process from fully initializing and my DllMain from running reliably.
The Fix: Export Forwarding
By using #pragma comment(linker, "/export:...") directives to forward those required exports to the real version.dll in C:\Windows\System32 as implemented in the Spartacus code (mentioned below), I ensured the host process could resolve its function calls as expected. This allowed the process to continue running normally — and my malicious DllMain to execute without crashing the process.
Key Takeaway
DLL sideloading requires a valid export table if the host binary expects certain functions. Simply defining
_DllMain_is not enough — the DLL must either implement or forward the required exports, or the host binary may fail to load or execute correctly.
**Our Final ‘Malicious’ DLL
**Utilising the Spartacustool from Accenture, found here on GitHub, I was able to build a DLL that both forwards the exports of the legitimate version.dll and spawns a messagebox as intended when loaded and executed by icardagt.exe.
I needed to slightly modify the .vcxproj file to match my environment, and then built with the following command and copied with cp to the target directory
msbuild version.sln /p:Configuration=Release /p:Platform=x64
cp version.dll C:\Users\bfake\Downloads\research\SourceDir\ApplicationInstallationFolder_11
Executing the target process with .\icardagt.exe then triggers the DLL sideload, loading in our ‘malicious’ version.dll and we spawn a MessageBox, indicating our custom code was executed:
For a “why not”, a bit more fun and perhaps to drive home the point, I used msfvenom to create a reverse shell payload on a different virtual machine, then modified version.dll to contain this shellcode. When I ran icardagt.exe again, the shellcode injected into svchost.exe and I received a reverse shell to my attacker machine, note that this is being executed with SYSTEM privileges.
Hope you enjoyed this part malware analysis, part blue team, part red team article. For blue teamers and threat hunters, I recommend checking out the Sigma rule found on the HijackLibs website. Be careful with what you click on :)
