The Labs team at VMRay actively gathers publicly available data to identify any noteworthy malware developments that demand immediate attention. We complement this effort with our internal tracking and monitor events the security community reports to stay up-to-date with the latest changes in the cyber threat landscape.
In April 2026, the VMRay Labs team has been focused on the following areas:
1) New VMRay Threat Identifiers addressing:
-
Detecting connections to blocklisted domains
-
Detecting cmd.exe started with ambiguous arguments
-
Detecting EvilTokens PhishKit behavior
-
Detecting connection to Microsoft Device Login Endpoint
-
Detecting network communication via AFD (\Device\Afd\Endpoint)
-
Detecting a mismatch between MIME type and filename extension
-
Detecting Windows Defender Firewall manipulation via PowerShell
2) VMRay’s AutoUI enhancements, including:
3) +20 new YARA rules
Now, let’s delve into each topic for a more comprehensive understanding.
New VTIs
In a series of these blog posts, we introduced you to the concept of the VMRay Threat Identifiers (VTIs). In short, VTIs identify threatening or unusual behavior of the analyzed sample and rate the maliciousness on a scale of 1 to 5, with 5 being the most malicious. The VTI score, which greatly contributes to the ultimate Verdict of the sample, is presented to you in the VMRay Platform after a completed analysis. Here’s a recap of the new VTIs that we added or improved in the past month.
Detecting connections to blocklisted domains
Category: Network Connection
Blocklisted domains are domain names identified as malicious, suspicious, or relevant to threat activity. These may include domains associated with malware’s command-and-control infrastructure, phishing pages, indicators reported by threat intelligence feeds, and more. When a sample extracts, resolves, or attempts to contact a domain that is already linked to malicious activity, it can help analysts quickly connect the observed behavior to known infrastructure or campaigns.
Our new VTI triggers when an analyzed sample extracts or connects to domains matching known malicious or suspicious infrastructure patterns. The initial detection focus includes domains associated with phishing kits, including domain and URL patterns observed in EvilTokens, a Phishing-as-a-Service platform used for Microsoft 365 device-code phishing and token theft activity.
Detecting cmd.exe started with ambiguous arguments
Category: Heuristics
Command-line arguments provide programs with additional input, context, or configuration that can alter how they behave. Common examples include specifying a file to open, a script to execute, or a feature to enable. In malicious activity, however, these arguments may be deliberately fake, misleading, or crafted to disguise the program’s true purpose.
In a recently analyzed sample, VMRay observed a process startingcmd.exe with arguments that looked meaningful at first glance but were actually ambiguous, fake, or misleading. In other words, the command line appeared to describe one action, while the sample’s actual behavior suggested another. For example, some arguments may look similar to those used by installers or enterprise tools, however, the option names and values may be random, unsupported by cmd.exe or unrelated to any real command-line function.
This can make the analysis noisier. An analyst or detection system may see a command line with multiple parameters and assume they are important. That can waste investigation time or obscure the fact that the real activity is happening elsewhere, such as in the parent process, injected code, a dropped script, or a different child process. This behavior can also support anti-analysis. Malware authors know that analysts review command lines during triage. Fake arguments can slow down investigations, point analysts toward irrelevant artifacts, or help the malware avoid simplistic command-line pattern matching.
Detecting EvilTokens PhishKit behavior
Category: Heuristics
EvilTokens is associated with phishing activity that abuses legitimate device-code authentication flows. In this type of attack, the victim may interact with a real Microsoft login page, but the login session is controlled by the attacker. Our new VTI detects two key behavioral patterns linked to EvilTokens-style activity.
Behavior 1: User code retrieval
In the first stage, the phishing page requests a device login code from its backend server. This code is then shown to the victim, often with instructions such as “Use this code to sign in.”
The victim may then be redirected to a legitimate Microsoft authentication page. Because the page is real, the process can appear trustworthy. However, when the victim enters the code and completes the sign-in, they may actually be authorizing an attacker-controlled session. As a result, the attacker may receive access tokens for the victim’s account without directly stealing the password.
Behavior 2: Polling for authentication completion
The second behavior occurs after the code is shown to the victim. At this point, the phishing kit repeatedly checks with its backend server to see whether the victim has completed the login process. This repeated checking is called polling; the phishing kit keeps asking: “Has the victim signed in yet?”, “Are the tokens ready?”
Once the victim completes authentication, the attacker can proceed with the authenticated session associated with the device code flow. In this scenario, the victim is not receiving the stolen access data. Instead, the attacker’s infrastructure uses the completed authentication to obtain or access the resulting tokens, which can then support follow-up activity such as mailbox access, data theft, or further account abuse.
For those interested in a deeper breakdown of this technique, Sekoia’s analysis of the EvilTokens provides additional context on how device code phishing is operationalized.
Detecting connection to Microsoft Device Login Endpoint
Category: Heuristics
The Microsoft Device Login Endpoint is a legitimate Microsoft sign-in page used for device-code authentication. The common URL is: https://microsoft.com/devicelogin. This flow is normally used by devices or apps that cannot easily display a full login screen, such as smart TVs, printers, or IoT devices. In a legitimate scenario, the device shows the user a short code. The user enters that code on Microsoft’s device login page, signs in, and grants access to the original device or application.
In a recently analyzed sample, VMRay’s Labs team observed a connection to the Microsoft Device Login Endpoint. On its own, this behavior is not necessarily malicious, which is why the VTI is informational and assigned a low score. However, in the right context, this connection can be relevant to phishing and credential access investigations.
Attackers and phishing kits may abuse Microsoft’s legitimate device-code flow to trick users into authorizing an attacker-controlled session. In this scenario, the victim may be shown a code and instructed to enter it on Microsoft’s real login page. Because the page is legitimate, the request can appear trustworthy. However, by completing the login, the victim may unknowingly grant access to their device or application.
Detecting network communication via AFD (\Device\Afd\Endpoint)
Category: Defense Evasion
Malware often needs network access to contact command-and-control infrastructure, download additional payloads, or send stolen data out of the environment. Although Windows provides well-documented APIs intended for network communication, lower-level system components can also be used to achieve the same goal.
One such component is AFD, short for Ancillary Function Driver for Winsock. AFD is a Windows driver used underneath normal network communication. Most applications rely on higher-level networking functions, while AFD operates closer to the Windows networking layer.
This behavior was observed in ACRStealer-related activity, where a process opened network communication through an AFD endpoint. From an analysis perspective, this indicates that the process is establishing or managing network communication at a lower level of the Windows networking stack, potentially to a specific remote IP address and port. While AFD itself is legitimate and expected to exist on Windows systems, direct interaction with AFD endpoints should be treated as suspicious when observed in malware-like execution contexts.
Using lower-level interfaces such as AFD may help malware reduce visibility, bypass assumptions made by monitoring tools, or obscure the origin of network activity. It may also indicate an attempt to avoid relying on high-level APIs, which are better documented, more commonly monitored, and more stable across Windows versions. Legitimate applications generally use documented Windows networking APIs because they are stable, supported, and publicly documented. Reliance on lower-level system interfaces is less common and may be fragile, as changes to kernel drivers or internal networking behavior are not always publicly announced. Malware authors may accept this risk if it helps them hide network activity or evade detection.
Detecting a mismatch between MIME type and filename extension
Category: Masquerading
MITRE ATT&CK® Technique: T1036
A filename is the identifier of a given file shown to the user, such as invoice.pdf or report.docx. It is mostly a label, and it can be changed easily. Malware often abuses this by giving a file a harmless-looking name, even when the file itself is something else. A filename usually consists of two parts:
-
Base name: the descriptive part of the name, such as invoice, report, or photo
-
Filename extension: the suffix after the final dot, such as .pdf, .docx, or .jpg
The base name is a label for the user. The extension, however, is important because it indicates what type of file the user or operating system should expect. For example, a file ending in .pdf is expected to be a PDF document.
A MIME type describes the file’s content type, such as application/pdf for a PDF, image/jpeg for a JPEG image, or application/vnd.microsoft.portable-executable for a Windows executable. MIME types are used by many applications, services, and security tools to understand how a file should be handled.
This becomes suspicious when the filename extension and MIME type do not match. For example,
At first glance, the file appears to be a PDF document. However, the MIME type indicates that the file is actually a Windows executable. This mismatch is suspicious because the file may be masquerading as a document while actually behaving like a program. Our new VTI triggers when the detected MIME type does not match the expected file type implied by the filename extension. While not every mismatch is necessarily malicious, it is a strong indicator of possible masquerading and should be investigated in context.
Detecting Windows Defender Firewall manipulation via PowerShell
Category: Defense Evasion
MITRE ATT&CK® Technique: T1685, T1059/001
Windows Defender Firewall controls which network connections are allowed into and out of a Windows system. Legitimate administrators may adjust firewall settings during normal system management, but in malware analysis, broad or unexpected firewall changes are a strong warning sign.
In a recently analyzed sample, VMRay observed suspicious PowerShell-based manipulation of Windows Defender Firewall. Rather than making a narrow, application-specific change, the sample attempted to weaken firewall protection more broadly, such as by allowing unrestricted traffic or disabling firewall protection across Windows network profiles.
This behavior is important to address because attackers may modify firewall settings to reduce network restrictions around their malware. Weakening the firewall can help malicious code communicate with command-and-control infrastructure, receive inbound connections, download additional payloads, or exfiltrate data with fewer obstacles.
Our new VTI triggers when an analyzed process attempts to weaken or disable firewall protections in a way that may indicate defense evasion.
AutoUI
Improved support for multi-stage fake CAPTCHA campaigns
We have further improved AutoUI to better handle the growing use of fake CAPTCHA pages in malware and phishing campaigns. In these attacks, a user may first land on a legitimate website that has been compromised or injected with malicious code. The injected code then loads content from an attacker-controlled site and displays it as a screen overlay. To the user, this may look like a routine “I am not a robot” check. In reality, the fake CAPTCHA is part of the attack chain.
These campaigns are often multi-stage. The initial page may only display the overlay, while the actual fake CAPTCHA is loaded from another location. Without user interaction, a sandbox may not reach the next stage of the attack, leaving important HTML content, scripts, or follow-on behavior hidden.
With our latest AutoUI improvement, VMRay Platform can interact with these multi-stage fake CAPTCHA overlays more effectively. AutoUI can click the fake CAPTCHA element, allowing the next stage to load and enabling the sandbox to collect additional HTML and behavioral evidence from the embedded content.
YARA Rules Update
Our hunt for new, undetected malware samples never stops. In the past month, we added many fresh YARA rules to strengthen detection across a wide range of threats. This month, we’re continuing that momentum with about 20 new rules, focused on delivering a solid drop of high-quality detections. Here’s a quick preview of what we’re shipping this month.
New YARA detections for:
Stealers:
Backdoor:
Loader:
RAT:
Ransomware:
Phishing:
-
New rule for phishing campaign exploiting storage.googleapis
-
EvilTokens phishing kit
-
Additional rules for recent phishing pages and CAPTCHAs
-
Additional rules for PowerShell samples dropped from pastejacking
-
Additional rules for suspicious QR codes in HTML files
-
Additional rule for obfuscated QR codes via HTML tables
Other:
