Obfuscation is a technique widely used by cybercriminals, Advanced Persistent Threat (APT) groups, and even red-teaming operations. APTs, in particular, rely on obfuscation to remain undetected within networks for extended periods. However, modern malware, ransomware, and Living-off-the-Land (LotL) attacks also employ obfuscation techniques to evade conventional detection systems. Understanding how to detect these obfuscated threats is critical to modern threat hunting and incident response.

Real-World Example: Obfuscation in Cyber Attacks

A recent attack highlights how obfuscation is strategically used to bypass security measures. Cybercriminals leveraged invoice-themed phishing emails to distribute malware such as Venom RAT, Remcos RAT, XWorm, and NanoCore RAT through a multi-stage infection chain:

1. Phishing Email with Malicious SVG Attachment: The email contained an attachment that, when clicked, initiated the attack.
2. Use of BatCloak and ScrubCrypt: These tools obscure the malware, preventing detection by signature-based security systems.
3. Execution of Venom RAT and Additional Malware: The malware deploys persistence mechanisms to anchor itself within the system while bypassing security protections like AMSI and ETW.
4. Data Theft and System Control: Venom RAT grants attackers remote access to the infected system, loads additional plugins, and exfiltrates sensitive data, including cryptocurrency wallet information.

This case demonstrates how modern cyberattacks leverage obfuscation to infiltrate IT environments undetected.

Common Obfuscation Techniques

Threat actors use various techniques to disguise malware and malicious activities:

• Code Obfuscation: Encrypting or scrambling malicious code to evade signature-based detection.
• Packing & Encoding: Using packers and crypters (e.g., ScrubCrypt) to obscure malware.
• Steganography: Concealing malicious code within seemingly benign files.
• Living-off-the-Land (LotL) Attacks: Exploiting legitimate system tools such as PowerShell and WMI for malicious purposes.
• Traffic Obfuscation: Concealing malicious communication within legitimate cloud services or encrypted tunnels.

Why Traditional Security Tools Fail

Many Endpoint Detection and Response (EDR) and Antivirus (AV) solutions rely on signatures or heuristic algorithms to detect threats. However, modern obfuscation techniques are designed specifically to circumvent these mechanisms. The major weaknesses of conventional security tools include:

• Polymorphic Malware: Constantly changes its code with each infection, rendering signature-based detection ineffective. Attackers use this technique to bypass antivirus solutions and distribute new malware variants continuously.
• Obfuscation via Legitimate Tools: Threat actors abuse trusted system tools such as PowerShell and WMI to execute malicious code. Since these tools are essential components of modern operating systems, their activity often appears benign, allowing them to bypass traditional security measures.
• Memory-Only Malware: Some threats reside exclusively in memory without leaving traces on disk. Many security solutions primarily scan files rather than analyzing volatile memory or process behavior, making it extremely difficult to detect such attacks.
• Multi-Stage Infection Chains: Cyberattacks increasingly use multi-stage installations, where an initially harmless file is executed to later retrieve and deploy additional malicious payloads. This strategy complicates detection since the actual malware may only activate after several steps.
• Bypassing Security Mechanisms: Many modern malware families are engineered to disable or evade security features such as AMSI (Antimalware Scan Interface) and ETW (Event Tracing for Windows), allowing them to operate stealthily even on systems protected by advanced EDR solutions.

How THOR Uncovers Hidden Cyber Threats

Understanding how to detect obfuscated threats requires more than reactive detection or simple IOC matching. While traditional EDR and AV solutions rely on recognizing known signatures, THOR leverages YARA-, Sigma-, and anomaly-based detection methods to identify hidden attacks and trace their origins. With that, Nextron’s THOR employs cutting-edge threat-hunting techniques to expose even the most sophisticated obfuscated threats. These advanced techniques go beyond static signature recognition and actively identify behavioral anomalies, suspicious patterns, and hidden attack indicators that would otherwise remain undetected.

As an on-demand forensic scanner, THOR inspects file systems, memory, logs, and system artifacts during scheduled or manually triggered scans. Its detection capabilities rely on a combination of YARA rules, Sigma rules, and anomaly detection techniques designed to uncover obfuscated activity and behavioral deviations indicative of compromise. Unlike conventional tools that depend solely on predefined threat intelligence, THOR applies a curated set of generic detection rules that surface suspicious patterns—even those associated with novel or previously unknown threats—by highlighting inconsistencies, misuse of legitimate tools, and traces typically missed by AV or EDR solutions.

Why THOR Is the Ultimate Threat Hunting Solution

• Identifies hacker tools, malware outputs, and customized threats that evade traditional signature-based detection.
• Requires no installation – runs portably, remotely, or through the ASGARD Management Center.
• Uses anomaly-based detection to uncover even unknown threats.

Gaining Visibility: The Key to Defeating Obfuscated Threats

Obfuscation is one of the most powerful techniques employed by modern attackers. However, with THOR, even well-hidden threats can be exposed. By combining YARA, Sigma, and behavioral anomaly analysis, Nextron provides a robust cybersecurity solution for rapidly identifying compromised systems.

Have you checked your IT environment for hidden threats? Try THOR now! 🚀

Security strategies often assume that systems can be patched, upgraded, or replaced. In reality, many critical environments operate on legacy platforms where these options are impractical. Industrial control networks, healthcare systems, and government infrastructure frequently rely on outdated operating systems and specialized hardware that remain essential despite lacking vendor support or security updates.

Patching? Not always possible. Upgrading? Too risky or too expensive. Replacing? Out of scope. These systems persist because they must, and attackers know it. Legacy systems become low-hanging fruit—under-protected, overlooked, and vulnerable.

When traditional security solutions fall short, forensic-level detection and compromise assessment become essential. Nextron Systems provides these capabilities with THOR and THOR Thunderstorm, enabling organizations to analyze and secure legacy systems without requiring software installations or real-time monitoring.

Why Legacy Systems Persist (And Why Attackers Love Them)

If you’re reading this, you probably know why legacy systems are still around. But for context, let’s clarify why they’re still in production:

• Regulatory or Compliance Needs – Industries like finance, healthcare, and critical infrastructure must often stick with certified, validated software. Moving to new versions is slow, expensive, and bureaucratically painful.
• Operational Dependencies – Some systems are mission-critical and only function on specific OS versions. Changing them risks breaking core operations.
• Cost Constraints – Replacing legacy systems can be prohibitively expensive, particularly for bespoke or embedded systems.
• Hardware Limitations – Older industrial machines and embedded devices simply can’t run modern software.
• Security Tool Incompatibility – Most EDRs and antivirus tools have abandoned support for systems like Windows XP, Server 2003, or IBM AIX.

These outdated systems and isolated networks become prime targets for attackers, offering the path of least resistance. They, often neglected by traditional security tools, present significant security gaps that attackers are quick to exploit. As a result, organizations struggle to find effective ways to secure them, leaving critical infrastructure vulnerable to compromise.

Why Patching Isn’t Always an Option

Security experts love saying, “Just patch it.” But in the real world, that’s not always an option. Here’s why:

• End-of-Life Software – The vendor isn’t issuing patches. The system is on its own.
• Operational Risk – A failed patch could take down a critical system, with impacts ranging from financial loss to public safety risks.
• Isolated Environments – Air-gapped systems and IOT networks don’t have an easy patch path.

Since patching isn’t always an option, organizations need alternative security strategies that provide threat detection and forensic investigation capabilities – without requiring an agent or software installation.

How THOR & THOR Thunderstorm Secure Legacy Systems

Nextron Systems’ forensic security tools provide powerful detection and compromise assessment capabilities, even for outdated, unsupported, or isolated platforms:

1. THOR – Portable Compromise Assessment & Malware Detection

• Agentless scanning – No installation required.
• Compatible with legacy OS – Supports Windows XP, Server 2003, IBM AIX, UNIX-based systems, and more.
• Deep forensic detection – Finds dual-use tools, web shells, backdoors, credential theft, and system anomalies.
• Independent of EDR support – Operates also in environments where traditional tools fail.
• Best for: Offline scanning, forensic analysis, and post-breach investigations.

