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! 🚀

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.

Every month the Nextron Threat Research Team (NTRT) shares insights into evasive threats that we’ve seen in the wild via our Valhalla service. The aim is to highlight interesting samples our rules detected and have or had very low detection rates as reported by VirusTotal scanning.

Please note that we are aware that VirusTotal results do not represent the full capabilities of antivirus or EDR Products. The aim is to highlight how Threat Actors are taking into account evasiveness with some of these samples.

Threat Overview

The following table gives an overview of the threats mentioned in this blog. You can use the respective Valhalla page for every threat to get a list of the hashes.

Threat Digest

MrAgent

The MrAgent sample was first reported by MalwareHunterTeam where he pointed it out from a related sample used by RansomHouse.

The sample triggered one of our generic Vmware ESX malware rules on the date of the upload last September.

A couple of months later the Trellix team put out a blog where they dissected the sample in question. Here is an excerpt from the Trellix blog.

MrAgent is a binary designed to run on hypervisors, with the sole purpose of automating and tracking the deployment of ransomware across large environments with a high number of hypervisor systems. The binary connects back to a set of command & control servers, which need to be supplied as a command-line argument.

We’ve only noticed one additional new sample uploaded on the 2024-03-01 that was quickly picked up by multiple vendors (430cbf6d340e3b3ee92a0bca41c349071564a14fd31f810bd1b0702d5df75351)

Guloader Shellcode

Guloader is a first stage shellcode based malware that is usually used to download other types of malware such as Agent Tesla, Lokibot and others. It was discovered in 2019 and is still going strong to this day.

We’re seeing multiple uploads a day to VirusTotal, with almost all of the uploaded samples having 0 detections.

It turns out that most of these samples are memory dumps uploaded via the VT API. Investigating them would reveal the GuLoader shellcode.

It is worth noting that we’ve also seen GuLoader ShellCode uploaded directly and some vendors did indeed pick it up directly.

HemiGate

HemiGate is a backdoor used by the threat actor known as Earth Estries. It was first reported by TrendMicro last year. Since the initial reporting we’ve tracked 4 samples uploaded to VT over the next months. The most recent one was uploaded early this (January 2024)

While the first 3 samples uploaded had very high AV matches. The most recent one only started with 3 vendors having coverage for it.

We can see the coverage increased over the next months to reach 34/70.

This latest sample of the HemiGate backdoor loader, is very similar in nature to the previous ones. It mimics the “libvlc.dll” DLL to achieve DLL sideloading as can be seen by the exported functions.

All of the exports are empty except for “libvlc_new” which calls the functions that decrypts the encrypted payload (HemiGate backdoor) with RC4.

From strings found in the sample, it seems highly likely that this was generated via the AheadLib tool.

IronWind

IronWind is an initial access downloader first reported by Proofpoint last November. You can read their analysis for full technical details. Since that report we’ve been tracking the IronWind samples being uploaded to VT.

And we can see, earlier uploads by the end of last year were highly flagged by almost every major vendor. But in recent months the samples we’re monitoring are getting more stealthier and evading AV signatures. A look at the decrypted strings shows potential new capabilities.

We’ll be releasing a blog in the upcoming weeks detailing the capabilities of this new variant.

Detection opportunity

HemiGate Sideloading Activity

The following Sigma rule can be used to detect potential sideloading of libvlc.dll

title: Potential Libvlc.DLL Sideloading
id: bf9808c4-d24f-44a2-8398-b65227d406b6
status: test
description: Detects potential DLL sideloading of "libvlc.dll", a DLL that is legitimately used by "VLC.exe"
references:
    - https://www.trendmicro.com/en_us/research/23/c/earth-preta-updated-stealthy-strategies.html
    - https://hijacklibs.net/entries/3rd_party/vlc/libvlc.html
author: X__Junior
date: 2023/04/17
tags:
    - attack.defense_evasion
    - attack.persistence
    - attack.privilege_escalation
    - attack.t1574.001
    - attack.t1574.002
