Fake SAP Concur Extensions Deliver New FireClient Malware Variant

December 4, 2025 | 12 min read

Thomas Elkins and Joshua Green

BV Blog card SAP Concur Fire Client Malware 120425 01

The BlueVoyant Security Operations Center (SOC) and Threat Fusion Cell (TFC) team are tracking an adversary luring users into downloading fake Concur browser extensions. The fake browser extension installer contains a FireClient Loader designed to gather host information and send to its command and control (C2) server. If execution succeeds with successful communication to the C2, the loader drops a backdoor BlueVoyant is naming FireClient Backdoor. This backdoor contains functionality to execute remote commands using command console and PowerShell.

What Happened?

While responding to an incident, the BlueVoyant SOC observed a user searching Bing for ‘Concur log in’. This resulted in the user clicking upon a malvertised URL which ultimately directed the user to the suspicious domain sap-concur[.]com. The BlueVoyant SOC then observed the user downloaded a large file (190.48MB) named ‘Concur+Browser+Extension.msi’ from an Amazon AWS URL.

BlueVoyant researchers identified that upon execution, the MSI installer deploys a portable version of Firefox to the directory LOCALAPPDATA\Programs\Firefox. This is an atypical installation path, as legitimate Firefox installations are normally located under ‘C:\Program Files\Mozilla Firefox\’ or ‘C:\Program Files (x86)\Mozilla Firefox\’. The use of the LOCALAPPDATA\Programs directory appears to be a deliberate tactic to evade detection and avoid conflicts with existing Firefox installations. By deploying Firefox in this location, the attacker ensures that this instance operates independently and does not load user profiles or settings from other legitimate Firefox installations.

After installation, the MSI file launches Firefox in headless mode, meaning the browser runs without a visible window, making its execution undetectable to the user. Once Firefox is running, the user’s default browser is opened and redirected to the legitimate Concur website. This tactic is intended to create the illusion that the extension installation was successful, thereby deceiving the user.

Using the open-source tool LessMSI to inspect the malware contents, BlueVoyant researchers discovered that the MSI file included multiple custom actions, including the execution of two distinct PowerShell scripts. Analysis revealed that the first script searches for pkcs11.txt files. Pkcs11.txt are configuration files used to initialize PKCS#11 security modules. PKCS#11 is a cryptographic standard that defines the Cryptoki API for interacting with cryptographic hardware such as hardware security modules (HSMs) and smart cards. These configuration files are typically located within Firefox profile directories. In this case, the PowerShell script deliberately deletes and recreates these files, overwriting their contents with the following entry:

library="C:\\Users\\$userName\\AppData\\Local\\Programs\\Firefox\\Data\\profile\\c3uN.dll"

name=Client Module

By inserting that library= line, the attacker forces Firefox’s Network Security Services (NSS)/PKCS#11 subsystem to register the specified native module for the profile. When that profile is opened (or when NSS initializes), Firefox will attempt to load c3uN.dll from the profile, giving the attacker an opportunity to execute native code inside the Firefox process. This is an abuse of a legitimate extensibility feature (PKCS#11) and while it can be stealthy and effective against some defenses (because it runs inside a trusted application), it is abusing rather than exploiting Firefox itself.

After overwriting the pkcs11.txt file, the PowerShell script contained code to send a POST command to URL hxxps://146.70.253[.]94:8443/work_finish, containing the text ‘"status": "step_1 started”’.

FireClient Loader

BlueVoyant researchers dubbed c3uN.dll as FireClient Loader and preliminary analysis revealed a high entropy level, suggesting the presence of encrypted data. Further investigation by BlueVoyant researchers found that the DLL’s resource section contained two highly suspicious files and made an API call to FindResourceW, indicating that the loader is designed to access and read its embedded resources. Additionally, researchers noted that FireClient Loader disguises itself as a legitimate Mozilla Firefox update file.

BlueVoyant researchers also discovered the loader employs multiple lightweight string obfuscation schemes. Some strings are encoded with a single-byte XOR key, others use a single-byte additive mask (each plaintext byte is the ciphertext minus a constant), and a third variant applies XOR with a key that is incremented by one for each successive byte until the string is fully decoded.

At startup, the FireClient Loader component decrypts a resource from its PE resource section. While the content of that resource does not appear critical to the loader’s immediate behavior, the significance lies in the routine used.

The decryption routine begins by reading the resource into memory using the API function FindResourceW. Once the resource is loaded into memory, the decryption routine reads the first byte contained within the resource, which is stored as the XOR key. It then reads the next sequential bytes which are stored as little endian, indicating the expected size of the resource. Once the key and size of the resource are obtained, the decryption routine reads the first byte of the encrypted resource.