2. THOR Thunderstorm – Live Forensic Scanning for Air-Gapped & Isolated Systems

• Minimalist scanning – Uses built-in system tools like find and curl to collect artifacts.
• No dependencies – Works without agents, software installations, or kernel access.
• Flexible deployment – Supports scanning industrial control systems (ICS), embedded devices, and IOT environments.
• Customizable detection – Leverages YARA and Sigma rules to detect hidden threats.
• Best for: Securing air-gapped networks, industrial control systems (ICS), and legacy UNIX/Linux environments.

Real-World Use Cases

• Windows XP & Legacy Systems – Many enterprises still run Windows XP or Server 2003 due to software dependencies. THOR can scan these systems where modern security tools no longer function.
• IBM AIX & UNIX Environments – Traditional security tools don’t cover AIX or legacy UNIX. THOR scans these systems to detect malware, backdoors, and system anomalies.
• Air-Gapped and IOT Networks – Industrial environments and air-gapped systems cannot use traditional security tools. THOR Thunderstorm enables agent-less forensic scanning, even in isolated environments.
• Critical Infrastructure & ICS Security – Industrial control systems (ICS) cannot be patched frequently. THOR provides forensic detection without impacting system uptime.

Protecting Systems Others Ignore

Legacy systems won’t disappear overnight, but that doesn’t mean they have to remain unprotected. Nextron Systems’ THOR and THOR Thunderstorm provide the forensic visibility organizations need to detect and analyze threats – across outdated, unsupported, and isolated systems.

Need to secure an outdated IT environment? Contact us today to learn how THOR can help.

In my 2024 article, Cyber Security 2024: Key Trends Beyond the Hype, I aimed to stay rational and avoid hype—especially around AI—and pointed out that most real-world attacks still involved unpatched systems, weak credentials, and social engineering. Over the past year, that has largely remained true.

Now, as we move into 2025, I’m revisiting those same areas with updated examples. Supply chain attacks remain a key concern—especially for identity providers and open-source libraries. Token and cloud API abuse hasn’t slowed down, and attackers keep finding ways to bypass or disable EDR solutions, often hiding behind legitimate software. Meanwhile, basic security missteps still leave many organizations open to recurring threats.

Although I was skeptical about AI-based attacks last year, we do see attackers using AI to automate tasks like scripting or generating phishing emails. There’s still no proof of a fully AI-driven breach from start to finish—it’s more of an efficiency boost than a total game-changer. My goal here is to remain as sober and factual as possible, highlighting what’s genuinely evolving in these trends and where we should pay close attention going into 2025.

1. Supply Chain Attacks

Supply chain attacks continue to pose a serious threat to organizations of all sizes, even those with sophisticated security measures. While these attacks often target software providers or trusted third-party vendors, recent events show that Identity and Access Management (IAM) service providers themselves can become single points of failure. A single breach at a major identity platform can compromise thousands of companies at once, exposing credentials, tokens, and other valuable data.

Okta: A Breach That Shook Customer Trust

Okta’s late-2023 breach is a prime example of how quickly an incident can escalate. Initially, the company reported that only 1% of customers were affected. Weeks later, it revealed that its entire customer base was impacted. To an outside observer, it seems Okta was overwhelmed by the attack’s sophistication and remained cautious in what it disclosed. As more details emerged, the root cause turned out to be surprisingly mundane – an Okta employee logged into a personal Google account on a corporate laptop, opening the door for a massive data exposure. For organizations depending on IAM services, it’s a stark reminder that even top-tier providers have blind spots, and if they’re compromised, the implications can be extremely severe.

Microsoft: The Underrated Damage of a Compromised Key

Shortly after the Okta breach, another incident at Microsoft highlighted just how powerful stolen signing keys can be. In an attack attributed to a Chinese threat actor (Storm-0558), a private encryption key for Microsoft’s identity services was taken.

While Microsoft initially stated the attack impacted only Outlook.com and Exchange Online, independent research suggests the key could have theoretically been used to forge tokens for services like SharePoint, OneDrive, Teams, or even third-party apps using “Login with Microsoft.” Because identity provider keys can grant access to a huge number of services, this breach may be more significant than Microsoft’s public statements suggest.

In reality, organizations have little direct control over how a major cloud provider safeguards its signing keys, so transparency from the provider after any compromise is crucial. Without clear information about the nature and scope of a breach, customers can’t accurately assess their exposure or respond effectively.

Open Source Supply Chain Risks

Open source ecosystems also continue to be a prime target. Malicious actors tamper with NPM packages, PyPi modules, GitHub repositories, or other code libraries, embedding backdoors in widely used dependencies. A notable example involves XZ Utils, a Linux compression library, which was briefly taken over by a suspicious contributor who shipped malicious updates aimed at undermining SSH authentication. Luckily, the rogue versions (5.6.0 and 5.6.1) weren’t widely adopted, limiting real-world impact. However, if they had been broadly deployed—especially in embedded or firmware environments—the fallout could have been much worse. As the reliance on open source only grows, so does the importance of continuous monitoring, code signing, and stricter vendor risk assessment.

These incidents show how quickly a single supplier or identity service compromise can affect thousands of organizations. Sometimes, more details only emerge after weeks, revealing a bigger problem than originally reported. When widely used vendors or open-source libraries are attacked, the damage often extends far beyond one victim. Because so many companies rely on the same tools and providers, supply chain attacks remain one of the most serious threats in cybersecurity today.

2. Token and Cloud API Abuse

Session tokens have become a critical part of modern authentication flows. They let users stay logged in to web apps, cloud consoles, and enterprise services without repeatedly entering credentials. While this feels convenient, it also introduces new ways for attackers to slip through defenses—even in setups that use multi-factor authentication (MFA). If a token is stolen or forged, someone with malicious intent can bypass many security checks and move laterally with little friction.

Below are some practical points worth highlighting:

Token Forging (Lessons from High-Profile Breaches)

The Microsoft Storm-0558 incident showed that losing control of a signing key can be more damaging than a typical credential leak. If attackers can forge their own tokens, they’re suddenly able to impersonate users in multiple cloud services. For any organization relying on a major cloud or identity provider, it’s important to understand how those critical signing keys are protected—because if they’re compromised, you’ll want to detect and respond immediately.

Third-Party Integrations and Code Repositories

Many organizations rely on services like Slack, Teams, or analytics platforms, which connect via tokens or API keys. These secrets often end up in code repositories, config files, or logs. Attackers systematically comb through public GitHub repos to find them. Integrating scanning tools (e.g., GitGuardian or truffleHog) into your CI/CD pipeline can help detect these tokens before they become a liability.

Beyond Web Browsers

Token theft isn’t limited to standard web sessions. Many Office 365–integrated apps, mobile apps, backend microservices, or serverless functions rely on tokens that can offer broader network access than a local user account. Although LSASS (Local Security Authority Subsystem Service) is also a user-mode process, it often has stronger protections (for example, Credential Guard or Protected Process Light) that make direct memory access more difficult. In contrast, Office 365–integrated apps and other cloud-connected processes may not have those same security measures, which can make token extraction easier. Worse yet, these tokens can have privileges that extend into various cloud services, potentially causing greater damage than a compromised local account.

At a minimum, turning on logging or anomaly detection for internal API calls can help reveal suspicious token usage—meaning you’d track typical patterns of API calls (who calls what, how often, at what times, etc.) and flag any outliers. For instance, if a token with standard user permissions starts performing admin-like actions on backend systems, or if an unusual volume of calls occurs outside normal work hours, that could trigger an alert for further investigation.

Zero Trust Increases Token Value

In a zero-trust setup, every request is authenticated—usually via a token. When those tokens become the primary way of granting access, attackers will prioritize stealing or forging them. Requiring continuous validation, checking for abnormal IP addresses or login times, and limiting privileges to the bare essentials can mitigate some of these risks.