logsource:
    category: image_load
    product: windows
detection:
    selection:
        ImageLoaded|endswith: '\libvlc.dll'
    filter_main_vlc:
        ImageLoaded|startswith:
            - 'C:\Program Files (x86)\VideoLAN\VLC\'
            - 'C:\Program Files\VideoLAN\VLC\'
    condition: selection and not 1 of filter_main_*
falsepositives:
     - False positives are expected if VLC is installed in non-default locations
level: medium

Nextron’s Solutions for Enhanced Cybersecurity

Nextron steps in where traditional security measures might miss threats. Our digital forensics tools conduct thorough analyses of systems that show signs of unusual behavior. They effectively identify risky software and expose a range of threats that could go unnoticed by standard methods.

Our signature collection is tailored to detect a variety of security concerns. This includes hacker tools, their remnants, unusual user activities, hidden configuration settings, and legitimate software that might be misused for attacks. Our approach is especially useful in detecting the tactics used in supply chain attacks and identifying tools that evade Antivirus and EDR systems.

Authors

• Mohamed Ashraf
• Nasreddine Bencherchali

SIGMA Log-Source

Before we delve deeper, Let’s take a step back and talk a bit about how the log-source attribute is used in Sigma rules.

Every Sigma rule requires a section called log-source that indicates as the name suggests, the log source on which this detection will fire. A typical example would look like this:

product: windows
category: process_creation

The “product” indicates that this rules is targeting the “Windows” product and a specific category called “process_creation” is used to indicate that this rule is using “Process Creation” events. You can read the full explanation of every field in the specification

To someone who isn’t familiar with Sigma or logging a couple of question will arise:

• Is “Process Creation” category using events “Sysmon/EventID 1” or maybe “Microsoft-Windows-Security-Auditing/EventID 4688”?
• The next question that arises: How would we collect these logs?

This is where the log-souce-guides enter the picture.

-Log-Source Guides

Starting from today, if you navigate to the Sigma main rule repository, you’ll see a new folder called “rules-documentation” this will be the location of the aforementioned “log-source-guides“ and future documentation projects teased here.

The log-source-guides will have a simple structure that reflects available log sources. So in the example of “process_creation” for the Windows product:

Structure

Now that we established the location of these guides, let’s talk about their structure and the information they provide. Every logsource guide will provide the following information:

Event Source(s)

This section will describe the source(s) used by the log-source. As a quick way for the reader to know exactly which channel or ETW provider is required to be able to receive the events.

Logging Setup

This section describe a step by step guide on how to enable the logging and which events are to be expected by enabling it. Let’s take the “Credential Validation” audit policy.

• The “Subcategory GUID” is the GUID for this specific audit policy which can be used with the auditpol command to enable the log (as we’ll see in a little bit).
• “Provider” indicates the exact ETW provider that is responsible for emitting these events.
• “Channel” is the Event Log channel where the generated events are emitted.
• “Event Volume” indicates the amount of logs to be expected by enabling that audit category or EventID.
• “API Mapping” is a direct link to jsecurity101TelemetrySource project.
• “EventIDs” are the events generated by enabling the policy or log.

Next comes the section on how you’ll be able to enable the log in question – in this example either via Group Policy or by using Auditpol.

Note: This section will obviously be different depending on the logs. Enabling Sysmon logs will be different than enabling Security logs.

Full Event(s) List

This section while not always be present and is meant to be a collection of all events generated by the event sources in question. It’s there as a quick reference for any event. As every event is linking to the MSDN documentation when possible.

Event Fields

The last section contains the specific event fields used by every event. While this section will be complete for certain log sources such as “process_creation”, it’s still a work in progress for logs such as security and will be populated over time.

The idea behind this is to provide the fields that the event generates as a reference. Since SIGMA rules aim to be as close to the original logs as possible and leave field mapping to the back end.

