Signed. Sideloaded. Compromised!

Executive Summary

During an incident observed by Ontinue’s Cyber Defence Centre (CDC), the team identified a sophisticated multi-stage attack leveraging vishing, remote access tooling, and living-off-the-land techniques to gain initial access and establish persistence.

The threat actor exploited exposed communication channels by delivering a malicious PowerShell payload via a Microsoft Teams message, followed by the use of Quick Assist to remotely access the environment. This led to the deployment of signed binaries (e.g., TeamViewer.exe), a sideloaded malicious DLL (TV.dll), and ultimately a JavaScript-based C2 backdoor executed via Node.js.

This attack chain highlights how a relatively simple vishing-based social engineering tactic can escalate into a full-scale compromise when paired with trusted tooling, signed binaries, and stealthy second-stage payloads. While the primary purpose of this report is to share technical findings, the incident also reinforces the real-world impact of social engineering threats, particularly when user training gaps exist.

Threat Intelligence

The techniques observed in this campaign strongly align with those previously attributed to Storm-1811, a threat actor identified by Microsoft known for leveraging vishing, Quick Assist, and social engineering tactics to gain initial access. While we cannot confirm attribution with high confidence, several TTP overlaps suggest possible tradecraft similarities.

These include:

• Abuse of legitimate remote support tools (e.g., Quick Assist)

• Initial access via Microsoft Teams social engineering

• Deployment of signed binaries for DLL sideloading

• Use of living-off-the-land binaries (LOLBins) and BITS jobs for stealth and persistence

This pattern is consistent with public reporting, including Microsoft’s advisory on Quick Assist abuse and a more recent analysis by Sophos MDR, which detailed ransomware campaigns involving Teams vishing and remote support exploitation (Sophos, Jan 2025).

MITRE Techniques:

The following techniques have been identified following post-compromise.

• T1105 – Ingress Tool Transfer | Adversary transfers tools to target system

• T1656 – Impersonation | Adversary impersonates IT/help desk personnel

• T1018 – Remote System Discovery | Use of nltest and net user to enumerate domain controllers.

• T1219 – Remote Access Software | remote support tools (e.g., QuickAssist or TeamViewer)

• T1218 – Signed Binary Proxy Execution | Abuses trusted, signed binaries

• T1197 – BITS Jobs | Employed for stealthy data transfers or staging via Background Intelligent Transfer Service.

• T1555.003 – Credentials from Web Browsers | Accessing browser password files (login data)

• T1021.002 – SMB/Windows Admin Shares | Using psexec.exe for lateral movement and execution over SMB.

• T1570 – Lateral Tool Transfer | Copying and deploying tools like psexec.exe across multiple systems.

• T1090 – C2 via Reverse Proxy | Utilization of PsExec for exfiltrating data.

Sample info

First Stage

SHA256: 904280f20d697d876ab90a1b74c0f22a83b859e8b0519cb411fda26f1642f53e

File Name: TeamViewer.exe

SHA256: 782e997382734a4c80b6f2c6aef51a55c9434457f5ee125a3cf5938ec7a72f55

File Name: TV.dll

Second Stage

File Name: Index.js

Description: C2 Backdoor via JavaScript

SHA256: 67199aaa4c7c9a7002958588b1bd1b81deecec871933f7c88d5838deb1c47e92

Attack Lifecycle Analysis

Initial Access

Before I delve into the analysis of the samples and the activities executed by the threat actor(s), it is essential to revisit the initial access stage of the attack chain. Our investigation revealed that the actor employed social engineering tactics to execute a vishing attack. This involved sending a message to the target through Microsoft Teams by creating an external chat. The actor transmitted a PowerShell command directly via the Teams message and also utilised the QuickAssist remote tool to gain access to the target device remotely.

The activity analysis reveals that at a certain stage during the execution of the PowerShell command, QuickAssist was used by the Threat actor as expected. This allowed them to remotely access the target device after they had successfully Vished the target user to ensure deployment of the PowerShell which came shortly after.

Execution

Upon initial execution, I observed a PowerShell command executed from the target endpoint by the threat actor, which facilitates the download of the first stage malware. The script retrieves a ZIP file from a suspicious IP address, extracts its contents, and subsequently executes a file named “TeamViewer.exe“ from a concealed directory (C:\ProgramData\TV). Furthermore, it utilises “AutoHotkey” as its User-Agent, implying the potential involvement ofAutoHotkey-based malware. This suggests that the downloaded payload may contain an AutoHotkey script (.ahk) or a compiled AutoHotkey executable (.exe) designed to carry out further malicious activities.

Upon executing TeamViewer.exe, the application loads the TV.dll module, which I have identified as a case of DLL (Dynamic-Link Library) sideloading . This module subsequently re-establishes a connection to the same IP address that was previously noted for downloading the first-stage malware.