User Education & MFA

Even robust technical defenses can fail if employees share their tokens or accept rogue MFA prompts. Attackers keep finding new ways to trick users into handing over access, including real-time phishing tactics that intercept session cookies. Regularly updating security training—and emphasizing the changing face of phishing—is crucial.

By keeping an eye on token usage, scanning for accidental leaks, and teaching employees to question unusual login prompts, organizations can make token abuse more difficult for attackers. It’s not an all-encompassing fix, but it helps curb the most common ways threat actors leverage stolen or forged tokens.

3. Evading EDR in Heavily Monitored Environments

As Endpoint Detection and Response (EDR) solutions become more common on workstations and servers, attackers have adapted. Instead of dropping obvious malware onto well-monitored endpoints, they’ll often store malicious tools on older or unmonitored systems (e.g., network appliances, print servers, exotic systems, outdated embedded devices) and later pivot into the EDR-guarded zone. However, not all attackers stop there—some actively disable EDR agents on highly monitored endpoints to move about undetected.

Below are some recurring tactics we’re observing:

Relying on Legitimate Accounts

Attackers often hijack compromised user or admin accounts to access files, internal apps, or cloud services. Because these actions seem normal on the surface, they frequently slip past rule-based detections. Baselines of typical user behavior or alerting on suspicious account usage can help spot these scenarios.

Direct Attacks on EDR Agents

Some adversaries go beyond evasion and deliberately disable the EDR’s visibility on a targeted system. They may load a known vulnerable driver, gaining kernel privileges to unhook or kill the security agent altogether. Once the agent is neutralized, attackers can deploy tools or tamper with the OS without detection. 

Minimizing Additional Tools

Rather than dropping custom executables (which EDR might flag), attackers use existing OS utilities (e.g., PowerShell, WMI) to escalate privileges, move laterally, or exfiltrate data. These “living off the land” techniques leave fewer artifacts and require closer scrutiny of standard processes to detect anomalies.

Staging Tools on Under-Protected Systems

Attackers often target devices that aren’t covered by modern EDR solutions—like older servers, virtual appliances, or networking appliances from vendors such as Fortinet, Ivanti, and Cisco. These devices not only suffer from recurring critical vulnerabilities but also offer limited logging and a restricted shell, making them hard to investigate thoroughly. By focusing on these “blind spots,” attackers can store malicious tools, launch deeper intrusions, and exfiltrate data without triggering the usual EDR alarms. If these systems aren’t regularly patched and closely watched, they remain a constant weak point in the network.

Layered Social Engineering

Gaining higher privileges often starts with subtle phishing or manipulation tactics. By impersonating help desk personnel, building rapport with employees, or sprinkling in accurate technical details, attackers trick people into revealing credentials. Once they have elevated access, they keep their actions low-key to avoid raising alarms.

Reconnaissance for Weak Spots

Attackers frequently scope out which endpoints are guarded by EDR or similar monitoring tools. They might read internal documentation or test quiet scans to see what triggers alerts. This reconnaissance phase is marked by caution—any loud move could blow their cover.

Stealthy Persistence

To avoid leaving clear IOCs, attackers combine Windows Registry modifications, scheduled tasks, or WMI event subscriptions with stolen tokens from valid sessions. A valid token may allow them to continuously re-authenticate without dropping any new binaries. In a large environment, this can linger for weeks if there are no specific checks for reused or anomalous tokens. Organizations need continuous, behavior-based monitoring to detect unexpected processes, modified configurations, and suspicious token usage.

4. Abuse of Legitimate Software

Attackers are increasingly swapping out traditional malware for legitimate software to evade detection. Whereas classic remote access trojans (RATs) often trigger antivirus and EDR alerts, legitimate tools like ConnectWise Control, Anydesk, NetSupport, TeamViewer, Atera, LogMeIn, or Splashtop usually fly under the radar because they’re widely used by IT teams. The same goes for built-in utilities and common third-party applications that aren’t inherently malicious. When adversaries exploit these, it’s harder for security products to flag the activity as unusual – especially in large organizations.

For a comprehensive list of remote monitoring and management (RMM) software that can be abused, check out LOLRMM.io. It’s a curated catalog of legitimate RMM tools that threat actors might leverage. Use it to inform your threat hunting, detection rules, and policy creation.

Here are some key trends we’re seeing:

Persistence Without Malware

Instead of deploying custom binaries, attackers install legitimate remote access software with benign-sounding names. Because these tools aren’t flagged as malicious, they help attackers remain on the network longer without triggering the usual alarms.

Lateral Movement with Built-in Tools

Beyond remote access, attackers also rely on built-in OS utilities (like net.exe, sc.exe, WMI, or even scheduled tasks) to explore and pivot across the environment. This strategy further masks their presence since they’re only using functionality that system administrators use daily.

Hiding in Plain Sight

Many threat actors register or reuse official-looking certificates and domain names (for example, connecting to “support.yourcompany.com”) to blend into real admin traffic. Security teams might notice some suspicious command sequences if they’re watching closely, but the software itself often goes unnoticed.

Configuration Backdoors

Some attackers don’t even need to run a process continuously. They alter configurations or schedules in existing tools. For instance, a legitimate remote management solution might be set to launch after hours, connecting back to an attacker-controlled server. Without a baseline of normal usage, it can be tough to see these modifications.

“Malware-less” Attacks

Because this approach doesn’t rely on a discrete piece of malware, it sidesteps many classic detection methods. Alerting on suspicious behaviors or unexpected connections becomes essential. Tools and processes that appear valid at first glance can still be used to exfiltrate data or execute commands silently.

5. AI-Aided Attacks – What’s Really Happening

For years, experts have debated the potential for game-changing AI-driven cyberattacks. While AI can streamline malicious operations, we’re not yet seeing radically new exploits. Instead, threat actors mostly use AI to speed up or automate tasks they already do—like writing scripts, debugging code, or crafting phishing lures.

Our findings align with recent analysis by the Google Threat Intelligence Group, who break down AI misuse into four broad categories:

Research & Reconnaissance

Attackers use AI to gather intelligence on target organizations, look up vulnerabilities, and sift through large data sets or open-source reports. This makes it easier for them to pinpoint weak spots and refine future exploits without manually combing through dense documentation.

Phishing & Social Engineering

AI-driven text generation helps create believable phishing messages in any language and can even spin up fake personas for social engineering or disinformation campaigns. The grammar is better, and the phrasing can be tailored to specific targets, reducing red flags.

Malware Development & Scripting

From coding new tools to obfuscating existing scripts, AI can automate much of the grunt work. Attackers—especially those with limited coding skills—gain the ability to produce or refine malicious software more quickly and with fewer errors.

Automation & Evasion

AI can assist with scripting tasks that bypass security measures, escalate privileges, and evade detection. It also lets attackers rapidly generate variants of known attacks, forcing defenders to react faster and update signatures or detections more often.

No Revolutionary Shift—Yet

Even with these AI-enabled efficiencies, there’s no sign of “AI-only” attacks or groundbreaking new exploits driven purely by machine learning. Most of the advantage lies in speed and scale: Threat actors spend less time writing or localizing content and more time on actual infiltration. The real concern going forward is the proliferation of powerful open-source AI models with minimal guardrails, which could further accelerate malicious automation and make these categories of misuse more accessible to a wider range of adversaries.

Conclusion

From supply chain attacks and token abuse to advanced evasion and the misuse of legitimate software, attackers are still relying on familiar methods—just with new twists and a growing interest in AI. Despite these evolving trends, unpatched appliances and missing MFA remain the most common pathways into an organization. While AI speeds up certain steps for attackers, it doesn’t turn breaches into an entirely new game. Instead, it’s an additional tool that defenders also need to adopt—otherwise, they risk falling behind.

Nextron’s Approach to Advanced Threat Detection

