A recent Proofpoint investigation gave researchers a detailed look at a threat actor’s post-compromise activity - with continuous visibility inside a controlled environment over the course of more than a month. 

The attacker - targeting transportation and logistics companies - didn’t rely on anything particularly advanced to get in. A malicious VBS file, a PowerShell script, a ScreenConnect installation. A fairly standard entry point. 

What stands out is not how the attack started - but how it operated afterward. 

The real problem: unrestricted PowerShell 

For most of the intrusion, the attacker didn’t need sophisticated evasion techniques or trusted binaries. They relied on PowerShell. 

Over the course of several weeks, at least 13 scripts executed inside the environment - enumerating users, scraping browser data across Chrome, Edge, and Firefox, identifying financial platforms, and exfiltrating results to Telegram. All unsigned. All effectively ungoverned.  

This is still the default in many organizations. 

PowerShell is widely available, deeply integrated into Windows, and often insufficiently restricted. Execution policies are misconfigured, inconsistently enforced, or trivially bypassed. In practice, this means that once an attacker gains a foothold, they can operate freely using scripts - without needing to introduce complex malware. 

And that’s exactly what happened here. 

Where the attack could have been stopped 

This kind of activity doesn’t require a novel detection technique to disrupt. It requires control over what is allowed to execute. 

If PowerShell scripts in this environment had been required to be signed - and signed only with certificates controlled by the organization - the attacker’s workflow would have looked very different. 

Those 13 scripts would not have executed by default. 
Each one would have required either: 

• access to a trusted signing certificate, or  

• a way to bypass enforcement mechanisms designed to prevent exactly that.  

Neither is trivial. And early in an attack chain, that kind of friction matters. 

Requiring script signing doesn’t make attacks impossible. But it forces attackers out of the “cheap and scalable” path - and that’s often enough to break the chain before it reaches meaningful impact. 

A side note: attackers care about signing too 

Later in the intrusion, the attacker introduced a new technique. Instead of deploying a payload directly, they routed it through a signing service they operated themselves - using a legitimately issued code-signing certificate. 

The resulting binary was properly signed, trusted by Windows, and appeared legitimate from the operating system’s perspective. 

This is notable, but not surprising. 

Attackers increasingly understand that signed code blends in better. Some are now going a step further - obtaining valid certificates and building their own signing infrastructure to support their operations. 

But this wasn’t the core of the attack. The entire operation - om initial reconnaissance to data exfiltration - was built on a much simpler prerequisite: unsigned PowerShell scripts executing freely. 

Signed isn’t the control - trust is 

The signing service detail highlights a broader issue. 

Most environments still operate on a binary model: something is either signed or it isn’t. But that distinction alone is not meaningful from a security perspective. 

A valid signature doesn’t tell you: 

• who signed the code  

• whether they were authorized to do so or 

• whether your organization should trust that certificate at all  

In this case, the certificate was legitimate. It passed validation. Windows accepted it. 

But it was never under the organization’s control. 

The question that matters isn’t “is this signed?” 
It’s “is this signed by a certificate we trust?” 

What controlling script execution actually looks like 

To prevent attacks like this, organizations need to do two things: 

• Control how code gets signed  

• Control what is allowed to run  

That means: 

• Requiring PowerShell scripts to be signed 
  Not optionally - enforced through policy.  

• Allow listing only your own certificates 
  Scripts signed with unknown or external certificates should not execute.  

• Protecting signing keys in controlled infrastructure 
  Not accessible to developers, scripts, or compromised systems.  

• Enforcing policies at the endpoint 
  Using mechanisms like WDAC and PowerShell execution policies to ensure only trusted code runs.  

With a setup like this, the attacker’s approach breaks down early. 

Unsigned scripts don’t run. 
Scripts signed with attacker-controlled certificates don’t run. 
And obtaining access to a trusted signing process becomes a much higher barrier than simply dropping a script. 

Enforcing these policies is not the hard part. Rolling out WDAC or PowerShell execution policies can be done with a few well-defined Group Policy changes. 

The real challenge is everything behind it: establishing controlled signing workflows, managing certificate access, introducing approvals where needed, and ensuring that sys-admins can still operate without friction. 

This is where a platform like SignPath comes in - providing the policy-driven signing process that makes strict enforcement practical in real-world environments. 

Breaking the attack chain where it matters 

The Proofpoint case highlights two separate realities: 

• Attackers are becoming more comfortable with code signing  

• Defenders are still not enforcing basic execution controls  

The first is interesting. The second is what actually determines the outcome. 

You don’t stop this attack by detecting a signed payload late in the chain. 

You stop it by preventing the first unsigned script from running.