Know Thy Enemy: A Novel November Case on Persistent Remote Access

Threat actors are, frankly, rarely original. They share the same playbooks, tactics, and often don't even bother to rename offensive security tool names. In early November 2024, the Huntress SOC investigated what appeared to be mundane tradecraft that, on closer inspection, held novel insight into a threat actor’s behavior for persistence and remote access. 

‍

Initial Access 

Threat actors are not magically conjured onto a network. Rather, they must gain their foothold somehow. Huntress has a blog in the pipeline all about initial access and our thoughts on how to mitigate it, as denying a threat actor their initial access from your network will prevent having to worry or act on any further tradecraft.

In this blog's case, the adversary gained initial access via a public-facing RD-Web instance. It was discovered that this RD-Web instance had been subject to brute forcing, whereby multiple threat actors had taken advantage of the opportunity to gain entry to the network from the insecurity that RDP had brought to the perimeter.

‍

Brute force is unsophisticated but does achieve results for threat actors. A brute force against a non-MFA’d authentication service will inevitably yield access. A user was eventually accessed from brute force via the following public IPv4s between October 28 and November 12: 

• 217.138.216[.]60
• 23.158.40[.]185
• 147.135.112[.]230
• 31.220.5[.]23
• 78.141.202[.]136
• 147.45.79[.]193

‍

Lateral Movement

Threat actors typically don’t wish to reside on the beachhead machine but seek to understand more about the new terrain and pivot across it to higher-tiered machines. The threat actor leveraged the legitimate tool PsExec to begin to not just move laterally but also execute commands across multiple machines at one time. 

‍

Via PsExec, the compromised user ran two batch files from the remote PsExec session. The batch files completed the following actions:

[.highlight]openrdp.bat[.highlight] facilitated RDP connections to hosts by manipulating both the registry and the firewall rules. Its contents are revealed below:

[.highlight]mimon.bat[.highlight] worked to ensure the successful installation of the MeshAgent, remove LSA protection, and enable WDigest to facilitate the storage of credentials in plaintext. The contents of this file are:

Huntress has shared much about how to investigate PsExec, but an under-appreciated feature of PsExec is its ability to run commands across all machines in the network, at once, providing the compromised user has the appropriate privileges.

> Computer | …..if you specify a wildcard (\\*), PsExec runs the command on all computers in the current domain.

Threat actors, like the one in this case, can, therefore, have a huge negative cascading impact on the environment.

‍

Renamed MeshAgent 

Following initial access via successful brute force, the threat actor escalated their privileges and gained control of an Administrator account.

Via their PsExec activity, they proceeded to push the installation of a renamed malicious MeshAgent instance: "[.highlight]C:\Program Files\Windows NT\nvspbind\nvspbind.exe[.highlight]"—the name of a virtualization binary (but more on this shortly).

‍

A quick analysis of the binary showed the MeshAgent instance reached out to the following domain: [.highlight]wss[://]193.46.255[.]73:443/agent[.]ashx[.highlight]

‍

Pivoting on this investigative thread, an online search of this IP showed it had the associated hostname [.highlight]WIN-O5926T00T93[.highlight]. Not only did this machine hostname not match the naming convention of the legitimate machines in the Active Directory, but it's a telling static indicator that can be tracked—Huntress has found that threat actors rarely change their machine names, offering high-fidelity detection opportunities for defenders when these machines successfully authenticate.

Moreover, honing in on the call-back address of the MeshAgent, it fronted itself as a "[.highlight]Windows Network Virtual Adapter (v3.1.56.8342) - Login [.highlight]," which was, to put it bluntly, weird.

‍

To confirm, Windows Network Virtual Adapter is a technology dedicated to host-based virtualization and has nothing to do with malicious activity. What the threat actor has attempted to do here is fly under the radar by renaming their client-side MeshAgent after a virtualization binary (“[.highlight]C:\Program Files\Windows NT\nvspbind\nvspbind.exe[.highlight]”) and the server side as “[.highlight]Windows Network Virtual Adapter (v3.1.56.8342) - Login[.highlight],” when it is, in fact, just the login for MeshAgent. 

This is an unrefined but effective defense evasion for their remote access. They’re likely able to suppress suspicion due to the “consistency” in client/server naming schemas. 

The intrusion was wrapped up, and the partner was informed of all findings. But the Huntress SOC did not take the findings to full satisfaction—could this threat actor have deployed similar activity elsewhere, in a completely different network?

‍

Hunting Down Tradecraft

Threat hunting is the art of specifically querying a verbose set of telemetries with specific security questions until the investigator is satisfied. The aims for threat hunting are myriad, but the goal for the SOC at this time was to identify if this threat actor had compromised any other environments with similar tradecraft.

After the Huntress SOC neutralized and concluded the above intrusion, a retroactive analysis of all Huntress data was conducted for the specific MeshAgent/Nvspbind tradecraft. One result returned:

‍

This case was known to us—the first alert was a week prior to the investigation above. The Huntress SOC had responded to a Defender alert for credential dumping, which blocked “avrestore.exe” and “ARest1.exe.” These binaries were determined not to be mimikatz but, in fact, part of a previously documented tool kit for brute force to aid and facilitate lateral movement.

‍

Now, a week later, our retrospective threat hunt had uncovered a final persistent artifact of the threat actor’s operation—the MeshAgent/Nvspbind remote connection. Moreover, for this additional case, the root cause was also an RDP brute force, AS WELL AS the threat actor using WDigest again for credential access, suggesting this threat actor is consistent in their tradecraft and playbook.

‍

Conclusions

The Huntress SOC enjoys ruining cyber criminals’ days. This threat actor has displayed a novel and amusing tradecraft for their remote access/command-and-control infrastructure, but one that can nonetheless be tracked and detected for the benefit of the information security community.

The cases shared here highlight the importance for security investigators to create and commit to continuous feedback loops between iterations of detection and hunting. This ensures that threat actors are given no quarter or reprieve for any insidious persistence and backdoors they think they may peacefully enjoy. 

For defenders of networks, the cases here have the following lessons learned we can recommend: 

• Continuously review and harden the external perimeter, removing authentication services—like RDP—from the public internet where possible.

• Enforce MFA where external services must be exposed, and ensure all MFA services actually work—third-party MFA for RDP is notoriously difficult to configure correctly.

• Where possible, deploy allow-lists for software to ensure that threat actors and users alike cannot easily run whatever tools and toys they wish haphazardly. 

‍

Indicators of Compromise

‍

MITRE ATT&CK

‍

Credit to Faith Stratton and Josh Allman for the root-cause investigation and related findings from threat hunting.

Thanks to Austin Worline and Jamie Dumas for initial intrusion investigation. 

‍Special thanks to Anton Ovrutsky for additional findings and editing the blog.

‍

‍