Linking Log-Source Guides and Rules

To make these log-source guides easily accessible. Every Sigma rules will now link to their respective logsource documentation via a unique ID that will be added to the “definition” section. Here is an example:

As part of this initial release documentation will be available for the for the following log-sources:

• product: windows / service: security
• product: windows / category: process_creation
• product: windows / category: ps_module
• product: windows / category: ps_script

In the coming weeks and months we’ll keep adding more documentation to cover every available log-source.

Sigma Log-Source Checker

As part of this release we’re also providing a new script we’re calling “sigma-logsource-checker“. The idea behind this script is to provide the user the ability to know which logs to enable based on the SIGMA rules they’re using.

It takes a Sigma rules folder as input, parses all the used log-source and Event IDs and suggests the Audit policies and logging configurations that should be enabled.

As an optional feature, It can also parse the XML output of gpresult

gpresult /x [results.xml]

and then suggests configuration changes based on current policy:

Note: This version will only check the Security Audit policy and PowerShell log configuration. We’ll keep improving it as we go along.

You can have a look at this today by visiting the Sigma HQ main repository

Valhalla Front Page Now Shows Sigma Rule Information

The Valhalla front page already shows Sigma rule information. The grey bars show the number of new Sigma rules created per day.

Two new tables on the front page list new Sigma rules and the rule categories. The first table contains new rules with rule title, description, creation date, a reference link and an info page.

Nextron Systems has always supported the Sigma project, investing hundreds of work hours into creating and maintaining the community rules shared in the public Sigma rule repository. Apart from the community support, we’ve created a set of internal detection rules for our products, THOR and Aurora, that we kept confidential for various reasons and didn’t share publicly.

Today we are glad to announce that we’ve started feeding these rules into the Valhalla service.

The private Sigma rule feed contains 190 Sigma rules at the date of this blog post and is expected to grow by 600 rules every year. The following table from the front page of the Valhalla web service shows the different categories and the number of rules per category.

Getting started

We offer the Sigma feed subscription independently of the YARA rule subscription at a much lower price. If you’re interested, please get in touch with your sales representative for pricing information or fill out this form.

The following recorded video session includes information about our new Sigma-based EDR agent called “Aurora” and the free “Aurora Lite”. It’s a preview of the agent with information on its features, limits, advantages and a live demo.

The release is scheduled for December 2021. Follow us on Twitter or subscribe to the newsletter to get updates about the development of Aurora.

Our compromise assessment scanner THOR is able to apply Sigma rules during the local Eventlog analysis. This can help any customer that has no central SIEM system or performs a live forensic analysis on a system group that does not report to central monitoring. 

By running THOR on these systems with activated Sigma feature, THOR becomes a kind of a distributed and portable SIEM.

Since the Sigma scan module isn’t active by default, we thought it a good idea to explain how to activate an use it in the best possible way. 

Sigma Scanning

To activate the Sigma module simply use the “–sigma” flag (or “sigma: True” in a YML config file).

You can start a THOR scan that analyzes the local Eventlog and activates the Sigma feature with:

thor64.exe -a Eventlog --sigma

To run a Sigma scan on a single Eventlog e.g. Sysmon’s log, use the “-n” flag.

thor64.exe -a Eventlog --sigma -n "Microsoft-Windows-Sysmon/Operational"

To include the Sigma feature in a standard THOR scan and check only the last 3 days of the Windows Eventlogs to reduce the scan duration, use:

thor64.exe --sigma -lookback 3

Sigma Matches

Once a Sigma rule matches on a log entry, you’ll see it listed in one of the REASON’s that lead to the classification of an event. 

The following example shows the detection of a China Chopper (Caidao) ASP web shell. That web shell has been detected by multiple Sigma rules. 

1. Webshell Detection With Command Line Keywords 
2. Shells Spawned by Web Servers
3. Whoami Execution

Getting Started

