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.

In an era where cyberattacks are escalating in both frequency and complexity, establishing robust networks of technology partners and clients is essential for achieving success in cybersecurity. At it-sa Expo&Congress 2024, Europe’s leading cybersecurity industry event, we had the opportunity to showcase our commitment to this collaborative approach with our very own booth for the first time. This significant step has allowed us to elevate our engagement with partners, existing customers, and new contacts to new heights.

Learning from Intelligence Services: Unmasking APTs like the Pros

One of the highlights for me was the opportunity to present to an audience at it-sa. I discussed the serious risks Advanced Persistent Threats (APTs) pose to organizations, in my talk titled “Learning from Intelligence Services: Unmasking APTs Like the Pros”. (The presentation was delivered in German and can be found here on our Youtube Channel.) I also outlined strategies for the detection of these threats, which can be applied across various industries. It was encouraging to see many attendees express interest after the presentation, visiting our booth to learn more about our solutions and their advantages. 

Meet THOR: Detecting the Undetected

THOR is an advanced compromise assessment scanner designed to uncover traces of malicious activity across corporate networks. By automating forensic analysis, it identifies and neutralizes threats before they escalate, ensuring swift detection of malicious artifacts and providing security teams with the insights needed to mitigate potential damage. THOR enables organizations to enhance their security posture and respond effectively to both known and unknown threats.

Effective Cybersecurity extends beyond mere technological solutions

Conversations with customers, partners, and industry experts at it-sa reaffirmed our conviction that cybersecurity success relies on more than just technology. It calls for a collaborative mindset – one that values knowledge exchange, shared experiences, and expert insights.  

We are excited to continue this journey alongside our partners and clients. By working together, we aim to build a security framework that is both resilient and sustainable. The insights we gained at it-sa will be integrated into our daily operations, ensuring our clients’ defenses stay strong in an ever-evolving landscape. 

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

The German BSI Alert: A Critical Warning

The BSI’s alert brings to light the precarious state of Microsoft Exchange servers across Germany, with around 37% of systems found to be critically vulnerable. This includes outdated versions such as Exchange 2010 and 2013, which make up 12% of the installations and have not been updated since October 2020 and April 2023, respectively. Additionally, nearly 28% of the servers running newer versions like Exchange 2016 and 2019 are missing essential patches for critical security flaws that could be exploited in remote code execution attacks.

The BSI’s warning about the vulnerabilities in Microsoft Exchange servers in Germany highlights a crucial aspect of cybersecurity: the inadequacy of relying solely on patching, especially for systems that have been exposed online. The alert reveals that a significant percentage of these systems remain critically vulnerable due to outdated versions or missing patches for known security flaws. This situation indicates that, while patching is a necessary step in cybersecurity maintenance, it is not sufficient on its own. For systems that have been exposed to the internet and potentially compromised before the application of patches, conducting a thorough compromise assessment is an essential next step. This assessment determines the extent of any breach and the presence of attackers within the network, guiding the necessary response to secure the compromised systems.

In this blog article, we will talk about how you can use THOR to scan Docker images. Consider the following use case:  Before using an upstream Docker image, you want to precheck it for known IOCs and backdoors. THOR can help you with this!

Prerequisites

• Docker image with a shell installed (e.g. sh, bash, etc.)
  • In this example we will use Alpine Linux
• THOR 🙂
  • In this example we will use Thor-Lite. However, for a real-world usecase you should consider using the full Thor version (Thor vs Thor-lite).

Running THOR in a Docker container

In your THOR folder run: docker run --rm -it -v ${PWD}:/thor alpine /bin/sh. This will create a Docker container based on Alpine Linux, mount your working directory (where THOR is stored) to /thor in the container, and will drop you into the sh shell. Inside the Docker container you can cd /thor and start THOR: ./thor-lite-linux. You can exchange alpine with any Docker image, as long as it includes a shell.

• {docker-id}_files_md5s.csv
• {docker-id}_thor_{date}.html
• {docker-id}_thor_{date}.txt

These files contain all findings of the THOR scan.

By using THOR to scan Docker images, you do not have to blindly trust the author of an upstream Docker image – you can see for yourself!

In part 2 of this series we explain how to scan Docker containers using THOR. 

Virustotal Account

You can use it with a Virustotal Enterprise account or even a free account that requires registration. 

The free account limits the number of requests per minute, but since THOR only checks findings with a particular score, only a few files are checked. 

By default THOR skips the enrichment when the quota is exhausted. The flag “–vtwaitforquota” can be used to make him wait for more quota.

Command Line Flags

The following command line flags are available:

Two lookup modes are available:

1. Limited = hash lookups only (default)
2. Full = hash lookup or sample upload (if hash is unknown)

A typical command line using the new feature would look like this:

thor64.exe --vtaccepteula --vtkey fb2c3babb1796f97dcd0a877e05207294110bea8a9b93a933b...

Example Match with Virustotal Information

Inspiration

The new lookup feature allows for some exciting detection ideas, which combine YARA rule matching and Virustotal lookups. 

YARA as Preselector for Uploads

This idea could be helpful in the case in which you know that an actor makes use of compiled Go (Golang) binaries. You could write a YARA rule that detects all compiled Go binaries for the Windows platform, set a score of 40 (noteworthy) to let the new feature pick them up, and submit them to Virustotal for analysis. (remember that you can use the –customonly flag to only apply your custom YARA rules if needed)

Check New Files with Virustotal

