Unmasking a Dual-Stage Credential Harvester Operating via RMM Tools

This investigation became the foundational case that allowed me to fingerprint a recurring threat actor across multiple years of activity — the same actor documented in the Straw Hat Campaign writeup.

A Curious Anomaly

My investigation began not with a high-severity alert, but with a repetitive, informational anomaly: Windows Event ID 4610. This event signifies that an authentication package has been loaded by the Local Security Authority (LSA).

Usually, this is noise. However, the log showed ScreenConnect.WindowsAuthenticationPackage.dll being loaded into a privileged memory space. The problem?

This environment has no authorized ScreenConnect deployment.

INSIGHT: ScreenConnect is a legitimate RMM tool, and its custom LSA Authentication Package is a standard component for the app. However, its presence on a system where it was never authorized is a massive red flag. This discovery shifted my hypothesis: I wasn’t just looking at a stray installer; I was looking at an unauthorized, high-privilege process leveraging trusted components for persistence.

Initial Access and Deployment Methods

I started in the middle of the story, which left me missing the context. I had to back track to find the initial point of compromise. To be brief, that compromise was a social engineering tactic paired and a trojanized installer.

The Initial Access Vector (TA0001)

The infection originated from a file disguised as a ubiquitous corporate tool: Adobe_Reader_V400A18420.msi. In reality, this was a wrapper for the Syncro RMM agent.

Dynamic analysis confirmed that the “Adobe” installer was merely a shell. Upon execution via msiexec.exe, it launched a chain of processes designed to deploy multiple RMM agents. The attacker wasn’t just getting a foot in the door; they were setting up a redundant “Living Off the Land” (LOTL) environment using:

• Syncro (Primary C2) - Syncro hidden in an AdobeReader wrapper!

• Splashtop & Atera (Redundancy)

• ScreenConnect (High-Privilege Persistence)

Forensic Verification

Initial attempts to identify malicious strings in the MSI were met with resistance due to the database structure, but a low-level binary extraction revealed the truth. Despite the “Adobe” filename, the internal metadata was a 1:1 match for Syncro RMM (Servably, Inc.).

I recovered the embedded CONFIG_JSON blob directly from the binary stream. Decoding this revealed hardcoded endpoints to kabutoservices.com—the same “Kabuto” infrastructure seen in the later “Straw Hat” campaigns.

Living Off the Land (LOTL) Deployment

Upon execution, the attacker didn’t rely on a single, custom piece of malware. Instead, they leveraged the trusted nature of Managed Service Provider (MSP) tools, a technique known as “Living Off the Land” (LOTL), and even deployed a redundant set of RMM tools:

• Syncro
• Splashtop
• Atera
• (x2) ScreenConnect

Persistence and Evasion Mechanisms (T1543.003, T1497)

The dynamic analysis provided technical details on how the attacker ensures persistence and evades detection using the Syncro installer.

Technical Mechanism	MITRE ATT&CK	Joe Sandbox Analysis Details
Service Persistence	T1543.003 (Windows Service)	The installation used InstallUtil.exe to create a dedicated “Syncro” service with a configured automatic restart on failure (after 5, 10, and 60 seconds), ensuring recovery.
System Profiling / Evasion	T1497 (Virtualization/Sandbox Evasion)	The Syncro service runner performed extensive WMI queries against hardware components (Win32_PnPEntity, Win32_VideoController, Win32_PhysicalMemory, etc.). This systematic environment profiling is characteristic of malware attempting to detect and avoid analysis within a virtual machine or sandbox.
C2 Infrastructure & Discovery	T1105 (Remote Services), T1018 (Remote System Discovery)	Configuration data embedded in the execution reveals endpoints for authentication and C2, including admin.syncroapi.com and realtime.kabutoservices.com.

The LSA Persistence Mechanism

With the initial attack vector mapped and the ScreenConnect.WindowsAuthenticationPackage.dll from the Event Viewer log in scope, static analysis of the ScreenConnect components surfaced a notable anomaly in file composition: while the majority of files were compiled .NET assemblies, the authentication and credential components were compiled assembly code — low-level unmanaged binaries required to interface directly with Windows security APIs.

Loading the unmanaged DLLs into Ghidra to analyze their imported functions revealed the following:

Stage 1: Credential Harvesting and Identity Manipulation (T1003.003)

The ScreenConnect.WindowsAuthenticationPackage.dll contained direct calls to the following critical, high-privilege APIs:

API Function (Module)	Technical Purpose	Forensic Conclusion
LsaGetLogonSessionData (SECUR32.DLL)	Retrieves security tokens and credential information from the LSA’s memory space.	Evidence of credential harvesting capability. This is the core function leveraged by tools like Mimikatz.
AllocateLocallyUniqueId (ADVAPI32.DLL)	Creates a unique ID for a process or user.	Identity & Token Manipulation. Necessary for an attacker to establish a new, possibly temporary, security context.
CreateWellKnownSid (ADVAPI32.DLL)	Creates a Security Identifier (SID) for a predefined system group (e.g., Administrators).	Privilege Enumeration/Escalation. Used to check for or construct privileged identity tokens.

• LsaGetLogonSessionData (Microsoft Learn)
• SECURITY_LOGON_SESSION_DATA (Microsoft Learn)

With this evidence mapped, the working hypothesis is that the attacker leveraged the ScreenConnect LSA component to achieve high-privilege persistence — a technique formally classified as LSA Authentication Package Abuse. While direct code injection could not be confirmed from assembly analysis alone, the imported API surface is consistent with credential access and active session data exfiltration.

The Outcome

This case was later attributed to the same threat actor fingerprinted in the Straw Hat Campaign Investigation.

What began as a repetitive informational event in the log pipeline became the anchor point for tracking a multi-year operation.

Defensive Takeaways

The initial signal here — Event ID 4610 — is classified as informational and is routinely suppressed in noisy environments. That classification is precisely what made it useful as a pre-compromise indicator. A few concrete controls:

• Maintain an authorized RMM inventory. Any RMM agent not in that list, regardless of how legitimate it appears, warrants immediate investigation.
• Alert on Event ID 4610 for non-baseline authentication packages. Establish a known-good baseline and treat deviations as high-priority events.
• Treat LSA-touching DLLs as high-value forensic artifacts. Unmanaged binaries in an otherwise managed-code deployment are an anomaly worth examining at the API import level.
• Informational Event IDs are often the quietest pre-compromise signals. Attackers rely on defenders ignoring low-severity telemetry. Tuned baselines turn that assumption against them.