Nextron provides specialized digital forensics solutions designed to detect threats that traditional security tools often overlook. Our technology identifies unusual system behavior, hidden malicious activity, and sophisticated attacks that evade conventional antivirus and EDR products.

Our comprehensive signature set detects a broad spectrum of threats, including attacker toolkits, forensic traces, abuse of legitimate applications, and supply chain-based compromises. This extends to identifying “malware-free” intrusions, where adversaries operate without deploying conventional malware, making them difficult to detect.

Additionally, Nextron’s solutions support flexible scanning for unsupported or legacy systems that standard EDR platforms cannot monitor. This allows organizations to expand their detection coverage, ensuring a more comprehensive and actionable security posture across their entire environment.

According to recent reports, cyberattacks rose by 75% in the third quarter of 2024 compared to the same period in the previous year and by 15% compared to the second quarter of 2024. This alarming trend clearly shows that companies are more than ever required to protect their intellectual property, customer data, and reputation.

In today’s interview, Frank Oster, Senior Security Advisor at Nextron Systems, explains why a second line of defense is essential and how companies can benefit from it.

How do you define the first and second line of defense in IT security? 

Frank Oster: The threat landscape has changed significantly. Cybercriminals are becoming more sophisticated and increasingly bypass traditional security mechanisms. The first line of defense consists of technologies such as firewalls, antivirus software, and Endpoint Detection and Response (EDR) systems. These solutions block known threats and prevent unauthorized access.
But what happens when attackers gradually and almost imperceptibly overcome these barriers? This is where the second line of defense comes into play. It detects attackers who have already infiltrated a system and may have been active for an extended period. This approach serves as an additional protective measure and does not replace the solutions of the first line of defense.

What measures are part of the second line of defense?

Frank Oster: The second line of defense includes APT scanners, forensic analysis, and intrusion detection systems. The key difference lies in their approach: While the first line is designed to prevent attacks, the second line focuses on detecting and analyzing threats that have already infiltrated the system. It ensures that no attack goes unnoticed and can be contained quickly. In other words, companies gain crucial time to identify and combat even highly specialized, targeted attacks conducted with significant financial resources.

What role do APT scanners play in this context?

Frank Oster: APT-scanners like THOR are key technologies of the second line of defense. Advanced Persistent Threats (APTs) and other sophisticated attacks intentionally evade traditional security mechanisms and remain undetected for long periods.

An APT scanner searches for indicators of such threats—suspicious log files, obfuscation techniques, or hidden malware. It not only detects known threats using Indicators of Compromise (IOCs) but also identifies suspicious behavior based on YARA and Sigma rules, which may indicate deeply embedded attacks.

Are APT scanners specifically designed to detect targeted attacks?

Frank Oster: Exactly. These scanners identify IOCs and use various techniques to make hidden threats visible. They analyze how deeply an attack has already penetrated the system. This is crucial because the longer a threat remains undetected, the harder it becomes to recognize and eliminate.

Would you recommend integrating APT scanners into a company’s security framework?

Frank Oster: Absolutely. These scanners enable targeted and periodic security assessments to determine whether a company has been compromised.

THOR can be seamlessly integrated with SIEMs, Threat Intelligence platforms (e.g., MISP), and the ASGARD Management Center, enabling centralized management and analysis of results.

These systems identify suspicious activities and document them, allowing incident response teams to react quickly. However, it is important to note that THOR does not provide real-time detection or response like EDR solutions. Instead, it facilitates in-depth forensic analysis, making attacks visible and enabling effective investigations.

What is your ideal security approach?

Frank Oster: A multi-layered security approach is ideal. The first line of defense – including antivirus software, firewalls, and EDR solutions – is essential. However, the second line of defense is just as crucial, as it detects what the first line may have missed. As mentioned earlier, it has become more important than ever for companies to detect and contain attacks before they cause significant damage. Last but not least: Employee awareness remains a critical success factor in the fight against cybercrime.

Is the second line of defense also a tool for damage mitigation?

Frank Oster:  Definitely: It functions like an emergency response team that intervenes when an attack has occurred. Technologies like THOR enable incident response teams to systematically search for attack traces and reconstruct the attack chain. This allows for a faster response and more precise countermeasures.

However, THOR does not stop attacks in real-time but provides valuable insights for damage mitigation and post-attack analysis. In today’s threat landscape, this forensic capability is indispensable for developing robust and resilient security strategies.

Thank you for your insights, Frank Oster.

Introduction

Lynx ransomware is a newly emerged and sophisticated malware threat that has been active since mid-2024. Lynx ransomware has claimed over 20 victims across a range of industries. Once it infiltrates a system, it encrypts critical files, appending a ‘.lynx’ extension, and deletes backup files like shadow copies to hinder recovery.

Uniquely, it also sends the ransom note to available printers, adding an unexpected element to its attack strategy.

This malware shares similarities with previous INC ransomware, indicating that they bought INC ransomware source code.

The first sample was identified by rivitna2, checking VT showed it had only 26 detections which is a low detection rate for a ransomware sample,so we decided to dive deeper.

Overview

Lynx ransomware employs a variety of techniques such as:

• Terminating processes and services.
• Directory enumeration.
• Privilege escalation.
• Deleting shadow copies.
• Encrypting all mounted drives and shared folders.
• Changing the background image.
• Printing the ransomware note.

By default when executed the ransomware will encrypt every file on the system but in addition to that it also allows the attacker to customize the ransomware behaviour via command line flags which are highlighted below :

A comprehensive list of Indicators of Compromise (IOCs) is available at the end of this article.

In the next section, we will take a closer look at Lynx ransomware and analyze its inner workings, including key aspects such as its encryption implementation and file processing methods.

Full Ransomware Analysis

The ransomware starts by calling main function and assigning flags based on the parameters passed to the ransomware.

Terminate Process

Passing the kill flag, the malware begins by enumerating all running processes and terminates any process whose name contains any of the following words:

• sql
• veeam
• backup
• exchange
• java
• notepad

First, CreateToolhelp32Snapshot is called with the TH32CS_SNAPPROCESS flag to capture a snapshot of all processes in the system. Passing 0 indicates that all processes are included.

Next, Process32FirstW retrieves information about the first process in the snapshot and stores it in the pe structure.

For each process, the code compares its name (pe.szExeFile) with the target process names array using a case-insensitive search function.

If a process name matches, OpenProcess is called with the PROCESS_TERMINATE flag to obtain a handle to the process.

Finally, TerminateProcess is called to terminate the matched process.

Enumerate Services Function

The function enumerates and terminates services along with its dependent services, if the display name or service name contains any of the words mentioned above.

OpenSCManagerW is used to obtain a handle to the service control manager database with full access permissions.

The services are enumerated and stored in lpServices.

A loop processes each service in the list, checking if it matches any of the target service names.

If a match is found, stop_services is called to stop the service along with its dependent services.

Stop Services Function

The function attempts to stop a specified service along with its dependent services.

OpenSCManagerW is used to obtain a handle to the Service Control Manager with full access permissions.

OpenServiceW is used to open the specified service with the required access rights (SERVICE_QUERY_STATUS, SERVICE_ENUMERATE_DEPENDENTS, and SERVICE_STOP).

QueryServiceStatusEx is used to query the current status of the service.

The dependent services are enumerated and stopped recursively by calling stop_services for each dependent service.

ControlService is called to send a stop command to the service.

Your data is stolen and encrypted.
Your unique identificator is %id%
Use this TOR site to contact with us:
http://lynxch2k5xi35j7hlbmwl7d6u2oz4vp2wqp6qkwol624cod3d6iqiyqd.onion/login

Use this email to contact with us:
martina.lestariid1898@proton.me

Our blog
 ~ TOR Network: http://lynxbllrfr5262yvbgtqoyq76s7mpztcqkv6tjjxgpilpma7nyoeohyd.onion/disclosures
 ~ Mirror #1: http://lynxblog.net/ 

