Rayan Annabi on Senthorus Blog

Killing the Sensor First: What Happens Before the Encryptor Runs

Tue, 22 Sep 2026 00:00:00 +0000

Introduction

Read enough ransomware reports and you start noticing the same gap. Initial access is documented in detail. The encryptor is documented in detail. The minute in between, where the endpoint agent quietly stops talking, gets a single line.

That minute is where the intrusion is actually won.

The stage nobody watches

Once an operator has local admin on a host, encryption is rarely the next move. Blinding the sensor is. ESET describes EDR killers as a predictable, standard stage of modern ransomware operations, with attackers gaining high privileges first and then launching a killer to cripple endpoint defences before deploying the payload.

For an MDR this changes how you read a quiet console. A client’s EDR going silent on three machines at once used to be filed under agent maintenance. In 2026 it deserves an escalation on its own merits, before anyone finds a ransom note.

Why a signed driver works so well

The technique behind most of these tools is BYOVD, bring your own vulnerable driver. The goal is kernel-mode privileges, often called Ring 0, where code has unrestricted access to system memory and hardware. An attacker cannot load an unsigned malicious driver, so instead they bring one signed by a reputable vendor, typically a hardware manufacturer or an old antivirus version, that happens to carry a known vulnerability.

Nothing is forged at any point. The drivers carry valid signatures from real vendors, which means Windows and most security products are predisposed to trust them. Nobody is cracking a certificate. They are simply loading an old, unpatched version of legitimate software that still contains a kernel level flaw, and old signed copies are trivially obtainable.

Once execution lands at Ring 0, the attacker can terminate protected processes, tamper with kernel callbacks and switch off telemetry from underneath the layer the EDR operates in. This is also why tamper protection settings offer no comfort here. They run at user mode privilege level and cannot stop a tool that has already reached the kernel.

What changed over the last eighteen months

BYOVD stopped being an APT speciality somewhere in 2025 and became commodity tooling. ESET now counts almost 90 EDR killers in active use, 54 of them BYOVD based, abusing 35 distinct vulnerable drivers between them. Worth remembering when you read attribution reports: affiliates rather than core operators usually pick which killer to deploy, so the driver tells you very little about who is on the keyboard.

Three things are worth pulling out of the 2026 research.

The tooling now ships with the kit. ESET’s June 2026 investigation into the Gentlemen operation found that the operator centrally develops and maintains its own EDR killer framework, GentleKiller, and hands it to every affiliate as part of onboarding. The variants abuse drivers from Safetica, Zemana, Qihoo 360, IObit and Huawei.

“high operational effectiveness and tight integration”
Jakub Souček, ESET, on the Gentlemen toolkit

Blocklists are being outrun on purpose. Check Point documented more than 2,500 distinct variants of a single driver, TrueSight.sys, produced by tweaking eight bytes in the PE header, each with a unique hash and a still valid signature. In an April 2026 intrusion, Expel found the attacker using ktapi.sys, a Kontron industrial driver that was not on any public blocklist at the time.

And the scale of some of this is genuinely uncomfortable. Cisco Talos published research in April 2026 showing that Qilin had built a technique capable of disabling more than 300 endpoint detection and response products.

The category is also widening past drivers entirely. ESET identified script based tools that lean on built in commands like taskkill, net stop or sc delete, with some variants combining scripting with Windows Safe Mode. Driverless options such as EDRSilencer and EDR-Freeze disrupt security tooling without touching the kernel at all.

Where the chain leaves traces

The sequence barely varies across families, which is the good news. Drop the driver, register it as a service, exploit it to reach Ring 0, then start killing processes. Each step maps to telemetry you already collect.

Everything to the right of the exploit step is already too late. The detection value sits on the left.

Four places to look

Start with the driver landing on disk. It has to be written somewhere before it can load, so file creation monitoring against known vulnerable driver hashes gives you the earliest possible warning. The community maintained LOLDrivers database is the obvious feed for that.