Persistence

Following this, the malware creates a persistence mechanism by generating an LNK file in the Start-up folder, ensuring execution upon system reboot. The created shortcut file is located at:

C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\GPU_Scv_Pack.lnk

C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\GPU_Scv_Pack.lnk

C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\GPU_Scv_Pack.lnk

C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\GPU_Scv_Pack.lnk

The LNK file directs to “TeamViewer.exe” located in the directory “C:\ProgramData\TV”.

Defence Evasion

Once persistence is established, the malware proceeds to terminate nine specific processes, likely with the intention of disabling security tools.

The threat actor has also established a BITS Job, enabling them to transfer tools to the target endpoint. BITS jobs can also be used as persistence as they can have a lasting length of 90 days.

Additionally, I have noted instances of process injection activity, specifically where PowerShell initiated the process ‘PING.exe’. Subsequently, ‘PING.exe’ employed process hollowing techniques to inject malicious code into ‘dllhost.exe’.

Discovery

I then noted several additional Discovery commands that involved the use of WMI. I encountered the WMI commands and also observed their presence within Strings.

System Information Collection

• Win32_OperatingSystem – OS version, architecture, uptime.

• Win32_Processor – CPU model, architecture.

• Win32_LogicalDisk – Disk layout, storage capacity.

• Win32_VideoController – GPU info (often used in VM detection).

• Win32_NetworkAdapterConfiguration – Active network interfaces & IPs.

Security Product Enumeration

• FirewallProduct, AntiSpywareProduct, AntiVirusProduct – Checks for security software

Furthermore, within the activity I have also observed ‘nltest.exe‘, this is a built-in windows command line tool that can be used for domain and network reconnaissance by an actor. The tool allows the following:

• Get a list of domain controllers

• Force a remote shutdown

• Query the status of trust

• Test trust relationships and the state of domain controller replication in a Windows domain

• Force a user-account database to synchronize on Windows NT version 4.0 or earlier domain controllers

Lateral Movement

By executing process injection, the attacker successfully transferred a tool onto the targeted host, enabling attempts at lateral movement.

Credential Access

Recently, I have identified a common threat among certain malware families that involves the theft of credentials through web browsers. This type of malware attempts to capture login data, which is subsequently stored in a local SQL database before being exfiltrated.

Second Stage Analysis

During its operation, TeamViewer.exe creates a compressed file named hcmd.zip. This archive is then unzipped using 7-Zip, which was included in the toolset downloaded from a.zip. The extracted file, hcmd.exe (formerly Node.exe), is executed, launching index.js, which contains a C2 JavaScript backdoor used to establish a command-and-control channel.

Code Analysis

The second stage of the attack I have observed a JavaScript based backdoor that was executed using Node (renamed to hcmd.exe). Upon closer inspection, the script is designed to establish persistence connection with a C2 server allowing the attacker to execute arbitrary commands on the compromised machine.

Socket IO Connection

The script imports and utilizes the socket library to enable the remote connection from the compromised machine and the attacker.

Command Execution via Node.js

The script uses ‘node-cmd’ to execute the system commands

• This spawns a hidden CMD process (cmd.exe), allowing the attacker to send and execute Windows commands remotely.

• The reference (processRef) is later used to interact with this shell.

Hardcoded Credentials & C2 Server

The script contains a hardcoded:

• Hardware ID (hwid) for tracking infected systems

• Password: (AutoHotkey)

• C2 Server IP: 5.252.153[.]81

Static & Dynamic Analysis

Upon examining the activity timeline, one might initially assume that the attacker is utilising TeamViewer as a Remote Management Tool (RMT) to establish an initial foothold. However, the decision to download a separate sample piqued my interest. Notably, the TeamViewer.exe file was a signed binary, which, while typical for code signing, raised some questions for me.

Further investigation led me to compare it with an older sample of TeamViewer version 5, which had been packed using UPX. In contrast, the sample I analysed did not exhibit any UPX packing. This is a common technique employed to preserve the signature and metadata while obfuscating the true nature of the file.

My initial analysis focused on determining how the file TV.dll was loaded. Initially, I was unable to find any references to TV.dll being loaded through either LoadLibraryA or LoadLibraryW, which are functions that load the specified module into the calling process’s address space. This absence of references indicated that TV.dll might have been loaded dynamically at runtime.

Additionally, I uncovered an indirect loading mechanism via the function “FUN_004be74b“, which dynamically resolves “LoadLibraryW“ during runtime. A string referencing “TV.dll“ was located within a data structure, confirming that the binary anticipates the availability of the DLL.