The routine copies the encrypted or decrypted data into a buffer and then “scrambles” it in place using a custom rolling XOR scheme. It starts with a one-byte key, XORs the first few bytes one by one while updating the key with a small formula, then processes the rest, four bytes at a time using a fixed set of math operations to generate a different mask for each byte. After each 4-byte block, the key gets updated. The result is a lightweight but custom obfuscation scheme that disguises the original data without using strong cryptography such as AES or RSA.

Upon decryption, BlueVoyant researchers found the payload begins with the zlib/DEFLATE header (0x78 0x9C), confirming that the data is compressed using zlib. The FireClient Loader then transfers the decrypted buffer to a secondary function that mirrors the behavior of a zlib inflate routine, expanding the compressed data back into its original form. Notably, the loader employs this routing a couple more times, including decrypting the second payload contained within its resource section.

After decrypting the first payload, the FireClient Loader proceeds to its core functionality which was identified after the FireClient Loader decrypted the string ‘Client::DLLMain’.

The FireClient Loader first begins by creating a mutex through the API function CreateMutexW supplying the value ‘ConsoleMutex’. The purpose of this function is to ensure there are no other instances of the program running. If another instance is running, the program exits.

Next, the FireClient Loader gathers information regarding the compromised host including the hosts name, obtaining the MachineGuid via querying the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography’ and obtaining the local IP address of the machine. The returned values are stored into the following variables:

clientIP
clientHostName
domainClientID (MachineGuid)

After the FireClient Loader obtains this information, it compresses the data using the Zlib inflate function. Once the data has been compressed, the FireClient Loader generates a random one-byte XOR key using the API function rand. This key is then used to encrypt the compressed data using the same decryption routine identified above.

Once the information is stored, the FireClient Loader proceeds to attempt communication with its C2 and obtain a unique ID used for communication with the C2 located at URL hxxps://146.70.253.94/api/v1/register/<MachinGuid>. If the server is responsive, it answers with a new ID for the FireClient Loader to use.

After obtaining the new ID, the FireClient Loader proceeds to gather additional information including its file location, the parent process, and the supposed version of the malware itself by querying the local domain name of the compromised machine and enumerating running processes on the compromised host using API functions such as CreateToolhelp32Snapshot, Process32FirstW and Process32NextW. These values are stored as JSON and sent to the C2 at URL hxxps://146.70.253.94/api/v1/clientinfo/<ID>.

After sending process information, the FireClient Loader proceeds to a create a listener on 127.0.0.1 (localhost) over port 9001. Once complete, the FireClient Loader then proceeds to continue communication attempts to the C2 at URL hxxps://146.70.253.94/api/v1/commands/<ID>.

Once the C2 responds with a command, the FireClient Loader extracts its backdoor component from the resource section and injects the binary into Firefox for stealthy execution.

FireClient Backdoor

The FireClient Backdoor is a light weight backdoor whose purpose is to retrieve commands passed via the FireClient Loader. Once the FireClient Backdoor is dropped by the FireClient Loader component, it is stored within file path C:\Users\<user>\AppData\Local\Programs\Firefox\App\Bin\ and saved as UpdateHost.exe.

The FireClient Backdoor begins by connecting to port 9001 on localhost (which was initially established by FireClient Loader). The FireClient Backdoor then proceeds to await communication from the C2 passed via the FireClient Loader.

The C2 server eventually sends Base64-encoded commands, which the FireClient Backdoor decodes and executes through either the command-line interpreter or PowerShell.

From the above image, the server responds with a Base64 encoded command which decodes to ‘ipconfig /all’.

After the command is executed, the FireClient Backdoor is responsible for capturing the response of the command and sending it back to the C2 via the FireClient Loader as Base64 encoded strings to URL hxxps://146.70.253.94/api/v1/cmd/<ID>.

Additionally, the backdoor includes several built-in commands, such as:

Nslookup – used to query DNS servers
Chcp – used to view and change active character encoding
Echo – used to display text on the screen and can redirect output to files
Klist – used to query Kerberos tickets
Copy – used to copy files and can rename copies by specifying a new name

While investigating the FireClient Backdoor incident, BlueVoyant researchers observed the use of ipconfig for network configuration details and nltest for domain controller enumeration.

Tracing It Back

During the investigation of the FireClient Backdoor, BlueVoyant researchers identified an older sample dating back to January 2025. This variant was an earlier FireClient Loader embedded within a DLL named c1uN.dll. Similar to the malware found in the incident handled by our SOC, c1uN.dll was distributed via a large MSI installer (189.94MB) that dropped a portable version of the Firefox application within AppData/Local/Programs and injected the FireClient Loader using previously described techniques.