Then service creation. Loading a driver normally creates a kernel service, which puts Sysmon Event ID 13 on service registry keys and Event ID 6 on driver load at the centre of this. Rules that fire on a new driver being installed as a Windows service give you warning before the kill sequence starts.

Third, Code Integrity logging. Under Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational, Event ID 3099 confirms which blocklist policy is genuinely active on a machine. Half the value here is discovering how much of your estate is not enforcing the policy you assumed it was.

Fourth, and least practised, the silence itself. A gap in endpoint telemetry followed by evidence of malicious activity is a strong sign the EDR was disabled during that window. Agents that stop reporting, unexpected kernel driver installations in event logs and odd traffic picked up by network monitoring all point the same way.

That last one deserves its own rule. Detection pipelines alert on events. Almost none of them alert on the absence of events. A rule that fires when an agent stops checking in, correlated against a recent service creation on the same host, costs very little to build and covers the exact scenario where every other control has been switched off.

Hardening, and its ceiling

The controls that actually operate at or below the attack surface are HVCI, the Microsoft Vulnerable Driver Blocklist and detection on driver installation. HVCI verifies kernel code before execution and enforces the blocklist, and you can check it per device under Windows Security, Device Security, Core isolation. If Memory Integrity is greyed out, something is blocking it and that machine is worth a ticket.

Alongside that, enable the ASR rule “Block abuse of exploited vulnerable signed drivers” so the driver never lands:

Add-MpPreference `
 -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 `
 -AttackSurfaceReductionRules_Actions Enabled

Merge the driver block rules into a WDAC base policy on your most critical assets, deploy it in audit mode first, and keep local admin rights tight, since the whole chain assumes them.

Be realistic about what this buys you. Blocklisting stops known vulnerable drivers, while capable operators rotate to signed drivers that are not on the list yet, or exploit flaws unknown to Microsoft and the EDR vendors, which bypasses enforcement entirely. There is movement on the platform side at least. By April 2026, Microsoft was reported to be removing trust for older cross signed kernel drivers in newer Windows releases, which could shrink the abusable surface considerably given how many LOLDrivers entries are cross signed.

Conclusion

An EDR killer is a line item in a ransomware as a service onboarding package now, not an exotic capability. Two things follow from that. Stop treating the endpoint agent as a trusted narrator and correlate it against identity, authentication and network telemetry that lives somewhere the attacker has not reached. And build the unglamorous detections, because by the time the encryptor runs, the best evidence you had was written twenty minutes earlier by a .sys file nobody was watching.

Sources

How APT Groups Evade Detection in a SOC

Mon, 13 Jul 2026 00:00:00 +0000

How APT Groups Evade Detection in a SOC

Advanced Persistent Threats (APTs) represent some of the most sophisticated and dangerous cyber adversaries in the world. Unlike opportunistic attackers or commodity malware campaigns, APT groups are well-funded, highly skilled, and extremely patient. Their goal is not a quick win, it is long-term access, data exfiltration, or strategic disruption.

For Security Operations Centers (SOCs), detecting APT activity is one of the hardest challenges. These attackers know how SOCs operate, and they deliberately design their techniques to blend in with normal network traffic, bypass standard detection tools, and remain unnoticed for months or even years.

Let’s explore the primary ways APT groups evade detection in a SOC, and what defenders can do to counter them.

1. Living Off the Land (LOLBins)

APT groups frequently abuse legitimate system tools, often called Living-off-the-Land Binaries (LOLBins). Instead of deploying custom malware that could be flagged by antivirus or EDR solutions, they use built-in utilities like:

PowerShell – executing scripts and downloading payloads
WMI (Windows Management Instrumentation) – persistence and remote execution
Certutil – encoding/decoding and transferring files
Rundll32 – running malicious code via DLLs

Because these tools are part of the operating system, their execution doesn’t immediately appear suspicious. To a SOC analyst looking at logs, activity may resemble normal administrative behavior.

