Short Summary:
Proofpoint researchers uncovered a sophisticated malware campaign named “Voldemort,” which targets organizations globally by impersonating tax authorities. The campaign employs unique techniques, including the use of Google Sheets for command and control, and is assessed to be espionage-oriented rather than financially motivated.
Key Points:
- Campaign named “Voldemort” identified by Proofpoint researchers.
- Targets organizations worldwide by impersonating tax authorities from various countries.
- Utilizes a novel attack chain with unusual command and control methods, including Google Sheets.
- Malware is a custom backdoor capable of intelligence gathering and delivering additional payloads.
- Over 20,000 messages sent, impacting over 70 organizations globally.
- Threat actor likely an advanced persistent threat (APT) focused on espionage.
- Employs techniques commonly seen in both cybercriminal and espionage activities.
- Defense recommendations include restricting access to external file sharing services and monitoring suspicious activity.
MITRE ATT&CK TTPs – created by AI
- Command and Control (T1071)
- Using Google Sheets for command and control communication.
- Exfiltration Over Command and Control Channel (T1041)
- Exfiltrating data through Google Sheets.
- Credential Dumping (T1003)
- Collecting information about the system and users.
- Execution through API (T1203)
- Executing commands via Google Sheets API.
- Abuse Elevation Control Mechanism (T1548)
- Using legitimate software (CiscoCollabHost.exe) to execute malicious DLLs.
Key findings
Proofpoint researchers identified an unusual campaign delivering malware that the threat actor named “Voldemort”.
Proofpoint assesses with moderate confidence the goal of the activity is to conduct espionage.
The activity impersonated tax authorities from governments in Europe, Asia, and the U.S. and targeted dozens of organizations worldwide.
The ultimate objective of the campaign is unknown, but Voldemort has capabilities for intelligence gathering and to deliver additional payloads.
Voldemort’s attack chain has unusual, customized functionality including using Google Sheets for command and control (C2) and using a saved search file on an external share.
Overview
In August 2024, Proofpoint researchers identified an unusual campaign using a novel attack chain to deliver custom malware. The threat actor named the malware “Voldemort” based on internal filenames and strings used in the malware.
The attack chain comprises multiple techniques currently popular within the threat landscape as well as uncommon methods for command and control (C2) like the use of Google Sheets. Its combination of the tactics, techniques, and procedures (TTPs), lure themes impersonating government agencies of various countries, and odd file naming and passwords like “test” are notable. Researchers initially suspected the activity may be a red team, however the large volume of messages and analysis of the malware very quickly indicated it was a threat actor.
Proofpoint assesses with moderate confidence this is likely an advanced persistent threat (APT) actor with the objective of intelligence gathering. However, Proofpoint does not have enough data to attribute with high confidence to a specific named threat actor (TA). Despite the widespread targeting and characteristics more typically aligned with cybercriminal activity, the nature of the activity and capabilities of the malware show more interest in espionage rather than financial gain at this time.
Voldemort is a custom backdoor written in C. It has capabilities for information gathering and to drop additional payloads. Proofpoint observed Cobalt Strike hosted on the actor’s infrastructure, and it is likely that is one of the payloads that would be delivered.
Campaign details
Volume and targeting
Beginning on 5 August 2024, the malicious activity included over 20,000 messages impacting over 70 organizations globally. The first wave of messages included a few hundred messages daily but then spiked on 17 August with nearly 6,000 total messages.
Messages purported to be from various tax authorities notifying recipients about changes to their tax filings. Throughout the campaign the actor impersonated tax agencies in the U.S. (Internal Revenue Service), the UK (HM Revenue & Customs), France (Direction Générale des Finances Publiques), Germany (Bundeszentralamt für Steuern), Italy (Agenzia delle Entrate), and from August 19, also India (Income Tax Department), and Japan (National Tax Agency). Each lure was customized and written in the language of the authority being impersonated.
Proofpoint analysts correlated the language of the email with public information available on a select number of targets, finding that the threat actor targeted the intended victims with their country of residence, rather than the country that the targeted organization operates in, or country or language that could be extracted from the email address. For example, certain targets in a multi-national European organization received emails impersonating the IRS because their publicly available information linked them to the US. In some cases, it appears that the threat actor mixed up the country of residence for some victims when the target had the same (but uncommon) name as a more well-known person with a more public presence.
Emails were sent from suspected compromised domains, with the actor including the real domain of the agency in the email address. For example, an email impersonating the U.S. IRS appeared to be:
From: Federal IRS <no_reply_irs[.]gov@amecaindustrial[.]com>
Other sender domains included:
tblsys[.]com
joshsznapstajler[.]com
ideasworkshop[.]it
Emails impersonating HRMC and DGFIP.
The threat actor targeted 18 different verticals, but nearly a quarter of the organizations targeted were insurance companies. Aerospace, transportation, and university entities made up the rest of the top 50% of organizations targeted by the threat actor.
Vertical targeting breakdown of Voldemort malware email campaigns.
Attack chain
The messages contain Google AMP Cache URLs that redirect to a landing page hosted on InfinityFree, or later in the campaign, linking directly to the landing page. The landing page includes a “Click to view document” link that, when clicked, checks the User Agent of the browser.
InfinityFree hosted landing page with a background User Agent check, with popup asking the victim to open Windows Explorer after clicking the “View Document” button.
If the User Agent contains “windows”, the browser is redirected to a search-ms URI, pointing to a TryCloudflare-tunneled URI ending with .search-ms, prompting the victim to open Windows Explorer; however, this query is never visible to the victim, only the resulting popup is. It will also load an image from a URL ending in /stage1 on an IP address running the logging service pingb.in to log a successful redirect. The use of the pingb.in service allows the threat actor to gather additional browser and network information about the victim.
HTML Redirect Logic embedded on landing page.
If the User Agent does not contain “windows,” the browser will be redirected to a Google Drive URL that is empty, and it will load an image similarly from the pingb.in IP, but with the URL ending in /stage0. This allows the threat actor to track browser and network details for those that did click the button but were not served any malicious content.
If the victim accepts opening Windows Explorer, Windows Explorer will silently perform a Windows Search query as directed by the linked .search-ms file. The .search-ms file is never downloaded or displayed to the user but instead abuses the file format which will be discussed in the “Abusing the Saved Search File Format” section of this blog. This will result in displaying a Windows shortcut file (often referred to as a LNK because of the file extension it uses) or, later in the campaign, a ZIP file containing a similar LNK in Windows Explorer using a filename related to the original email lure. This LNK or ZIP is hosted on the same TryCloudflare host, but in another WebDAV share, pub. Notably, the file looks like it is hosted directly in the Downloads folder on the recipients’ host as opposed to the external share. It also uses a PDF icon to masquerade as a different file type. These two techniques may lead the recipient to believe it is a local PDF file, which may increase the likelihood of clicking on the content.
Shortcut masquerading as a PDF hosted on an external WebDAV in a way that makes it appear as if it were in the user’s local Downloads folder.
If the LNK is executed, it will invoke PowerShell to run Python.exe from a third WebDAV share on the same tunnel (library), passing a Python script on a fourth share (resource) on the same host as an argument. This causes Python to run the script without downloading any files to the computer, with dependencies being loaded directly from the WebDAV share.
Security notification displayed to the user when the LNK is opened.
The executed Python script is specific to the original lure, depending on language and geographic targeting. Interestingly, it begins by checking the operating system, even though this check was already done on the landing page. If the script detects a Windows environment, it proceeds with specific actions. No functions are executed on other operating systems, however. These actions on Windows include:
Collecting information about the computer using the Python function platform.uname(), including the computer name, Windows version information, and CPU information.
Sending data as base64 in a URL via a GET request to the same pingb.in IP as on the landing page, but with /stage2-2/ in the URL, for example:
hxxp://83[.]147[.]243[.]18/p/7c31e3ebfb77ead34ea71900b1b0/stage2-2/[base64 string]
Threat actor’s pingb.in web interface.
PCAP of pingb.in traffic.
The GET request does not contain any other data except the standard headers automatically generated by the Python HTTP library. It then downloads a decoy PDF, relevant to the targeted country, from OpenDrive (a file hosting service like OneDrive) and opens it.
Decoy PDF impersonating DGFIP.
The script collects the computer name, username, domain, and again the result of platform.uname(), storing it as a base64 string and posting it as described above but this time with /stage1-2/ in the URL (despite being executed after stage2-2).
It downloads a password-protected ZIP file called test.png or logo.png from OpenDrive saves it as %localappdata%MicrosoftWindowstest.zip or logo.zip, and extracts the contents, CiscoCollabHost.exe and CiscoSparkLauncher.dll, using the password “test@123.”
It executes the file CiscoCollabHost.exe and deletes the downloaded ZIP as the final action of the Python script. CiscoCollabHost.exe is a legitimate executable related to WebEx and is used to side-load the DLL named CiscoSparkLauncher.dll
CiscoSparkLauncher.dll, which has the exported DLL name “Voldemort_gdrive_dll.dll” or, later in the campaign, “Voldemort_gdrive_c.dll”, is detailed in the Malware Analysis section of this report. Proofpoint tracks this payload as Voldemort.
While the URLs to the respective landing pages have been static, the hostname for the TryCloudflare tunnel used in the initial seach-ms query and subsequent WebDAV shares has changed frequently, often daily. Even though the hostname has changed, the structure of the WebDAV shares has been the same:
public – contains the .search-ms files.
pub – contains the LNK or later ZIP files
library – contains the Python distribution and dependencies
resource – contains the Python scripts
Voldemort is a backdoor with capabilities for information gathering and can load additional payloads. A full technical breakdown of the malware and related payloads is available below.
APT activity with cybercrime vibes
Interestingly, the actor used multiple techniques that are becoming more popular in the cybercrime landscape, which—in addition to the volume and targeting that is also more aligned with ecrime campaigns—is unusual. While the lures in the campaign are more typical of a criminal threat actor, the features included in the backdoor are more similar to the features typically found in the tools used for espionage.
Threat actors abuse file schema URIs to access external file sharing resources for malware staging, specifically WebDAV and Server Message Block (SMB). This is done by using the schema “file://” and pointing to a remote server hosting the malicious content. This technique is observed with increasing frequency from cybercriminal threats including IABs.
Proofpoint researchers recently observed an uptick in the abuse of Cloudflare Tunnels, specifically the TryCloudflare feature that allows an attacker to create a one-time tunnel without creating an account. Tunnels are a way to remotely access data and resources that are not on the local network, like using a virtual private network (VPN) or secure shell (SSH) protocol. Each use of TryCloudflare Tunnels generates a random subdomain on trycloudflare[.]com, for example ride-fatal-italic-information[.]trycloudflare[.]com. Traffic to the subdomains is proxied through Cloudflare to the operators’ local server. Notably, with Voldemort activity, the threat actors used just four unique TryCloudflare tunnels over the month of August 2024, as opposed to creating a new tunnel for each wave of messages, as Proofpoint has observed with other malicious activity clusters. Unlike previously observed activity, in this campaign the Python dependencies were not downloaded directly on the host and were loaded from the WebDAV share instead.
Abusing the Saved Search File Format
In general, threat actors abuse the Windows search protocol (search-ms) in order to locally, in a folder, display files hosted on a remote machine. This technique is often used to deploy various remote access trojans (RATs). Search-ms allows applications, JavaScript, or HTML to display remote files that look like trusted content directly on a host. Proofpoint has observed multiple cybercrime threat actors – from commodity malware users to initial access brokers (IABs) – leverage this technique. The Voldemort malware campaign is using the rarely observed technique of the saved search file format (.search-ms) which lets the actor save a search query as a file on the WebDAV share.
Normally when a threat actor abuses the Microsoft search protocol, the URI includes the host on which the search is going to be performed, the query that is going to be executed, and the display name of the search. In this case, the search-ms URI contained just the display name and a subquery for a URI on a WebDAV share that also ended in .search-ms. For example:
Search[:]displayname=Downloads&subquery=%5C%ways-sms-pmc-shareholders[.]trycloudflare.com@SSL%5Cpublic%5CSA150_Notes_2024.search-ms
Even more puzzling, when the query was opened in Windows Explorer, the user was instead directed to a search for an .lnk or .zip file without any indication that a file was opened or something similar—the query was performed silently. Moreover, when Proofpoint researchers manually inspected the location of the file, it was no longer in the public share. Instead, the displayed file resided in the pub share on the same host. Upon investigation, researchers discovered virtual folders that, if opened, resulted in the same experience as opening the search URI. The virtual folders were actually the .search-ms files used in the search URI.
Manual browsing of WebDAV share via browser.
These .search-ms files turned out to be XML files of the type “Saved Search File Format.” Typically, these files are created when performing a search in Windows and manually saving the search, for example, by right-clicking in the search window and selecting “Save search.”
Searching locally and saving the search to create a .search-ms file.
Resulting .search-ms file after saving the search.
Saving a search will create a .search-ms file in the saved search folder on a Windows host. However, the extension is hidden, even if the option to view extensions for known file types is selected. This is similar to how a user does not typically see the .lnk extension for Windows shortcuts. The functionality of a saved search is intended for situations where someone performs the same searches regularly and wants to easily repeat them with the results presented in a consistent manner. Similar to a search: or search-ms: URI, this will perform the same search again. But with the .search-ms file, a user can also specify how they want Windows Explorer to display the results more specifically. If abused, .search-ms files can more effectively hide elements that would otherwise indicate that the victim is not in a folder on their local machine.
Here are some interesting parts from one of the .search-ms files the actor was using:
Manually editing a file to specify, among other things, that the view should just be shown as “Downloads.”
<viewInfo iconSize=”32″ stackIconSize=”0″ displayName=”Downloads” autoListFlags=”0″>
Defining a narrow view in Windows Explorer to more effectively hides artifacts that could show what share the file is hosted on.
<column viewField=”System.ItemFolderPathDisplayNarrow”/>
A search condition only showing the malicious file on the share.
<condition type=”leafCondition” property=”System.FileName” operator=”starts with” propertyType=”string” value=”ABC_of_Tax.zip” localeName=”en-US”>
Specifying the path to the folder or share that should be searched. The GUID represents a network location.
<include path=”::{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}invasion-prisoners-inns-aging[.]trycloudflare[.]com@SSLpub” attributes=”1887437133″/>
Author type containing the display name of the Windows user that created the .search-ms file.
<author type=”string”>test</author>
Malware analysis
The malware is executed by utilizing CiscoCollabHost.exe, which is vulnerable to DLL hijacking. The executable attempts to load a DLL called CiscoSparkLauncher.dll which is kept in the same directory as the executable, but in this case, is malware. The only requirement is the DLL has the correct name and exports a function called SparkEntryPoint.
This SparkEntryPoint starts with a sleep mechanism of roughly 5 –10 minutes with a jitter amount to try and evade sandboxes that run for short periods of time.
Calculating sleep time.
The malware then has a routine to dynamically invoke APIs that is relatively unique. To resolve functions and call them, the malware passes a DLL handle, a callback to a function, and the arguments to the function it’s trying to call.
Call to resolve and invoke a function.
The callback is a function that decrypts a string that is called in the function invoking the Windows APIs.
Stub to call the resolved function and preserve the arguments on the stack.
Cobalt Strike shellcode commonly uses this technique, wherein the resolver resolves the function it’s looking for as well as calling it.
To decrypt strings, the malware relies on an algorithm that looks very similar to XTEA but is unrolled to remove the loops with the block decryption.
Decryption algorithm.
The unrolled algorithm can be seen below:
Unrolled algorithm.
During the analysis, Proofpoint found the algorithm was nonstandard and therefore we used emulation methods to decrypt the embedded strings, which we will detail below.
Utilizing the fantastic tool Dumpulator by MrExodia, we can create a dump of the malware in x64dbg and use that as custom tooling within a Python environment.
Python code showcasing Dumpulator usage to decrypt strings.
This allows us to call functions within the malware given they are relatively simple and do not rely on Windows internals. Great candidates for this are functions that do not make any other calls and just translate data.
The Python script implements string decryption using emulation, and at the end we can read the decrypted string from the allocated memory to which we wrote the encrypted contents. Running this code over the entire data section of the DLL gives us all the decrypted strings within the sample:
Decrypted strings.
With API calls resolved, the malware continues by decrypting its own configuration. Unlike other malware that stores a direct reference to the encrypted configuration, this malware contains a string that it searches for in its own file, more commonly referred to as “egg hunting” — the egg being “g00” in this case.
Start of encrypted configuration denoted by “g00”.
After the egg, the next four bytes indicate how long the config is, and the rest of the data is decrypted via an XOR cipher using the executable name “CiscoCollabHost.exe”. Decrypting this data gives the keys required for the malware to communicate with the command and control (C2) server. The following table shows the relevant decrypted strings from the configuration.
test
962194083343-nevo9pjnlr7cgirjs1eonpebakrlq3qc.apps.googleusercontent.com
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
1//0eg8RBquaRQvhCgYIARAAGA4SNwF-L9IrSsPADLEx_CMsoJYspPSfaoeUbxii4xLVK10CafejzYAEBi2IptPt9KpwO7vphUTPFtest
962194083343-nevo9pjnlr7cgirjs1eonpebakrlq3qc.apps.googleusercontent.com
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
1//0eg8RBquaRQvhCgYIARAAGA4SNwF-L9IrSsPADLEx_CMsoJYspPSfaoeUbxii4xLVK10CafejzYAEBi2IptPt9KpwO7vphUTPF28
Rather than using dedicated infrastructure or even compromised infrastructure, the malware utilizes Google Sheets infrastructure for C2, data exfiltration and executing commands from the operators.
At this point, the malware has all the information it needs to start communicating with the C2. Since the malware is using Google Sheets with a client token, it needs to authenticate before it can write data to Google Sheets.
POST request getting an access token from Google.
The client ID, client secret, and refresh token value are taken from the decrypted configuration and sent to receive an access token.
Raw request of getting the access token from Google.
With the access token acquired, the malware can read the given Google Sheet that contains commands for the bot.
Code to read data from the Sheet acting as the C2.
The first request made to read the Sheet is to check where to write its own data. The malware starts by reading value A1:A1 of the Sheet; if a UUID is returned, it knows there is already victim data within that set. It then proceeds to read 2:2 and so on until a UUID is not returned. Following is a request showing a UUID returned:
Raw response showing a UUID being returned from the Sheet.
After six iterations, if the malware does not get a UUID back, that indicates that it can freely write to those cells without overwriting existing bot data.
Raw response showing a UUID not being returned.
As an unintended consequence, this loop of iterating over cells shows how many victims there are within the given Google Sheet.
After the malware has found a set of cells it can write data to, it sends an array of host information in the sixth row:
Raw request of the bot uploading its host info to the Google Sheet.
The following table shows some of the notable fields included in this request. Most values within this request are base64 encoded, and RC4 encrypted using the executable’s filename as the RC4 key, e.g., “CiscoCollabHost.exe”:
Bot UUID
Local IP
Hostname
Username
Program Files list
Program Files (x86) list
Environment Variables
Filename of executable
Infection Timestamp
Description of fields.
At this point in the malware, the actors can issue commands to the bot via the Google Sheet. The commands the malware supports are as follows:
Ping
Dir
Download
Upload
Exec
Copy
Move
Sleep
Exit
All of these come with their own status messages indicating whether the operation was successful or not, as well as a leaked name for the malware, “Voldemort”.
Decrypted status messages related to executing commands.
Google exploring
After observing the malware uses a standard service as its communication protocol and that service exposes a client ID and client secret to be able to read data from the Google Sheet, we felt it was worth exploring the given Google Sheet to see what information was available. With the following Python code, we identified all the active infections that had made it to the point of sending host information to the Google Sheet. In total, we observed six total victims in the Sheet, with all but one of them being a sandbox or a known researcher.
Python code showcasing how to read data from a Google Sheet.
Exploring the other pages within the Google Sheet also allowed us to see commands executed via the actors for the few bots that were registered in the spreadsheet. For each victim machine the actor interacts with, a new page is created that uses the hostname + username as the name. As of this writing, the actors had only executed commands to show directory listings of two directories.
After seeing the success of being able to read the given Google Sheet, we felt the need to see what else these client secrets allowed us to read. Taking similar Python code as the Sheet reader but using it to read Google Drive showed some interesting artifacts. To do this, we needed a folder ID. Luckily just as with the Sheet ID, this Drive ID was embedded with the configuration for infected machines to upload files of interest to Drive.
Python code showing how to list files within a Google Drive.
This scraping let us query the entire folder contents and download specific uploaded files. From this work we identified the following files:
API (Google Sheet used for C2)
7za.exe (7z executable)
Test.7z (Password protected 7z)
In addition to the following folders:
V1 [2023]
V2 [2023]
V1 [2023]
These directories contained training materials related to OpenWRT firmware code.
Directory output of the threat actor’s Google Drive.
In addition to these firmware images was a single picture shown below:
Image showing OpenWRT’s GUI.
Proofpoint researchers are unsure what the purpose of these files are as they are not being used to interact with any of the victims. It is possible they might be leftover from other activities performed by the actor.
The file named test.7z in the Google Drive is a password-protected 7-zip archive. Although no password was evident, the archive was easily decrypted with the commonly observed password “test123”. This archive contained a DLL and executable.
Directory listing showing the test files uploaded by the threat actor.
The executable “Shuaruta.exe” is another executable vulnerable to DLL side loading. The Shuaruta.exe program could be used to side-load “nvdaHelperRemote.dll” which was written in Go language and simply loads a Cobalt Strike Beacon. Fortunately, the developers of the Go binary compiled it with symbols and debug information.
Debug output contained within the Go binary to inject Cobalt Strike.
This gives us information on a potential username (yOIR) as well as when the DLL was compiled. Finally, extracting the configuration from the Cobalt Strike beacon itself gives us the following relevant fields:
DOMAINS: [‘autodiscover[.]iitt[.]eu[.]org’]
URIS: [‘/ows/v1/OutlookCloudSettings/settings/global’]
WATERMARK: 987654321
USERAGENT: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64;Trident/6.0)
The watermark in this Cobalt Strike configuration is associated with a cracked version of the software. The watermark has been observed in multiple unrelated threats in open-source reporting. The eu[.]org domain is a publicly available domain that offers free subdomains to non-profit organizations.
Attribution
Proofpoint does not attribute this activity to a tracked threat actor. Based on the functionality of the malware and collected data observed when examining the Sheet, information gathering was one objective of this campaign. While many of the campaign characteristics align with cybercriminal threat activity, we assess this is likely espionage activity conducted to support as yet unknown final objectives.
The Frankensteinian amalgamation of clever and sophisticated capabilities, paired with very basic techniques and functionality, makes it difficult to assess the level of the threat actor’s capability and determine with high confidence the ultimate goals of the campaign. It is possible that large numbers of emails could be used to obscure a smaller set of actual targets, but it’s equally possible the actors wanted to genuinely infect dozens of organizations. It is also possible that multiple threat actors with varying levels of experience in developing tooling and initial access worked on this activity. Overall, it stands out as an unusual campaign.
Why it matters
The behavior combines a variety of recently popular techniques observed in several disparate campaigns from multiple cybercriminal threat actors that have used similar techniques as part of ongoing experimentation across the initial access ecosystem. Many of the techniques used in the campaign are observed more frequently in the cybercriminal landscape, demonstrating that actors engaging in suspected espionage activity often use the same TTPs as financially motivated threat actors.
While the activity appears to align with espionage activity, it is possible that future activities associated with this threat cluster may change this assessment. In that case, it would indicate cybercriminal actors, while demonstrating some typical ecrime delivery characteristics, used customized malware with unusual features currently only available to the operators and not abused in widespread campaigns, as well as very specific targeting not normally seen in financially motivated campaigns.
Defense against observed behaviors includes restricting access to external file sharing services to only known, safelisted servers; blocking network connections to TryCloudflare if it is not required for business purposes; and monitoring and alerting on use of search-ms in scripts and suspicious follow-on activity such as LNK and PowerShell execution.
Proofpoint reached out to our industry colleagues about the activities in this report abusing their services, and their collaboration is appreciated.
Emerging Threats signatures
2857963 – ETPRO HUNTING GoogleSheets API V4 Activity (Fetch Single Cell with A1 Notation)
2857964 – ETPRO HUNTING GoogleSheets API V4 Response (Single Cell with UUID)
2857976 – ETPRO HUNTING GoogleSheets API V4 Activity (Possible Exfil)
2858210 – ETPRO MALWARE Voldemort System Info Exfil
Indicators of compromise
Indicator
Description
First Observed
hxxps://pubs[.]infinityfreeapp[.]com/SA150_Notes_2024[.]html
Redirect Target / Landing Page
2024-08-12
hxxps://pubs[.]infinityfreeapp[.]com/IRS_P966[.]html
Redirect Target / Landing Page
2024-08-06
hxxps://pubs[.]infinityfreeapp[.]com/Notice_pour_remplir_la_N%C2%B0_2044[.]html
Redirect Target / Landing Page
2024-08-13
hxxps://pubs[.]infinityfreeapp[.]com/La_dichiarazione_precompilata_2024[.]html
Redirect Target / Landing Page
2024-08-05
hxxps://pubs[.]infinityfreeapp[.]com/Steuerratgeber[.]html
Redirect Target / Landing Page
2024-08-13
hxxps://od[.]lk/s/OTRfNzQ5NjQwOTJf/test[.]png
Python Payload (Renamed ZIP containing Voldemort)
2024-08-05
hxxps://od[.]lk/s/OTRfODQ1Njk2ODVf/2044_4765[.]pdf
Python Payload (Decoy PDFs)
2024-08-05
hxxps://od[.]lk/s/OTRfODM5Mzc3NjFf/irs-p966[.]pdf
Python Payload (Decoy PDFs)
2024-08-06
hxxps://od[.]lk/s/OTRfODM3MjM2NzVf/La_dichiarazione_precompilata_2024[.]pdf
Python Payload (Decoy PDFs)
2024-08-05
hxxps://od[.]lk/s/OTRfODQ1NDc2MjZf/SA150_Notes_2024[.]pdf
Python Payload (Decoy PDFs)
2024-08-12
hxxps://od[.]lk/s/OTRfODQ1NzA0Mjlf/einzelfragen_steuerbescheinigungen_de[.]pdf
Python Payload (Decoy PDFs)
2024-08-13
hxxp://83[.]147[.]243[.]18/p/
pingb.in base URL
2024-08-05
3fce52d29d40daf60e582b8054e5a6227a55370bed83c662a8ff2857b55f4cea
test.png/zip SHA256
2024-08-05
561e15a46f474255fda693afd644c8674912df495bada726dbe7565eae2284fb
CiscoSparkLauncher.dll SHA256 (Voldemort Malware)
2024-08-05
6bdd51dfa47d1a960459019a960950d3415f0f276a740017301735b858019728
CiscoCollabHost.exe SHA256 (Benign file used for side-loading)
2024-08-05
pants-graphs-optics-worse[.]trycloudflare[.]com
TryCloudflare Tunnel Hostname
2024-08-05
ways-sms-pmc-shareholders[.]trycloudflare[.]com
TryCloudflare Tunnel Hostname
2024-08-05
recall-addressed-who-collector[.]trycloudflare[.]com
TryCloudflare Tunnel Hostname
2024-08-05
hxxps://sheets[.]googleapis[.]com:443/v4/spreadsheets/16JvcER-0TVQDimWV56syk91IMCYXOvZbW4GTnb947eE/
Voldemort C2
2024-08-05
hxxps://resource[.]infinityfreeapp[.]com/ABC_of_Tax[.]html
Redirect Target / Landing Page
2024-08-19
hxxps://resource[.]infinityfreeapp[.]com/0023012-317[.]html
Redirect Target / Landing Page
2024-08-19
hxxps://od[.]lk/s/OTRfODQ4ODE4OThf/logo[.]png
Python Payload (Renamed ZIP containing Voldemort)
2024-08-19
hxxps://od[.]lk/s/OTRfODQ5MzQ5Mzlf/ABC_of_Tax[.]pdf
Python Payload (Decoy PDFs)
2024-08-19
0b3235db7e8154dd1b23c3bed96b6126d73d24769af634825d400d3d4fe8ddb9
logo.png/zip SHA256
2024-08-19
fa383eac2bf9ad3ef889e6118a28aa57a8a8e6b5224ecdf78dcffc5225ee4e1f
CiscoSparkLauncher.dll Hash (Voldemort Malware)
2024-08-19
invasion-prisoners-inns-aging[.]trycloudflare[.]com
TryCloudflare Tunnel Hostname
2024-08-19
Source: Original Post