Listen to this Post
Introduction: Ransomware Is No Longer Just About Encryption
Modern ransomware operations are evolving into highly organized criminal service ecosystems. The days when an attacker simply deployed an encryptor and demanded payment are fading. Today’s ransomware groups increasingly provide affiliates with complete operational toolkits, technical support, specialized malware, and defensive-evasion capabilities designed to weaken an organization before the ransomware payload is ever launched.
Phantom Mantis, previously known as ArmCorp and now operating through a partnership program called “The Gentlemen,” appears to represent this shift. Rather than requiring affiliates to independently develop tools capable of disabling endpoint security products, the operation reportedly provides a dedicated support capability known as LARVA-368. This service supplies customized EDR-killing packages based on the security technologies encountered during an intrusion.
The result is a more scalable and dangerous ransomware model. Affiliates can focus on gaining access, moving laterally, stealing information, and preparing extortion operations, while the ransomware operator centrally develops and maintains specialized tools for neutralizing security controls.
Original Summary: A Centralized EDR-Killing Service for Ransomware Affiliates
Phantom Mantis reportedly maintains several kernel-oriented attack chains designed to interfere with endpoint detection and response platforms, antivirus products, remote monitoring tools, and other security software.
The current toolkit centers on three major components:
G12, an automated loader and kernel driver chain.
G13, an expanded and more destructive evolution of the G12 capability.
DriverKiller, a tool reportedly based on a Bring Your Own Vulnerable Driver, or BYOVD, approach.
These tools move critical security-disruption actions into the Windows kernel. This is important because many modern endpoint products use hardened services, protected processes, and self-defense mechanisms that make user-mode termination increasingly difficult.
By operating at the kernel level, Phantom Mantis tools may be able to interfere with defensive processes and components below the layer where many conventional security controls operate.
Phantom Mantis Arms Its Affiliates with Specialized Security Killers
A Ransomware-as-a-Service Model with Technical Support
The most notable aspect of Phantom Mantis is not simply the existence of an EDR killer. Malware capable of terminating security processes has existed for years. The more significant development is the apparent service model surrounding these tools.
Instead of distributing a static malware package and leaving affiliates responsible for adapting it, Phantom Mantis reportedly provides tailored support through LARVA-368.
An affiliate encountering a specific endpoint security stack may be able to request a package adapted to that environment. This could reduce the technical knowledge required to conduct sophisticated ransomware operations and make advanced defensive evasion available to a broader group of criminal partners.
The model resembles a commercial software support structure—except the service is designed to help attackers disable security technology during real-world intrusions.
Centralized Development Creates a Faster Criminal Ecosystem
Centralized tooling can provide several advantages to ransomware operators.
A single development team can maintain drivers, update process lists, improve compatibility, and respond to changes in security products. Affiliates may then receive updated capabilities without independently researching kernel internals or building their own EDR-disabling tools.
This division of labor can make ransomware operations more efficient.
The operator develops the technology.
The affiliates perform the intrusions.
The support service adapts the tools.
The ransomware infrastructure manages encryption and extortion.
Such specialization may allow criminal groups to operate with greater speed and consistency than loosely connected attackers using unrelated public tools.
Deep Analysis: Why Kernel-Level Attacks Are So Dangerous
The Windows Kernel Represents a Powerful Security Boundary
Windows separates software into different privilege levels. Most applications operate in user mode, where the operating system limits their ability to directly control critical system components.
Kernel-mode code operates with significantly greater privileges. A malicious or abused kernel driver may be able to interact with processes, memory, drivers, network components, and system resources at a level that ordinary applications cannot reach.
This creates a serious security concern.
If attackers obtain reliable kernel-level execution, they may attempt to interfere with security products that are otherwise protected from ordinary process termination.
The kernel is not automatically malicious. Legitimate hardware drivers and security products depend on it. The danger arises when attackers load malicious drivers, exploit vulnerable drivers, abuse trusted components, or manipulate kernel interfaces.
G12 and G13 Search for Security and Management Software
The G12 and G13 chains reportedly scan systems for a fixed list containing approximately 180 security and management processes.
The targeted ecosystem reportedly includes products and services associated with:
Microsoft
CrowdStrike
SentinelOne
Elastic
Sophos
Bitdefender
Kaspersky
ESET
Remote monitoring and management platforms
Vulnerability assessment tools
The inclusion of management and monitoring software is significant.
Attackers may not only want to disable antivirus or EDR products. They may also attempt to disrupt remote administration tools, monitoring agents, vulnerability-management systems, and other technologies that could reveal suspicious activity or allow defenders to respond.
Process Discovery Can Turn Security Software into a Target Map
A large hard-coded process list allows malware to identify defensive tools automatically.
Once a process name matches an entry in the list, the loader can reportedly obtain the process identifier and communicate it to the kernel driver.
The reported communication mechanism uses the following IOCTL value:
IOCTL: 0x22201C
An IOCTL, or input/output control request, allows user-mode software to communicate with a driver.
In this case, the process identifier may be passed to the driver so the kernel component can attempt to access and terminate the selected process.
The reported termination path involves Windows kernel functionality associated with process termination:
Target process identified
↓
Process ID passed through IOCTL
↓
Kernel driver receives request
↓
Target process opened with termination access
↓
ZwTerminateProcess invoked
This architecture separates the user-mode loader from the privileged kernel action.
G12 Uses an Embedded Driver and Automated Installation
G12 reportedly contains an embedded driver that is decoded before installation.
The driver is associated with the filename:
drv.sys
It is reportedly registered through a kernel service named:
drvsvc
The loader automates the deployment process, reducing the amount of manual work required from the attacker.
Security teams should monitor unexpected driver creation, suspicious kernel service registration, and unusual driver-loading activity—especially when these events occur shortly before endpoint security services stop functioning.
G13 Uses a Different Driver and Service Pattern
G13 reportedly writes its driver to the Windows temporary directory using the filename:
anticheatG13.sys
The associated service name is reportedly very short:
a
Short or generic service names are not automatically malicious. However, a newly created kernel service with an unusual driver path should receive attention.
A driver loaded from a temporary directory may be especially suspicious because legitimate kernel drivers are commonly installed through controlled vendor or operating-system deployment mechanisms.
Defenders can investigate driver services with:
sc query type= driver
Administrators can also inspect installed drivers using:
driverquery /v
PowerShell can help review kernel-driver services:
Get-CimInstance Win32_SystemDriver | Select-Object Name, DisplayName, State, StartMode, PathName
These commands are useful for defensive inventory and incident-response validation. They should be combined with endpoint telemetry rather than treated as standalone detection mechanisms.
Simple XOR Obfuscation Can Still Slow Analysis
Both G12 and G13 reportedly use a single-byte XOR key:
0xAB
The purpose is not necessarily to provide strong cryptographic protection. Single-byte XOR is weak and can be reversed relatively easily.
Its practical value is often operational.
The technique may prevent an embedded driver from appearing in clear form inside the loader. This can complicate simple signature-based detection and reduce the effectiveness of basic static scanning.
A defensive analyst examining a suspected sample may test whether an embedded region has been XOR-encoded.
A simplified Python example for authorized malware analysis is:
Run key = 0xAB
with open("suspected_blob.bin", "rb") as source:
encrypted = source.read()
decoded = bytes(byte ^ key for byte in encrypted)
with open("decoded_output.bin", "wb") as output:
output.write(decoded)
This example only demonstrates XOR decoding. Analysts should conduct malware examination inside an isolated environment and avoid executing recovered binaries.
G13 Expands Beyond Process Termination
Driver-Load Inspection Raises the Stakes
G13 reportedly extends the G12 capability set by examining newly loaded kernel images.
Rather than waiting for a defensive driver to become active, the malware may attempt to evaluate the driver during its loading process.
Reported checks include:
Whitelist comparisons
CRC32-based blacklists
Optional byte signatures
VMProtect-related markers
If a driver matches a configured rule, G13 may reportedly modify its entry behavior so that the driver returns:
STATUS_ACCESS_DENIED
This could prevent a selected defensive driver from successfully initializing.
The strategy is important because it shifts the attack from “kill the security product after it starts” toward “prevent the security component from starting at all.”
Blocking Defensive Drivers Before Initialization
Security products increasingly rely on kernel components to protect themselves and monitor low-level system activity.
If an attacker can interfere with those components during loading, the attack may weaken security visibility before the endpoint product fully activates.
This creates a potential race between defensive initialization and malicious kernel activity.
Organizations should therefore monitor not only whether security processes are terminated, but also whether security drivers fail to load, repeatedly crash, or unexpectedly return initialization errors.
A sudden endpoint-security outage without an obvious software update or system failure should be treated as a possible security incident.
Memory Corruption Can Be Used When Termination Fails
G13 reportedly includes destructive memory operations intended to destabilize selected processes.
The reported behavior involves attaching to a target process, identifying writable user-space memory regions, and overwriting data using repeated patterns such as:
0xCC 0xCC 0xCC 0xCC
The byte value 0xCC is commonly associated with software breakpoints in x86 debugging contexts. Repeatedly writing it into active memory may corrupt instructions, application data, or runtime structures.
The goal may be to break a security process even when direct termination is blocked, monitored, or restored automatically.
This creates an important defensive lesson:
A security product that remains visible in Task Manager is not necessarily functioning correctly.
Security teams should validate telemetry flow, sensor health, policy enforcement, and backend connectivity rather than relying only on process presence.
Cross-Process Memory Operations Increase Flexibility
The reported use of:
MmCopyVirtualMemory
suggests support for transferring memory between processes.
Such functionality may enable additional manipulation, data movement, or interference beyond basic process termination.
Kernel memory operations are highly sensitive because they can affect the integrity and stability of applications.
Defenders should monitor suspicious driver behavior involving cross-process memory access, especially when it originates from unknown, unsigned, recently installed, or unusually located drivers.
Minifilter Interference Could Reduce File-Level Visibility
G13 reportedly supports minifilter enumeration and deregistration.
Windows minifilter drivers are commonly used by security products and system components to observe or control file-system activity.
If an attacker interferes with defensive minifilters, file monitoring may be weakened.
This could be valuable during ransomware preparation because attackers often need to:
Stage tools
Modify files
Disable backups
Deploy ransomware payloads
Remove evidence
Encrypt large numbers of files
A sudden change in security-related file-system monitoring should therefore be investigated alongside process and driver telemetry.
Protected Logging May Help Attackers Maintain Operational Awareness
The malware reportedly uses XOR-obfuscated log files with names derived from WindowsData-related patterns.
Attackers may use protected logging to track actions, record successful process disruption, or troubleshoot failures during an intrusion.
This demonstrates that sophisticated ransomware tooling may include its own operational diagnostics.
Defenders should search for unusual hidden or obfuscated log artifacts, particularly when they appear near suspicious driver installation events.
DriverKiller and the BYOVD Threat
Vulnerable Drivers Can Become an Attack Tool
DriverKiller is described as a BYOVD-style capability.
BYOVD stands for:
Bring Your Own Vulnerable Driver
In this technique, an attacker installs a legitimate but vulnerable driver and abuses its privileged functionality.
The driver may be digitally signed and originally intended for legitimate software or hardware. However, a vulnerability or unsafe control interface can allow attackers to perform privileged operations.
This can help attackers bypass security boundaries without developing a completely new malicious driver.
Driver Trust Must Be Continuously Evaluated
A valid digital signature does not guarantee that a driver is safe in every context.
A signed driver may still contain vulnerabilities.
It may expose dangerous functions.
It may be outdated.
It may be abused outside its intended purpose.
Organizations should maintain driver inventories and apply vulnerable-driver blocklists where supported.
Microsoft Defender and Windows security features can provide additional protection, but organizations should validate compatibility before enabling stricter controls across production environments.
Defensive Commands for Incident Responders
Reviewing Recently Installed Driver Services
PowerShell can help identify driver services and their paths:
Get-CimInstance Win32_SystemDriver | Sort-Object Name | Format-Table Name, State, StartMode, PathName -AutoSize
Investigators should look for:
Unknown driver names
Drivers loaded from temporary directories
Recently created services
Unusual short service names
Unexpected paths outside standard driver locations
Checking for Drivers in Temporary Directories
A defensive search may include:
Get-ChildItem "$env:TEMP" -Filter ".sys" -Recurse -ErrorAction SilentlyContinue | Select-Object FullName, Length, CreationTime, LastWriteTime
A .sys file in a temporary directory is not automatically malicious, but it may justify investigation when correlated with endpoint-security failures.
Reviewing Recent Service Installations
Windows event logs may reveal service creation activity.
A defensive query can include:
Get-WinEvent -FilterHashtable @{
LogName = "System"
Id = 7045
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Message
Event ID 7045 is commonly associated with service installation.
Investigators should correlate service creation with driver files, endpoint alerts, process termination, and user activity.
Checking Security-Service Health
Administrators can review service status with:
Get-Service |
Where-Object {
$_.Name -match "Defender|Sense|Crowd|Sentinel|Sophos|Elastic|ESET"
} |
Select-Object Name, Status, StartType
The exact service names differ between products. Organizations should build environment-specific monitoring rules based on their deployed security stack.
What Undercode Say:
The Threat Is the Service Model, Not Only the Malware
Phantom Mantis demonstrates how ransomware groups are becoming structured technology providers.
The operation is reportedly reducing the technical burden placed on affiliates.
That may allow less-skilled attackers to use advanced kernel-level capabilities.
The centralized support model can accelerate ransomware campaigns.
It may also improve consistency across multiple intrusions.
Affiliates no longer need to independently study every EDR platform.
The operator can maintain specialized tooling for them.
This creates a criminal ecosystem built around division of labor.
One team develops ransomware.
Another team performs initial access.
Another service may provide EDR killers.
Negotiators may manage extortion.
Infrastructure operators may handle payment systems.
The result resembles an illegal technology supply chain.
Kernel-level interference is especially concerning.
Many security products depend on protected processes.
Traditional process-killing techniques may fail against hardened software.
Kernel access can potentially bypass some of those protections.
That does not mean kernel access guarantees success.
Modern Windows security includes multiple protections.
Driver signing requirements create barriers.
Memory integrity can restrict some malicious behavior.
Vulnerable-driver blocklists can reduce BYOVD exposure.
Endpoint platforms also monitor suspicious driver activity.
However, attackers continuously test these defenses.
The reported G13 behavior shows a move toward prevention of defensive initialization.
Stopping a security driver before it starts may be more valuable than killing a running process.
The destructive memory capability adds another layer.
A process may remain visible while becoming operationally broken.
Security teams should therefore validate telemetry quality.
A running process is not proof of protection.
Healthy security requires active sensors.
It requires successful communication with management platforms.
It requires functioning policies and event collection.
Organizations should monitor sudden sensor silence.
Unexpected driver failures deserve immediate attention.
Kernel-service creation should be correlated with other events.
Temporary-directory driver execution should raise suspicion.
Security products should be configured with tamper protection.
Driver inventories should be maintained.
Vulnerable drivers should be blocked where possible.
Incident responders should preserve driver artifacts.
They should collect service configuration data.
They should review kernel-related event telemetry.
They should avoid rebooting immediately when evidence preservation is important.
Ransomware defense must begin before encryption.
The critical stage may be the quiet period when attackers disable visibility.
Detecting that preparation phase can prevent the larger incident.
✅ The Ransomware-as-a-Service Model Is a Documented Criminal Strategy
Ransomware groups have long used affiliate programs that separate malware development from intrusion activity. A centralized support function for specialized tools is consistent with the broader evolution of ransomware ecosystems.
✅ Kernel-Level Access Can Provide Greater Control Than User-Mode Malware
Kernel drivers operate with high privileges and may interact with processes, memory, drivers, and system components beyond the reach of ordinary applications. This is why malicious or vulnerable drivers represent a major security concern.
✅ BYOVD Is a Well-Known Defensive-Evasion Technique
Attackers have repeatedly abused legitimate but vulnerable drivers to obtain privileged capabilities. Driver blocklists, memory integrity, and endpoint monitoring can reduce risk but may not eliminate it.
⚠️ The Exact Scope of the Phantom Mantis Toolset Requires Continued Verification
Technical reports may describe samples, observed behavior, or analyst conclusions that can change as new evidence emerges. Organizations should treat indicators and capability claims as threat-intelligence inputs rather than universal guarantees.
Prediction
(-1) Ransomware Operations Will Continue Turning Advanced Evasion into an Affiliate Service
The next stage of ransomware-as-a-service will likely involve more specialized support packages, including automated security-product profiling, environment-specific EDR disruption, and rapid updates when defensive vendors change their protections.
Kernel-level tools may become more modular and easier for affiliates to deploy.
Defenders will likely respond with stronger driver trust controls, improved vulnerable-driver blocklists, and more aggressive monitoring of kernel-service creation.
The most important security battle may increasingly occur before ransomware execution—during the hidden preparation phase when attackers attempt to blind monitoring systems and weaken endpoint defenses.
Organizations that detect security-tool degradation early will have a better chance of stopping ransomware before encryption and large-scale business disruption begin.
▶️ Related Video (88% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.facebook.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