By placing a breakpoint on “LoadLibraryW,” I was able to trace the execution of TV.dll, confirming its dynamic loading at runtime. This process involves loading the module and mapping it into memory. Now that the module has been loaded, it has been assigned a new EntryPoint following the DLL’s loading process, which was facilitated by a TLS callback. Specifically, the “INT3 breakpoint ‘TLS Callback 1 (tv.dll)’ at tv.0317A748” further verifies that this callback was invoked prior to the execution of DLLMain.

By examining the memory map view, I can confirm the successful loading of the DLL and ensure that the memory address corresponds accurately to the data displayed in EDX.

How is TV.dll Loaded?

• TeamViewer.exe starts execution.

• At runtime, it constructs the DLL name (TV.dll).

• It calls LoadLibraryW (or an equivalent function) using an indirect reference.

• TV.dll is mapped into memory

• Execution is transferred to TV.dll, allowing it to run code inside the TeamViewer process.

Malicious DLL Sideloaded

Anti Virtualisation & Debugger Detection

In my analysis, the primary focus was to determine whether there were any checks for a debugger present in the environment. If such a debugger is detected, the process may be terminated. As expected, the “isDebuggerPresent” function was found among the static imports. I checked the location and further analysed the decompiled code.

• IsProcessorFeaturePresent(0x17) – checks for Hardware Debug Registers.

• Calls FUN_100bb403() – likely an internal function that could be another debugger check.

• Clears memory (memset) – to avoid leaving traces in memory.

• Sets up a fake exception record (0x40000015) – an arbitrary exception code that debuggers may handle differently.

• IsDebuggerPresent() – Standard API to detect attached debuggers.

• Registers an UnhandledExceptionFilter. This is a trick where the process raises an exception.

• If a debugger is present, it might intercept the exception, altering execution flow.

A second function I uncovered alongside IsDebuggerPresent is called “ProcessorFeatureRequest.” I have renamed the subroutine to “DetectVirtualisation.” The disassembled section of code reveals what appear to be CPU checks designed to identify any form of virtualisation. For instance, it potentially verifies the presence of virtualisation firmware, such as Intel VT-x or AMD-V.

Uses XGETBV(0) via in_XCR0: sandbox/VMs often don’t support AVX, XMM registers fully.

CPUID Checks: cpuid_basic_info(0) and cpuid_Version_info(1)

• CPU vendor string (GenuineIntel)

• Feature flags (EDX, ECX)

• Processor signature (EAX)

This confirms the CPU vendor is Intel:

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

Compares against known legit Intel CPUs:

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

If matched, sets DAT_100f04b8 |= 1 – meaning “expected CPU”.

Userland Hooking & Unhooking

During our analysis, I identified two functions that were implementing inline hooking, effectively intercepting redirect function calls within userland space. Unhooking refers to the process of removing or circumventing hooks, such as those established by security tools like EDRs. This technique is frequently employed by malware to operate covertly within a system.

The two functions observed:

• MinHookDisabled

• MinHookEnabled

The team also renamed some of the components observed within the decompiled code to make it more readable.

MinHookDisabled

The function that effectively disables a previously placed hook by restoring the original bytes at the target function’s memory location. This process effectively reverses any modifications made by the hook, such as jump or call redirections.

• hookData > points to an array or structure holding hook-related metadata.

• hookData[5] > holds a flag used to determine if the platform is 64-bit or 32-bit.

  • If the left shift does not set the sign bit, it’s assumed to be 64-bit.

• Sets the size of the hook to restore:

  • 7 bytes for 32-bit

  • 5 bytes for 64-bit

• Uses VirtualProtect to change memory protections at hookLocation to PAGE_EXECUTE_READWRITE (0x40) so it can overwrite the bytes.

• If memory protections were successfully changed:

  • Determine the original instruction size (5 or 7 bytes) based on a bit flag in hookStruct[5].

• memcpy Restore the original bytes from the hook structure (hookStruct + 3 holds the original code).

  • Re-apply the original memory protection after restoration.

• free(hookStruct) > Deallocates the memory used by the hook metadata after restoration.

MinHookEnabled

The function is tasked with installing a hook that redirects execution from a specified target function to a custom detour function. Additionally, it can optionally preserve a pointer to the original function, referred to as the trampoline. This functionality aligns with the operations of the MinHook API hooking library.

• hookData will store:

  • hookData[0] = original function address

  • hookData[1] = detour function address

  • hookData[2] = trampoline (original entry)

  • hookData[3+] = backup of original bytes, flags, metadata

• Saves 5 or 7 bytes from the target function to allow restoring later (MinHookDisable uses this).

• Changes the function memory to “PAGE_EXECUTE_READWRITE” so it can modify code in memory.

• Writes a relative jump to the detour function from the start of the original function.

• Ensures that the CPU’s instruction cache is updated and protections are restored.

• Saves pointer to the original function for future use (e.g., to call it from the detour).

Indicators of Compromise