War Room

Shells From Above

RSM logo

Home > Defense > The Threat That Slipped Past the Machines, and Ran Into a Human

The Threat That Slipped Past the Machines, and Ran Into a Human

By

How proactive threat hunting caught an attack engineered to evade the industry’s leading endpoint platforms.
By Justin Dolgos, Senior Threat Hunter at RSM Defense


Most malware tries to avoid your security tools. This one knew them by name.

Modern attackers have learned that the fastest way past a hardened security stack is not to break it. It is to convince a trusted user to walk them through the front door. Social engineering attacks that prompt a person to run a command they do not understand are surging across every industry, and they are purpose-built to slip past the automated controls organizations rely on every day.

One of these attacks recently landed on an endpoint in a customer environment we protect. It was well-built, deliberately evasive, and engineered to recognize and avoid many of the biggest names in endpoint security. It did not avoid us. Here is how our threat hunting team caught it, why we believe it ultimately came up short, and what we did to make sure the same technique never gets a second chance.

The Setup

The attack began the way many of these incidents do, with a user who believed they were being helped. According to the user, they were contacted by someone claiming to be technical support and were guided to open their browser and enter a code. That single action triggered a chain of events that downloaded and executed a malicious PowerShell script.

The delivery mechanism was clever. Rather than hosting the script somewhere obviously suspicious, the attacker staged it on a fraudulent Microsoft SharePoint site. SharePoint domains are trusted almost universally, which means reputation-based URL filtering tends to wave them through. The user’s machine reached out, pulled down the script, and executed it directly in memory, leaving little on disk to find.

A Script Built to Hide

What made this payload notable was not just what it did, but what it was designed to avoid. Before taking any meaningful action, the script ran a series of checks to decide whether it was safe to proceed. This is the hallmark of a mature, professionally developed tool rather than opportunistic commodity malware.

 

  • Security vendor evasion. The script queried the Windows Security Center for installed antivirus and EDR products and carried a hardcoded list of major vendors it was built to flee from. That list included names like CrowdStrike, Trellix, Rapid7, Carbon Black, and others. If any of them were present, the script would silently shut down and leave no trace. It was, in effect, a tool that reads the room before making a move.
  • Corporate-only targeting. The script checked whether the machine was joined to a corporate domain. If the endpoint was a standalone or workgroup machine, it exited immediately. This ensures the attacker only spends effort on real corporate targets, and it doubles as a way to sidestep many automated analysis sandboxes, which are frequently not domain-joined.
  • Reconnaissance built in. The script programmatically located the domain controller, resolved its address, and confirmed it could see the internal Active Directory infrastructure. This is the digital equivalent of an intruder mapping the building’s floor plan before deciding where to go next.

 

Once those gates were passed, the script went to work. It collected the hostname, domain details, the current user, the full network configuration, and the list of installed security software, then bundled it all into a single report written to a temporary folder. From there it attempted to ship that report to an attacker-controlled server and pull down a second-stage payload, a malicious installer that the broader security community has confirmed as a trojan.

Why It Did Not Trigger, and Why We Caught It Anyway

Here is the uncomfortable truth that organizations need to sit with: this script ran without tripping native alerting. It was specifically engineered to evade detection, and against many configurations it would have succeeded quietly. The reconnaissance would have been exfiltrated, the second-stage payload installed, and persistence established, all before anyone realized something was wrong.

That is exactly the gap that proactive threat hunting exists to close. Automated detection is essential, but it is a floor, not a ceiling. Our team does not wait for an alert to tell us something is wrong. We hunt for the behaviors that attackers cannot avoid exhibiting, even when they have gone to great lengths to stay quiet. In this case, a hunt across the environment surfaced the suspicious PowerShell activity, and we pulled the thread from there.

Within the investigation we reconstructed the full execution chain end to end: the initial browser-driven execution, the in-memory script, the reconnaissance collection, and the outbound attempts to attacker infrastructure. We confirmed exactly how far the attack progressed, and just as importantly, how far it did not.

The Wheels Came Off