First, the function call populates the SystemInfo structure with information about the current system, such as the number of processors.

The number of threads to be used is set to four times the number of processors in the system. This aims to leverage multi-threading to speed up disk encryption.

An I/O Completion Port is then created to manage asynchronous I/O operations.

0xffffffff: This parameter indicates that no file handle is associated with the completion port initially.
0: This parameter specifies that the completion port is not associated with an existing port.
0: The completion key is set to zero, and the last parameter specifies the maximum number of threads that can run concurrently. If it’s zero, it defaults to the number of processors.

It Creates a thread for each processor to handle I/O completion.

Each thread runs the Encryption function and uses the CompletionPort for synchronization.

The encryption function will be discussed later.

Enumerate Directory Function

The function attempts to create a README.txt file in a specified directory, it uses the FindFirstFileW function in order to find the first file in the directory.

A loop iterates over each file and directory, special directories notations like ‘.’ and ‘..’ , as well as reparse points, are skipped.

For each file, the function checks if it is a system file or has certain extensions such as ‘.exe’, ‘.msi’, ‘.dll’, ‘.lynx’, if the file does not match these criteria and is not named LYNX or README.txt, it is queued for encryption by creating a new thread.

For each subdirectory, a recursive call to ‘enum_dir’ is made.

Special directories like ‘windows’, ‘program files’, and others are skipped to avoid processing system directories.

It Handles “Program Files” and “Program Files (x86)” separately, for each subdirectory within, a recursive call to ‘enum_dir’ searching for “microsoft sql server” directory to be encrypted.

Prepare Encryption Function

This function performs several tasks:
It checks if it has write access to the file that is to be encrypted.

If it does not, it attempts privilege escalation and checks again for write access.

If a ‘stop_processes_flag’ flag is passed, the function attempts to terminate every process that has an open handle to the file at that moment.

If all these attempts fail, the file will not be encrypted.

Check Write Access Function

This function essentially checks if the malware has write access to the file being encrypted.

It does this by writing a dummy data of 36 bytes of the character “2” at the end of the file.

It then verifies if the written data is indeed 36 bytes.

If so then the data was written successfully, indicating that the malware has write access to the file.

SetFilePointerEx moves the file pointer to the end of the file.

After writing the data, the file pointer is moved back to its original position.

Finally, SetEndOfFile truncates the file, effectively removing the written data.

Privilege Escalation function

If the write check fails the ransomware will call priv_escalation which tries to enable ‘SeTakeOwnershipPrivilege’ on the current process token.
This privilege will allow the process to take ownership of an object without being granted discretionary access, With this privilege, the user can take ownership of any securable object in the system effectively granting the ransomware write access.

From a code perspective the following is how write access is granted:

1- The function starts by taking ownership of a file or directory and sets its security descriptor to grant full control to a specified group.
2- AllocateAndInitializeSid is called to create a SID for the specified group.
3- The EXPLICIT_ACCESS structure is set up to define the permissions (full control) for the new ACL.
4- SetEntriesInAclW is called to create a new ACL that grants these permissions.
5- SetNamedSecurityInfoW is used to set the DACL for the file or directory.
6- A handle to the current process token is opened using OpenProcessToken.
7- LookupPrivilegeValueW is used to get the LUID for the SeTakeOwnershipPrivilege.
9- The LUID is needed to adjust the token’s privileges.
10- AdjustTokenPrivileges is called to enable the SeTakeOwnershipPrivilege for the current process access token, this privilege is required to change the owner of the file or directory.
11- SetNamedSecurityInfoW is used again to set the ownership of the file or directory to the specified SID, this step changes the owner of the file or directory to the specified SID, the OWNER_SECURITY_INFORMATION flag is used to specify that the owner is being set.
12- LookupPrivilegeValueW is used to retrieve the LUID for SeTakeOwnershipPrivilege again, which is needed to disable the privilege in the next step
13- AdjustTokenPrivileges is used to disable the SeTakeOwnershipPrivilege privilege in the current process’s access token, returning the token to its original state.
14- SetNamedSecurityInfoW is used to re-apply the DACL to ensure that the permissions are set correctly.

Terminate Process Using Restart Manager Function

The function terminates every process that has an open handle to the file to be encrypted, it leverages the Restart Manager (RM) API to identify these processes and then terminates them, while avoiding the termination of ‘Windows Explorer’, ‘critical system processes’, and processes that the current user does not have permission to shut down.

RmStartSession initiates a new Restart Manager session.

RmRegisterResources registers the specified file as a resource to be managed within this session.

RmGetList retrieves the list of processes currently using the specified file.

The function then iterates through this list of processes. It ensures that it avoids terminating Windows Explorer (RmExplorer) and critical system processes (RmCritical). For each process, it verifies that the process is not the current one and opens it with PROCESS_TERMINATE access.

It then calls TerminateProcess to terminate the process and waits for the termination to complete using WaitForSingleObject.

The marker contains the following data of a total of 116 byte that will be appended at the end of the encrypted file:

• ECC public key (32 bytes)
• SHA512(ECC public key) (64 bytes)
• "LYNX"
• 00 00 00 00 (unknown purpose)
• 40 42 0F 00 (representing 1,000,000 – 1MB – encryption block size)
• 05 00 00 00 (possibly the encryption block step – will be explained later )
• 01 00 00 00 (number of skipped blocks a block is 5MB)

and it sets switch_value to equal 2.

As the function performs operations like reading the file, it uses the OVERLAPPED structure to manage asynchronous operations. When an operation completes, it posts a completion packet to the I/O completion port indicating that the file is ready for encryption.

The Encryption function waits for these completion packets using GetQueuedCompletionStatus. When it receives a completion packet, it processes the operation based on the switch_value set in the OVERLAPPED structure by prepare_encryption.

The Encryption function receives this packet and transitions to encrypting the file data.

Encryption Function

The Encryption function starts by setting up the environment and parameters it needs to operate.

It waits for I/O completion packets using the GetQueuedCompletionStatus function.
Waiting for I/O Completion:

The function continuously waits for an I/O completion packet. When a packet is received, it processes the operation based on the switch_value.

the switch block handles 4 cases:

• case 0
• case 1
• case 2
• case 3

as mentioned above the switch_value is set to 2, so we start explaning case 2.

Case 2 :

The function checks if the read_counter is equal to 0.

read_counter is used to count how many blocks are read/encrypted.

which leaves us with 2 cases:

1 – read_counter = 0 indicates that this is our first block to read/encrypt.

It doesn’t evaluate next_enc_block_offset.

2 – read_counter != 0 indicates that it’s not the first block to read/encrypt.

if it’s not the first block to be encrypt, next_enc_block_offset is evaluated, next_enc_block_offset is used to indicate where the next block to be encrypted .

Example:

the malware encrypt 1MB at the start of the file and then encrypt 1MB starting at 6MB , so it skips 5MB every time.

It also write the marker at the end of the file.

The function checks if the next_enc_block_offset is bigger than the filesize which means there is no more data to encrypt, and that the read_counter not equal to 0 and that means it’s not our first encryption block.
if so it then sets switch_code to 3 ( case 3 – ends the encryption – no more data to encrypt).

if not then there are more data to be encrypt.

the condition aims to determine how many bytes will be read/encrypted.
let’s break it down with example.

The first 1MB will be encrypted normally, and then it start encrypting starting from 6MB which is only the last 0.5MB but the malware reads 1MB each time so it will read 0.5 MB + 0x74 byteS (which we don’t want it to be encrypted).

The condition is trying to know how to get the right size of data to be written.

it’s doing a simple math: lpNumberOfBytesRead + next_enc_block_offset – filesize which for the given example would be:

lpNumberOfBytesRead = 0.5MB + 0x74 bytes

next_enc_block_offset = 6MB

filesize = 6.5 MB