Further analysis of c1uN.dll and c3uN.dll revealed similar behavior. Both contained a payload stored in the resource section of the binary. Each binary decrypted its payload using an XOR routine combined with zlib inflate compression. In addition to payload storage, both exhibited identical network communication patterns with their respective C2 servers.

BlueVoyant researchers did distinguish that the newer FireClient Loader contained string obfuscation, most likely used to hide its core functionality from EDR and antivirus programs. In addition to creating a file named config.dat (which stored host information), the loader also enumerated running processes and transmitted this data to the C2 server.

Links to GrayAlpha

Analysis of the FireClient malware campaign reveals significant tactical and infrastructural overlaps with GrayAlpha, a cluster with established links to the financially motivated cybercriminal group Obsidian Marauder (a.k.a. FIN7). The connection is assessed with moderate to high confidence based on shared TTPs and infrastructure. The initial infection vector—malvertising spoofing the sap-concur[.]com domain—is a hallmark of GrayAlpha operations, as detailed in RecordedFuture’s June 2025 report. This report explicitly documents GrayAlpha's use of fake browser update sites impersonating legitimate services like SAP Concur since at least April 2024, listing numerous SAP Concur-themed domains (e.g., concur[.]life, sapconcur[.]top) within their infrastructure.

The technical artifacts within the MSI installer provide a direct link between this activity and previously identified GrayAlpha tradecraft. One artifact was observed in samples related from these attacks and linked to a handful of other Concur- and DP World-themed August 2024 samples that also had large file sizes (over 100MB). Furthermore, those August 2024 samples also contained artifacts related to PKCS#11 while also containing a malicious BAT script file. That BAT file was part of a Concur-themed MSIX MaskBat malware sample identified in RecordedFuture's report and is described as part of activity logged in an August 2024 ISC Diary report describing an attack that leveraged a large (179MB) MicroDicom file to establish a backdoor SSH tunnel.

Evidence further suggests these attacks are part of a broader operation. RecordedFuture analysis identified GrayAlpha preferences to leverage business and IT tools for lures like SAP Concur, LexisNexis, Thomson Reuters, 7-Zip, Advanced IP-Scanner. BlueVoyant analysis echoes those findings with lures targeting not only SAP Concur but others as well: DP World (a global supply chain leader), Tiger TMS (a major supplier of hotel management systems), and MicroDicom (medical imaging software).

The evolutionary analysis of the malware itself, from c1uN.dll to the more sophisticated, string-obfuscated c3uN.dll, demonstrates a development cycle consistent with a mature and resourced threat group. This continuous refinement of tools to evade detection aligns with the known behavior of GrayAlpha, an activity cluster noted for professional malware development practices and long-term operation. While the final payload in this instance—the bespoke FireClient backdoor—differs from the NetSupportManager RAT typically deployed in GrayAlpha activity, the sophisticated loader mechanism and the overall attack chain—coupled with the low volume of observed samples—suggest FireClient may represent a new, previously unidentified tool within GrayAlpha's expansive arsenal, potentially reserved for high-value targets or specific operational requirements within the targeted verticals.

The FireClient malware likely represent a sophisticated component of GrayAlpha's evolving toolkit, deployed within a multi-pronged campaign leveraging a variety of trusted software lures.

Conclusion

The FireClient campaign is a unique operation attributed with moderate to high confidence to the GrayAlpha activity cluster. This attack demonstrates a continuous evolution in tradecraft, from the initial malvertising lure to the deployment of a custom backdoor. The abuse of Firefox's PKCS#11 module for stealthy code execution, coupled with lightweight yet effective obfuscation techniques and a development cycle that has refined the loader over time, underscores the technical competency of this adversary. The campaign's focus on trusted business software brands like SAP Concur aligns perfectly with previously documented GrayAlpha tactics, indicating this activity is part of their broader, ongoing strategy to infiltrate target networks.

The identification of the FireClient backdoor suggests this malware may be a specialized component within GrayAlpha's arsenal potentially reserved for high-value targets or even a sign of an attack still in development. Organizations, particularly those in the business services, logistics, and hospitality sectors highlighted in the lures, should treat this threat with high priority. Defensive efforts must focus on monitoring for identified infrastructure, auditing Firefox profiles for malicious pkcs11.txt modifications, and educating users on the risks of downloading software outside of official vendor channels, as this campaign effectively exploits trust in legitimate applications to enable initial access.

BlueVoyant's TFC used this intelligence to distill relevant behaviors and indicators, map them to BlueVoyant's current coverage and detection portfolio to pinpoint potential visibility enhancements. Using those findings, BlueVoyant built and deployed focused hunt packages and tuned detections to proactively surface related activity across environments. The results flow back into playbooks and detection engineering, so each hunt tightens fidelity and accelerates future investigations.

MITRE ATT&CK TECHNIQUES