This is the part that matters most. For all its engineering and evasion, the attack stalled out. It cleared every check it was built to clear, gathered its reconnaissance, and then ran straight into a wall at the moment it needed to phone home. Our investigation confirmed the following:

 

  • No confirmed exfiltration. The reconnaissance data was written to the local machine, but we found no evidence that it was ever successfully transmitted to the attacker’s server.
  • No second-stage payload. We found no evidence that the malicious second-stage installer was downloaded, written to disk, or executed.
  • No persistence. The script attempted to plant a registry-based persistence mechanism, but we found no evidence that it was ever created.
  • No lateral movement. We found no evidence of the attacker moving from the affected endpoint to any other system, and no evidence of credential misuse or account manipulation following the incident.

 

So why did a payload this well-built fall flat? We cannot state the cause with certainty, but the evidence points to a failure at the network egress stage, the moment the script tried to reach attacker infrastructure. A few hypotheses stand out:

 

  • Egress controls held the line. The script attempted to contact its command-and-control server at 46[.]30[.]188[.]33 using plain, unencrypted HTTP to a bare IP address. That is precisely the kind of traffic that perimeter controls, web proxies, and egress filtering are designed to flag and drop. A single well-placed network control may have been all it took.
  • The infrastructure was dead on arrival. Attacker infrastructure is notoriously short-lived. The command-and-control server at 46[.]30[.]188[.]33 may have already been taken down, sinkholed, or simply offline by the time this particular victim’s script tried to reach it. The attacker built the machine; the destination may not have been home.

 

Whatever the precise cause, the outcome is the same. The attack was contained to a single endpoint. That machine was isolated and slated for reimaging, and a sweep across the rest of the environment confirmed the malicious infrastructure and script were not present anywhere else.

How the Attack Was Meant to Unfold

It is worth visualizing the full plan, because the gap between what the attacker intended and what actually happened is the whole story. The diagram below traces the intended progression. Everything in green was confirmed in our telemetry. The point where the attack stalled is marked in red, along with the stages that were attempted but never confirmed successful. The final stages, in gray, represent where an attack like this typically goes when it is not stopped, a trajectory this one never reached.

Had the recon reached the attacker and the second stage landed, the most likely next steps would have been hands-on-keyboard access to the host, theft of credentials to enable movement deeper into the network, and ultimately a domain-wide impact such as data theft, extortion, or ransomware. The reconnaissance the script gathered, including domain controller details and the internal network layout, is exactly the intelligence an operator uses to plan that kind of expansion. Stopping the attack at the recon stage did not just protect one endpoint. It denied the attacker the map they needed for everything that would have come next.

Indicators of Compromise

For the broader defender community, the following indicators were associated with this attack and can be used to hunt within your own environments:

Turning One Incident Into Lasting Protection

Catching an attack is only half the job. The other half is making sure the same technique can never succeed again. Out of this investigation, our team built and deployed a new custom behavioral detection across every environment we protect.

We deliberately did not build it around the specific filenames or IP addresses involved, because those are trivial for an attacker to change. Instead, we targeted the underlying techniques the attack relied on, the behavioral fingerprints that a dropper of this kind has to exhibit regardless of how it is dressed up. The result is a detection that remains effective even as attackers rotate their infrastructure and rename their payloads.

Critically, this detection is not just an alert. It is paired with an active response policy. If this behavior appears on a protected endpoint again, the offending process is killed and the endpoint is automatically quarantined, stopping the attack before it can reach the stages of exfiltration or payload delivery. What slipped past native tooling would now be neutralized on contact.

The Takeaway

Attackers are investing real engineering effort into evading the security tools the industry depends on. The script we analyzed was purpose-built to recognize and avoid the leading endpoint platforms, and it was good at it. That reality should reframe how organizations think about defense.

Tooling alone is not enough. The organizations that catch these attacks are the ones pairing strong technology with skilled humans who hunt proactively, investigate thoroughly, and turn every incident into a durable improvement. That is the model that stopped this attack, and it is the model we bring to every environment we defend.

If you want to know whether an attack like this would be caught in your environment, that is a conversation worth having before an attacker forces it.

 

 

About the author: Justin Dolgos is the Senior Threat Hunter at RSM Defense, where he leads proactive threat hunting and detection engineering across the organization’s managed customer environments.