Imagine that you want to check all new .aspx files dropped on an MS Exchange server. You could write a YARA rule that looks for certain contents or the file extensions .aspx and give that rule a score of 40. You could then run a THOR scan on MS Exchange server setting the –lookback flag with the number of days you want to include and instructing it to scan only the C:\inetpub folder. If you schedule this scan to run daily, you will let THOR find all .aspx files changed during the last 24 hours, scan them with its own rules and check them on Virustotal for a verdict of 60+ scan engines. It’s hard to imagine better coverage for web shells than this. 

The full command line would look like this:

thor64.exe --vtaccepteula --vtkey fb2c3babb1796f97dcd0a877e05207294110bea8a9b93a933b... --lookback 1 -p C:\inetpub

FAQs

Does a low Antivirus detection rate reduce the score of the THOR matches?

No, that wouldn’t be smart, as THOR focuses on other types of threats that Antivirus software often is unable to detect. However, positive Antivirus matches increase the score for a scanned file depending on the number of Antivirus engines with matches.

THOR adds the following sub-scores based on the lookup result:

• more than 5 engines with matches > score 40
• more than 10 engines with matches > score 60
• more than 20 engines with matches > score 75

What happens when the quota for lookups per minute exceeds?

THOR will not add additional information to the printed event. By default, the lookups will not slow down the scan significantly. If you see too many notice or warning level messages in your environment, adjust the --vtscore value or filter out some known false positives using the false_positive_filters.cfg file.

Can I use this feature with the free THOR Lite version and a free Virustotal account?

Yes.

Which THOR modules trigger a Virustotal lookup?

Basically, only the ‘FileScan’ module uses the lookups. But since THOR also triggers a file scan on the image file during ‘ProcessCheck’, other modules also benefit. 

Where can I register a Virustotal account?

Visit this link to register a free account. 

How can I get THOR Lite?

You can download THOR Lite here. 

Get the full THOR version

Apart from the usual advantages of the full THOR version over THOR Lite, there are a few more reasons to use the full version in this scenario:

• Much bigger number of so-called “threat hunting” rules with low scores that would trigger a Virustotal Lookup
• Multi-threaded scanning significantly reduces the scan duration

If you’re interested in the full version, contact us using the “Get Started” button in the upper right corner. 

In a report published on the 20th of December CrowdStrike published a report of a new technique exploiting the Microsoft Exchange vulnerability called ProxyNotShell. The called the new technique OWASSRF as it uses Outlook Web Access, CVE-2022-41080 and CVE-2022-41082 to achieve remote code execution (RCE). 
PaolAlto Networks’ Unit42 released their report one day later. 

Signatures That Detect This Attack

Exploitation

YARA (public)

SIGMA (public)

Potential OWASSRF Exploitation Attempt – Proxy
UUID: 1ddf4596-1908-43c9-add2-1d2c2fcc4797

Potential OWASSRF Exploitation Attempt – Webserver
UUID: 181f49fa-0b21-4665-a98c-a57025ebb8c7

Post-Exploitation

SIGMA (Private)

Microsoft Exchange ProxyNotShell Exploit
UUID: df23d4fb-b12b-4425-a340-8d59e2460c43

Webshell Detection Suspicious Children
UUID: 9a8e8057-32a7-432d-bf80-197dacf1a77f

Shells Spawned by Web Servers in Process Tree
UUID: 6dc0f4e1-7a11-429f-b240-d9f852cea8b3

SIGMA (Public)

Suspicious File Drop by Exchange
UUID: 6b269392-9eba-40b5-acb6-55c882b20ba6

Shells Spawned by Web Servers
UUID: 8202070f-edeb-4d31-a010-a26c72ac5600

New Baselining Views

Over the course of the last 18 months we reviewed most of our detections regarding their success in real world scenarios. In this context “success” means, that the detection uncovered malicious activity in the wild and at the same time had a low anomaly and false positive rate. Additionally we also consider a detection to be successful that caused little or no false positives or anomalies.

All this lead to two new views within the Cockpit’s Baselining section: “Compromise Assessment Mode” and “Deep Inspection Mode”.

“Compromise Assessment Mode” includes only matches of the highly successful rules. The second mode is the “Deep Inspection Mode”. This view is basically how it used to be (the old default view). It shows all Alerts and Warnings unless they are already part of an existing case.

This new “Compromise Assessment Mode” dramatically reduces our customer’s baselining effort.

In our tests we noticed a decrease of events in the Baselining section of more than 90%. We believe that especially entities that follow our “Continuous Compromise Assessment” approach should switch into this new mode. We’ve also challenged the new mode with the post exploitation tools and techniques found in the context of HAFNIUM / Exchange exploitations in March 2021 and covered almost every aspect of the attacks in the new view.

Asset Labels

Another exciting new feature that comes with Analysis Cockpit version 3.5 is an event filter based on asset labels. This was requested by many of our customers and partners, but until now we never found a way to deliver this feature without negatively affecting the Cockpit’s performance. We solved this now by allowing two limitations to this feature. It doesn’t work for events that existed prior to the update. Secondly an event always remains linked to the asset label it had at the time the event occurred. Changing an assets label will only affect events from scans that take place after the label change.

Other Changes

• Hidden static filters in certain views
• Minor bugfixes and stability improvements

Release

The new Analysis Cockpit will be released in the 2nd half of August. Interested customers can get a guide to use the “preprod” version of Analysis Cockpit 3.5.