Why it works: SOCs struggle to distinguish between legitimate admin activity and malicious abuse of system tools.

2. Fileless Malware and Memory-Resident Payloads

Rather than writing malicious binaries to disk (where antivirus or EDR may detect them), APTs often operate entirely in memory. They inject code directly into legitimate processes or use scripting languages (like PowerShell or Python) to execute payloads dynamically.

Example:
APT29 (Cozy Bear) has been observed using memory-resident implants that vanish once a system reboots, leaving almost no forensic trace.

Why it works: Traditional detection methods rely on scanning files on disk. Fileless techniques drastically reduce the footprint available for SOC tools to analyze.

3. Encryption and Traffic Obfuscation

Modern SOCs rely heavily on network monitoring to spot malicious traffic. APTs counter this by encrypting or disguising their communications.

Using HTTPS or TLS to hide command-and-control (C2) traffic inside normal web browsing patterns
Leveraging cloud services (e.g., Dropbox, Google Drive, OneDrive) as exfiltration channels
Domain fronting, where attackers hide C2 traffic behind trusted domains like Microsoft or Google

Why it works: To a SOC, encrypted outbound traffic to cloud platforms looks identical to normal user activity. Without deep inspection, malicious traffic blends perfectly.

4. Credential Theft and Abuse

APTs often compromise legitimate user accounts instead of creating new ones. Once they have valid credentials, they can move laterally, escalate privileges, and exfiltrate data, all under the guise of a trusted employee.

Pass-the-Hash or Pass-the-Ticket attacks let them impersonate users without knowing their passwords
Privileged accounts (like domain admins) are especially targeted for stealthy persistence

Why it works: SOC detection rules are often focused on failed logins, brute-force attempts, or unusual account creation. But if the attacker is using legitimate credentials, their activity can appear completely normal.

5. Low-and-Slow Tactics

Unlike ransomware actors who create noise, APTs play the long game. They deliberately keep activity levels low to avoid triggering alerts.

Exfiltrating data in small chunks over weeks or months
Spacing out commands to avoid suspicious spikes in activity
Operating during regular business hours to blend in with normal network traffic

Why it works: Most SOCs tune detection systems to identify abnormal spikes or bursts of malicious behavior. Slow, consistent activity often flies under the radar.

6. Supply Chain and Trusted Software Abuse

APT groups increasingly compromise software vendors, IT providers, or managed services to infiltrate targets indirectly.
The SolarWinds attack (attributed to APT29) is a prime example: attackers compromised an update mechanism, pushing signed malicious code to thousands of customers.

Why it works: SOCs generally trust updates signed by legitimate vendors. Malicious behavior originating from a trusted source is extremely hard to flag without advanced behavioral monitoring.

7. Evasion of Detection Tools

APTs actively study SOC technologies like SIEM, EDR, and AV to craft evasion strategies.

Log tampering: Clearing or modifying event logs to erase traces of activity
Process injection: Running code inside trusted processes (like explorer.exe or svchost.exe)
Disabling security tools: Shutting down EDR agents or tampering with Windows Event Logging

Why it works: If the SOC’s visibility is reduced, analysts may miss critical parts of the attack chain.

Some APTs bypass technical detection entirely by exploiting the human element.

Recruiting insiders to provide credentials or disable monitoring
Using spear-phishing emails tailored so precisely they appear legitimate
Deploying malware via removable media or direct insider access

Why it works: SOCs can defend against malicious code, but defending against a trusted employee acting maliciously is far more complex.

Countermeasures: How SOCs Can Respond

While APTs are formidable, they are not invisible. SOCs can strengthen detection with:

Behavioral Analytics – focus on deviations in user or system behavior rather than static signatures.
Threat Hunting – proactively search for anomalies in logs and endpoints instead of waiting for alerts.
Threat Intelligence Integration – use IOCs and TTPs from frameworks like MITRE ATT&CK to spot attacker patterns.
Deception Technologies – deploy honeypots, honeytokens, or decoy accounts to lure attackers and reveal their presence.
Zero Trust Architecture – minimize reliance on implicit trust, even for internal accounts or services.
Continuous Training – upskill SOC analysts to recognize advanced techniques and not rely solely on automated alerts.

