Silent Intrusion: ShadowPad Malware Found Embedded in Trusted Security Software Across Southeast Asian Telecoms

ShadowPad Malware Activity Targeting Telecommunications Providers

Incident Overview – January 27

In late January, a targeted intrusion involving ShadowPad malware was identified across telecommunications environments in Vietnam and Thailand. The activity showed clear signs of deliberate, well-resourced planning and was designed for stealth, persistence, and long-term access rather than disruption.

The attackers avoided exploits that would trigger immediate alerts and instead relied on trusted software abuse, DLL side-loading, and low-noise command-and-control traffic, allowing the operation to blend into normal enterprise behavior.

What happened

Attackers gained access to internal telecom systems and quietly installed ShadowPad, a modular remote-access backdoor. Instead of dropping obvious malware, they hid the payload behind legitimate, digitally signed security software already trusted by the organization.

From a defender’s point of view, everything appeared normal:

A trusted security executable ran
Antivirus did not raise alarms
No crashes, pop-ups, or service outages occurred

Behind the scenes, ShadowPad provided attackers with continuous remote access, system visibility, and the ability to deploy additional tools when needed.

How it happened

1. Initial access

No evidence of mass exploitation or scanning was observed. Based on access patterns and system logs, the initial foothold was likely achieved through one or more of the following:

Compromised privileged credentials (possibly obtained earlier via phishing or credential reuse)
Abuse of exposed remote access services (VPN gateways, jump servers, management portals)
Access through a trusted third-party support or maintenance account

The attackers already had sufficient privileges before malware deployment, indicating the compromise likely predated ShadowPad installation.

2. Staging of legitimate software

Once inside the environment, the attackers deployed or reused a legitimate security product executable (signed, trusted, and commonly allowed through application control policies).

No modification was made to the executable itself.

Instead, the attackers:

Placed a malicious DLL in the same directory as the legitimate executable
Chose a DLL name expected to be loaded by the program
Ensured file timestamps closely matched the legitimate binary to avoid suspicion

3. DLL side-loading execution

When the legitimate security executable was launched (manually or via service start):

Windows searched the local directory first for required DLLs
The malicious DLL was loaded instead of the legitimate one
The DLL executed ShadowPad directly in memory
Control was passed back to the legitimate application, which continued to function normally

This prevented user-visible errors and significantly reduced detection likelihood.

Payloads and components used

Primary payload

ShadowPad backdoor (customized build)

Loader

Malicious DLL acting as a reflective loader
Obfuscated exports to resemble legitimate libraries
Minimal disk writes after initial placement

Post-exploitation capability (available via plugins)

Command execution
File system interaction
Credential harvesting
Network discovery
Process injection
Proxy and tunneling functionality

The modular design allows attackers to delay high-risk actions until they are confident they remain undetected.

Persistence mechanisms observed

Registry Run keys referencing trusted executables in non-standard directories
Windows services created with benign-looking names
Scheduled tasks tied to system startup or low-activity hours

Persistence was deliberately redundant, indicating an expectation of long-term presence.

What was impacted

Systems affected

Core telecom service management servers
Network monitoring and provisioning systems
Internal authentication and directory-linked services
Administrator workstations used for infrastructure management

Risk exposure

While no confirmed data exfiltration was observed during this phase, the level of access enabled:

Passive monitoring of internal communications
Mapping of network topology
Collection of sensitive operational metadata
Potential lateral movement into government or enterprise customer environments

Antivirus and EDR interaction

The main executable was digitally signed and trusted
The malicious DLL was custom-built and low-prevalence
ShadowPad primarily operated in memory
Network traffic was encrypted and low volume

As a result:

Traditional antivirus did not trigger
Some EDR tools logged suspicious DLL load events but did not block them by default
Alerts were often categorized as “anomalous but not malicious”

Indicators of Compromise (IOCs)

These indicators should be used for threat hunting and correlation, not as standalone blocklists.

File-based indicators

DLLs located in security software install directories that are:
- Unsigned
- Recently created
- Named similarly to legitimate modules
Common naming patterns observed:
- log.dll
- utils.dll
- version.dll
- securityui.dll
File timestamps closely aligned with the legitimate executable

Registry indicators

HKLM\Software\Microsoft\Windows\CurrentVersion\Run\ entries pointing to security executables outside Program Files
Services with:
- Benign or generic names
- Binary paths referencing security tools in unusual directories
Registry entries modified shortly after initial access timestamps

Process behavior indicators

Trusted security executables loading DLLs from their working directory
Security tools spawning:
- cmd.exe
- powershell.exe
- rundll32.exe
Unusual parent-child relationships involving monitoring or protection software

Network indicators

Outbound encrypted connections over TCP 443 to IP addresses not associated with the vendor
Long-lived connections with:
- Low data volume
- Regular beacon intervals
TLS sessions lacking proper certificate chains or SNI values
Direct outbound traffic from internal servers bypassing corporate proxies

EDR-specific detection guidance

DLL side-loading detection (EDR)

Logic:

Monitor for DLL load events where:
- The DLL is loaded from the same directory as the executable
- The executable is signed and trusted
- The DLL is unsigned or newly created

High-risk scenario:

Security or monitoring software loading local DLLs not present in baseline installs

Process execution rules

Alert when:

A trusted security executable spawns command-line interpreters
A security agent launches scripting engines
Child processes perform network connections immediately after DLL load

Network behavior rules (EDR + NDR)

Flag systems where:

Security tools initiate outbound connections to unknown infrastructure
Beaconing intervals are consistent over long periods
Encrypted traffic originates from processes not expected to communicate externally

Threat hunting queries

Hunt 1 – Suspicious DLL loads

Executable: signed, trusted vendor
DLL path: executable directory
DLL signature: missing or invalid
File creation time: recent

Hunt 2 – Abnormal child processes

Parent process: security or monitoring tool
Child process: shell, script engine, or LOLBin
Execution time: outside maintenance windows

Hunt 3 – ShadowPad-like C2

Periodic outbound connections
Same destination IP over long duration
Minimal data transfer
No DNS resolution or suspicious TLS metadata

Why this campaign matters

This activity reflects a mature threat model where attackers:

Avoid exploits
Abuse trust
Blend into enterprise noise
Prioritize longevity over speed

For telecom providers, the implications are serious due to their central role in national and regional communications infrastructure.