so the result is 0x74 , if the the result is equal to 0x74 it will basically subtract the marker size from lpNumberOfBytesRead and assign that to lpNumberOfBytesWritten, lpNumberOfBytesWritten = 0.5 MB which is what we want.

Case 3 :

It renames the encrypted file to its final name and close all open handles.

The nonce is incremented after each block to ensure a unique keystream for each block.

The encrypted data is written back to the file.

Delete Shadow Copies Function

The enc_del_shadow_copies function attempts to delete shadow copies on all available drives and then proceeds to enumerate directories and encrypt them , it although encrypt network shares if the encrypt_network_flag is set.

The function iterates over each possible drive letter (‘A’ to ‘Z’) and uses GetDriveTypeW to determine if the drive is removable, fixed, or remote.

It ignores drives that are not of these types, such as CD-ROM drives or non-existent drives.

CreateFileW is called with paths in the format \\?\A:\ to create file handles for each drive.

The prefix \\?\ instructs the Windows API to treat the path as a literal string and bypass normal path parsing rules, allowing the application to work with paths longer than MAX_PATH and to include special characters.

The string A: specifies the drive letter, and the :\ following the drive letter indicates the root directory of that drive.

It attempts to delete shadow copies using DeviceIoControl with the control code 0x53C028 (IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE), setting the maximum size to 1.

The function enumerates each available drive to be encrypted.

Encrypt Shared Folders Function

This function enumerates network shares, processes each shared folder found, and handles nested resources recursively.

WNetOpenEnumW is called to start the enumeration of network resources. It uses RESOURCE_GLOBALNET to enumerate all network resources, RESOURCETYPE_ANY to include all types of resources, and 0x13u for additional options.

WNetEnumResourceW is called in a loop to enumerate network resources. It populates the currentResource buffer with resource information and updates cCount with the number of resources.

For each resource, the loop iterates over the currentResource array.

If the resource’s display type is RESOURCEDISPLAYTYPE_SHARE, it indicates a shared folder.

enum_dir is called to process the directory corresponding to the shared folder.

If the resource has a scope indicating it is a container (RESOURCEUSAGE_CONTAINER), enc_shared_folders is called recursively to enumerate its contents.

RESOURCEUSAGE_CONTAINER means that this resource is a container and can be further enumerated to find additional resources inside it.

This is commonly seen in network domains, servers, or other hierarchical structures in network environments.

Mount Volume Function

The function mounts all available volumes to specific drive letters, ensuring that no drive letters are already occupied. It iterates through an array of drive letters, identifying unoccupied ones indicated by the DRIVE_NO_ROOT_DIR status.

Using FindFirstVolumeW and FindNextVolumeW, the function iterates through all volumes.

It then mounts each volume to an available drive letter from the lpszVolumeMountPoint array using SetVolumeMountPointW.

This process ensures that every drive is mounted, making it possible for them to be encrypted.

Change Background Function

It creates a temporary image file named “background-image.jpg” in the temp folder. This file contains the ransom note as an image and sets it as the desktop wallpaper.

Print Ransom Note Function

The function enumerates every printer connected to the system and sends the ransom note to be printed.

EnumPrintersW is called to retrieve the list of printers.

It iterates through each printer, skipping “Microsoft Print to PDF” and “Microsoft XPS Document Writer”.

For each remaining printer, it uses StartDocPrinterW to start the document and StartPagePrinter to start a page.

Finally, it uses WritePrinter to send the ransom note to the printer.

IDA IDB

You can take a look at the IDA IDB for more details here.

Indicators Of Compromise

You can find all IOCs and links to the latest version of the detection rules here.

LYNX hashes:

• eaa0e773eb593b0046452f420b6db8a47178c09e6db0fa68f6a2d42c3f48e3bc
• 571f5de9dd0d509ed7e5242b9b7473c2b2cbb36ba64d38b32122a0a337d6cf8b
• b378b7ef0f906358eec595777a50f9bb5cc7bb6635e0f031d65b818a26bdc4ee
• ecbfea3e7869166dd418f15387bc33ce46f2c72168f571071916b5054d7f6e49
• 85699c7180ad77f2ede0b15862bb7b51ad9df0478ed394866ac7fa9362bf5683

INC hashes:

• 64b249eb3ab5993e7bcf5c0130e5f31cbd79dabdcad97268042780726e68533f
• 508a644d552f237615d1504aa1628566fe0e752a5bc0c882fa72b3155c322cef
• 7f104a3dfda3a7fbdd9b910d00b0169328c5d2facc10dc17b4378612ffa82d51
• 1754c9973bac8260412e5ec34bf5156f5bb157aa797f95ff4fc905439b74357a
• d147b202e98ce73802d7501366a036ea8993c4c06cdfc6921899efdd22d159c6
• 05e4f234a0f177949f375a56b1a875c9ca3d2bee97a2cb73fc2708914416c5a9
• fef674fce37d5de43a4d36e86b2c0851d738f110a0d48bae4b2dab4c6a2c373e
• 36e3c83e50a19ad1048dab7814f3922631990578aab0790401bc67dbcc90a72e
• 869d6ae8c0568e40086fd817766a503bfe130c805748e7880704985890aca947
• ee1d8ac9fef147f0751000c38ca5d72feceeaae803049a2cd49dcce15223b720
• f96ecd567d9a05a6adb33f07880eebf1d6a8709512302e363377065ca8f98f56
• 3156ee399296d55e56788b487701eb07fd5c49db04f80f5ab3dc5c4e3c071be0
• fcefe50ed02c8d315272a94f860451bfd3d86fa6ffac215e69dfa26a7a5deced
• 11cfd8e84704194ff9c56780858e9bbb9e82ff1b958149d74c43969d06ea10bd
• 02472036db9ec498ae565b344f099263f3218ecb785282150e8565d5cac92461
• e17c601551dfded76ab99a233957c5c4acf0229b46cd7fc2175ead7fe1e3d261
• 9ac550187c7c27a52c80e1c61def1d3d5e6dbae0e4eaeacf1a493908ffd3ec7d
• ca9d2440850b730ba03b3a4f410760961d15eb87e55ec502908d2546cd6f598c
• 1a7c754ae1933338c740c807ec3dcf5e18e438356990761fdc2e75a2685ebf4a
• a5925db043e3142e31f21bc18549eb7df289d7c938d56dffe3f5905af11ab97a
• 7ccea71dcec6042d83692ea9e1348f249b970af2d73c83af3f9d67c4434b2dd0
• 5a8883ad96a944593103f2f7f3a692ea3cde1ede71cf3de6750eb7a044a61486
• 1a7c754ae1933338c740c807ec3dcf5e18e438356990761fdc2e75a2685ebf4a
• 463075274e328bd47d8092f4901e67f7fff6c5d972b5ffcf821d3c988797e8e3

Detection

Yara

rule MAL_RANSOM_INC_Aug24 {
   meta:
      author = "X__Junior"
      description = "Detects INC ransomware and it's variants like Lynx"
      reference1 = "https://x.com/rivitna2/status/1817681737251471471"
      reference2 = "https://twitter.com/rivitna2/status/1701739812733014313"
      date = "2024-08-08"
      hash1 = "eaa0e773eb593b0046452f420b6db8a47178c09e6db0fa68f6a2d42c3f48e3bc" // LYNX
      hash2 = "1754c9973bac8260412e5ec34bf5156f5bb157aa797f95ff4fc905439b74357a" // INC
      score = 80
   strings:
      $s1 = "tarting full encryption in" wide
      $s2 = "oad hidden drives" wide
      $s3 = "ending note to printers" ascii
      $s4 = "uccessfully delete shadow copies from %c:/" wide

      $op1 = { 33 C9 03 C6 83 C0 02 0F 92 C1 F7 D9 0B C8 51 E8 }
      $op2 = { 8B 44 24 [1-4] 6A 00 50 FF 35 ?? ?? ?? ?? 50 FF 15}
      $op3 = { 57 50 8D 45 ?? C7 45 ?? 00 00 00 00 50 6A 00 6A 00 6A 02 6A 00 6A 02 C7 45 ?? 00 00 00 00 FF D6 FF 75 ?? E8 ?? ?? ?? ?? 83 C4 04 8B F8 8D 45 ?? 50 8D 45 ?? 50 FF 75 ?? 57 6A 02 6A 00 6A 02 FF D6 }
      $op4 = { 6A FF 8D 4? ?? 5? 8D 4? ?? 5? 8D 4? ?? 5? 5? FF 15 ?? ?? ?? ?? 85 C0 }
      $op5 = { 56 6A 00 68 01 00 10 00 FF 15 ?? ?? ?? ?? 8B F0 83 FE FF 74 ?? 6A 00 56 FF 15 ?? ?? ?? ?? 68 88 13 00 00 56 FF 15 ?? ?? ?? ?? 56 FF 15}
   condition:
      uint16(0) == 0x5A4D and
      (
         3 of ($s*)
         or 3 of ($op*)
         or (2 of ($s*) and 2 of ($op*) )
      )
}