Conclusion

APT groups evade SOC detection by mastering stealth: abusing legitimate tools, operating in memory, hiding traffic in encrypted channels, stealing credentials, and carefully pacing their operations. They study defenders as much as defenders study them.

For SOC teams, the key lesson is that prevention alone is not enough. Detection must evolve from static rules to adaptive, intelligence-driven, and behavior-focused strategies.

In the arms race between attackers and defenders, APTs thrive on invisibility. SOCs must respond by shining light in the darkest corners of their networks and staying vigilant against the threats designed to hide in plain sight.

Sources

Understanding CVE-2018-0171: A Persistent Threat to Network Infrastructure

Wed, 29 Oct 2025 00:00:00 +0000

Understanding CVE-2018-0171: A Persistent Threat to Network Infrastructure

1. The Nature and Exploitation of CVE-2018-0171

1.1 What Is CVE-2018-0171?

CVE-2018-0171 is a critical remote code execution (RCE) vulnerability affecting Cisco’s Smart Install feature, which is part of the IOS and IOS XE software platforms used in Cisco switches and routers. The flaw results from improper validation of packet data, allowing unauthenticated attackers to send specially crafted Smart Install messages over TCP port 4786.

If successfully exploited, an attacker can trigger a buffer overflow, leading to denial-of-service (DoS) conditions or even full control over the affected device. The vulnerability received a CVSS v3 base score of 9.8, reflecting its critical severity.

Smart Install was designed to simplify network deployment by automatically installing and configuring new switches without manual intervention. However, its default enablement on many devices inadvertently exposed networks to attack, especially when administrators were unaware of its risks (NVD).

1.2 How the Vulnerability Is Exploited

Exploitation of CVE-2018-0171 begins when an attacker identifies a vulnerable device on the network, often using simple scanning tools to detect open TCP port 4786. They then send crafted Smart Install packets designed to overflow memory buffers within the Smart Install client.

Consequences of successful exploitation include:

Device crash or reload, resulting in temporary denial of service.
Execution of arbitrary code, potentially giving attackers persistent access.
Theft of sensitive configuration data, including routing tables, VLAN configurations, and administrative credentials.

The risk is particularly high because Smart Install is often enabled by default on many Cisco devices, meaning even a minimally secured network can be compromised without authentication. Older Cisco devices running software prior to IOS 12.2(52)SE are not affected because they lack the Smart Install feature (Proficio).

1.3 Real-World Exploitation

Despite being disclosed in 2018, CVE-2018-0171 remains actively exploited. For instance, the Static Tundra group, a Russian state-sponsored cyber espionage operation, has repeatedly leveraged this vulnerability to infiltrate networks in multiple sectors: telecommunications, higher education, and manufacturing.

Attackers typically use the vulnerability to:

Steal configuration files, giving insight into network structure.
Establish persistent access, allowing long-term surveillance.
Move laterally within networks, potentially reaching sensitive systems.

Reports have confirmed that unpatched devices, particularly end-of-life switches and routers, remain the primary targets. This real-world activity demonstrates that legacy vulnerabilities can persist for years if not actively managed (Talos Intelligence, Splunk).

2. Mitigation and Defense Strategies

Protecting networks against CVE-2018-0171 requires a multi-layered approach, combining software updates, feature management, network segmentation, and continuous monitoring.

2.1 Applying Cisco’s Security Patches

The most effective way to mitigate CVE-2018-0171 is by upgrading affected devices to patched software versions. Cisco has released updates for all impacted IOS and IOS XE releases.

Administrators should use tools like the Cisco IOS Software Checker to:

Identify vulnerable devices.
Verify patch availability.
Schedule updates during maintenance windows to minimize downtime.

