Proxy — CraftedSignal Threat Feed

Mirax RAT Targeting Android Users in Europe

hello@craftedsignal.io — Thu, 16 Apr 2026 12:00:00 +0000

The Mirax RAT is a newly identified Android Remote Access Trojan (RAT) that has been actively targeting users in Europe since March 2026. It’s offered as Malware-as-a-Service (MaaS) to a small group of affiliates, primarily Russian-speaking actors, through tiered subscription models. Since December 2025, Mirax has been promoted on underground forums and used in multiple campaigns. The RAT’s distribution relies on malicious advertisements on Meta platforms like Facebook, Instagram, and Messenger, with over 200,000 users potentially exposed to these ads. The malware uses dropper pages hosted on GitHub and relies on APK sideloading for execution, bypassing the Google Play Store’s security measures. Mirax’s capabilities extend beyond typical RAT functions, including turning infected devices into residential proxy nodes via a SOCKS5 proxy.

Attack Chain

The attacker creates malicious ads on Facebook, Instagram, and Messenger promoting IPTV application services.
Users click on the advertisements, which redirect them to dropper pages hosted on GitHub.
The user is prompted to enable installation from unknown sources on their Android device.
The malicious IPTV application is installed via APK sideloading.
The application initiates a multi-stage infection process, utilizing Golden Encryption (Golden Crypt) to pack the payload.
The payload, an encrypted Dalvik Executable (.dex) file, is decrypted during installation using the RC4 stream cipher with a hardcoded key.
Mirax gains control of the device, enabling overlay and notification injection for credential theft.
Attackers can view the screen in real-time, navigate and control the device, manage applications, exfiltrate images and text, and launch a SOCKS5 proxy connection to proxy traffic through the infected device.

Impact

The Mirax RAT campaign has the potential to affect a large number of Android users in Europe. The malicious advertisements have already reached over 200,000 users. Successful infections can lead to credential theft, financial fraud, data exfiltration, and the compromised device being used as a residential proxy, potentially masking malicious activity and further expanding the attacker’s reach. Banks and financial institutions are specifically highlighted as high-value targets.

Recommendation

Monitor network traffic for connections to GitHub domains associated with APK downloads, and correlate that with android device user agents (Network Connection and User Agent logs).
Implement detections for process creation events related to sideloaded APK installations, specifically looking for unusual parent-child process relationships (Process Creation Logs).
Deploy the Sigma rule provided below to detect the execution of applications from untrusted sources and tune for your environment.
Monitor network connections for SOCKS5 proxy traffic originating from Android devices, which may indicate compromised devices acting as residential proxies (Network Connection Logs).

Potential Protocol Tunneling via Yuze

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This rule detects the execution of Yuze, an open-source tunneling tool written in C, which is commonly used for intranet penetration. Yuze supports both forward and reverse SOCKS5 proxy tunneling and is often executed using rundll32 to load yuze.dll with the RunYuze export. Threat actors can leverage Yuze to proxy command and control (C2) communications or to pivot within a network. The detection focuses on identifying processes with command-line arguments indicative of Yuze execution, specifically those involving “reverse,” “-c,” “proxy,” “fwd,” and “-l” parameters. This activity has been observed in real-world campaigns, increasing the importance of timely detection and response.

Attack Chain

The attacker gains initial access to a target system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker uploads or drops the yuze.dll file onto the compromised host.
The attacker uses rundll32.exe to execute yuze.dll, calling the RunYuze export.
The command line includes parameters to establish a reverse or forward SOCKS5 proxy tunnel (e.g., rundll32 yuze.dll,RunYuze reverse -c :).
Yuze establishes a tunnel to a remote server, allowing the attacker to proxy network traffic.
The attacker uses the established tunnel to pivot within the network and access internal resources.
The attacker may proxy C2 traffic through the tunnel, masking the true origin of the commands.
The attacker performs actions on the internal network, such as data exfiltration or lateral movement, using the tunnel as a covert channel.

Impact

Successful exploitation allows attackers to establish covert communication channels, bypass network security controls, and proxy malicious traffic, potentially leading to unauthorized access to sensitive data, lateral movement within the network, and data exfiltration. The use of Yuze can obscure the origin of attacks, making attribution more difficult and hindering incident response efforts.

Recommendation

Deploy the Sigma rule “Potential Yuze Tunneling via Rundll32” to your SIEM to detect the execution of yuze.dll via rundll32.exe with specific command-line arguments.
Enable process creation logging (Sysmon Event ID 1 or Windows Security Auditing) to capture the necessary command-line information for the Sigma rules.
Investigate any identified instances of rundll32.exe executing yuze.dll, focusing on the parent processes and network connections.
Block the C2/relay IP or domain found in the -c argument at DNS/firewall, as described in the Triage and Analysis section of the rule’s note.

Okta User Session Start via Anonymizing Proxy Service

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This threat brief focuses on detecting Okta user session starts that originate from anonymizing proxy services. Anonymizing proxies can be used by malicious actors to mask their true IP addresses and location, making it more difficult to trace their activities. The use of such proxies during Okta authentication is suspicious because it bypasses geographical restrictions and may indicate compromised credentials. Defenders should be aware that legitimate users may occasionally use anonymizing proxies for privacy reasons, but the activity warrants close scrutiny. The detection of this activity relies on Okta system logs and the security context of the authentication event.

Attack Chain

Attacker obtains valid Okta credentials through phishing, credential stuffing, or other means.
Attacker configures their network connection to route traffic through an anonymizing proxy service (e.g., Tor, VPN).
Attacker initiates an Okta user session using the compromised credentials.
Okta system logs record a “user.session.start” event.
The “securityContext.isProxy” field within the Okta event is set to “true”, indicating the use of a proxy service.
If successful, the attacker gains access to the Okta account and any associated applications or resources.
Attacker may then attempt to escalate privileges, access sensitive data, or perform other malicious activities within the Okta environment.
The attacker may attempt lateral movement to other systems within the organization that trust Okta for authentication.

Impact

Successful exploitation can lead to unauthorized access to sensitive applications and data protected by Okta. This could result in data breaches, financial loss, or reputational damage. Depending on the compromised user’s privileges, an attacker may be able to escalate privileges and gain control over critical systems. The number of potential victims depends on the scope of applications using Okta for authentication.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect Okta user sessions initiated through anonymizing proxies (logsource: okta, service: okta).
Investigate all alerts generated by the Sigma rule to determine the legitimacy of the proxy usage.
Implement multi-factor authentication (MFA) to reduce the risk of account compromise.
Monitor Okta system logs for other suspicious activities, such as failed login attempts or unusual access patterns (references: Okta System Log API).
Review and enforce Okta’s cross-tenant impersonation prevention and detection measures (references: Okta cross-tenant impersonation article).