Hackers Hide Reverse Shell Traffic Behind Signed Apps and AWS API Gateway

Threat actors are using a layered fake IT-support campaign to obtain remote access, deploy a malicious MSI package and conceal hands-on-keyboard activity behind legitimate signed applications and AWS API Gateway infrastructure.

The operation demonstrates how attackers can divide execution, command-and-control and interactive shell functions across multiple processes to frustrate conventional endpoint and network detections.

Once inside the victim environment, the attacker downloads a malicious MSI installer, including samples named SE15724BW.msi and KB5094126.msi, from an attacker-controlled Amazon S3 bucket and executes it through msiexec.exe.

Rather than immediately launching an obvious remote-access trojan, the installer deploys a trusted, signed Windows application alongside a rogue vcruntime140.dll.

Observed decoy loaders include FileZilla’s filezilla.exe, Altap Salamander’s salamand.exe, and a trojanized Kodi executable.

Because Windows commonly searches an application’s own directory before system locations when resolving DLL dependencies, the signed executable can load the attacker’s DLL instead of the expected copy from C:\Windows\System32.

This technique, known as DLL sideloading, enables malicious code to execute in the context of a trusted process.

The malicious DLL acts as the campaign’s external communications relay. It establishes encrypted HTTPS traffic with an attacker-controlled AWS API Gateway execute-api endpoint, effectively placing C2 traffic inside a commonly used cloud-service pattern.

The use of TLS and an AWS domain can reduce the value of basic reputation controls, particularly in environments where cloud APIs are broadly allowed for business operations.

The sideloaded DLL does not directly host the attacker’s shell. Instead, it uses Windows Management Instrumentation to create a separate custom reverse-shell agent.

This activity may appear as WmiPrvSE.exe spawning unusual children such as File Transfer.exe, Module Agent.exe, or SupportHost.exe.

That design breaks the straightforward parent-child lineage defenders often expect from a malicious installer. Rather than exposing a visible chain from msiexec.exe to a shell, the intrusion can be represented as:

msiexec.exe → signed loader → WmiPrvSE.exe → reverse-shell agent

The reverse-shell component then binds to 127.0.0.1:9001, while the malicious DLL connects to that listener locally.

The DLL maintains the outbound AWS API Gateway connection; the shell agent never needs to communicate directly with the internet.

Unit42 Researchers said that, the campaign begins with social engineering conducted over Microsoft Teams external access.

Operators impersonate IT technicians and persuade targets to grant remote control through Microsoft’s native Quick Assist utility.

The two components exchange traffic through a Type-Length-Value protocol. Type 1 carries keyboard input, Type 2 returns command output, and Type 3 handles terminal-window resizing.

AWS API Abuse

The local agent uses Windows ConPTY to provide an interactive cmd.exe session, giving the operator a functional remote command shell while keeping the shell process isolated from external network telemetry.

This separation is the operation’s most significant defensive-evasion feature. Security teams may see a signed application making encrypted connections to an AWS endpoint, while the actual reverse shell only communicates over localhost.

Host firewalls that trust signed binaries and monitoring programs focused only on external connections could therefore miss the connection between the two behaviors.

The shell agent reportedly uses a 64-bit C++ implementation built with Boost.Asio and spdlog.

It applies string obfuscation through XOR and subtraction routines, enforces single-instance execution with a mutex, and can relaunch itself using a --restarted flag to further detach from its original execution path.

Attackers also establish persistence with a Startup-folder shortcut, such as salamand.lnk, that relaunches the legitimate-but-abused signed loader at user logon.

After compromise, operators perform interactive discovery using commands including whoami, ipconfig /all, net user /dom, and dsregcmd /status, while also enumerating cloud-synchronized document directories.

Defenders should correlate process, module-load and local-network telemetry rather than treating them as separate events.

Additional signals include WmiPrvSE.exe creating rare child processes, Quick Assist execution shortly after external Teams contact, and signed applications initiating TLS sessions to unusual .execute-api.amazonaws.com destinations.

High-value detection signals include an unsigned vcruntime140.dll loaded from the same directory as a signed application.

A non-system process binding to 127.0.0.1:9001, and conhost.exe --headless launched by a process not normally associated with terminal activity.

DLL sideloading remains effective because it exploits Windows DLL search behavior and disguises malicious execution under legitimate application identities; defenders should baseline expected DLL paths, signatures and load relationships not merely trust the executable’s signature.

IOCs

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.