Prompt patching prevents attackers from exploiting the vulnerability while maintaining network performance and security (Proficio).

2.2 Disabling the Smart Install Client Feature

If patching cannot be performed immediately, disabling the Smart Install client provides an effective interim mitigation. Disabling this feature ensures the device no longer listens on TCP port 4786, removing the attack vector.

Cisco provides a safe procedure to disable Smart Install, which involves executing specific commands in the device configuration. While this may limit some automated deployment functionalities, it significantly reduces exposure until patches can be applied (Talos Intelligence).

2.3 Network Segmentation and Monitoring

Beyond patching and feature management, network segmentation is critical. Segmentation separates critical infrastructure (e.g., core routers, data center switches) from less sensitive devices, reducing the risk of lateral movement by attackers.

Additionally, continuous network monitoring allows early detection of malicious activity. Monitoring traffic on TCP port 4786 can reveal unauthorized attempts to exploit Smart Install, enabling rapid incident response before damage occurs.

2.4 Regular Vulnerability Assessments

Ongoing vulnerability assessments are essential to maintaining a secure network environment. Regular scans identify devices with outdated firmware, misconfigurations, or enabled features that could be exploited.

Organizations should also maintain an asset inventory to ensure all network devices are accounted for and updated. Automated tools like the Cisco IOS Software Checker or third-party vulnerability scanners can help streamline this process and reduce human error (Proficio).

Conclusion

CVE-2018-0171 continues to pose a significant threat to network infrastructure due to its high severity and persistent exploitation by advanced threat actors.

Mitigation requires a multi-layered approach:

Apply software patches immediately.
Disable unnecessary features like Smart Install.
Segment networks to contain potential compromises.
Continuously monitor and assess vulnerabilities.

By combining proactive patching, strict feature management, network monitoring, and regular assessments, organizations can minimize the risk of exploitation and protect critical network assets. Vigilance, ongoing maintenance, and rapid response remain the best defenses against legacy vulnerabilities like CVE-2018-0171.

Sources

The Log4Shell Vulnerability

Sun, 26 Nov 2023 00:00:00 +0000

Introduction

Log4Shell refers to a software weakness found in Apache Log4j 2, a widely used Java library used to log error messages in software applications. This vulnerability, identified as CVE-2021-44228, allows a malicious remote attacker to gain control over an internet-connected device running specific versions of Log4j 2.

A researcher from the Alibaba Cloud team reported the vulnerability on November 24, 2021, and Apache publicly disclosed it on December 9, 2021. This is a significant problem because it affects an extensive range of devices, numbering in the hundreds of millions.

This vulnerability can be abused by attackers through text messages to remotely manipulate a computer. Due to the ease with which it can be exploited, this vulnerability has been given the highest possible severity score (10/10).

Part 1: Understanding the Vulnerability

a. Log4Shell Mechanism

Log4j2 comes with a built-in feature called ‘Message Lookup Substitution.’ This functionality allows specific strings to be swapped, during the logging process, with dynamically generated strings.

The vulnerability arises from a feature called JNDI (Java Naming and Directory Interface) lookup, which allows Log4j configurations to reference external resources like LDAP servers. This feature allows a designated Java class to be retrieved from a remote location and deserialized, thus executing part of the class code. In this way, the attacker can obtain remote code execution on the application.

Here’s a schema which shows the attack flow of Log4Shell using an LDAP server:

Source: Cloud One Security Workshop

Step-by-step explication:

The attacker scans the Internet looking for exposed Log4j vulnerable applications.
The attacker sends the crafted log entry to the target application’s log system via a web form or API request.
When the target application logs the malicious entry, Apache Log4j 2 parses the log entry and processes it. If the Log4j version is vulnerable and the payload is successful, Log4j will query the remote LDAP server (or another resource specified in the payload).
The LDAP server will respond to the query with a malicious payload containing a malicious Java class.
The victim’s server will download and execute the malicious payload, and the attacker will, for example, have a remote shell on the victim’s server.