Sigma

Potentially Suspicious Desktop Background Change Via Registry

Appendix A

Different encryption modes

When it comes to cyber-attacks, web shells play a critical role in the arsenal of cyber criminals. They can provide persistent, stealthy access to compromised systems, making them a favored tool for maintaining long-term control over infected networks. In the following blog post, we will explain how our APT scanner THOR ensures that such threats are detected and why this is essential for maintaining robust cybersecurity defenses.

Understanding the Role of Web Shells

Web shells are versatile tools used for a variety of malicious activities, including data exfiltration, privilege escalation, lateral movement within networks, and launching further attacks. Their stealthy nature, often hidden within legitimate web traffic, makes them difficult to detect with traditional security measures, complicating incident response and cleanup.

In the hands of cyber criminals, web shells act as a gateway to exploitation. They enable attackers to establish a foothold in compromised systems, allowing for remote access and control. This foothold can then be leveraged to execute a multitude of malicious actions, from stealing sensitive data to deploying ransomware or conducting reconnaissance for future attacks.

Moreover, web shells are not limited to a specific type of attack or target. They are highly adaptable and can be deployed across various platforms and environments, making them a persistent threat in today’s interconnected digital landscape.

The Limitations of Antivirus Solutions

While traditional antivirus (AV) solutions play a crucial role in cybersecurity by identifying and removing known malware, they often fall short when it comes to detecting web shells. Unlike conventional malware, which operates as standalone executables or scripts, web shells are sometimes embedded within legitimate web applications or files, making them harder to detect using signature-based detection methods.

Furthermore, cyber criminals are constantly evolving their tactics to evade detection by AV solutions. They employ obfuscation techniques or encryption, and polymorphism to disguise their web shells, rendering traditional AV ineffective against these advanced threats.

The Importance of Specialized Tools

To effectively combat web shell attacks, organizations need to supplement their existing security solutions with specialized tools designed to detect and mitigate these threats. Solutions like our APT scanner THOR utilize a large set of generic rules that combine the tiniest patterns found in common web shells to detect new, modified or embedded web shells and has specific rules to detect the obfuscation itself.

To showcase the effectiveness of THOR in detecting web shells, we recently conducted a comparison study. We compared the web shell detection coverage between THOR and 70 antivirus solutions on VirusTotal. The study utilized the largest and most respected web shell repository on GitHub, curated by Tencent. By analyzing files identified as web shells by either THOR or any of the antivirus solutions on VirusTotal, we found that THOR consistently outperformed other solutions in detecting web shells.

Methodology: A Fair and Neutral Comparison

To ensure an unbiased comparison, we utilized the largest and most popular web shell repository on GitHub, curated by Tencent. This repository is highly respected and widely used, providing a reliable basis for our analysis.

Key Points:

• Neutral Basis: We deliberately chose not to use our own web shell collection. Instead, we relied on Tencent’s repository to prevent any bias.
• Detection Criteria: Only files identified as web shells by either THOR or any of the 70 antivirus solutions on VirusTotal were included. This approach eliminated non-relevant files such as READMEs, libraries, images, and CSS files.
• Current Data: All files were uploaded and reanalyzed on VirusTotal on May 13th, 2024, ensuring the antivirus detections were up-to-date.
• Versions Used
  • THOR: Version 10.7.15, Build: c114b1893902 (2024-03-25 10:29:36)
  • Signature Database: 2024/05/06-133122
• The data files from our analysis are available for review:
  • THORcsv: THOR’s CSV output, counting duplicate MD5 hashes only once
  • webshell-vt-hash-db.json: Munin’s output from the VirusTotal search

Key Takeaways

• Superior Detection: THOR detects web shells better than any other solution on the market.
• Comprehensive Security: Our findings highlight the need for more than just AV for a resilient security architecture.

Back in January 2023 Group-IB first reported and documented the TTPs of DarkPink, an APT group that targets the Asia-Pacific regions.

We’ve been monitoring KamiKakaBot samples since September of last year. And at the start of this year in January we’ve noticed 2 new samples being uploaded to Virustotal.

These 2 new samples have had a very low detection rate. Which led us to investigate them a bit closer.

 The following is a full writeup on the newer variants KamiKakaBot samples from the initial lure to full persistence on disk and credential stealer component.

Johann Aydinbas was the first to spot this and mention it on twitter. Kudos to him.

Start Of The Infection

As discussed in the original Group-IB research blog, DarkPink APT uses ISO files as a phishing mechanism. And this case is not much different in terms of structure.The ISO in question is named “Proposed Concept Note on the AOIP-based Comprehensive Regional Architecture.iso” and contains the following.

These newer KamiKakaBot samples use “WWLIB.dll” DLL in order to side-load the malicious payload, in contrast to “MSVCR100.dll” DLL that was used in older variants.

Something to note is that winword.exe (which is the binary being used to sideload the WWLIB DLL) as well as many Microsoft Office utilities such as Excel, PowerPoint, etc are vulnerable to many other side loading vulnerabilities. As it’s illustrated in the screenshot below that’s taken from hijacklibs.net.

WWLIB Sideloading

The infection starts when the victim launches the binary “CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOCX.EXE” which is the legitimate “WinWord.exe” binary masqueraded as a word document using the double extension technique. It tries to side load the “WWLIB.dll” from the current directory.

Once loaded, it starts by searching the current directory for a file that has the following characteristics:

• Hidden
• Read Only
• Filename contains both “~” and “.doc”

The file that fits these characteristics was shipped inside of the ISO and in our case it has the name “~CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOC”

Next, it’ll start reading the aforementioned DOC file starting from the end and going up until a null byte is reached. That blob is then decrypted with a hardcoded XOR key. The content is an XML file that we will discuss later in this article.

The next step is to decrypt the file name of the XML file that will be created next. This will result in “wctA91F.tmp”.

The XML file is then created under “C:\Users\<username>\AppData\Local\Temp\”

We’re providing a Python script that emulates the decryption routine mentioned above. It takes the “DOC” and a “XOR” key and outputs the XML in question.

After the decryption routine, the DLL will try to execute the lure document by locating the legitimate Word binary installed on the system. It does this by assuming that a “Start Menu” entry exists for Word.

When an application is installed in Windows it can be added to the list of applications in the Start Menu. This is achieved by adding a shortcut “.lnk” file pointing to it. A default Microsoft Office Word installation creates a shortcut called “Word.lnk” in that location.

The DLL chooses this method of execution to avoid hard coding different paths for the “WinWord.exe” binary. As the exact location will depend on which version is installed.

Once the Word.lnk shortcut is found it proceeds to execute the lure “~CN AOIP-BASED COMPREHENSIVE REGIONAL ARCHITECTURE (1).DOC” via CreateProcessW

Below is the command line after execution.

cmd /c C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Word 2016.lnk ~CN AOIP-based Comprehensive Regional Architecture.doc

Persistence & Execution