Since this feature isn’t available in THOR Lite, please contact us via the “Get Started” button in the upper right corner and get a free trial voucher. Most customers that use THOR with Sigma choose one of our THOR license packs, especially the SOC Toolkit Pack, which was geared to the needs of today’s SOC teams. 

“What do I want to detect?”

There are several white papers and guides for the most common log sources like the Windows Eventlog. What you have to do is to read the documents, extract the interesting detection methods and define searches, panels and dashboards in your SIEM system. One of the main purposes of Sigma is to relieve you from this time consuming process. These public descriptions of detection methods are already part of Sigma or will be integrated by one of the contributors.
But today I’d like to point out a different use case that is less obvious but very useful.

The Best Possible Monitoring

Security analysts try to define useful searches and statistical analyses on the log data from all different log sources. They typically follow the public guides and create many different “failed logon” rules for all kinds of operating systems and applications.
But what happens when start integrating log sources and types that are not covered by public guidelines?
There are different approaches to this problem:

• Cover failed authentication attempts
• Monitor any failure event (with a base-lining)
• Use statistic deviations (many new events of a certain type)
• Look through the log data and select interesting messages
• Talk to the application owners / administrators (often rather disappointing)
• Talk with the application developers (in case of inhouse development)

All of these methods are valid and can help you setup useful searches on the available data. However, in order to create the best possible signatures we have to consider the following:

• The most interesting and relevant fault conditions do not happen under normal conditions and therefore do not appear in everyday log data (the log data we have to select interesting events from)
• Developers know the rarest or most relevant error conditions and the corresponding error IDs and messages
• All possible error messages of that application appear in its source code

Imagine that we can extract the most interesting messages that the application is able to generate and define rules for these conditions. Imagine that this process is an easy task that any developer is able to perform.
Well, we have at our fingertips all the tools that are needed.

An Example: vsftpd

Let’s make this approach clearer. Under optimal conditions we ask the developers to extract the most relevant or abnormal error messages that the applications produces under conditions that indicate a manipulation or attack. Alternatively, we can do it ourselves and cross-check the results with the available log data to avoid false positives.
I checked the source code of the FTP server ‘vsftpd’ for error messages that indicate rare error conditions and fatal failures.

The resulting Sigma rule looks like this:

title: Suspicious VSFTPD error messages
description: Detects suspicious VSFTPD error messages that indicate a fatal or suspicious error that could be caused by exploiting attempts
reference: https://github.com/dagwieers/vsftpd/
author: Florian Roth
date: 2017/07/05
logsource:
    product: linux
    service: vsftpd
detection:
    keywords:
        - 'Connection refused: too many sessions for this address.'
        - 'Connection refused: tcp_wrappers denial.'
        - 'Bad HTTP verb.'
        - 'port and pasv both active'
        - 'pasv and port both active'
        - 'Transfer done (but failed to open directory).'
        - 'Could not set file modification time.'
        - 'bug: pid active in ptrace_sandbox_free'
        - 'PTRACE_SETOPTIONS failure'
        - 'weird status:'
        - "couldn't handle sandbox event"
        - 'syscall * out of bounds'
        - 'syscall not permitted:'
        - 'syscall validate failed:'
        - 'Input line too long.'
        - 'poor buffer accounting in str_netfd_alloc'
        - 'vsf_sysutil_read_loop'
    condition: keywords
falsepositives:
    - Unknown
level: medium

After some testing we can now share the rule with the world in order to build a large signature database for the all different types of applications and services.
We could also try to convince developers to provide Sigma rules with their applications to help organisations establish the best possible monitoring of their software. I was thinking about an error message extractor that would parse a software project and extract error message strings that contain certain keywords like “failure”, “fatal”, “permission denied”, “refused” and others to facilitate this process for the rule writer.
If you want to support the project, create a pull request or send me your rules as gists or via pastebin to @cyb3ops. You could also become a contributor by providing a new backend for the rule converter “Sigmac” or become a member of our Slack team for threat hunters (references required).