For more insights or hands-on experience, the platform TryHackMe offers a room called ‘Solar, exploiting log4j’ with a detailed Proof of Concept.

b. Potential Impacts

Log4Shell has had a huge impact on organizations worldwide. Once exploited, it allows the attacker complete remote access and control over the device. A successful attack may result in:

Data exfiltration: Attackers can steal sensitive data from affected devices.
Financial consequences: According to Atatus, remediation costs can reach approximately $33,000.
System Compromise: Can lead to complete compromise of systems and networks.
Reputational damage: Public breaches can erode customer trust and affect revenue.

Part 2: Reaction and Solutions

c. Community Response

The cybersecurity community responded swiftly. Security experts, developers, and organizations assessed systems and collaborated on mitigation.

A notable example is a GitHub repository listing affected components, apps, and vendors.

Community collaboration helped share tools, patches, and vital information to secure systems.

d. Detection & Mitigation

Detection:

Determine where Log4j is used and whether the versions are vulnerable. You can use YARA rules to scan for Log4Shell exploitation attempts. One such rule is available here.

If assets are potentially affected, isolate them:

Physically remove from the network
Move to a “jail VLAN”
Block at the network layer
Implement strict firewall rules
Restrict communication to the internet and the enterprise network

All Log4j versions up to and including 2.16.0 are vulnerable. Upgrade to version 2.17.0 or higher.

If an upgrade isn’t possible, disable the JNDI feature in the log4j2.xml or log4j2.properties:

<Configuration>
 <Properties>
 <Property name="log4j2.formatMsgNoLookups">true</Property>
 </Properties>
</Configuration>

Additionally, use firewall rules to limit access to Log4j services. Whitelist trusted IP addresses and block others.

Continue to hunt for compromise indicators and initiate Incident Response if needed.

Conclusion

The Log4Shell vulnerability (CVE-2021-44228) is a critical cybersecurity issue that allows remote code execution through flaws in Apache Log4j 2.

It stems from ‘Message Lookup Substitution’ and JNDI features, and its exploitation can lead to severe consequences, including data breaches, system compromises, and financial losses.

The cybersecurity community responded quickly with collaboration, patches, and shared resources. Mitigation includes detection, isolation, updates, configuration changes, and network restrictions.

Rayan Annabi on Senthorus Blog

Killing the Sensor First: What Happens Before the Encryptor Runs

Introduction

The stage nobody watches

Why a signed driver works so well

What changed over the last eighteen months

Where the chain leaves traces

Four places to look

Hardening, and its ceiling

Conclusion

Sources

How APT Groups Evade Detection in a SOC

How APT Groups Evade Detection in a SOC

1. Living Off the Land (LOLBins)

2. Fileless Malware and Memory-Resident Payloads

3. Encryption and Traffic Obfuscation

4. Credential Theft and Abuse

5. Low-and-Slow Tactics

6. Supply Chain and Trusted Software Abuse

7. Evasion of Detection Tools

8. Insider Threats and Social Engineering

Countermeasures: How SOCs Can Respond

Conclusion

Sources

Understanding CVE-2018-0171: A Persistent Threat to Network Infrastructure

Understanding CVE-2018-0171: A Persistent Threat to Network Infrastructure

1. The Nature and Exploitation of CVE-2018-0171

1.1 What Is CVE-2018-0171?

1.2 How the Vulnerability Is Exploited

1.3 Real-World Exploitation

2. Mitigation and Defense Strategies

2.1 Applying Cisco’s Security Patches

2.2 Disabling the Smart Install Client Feature

2.3 Network Segmentation and Monitoring

2.4 Regular Vulnerability Assessments

Conclusion

Sources

The Log4Shell Vulnerability

Introduction

Part 1: Understanding the Vulnerability

a. Log4Shell Mechanism

b. Potential Impacts

Part 2: Reaction and Solutions

c. Community Response

d. Detection & Mitigation

Conclusion

References