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.

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

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