Once the lure has been executed, the DLL sets up the following persistence mechanism in order to initiate the execution of the 2nd stage (XML payload) and to ensure execution across reboots.

It starts by setting 3 environment variables that point to the following values.

Once these variables are set. It overrides the Winlogon Shell registry entry in order to set up persistence.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell = explorer.exe, explorer.exe /e,/root,%Pyps% -nop -w h "Start-Process -N -F $env:Msbd -A $env:Temprd"

This will make sure that every time the current infected user logs onto the system, the above command is executed.

The command leverages the fact that anything passed to the “explorer.exe” binary is executed. If we replace the environment variables, we get the following PowerShell command:

powershell -nop -w h "Start-Process -N -F %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe -A %TEMP%\wctA91F.tmp"

Finally, it makes sure that the machine will shut down by setting a scheduled task called “OneDriver Reporting Task” that runs on a weekly basis, every Tuesday and Friday at 12:35PM executing the “shutdown” command:

SCHTASKS /CREATE /f /TN "OneDriver Reporting Task" /TR "shutdown /l /f" /SC WEEKLY /d TUE,FRI /ST 12:35 

After a reboot the Msbuild process will compile and run the KamiKakaBot, which we will look at next.

KamiKakaBot Says Compile Me Please

In the previous section we’ve seen that the side-loaded WWLIB.dll decrypted and dropped an XML in the temp directory that was going to be executed by MsBuild.

The XML file uses an MsBuild inline task to embed everything in one file, and it contains two components:

• KamiKakaBot Main Payload.
• KamiKakaBot Credential Stealer.

The main payload is stored as an XOR encrypted base64 blob, whereas the credential stealer is simply XOR encrypted.

The decryption key is hardcoded in the task itself.

The tasks start by generating a random name for the credential stealer, decrypting and storing it in the temp directory and setting its attributes to “Hidden”.

It then decodes and decrypts the main KamiKakaBot payload, which results in a ZIP file. This ZIP file is opened, and its entry is the DLL that will be directly loaded into memory and executed via the “InvokeMember” function.

The main KamiKakaBot payload is invoked with three arguments which are the following:

• Encrypted Telegram Token.
• Telegram Chat ID.
• Credential Stealer DLL path.

KamiKakaBot Main Payload

KamiKakaBot starts by decrypting the passed “Telegram Token” and calling the “Execute” function to start the execution.

Execute Function

The “Execute” function starts by initialising some variables.

• It sets the variable “Ap1kkk3y” which will contain the “bot” prefix and the telegram token for communication with the API.
• It sets the variable “CHATID” with the passed on chat ID from the previous step.
• It sets the variable “IdentifyName” by calling the “getIndentifyName” function. Which is a function that uses the “WindowsIdentity” class from .NET in order to obtain the current user information. The results will be in the form “Domain+=…=+Username”

• It sets the “linktel” variable to the telegram API domain “https://api.telegram.org/”
• It sets the “xmlName” variable to the value of “System.IO.Compression”
• It then checks if the credential stealer file that was passed as an argument from the previous step and that resides on disk. If it does, then it converts its content into base64 for later use, stores it in the “Dat10dje1” variable and then deletes the file from disk.

After this initialization it starts the main function “Run”.

Run Function

The “Run” function is the “real” main function of KamiKakaBot. It starts by calling a function called “k01mdhaj3yf”.

This function ensures the creation of a file in the temp directory with the name “%TEMP%\\3f88dd57-6ce606be-54c358fb-c566587a.tmp”. This text file will contain a string that’s a combination of a substring from the Telegram Token and the string “:0”.

For example if the token string was this “bot6860256103:ABFrlFzcLuyXU4HxKisFUhvhwKucyL4rDS0” then the content of the text file would be “ABFrlFzcLuyXU4H:0”. This string is parsed and depending on the value after the colon either a “0” or a positive integer value is returned.

The result is used to determine the path of the following “if” clause.

The function “s39fjMkdm” will simply take the results from the previously set “IdentifyName” variable and send it to the attacker by using Telegram’s “sendMessage” API.

Based on older samples the appended values “12” and “21” signify either a “new connection” established or “reconnection” respectively.

Next, the function “ok0djfnakf” is called which is responsible for launching the credential stealer component.

This function simply takes the contents of the previously initialised variable “Dat10dje1”, decodes it from its base64 form and loads it into memory.

It then invokes the member function from the stealer with the name “JegrywbXVS” and passes to it a randomly generated name in the form

xxxx-xxxx-xxxx-xxxx-xxxx.tmp

After invoking the stealer, the function “kowfnF1lwd3” is called. Its aim is to send the data collected by the stealer as a ZIP file to the threat actor via the sendDocument API.

Note: We’ll discuss the functionality of the stealer in a separate section.

After this we reach the main C2 loop which is straightforward. It loops indefinitely waiting for commands from the threat actor. These commands are collected via the getUpdates API.

The functions perform some checks related to the ChatID and MessageID to ensure that the commands are coming from the expected chat and commands aren’t repeated.

For a command to be passed a couple of conditions need to be satisfied.

• The ChatID from the API response needs to be equal the ChatID of the sample
• The From ID from the API response needs to be equal the ChatID of the sample
• The Message ID from the API response needs to be bigger than the current stored value.

While the 2 first conditions are straightforward. In order to obtain the current MessageID value, the function reads the contents of the file “3f88dd57-6ce606be-54c358fb-c566587a.tmp” from earlier and extracts the value stored after the colon.

In our example “abfrlfzcluyxu4h:0” the extracted value will be “0”. The MessageID sent by the threat actor needs to be bigger than “0”. This is to keep track of the last executed command.

The 2nd part of the condition that needs to be valid is that the command either starts with the string “all+=…=+” or with “Domain+=…=+Username” where “Domain” and “Username” are from the infected user machine.

Either way the result is passed on to the rest of the loop in order to execute the appropriate functions. The C2 accepts the special values to execute specific functions:

• 1* – Send current user Identity.
• 34 – Load the credential stealer module and collect the data.
• 91 – Update the Telegram Token and Chat ID.
• 45 – Update the build XML file in order to provide a newer version or newer payload.

If none of the above is sent then the command is passed on to the “s39fjMkdm” function, which will execute it via “Cmd.EXE”.

cmd.exe /c <command>

KamiKakaBot Credential Stealer

The credential stealer component is straight forward. It starts by creating a new directory in the temp folder with the OS version as a name by calling the “Environment.OSVersion.Version.ToString()” function.

The folder name will be in the form of

C:\Users\<username>\AppData\Local\Temp\<OSversion>

For example:

C:\Users\<username>\AppData\Local\Temp\6.2.9200.0

Its main goal is to steal credentials and login information from the user’s browser. It focuses on Mozilla Firefox, Microsoft Edge and Google Chrome.

It grabs the following file from the Firefox profile folder:

• autofill-profiles.json
• cookies.sqlite
• key3.db
• key4.db
• logins.json

It extracts the decryption key from the Chromium based browsers Chrome and Edge and saves it into a text file. It then copies the following files from their respective profile folders:

• Cookies
• Login Data
• Login Data For Account

All of the above is copied into the aforementioned temporary directory, compressed and put into a ZIP file, to be used by the KamiKakaBot function “ok0djfnakf” described above.

KamiKakaBot Variants – New Vs Old

While there are some slight differences between the old and new variants of KamiKakaBot. Including different text file anchors, code obfuscation, and different special C2 commands. The major difference is mainly the decoupling of the stealer component to a standalone DLL from the main payload.

Detection Opportunities

KamiKakaBot TTPs offer many detection opportunities that are easily detectable using public Sigma rules. For example, using our endpoint agent Aurora we can see many alerts triggering just for the first stage.

Indicators Of Compromise

You can find all IOCs and links to the latest version of the detection rules here.

MITRE ATT&CK

Contributors

• Mohamed Ashraf
• Nasreddine Bencherchali