In late February 2026, Proofpoint researchers executed a malicious payload from a threat actor targeting transportation organizations inside a controlled decoy environment operated by our partners at Deception.pro. While the environment did not represent a transportation carrier, it remained compromised for more than a month—offering rare, extended visibility into post‑compromise operations, tooling, and decision‑making.
Proofpoint previously documented this actor’s campaigns against trucking and logistics companies to facilitate cargo theft and freight fraud. In this case, the extended interaction revealed persistence through multiple remote management tools, the use of a previously unknown signing‑as‑a‑service capability designed to evade detection and suppress security warnings, and extensive post-compromise reconnaissance activity.
This reconnaissance focused on identifying financial access—such as banking, accounting, tax software, and money transfer services—as well as transportation‑related entities, including fuel card services, fleet payment platforms, and load board operators. The latter activity was likely designed to support crimes against the transportation industry, including cargo theft and related financial fraud.
In November 2025, Proofpoint published research describing a threat actor leveraging compromised load boards to gain access to trucking companies, enabling freight diversion and cargo theft. While that research focused on initial access and target impact, opportunities to observe the actor’s post-compromise operations were limited.
This engagement changed that.
Following payload execution inside the Deception.pro environment in late February, the actor maintained access for more than a month. Their ensuing activity provided Proofpoint researchers with an unusually detailed view of post‑compromise tooling, scripting, reconnaissance behavior, and operator‑driven decision‑making.
On February 27, 2026, after compromising a load board platform, the actor delivered a malicious payload via email to transportation carriers inquiring fraudulent advertised loads. Load board platforms are online marketplaces that connect shippers and freight brokers with motor carriers by advertising available loads. The payload consisted of a Visual Basic Script (VBS) file that, when executed:
Figure 1. Email content sent after responding to a fraudulent load posted on a load board.
Figure 2. Actor-controlled web page hosting a malicious VBS payload.
Once access was established, the actor focused heavily on remote administration and redundancy.
Over the following month, the actor leveraged existing access to install:
The use of multiple concurrent RMM platforms suggests deliberate redundancy designed to preserve access even if one tool is detected or disabled.
The fourth ScreenConnect instance, downloaded in late March, stood apart from earlier installations.
This installation chain began when the attacker used an existing ScreenConnect session to launch an initial PowerShell script. That script bypassed normal PowerShell controls, downloaded and executed a second‑stage PowerShell payload with parameters specific to the ScreenConnect installer, and then deleted itself to reduce forensic artifacts. The second‑stage script performed the core deployment using a third‑party signing‑as‑a‑service provider, which re‑signed ScreenConnect installers and components with a valid—but fraudulent—code‑signing certificate.
Specifically, the second‑stage script:
After installation, the script optionally downloaded a ZIP archive from the same S3 infrastructure. This ZIP contained ScreenConnect component binaries (e.g., ScreenConnect.Client.exe) re‑signed with the same certificate used for the MSI. The script extracted these files and replaced the originally installed components—backing up existing files, stopping and restarting the ScreenConnect service as needed. This step eliminated ScreenConnect binaries signed with now‑revoked ConnectWise certificates and ensured that all installed components were uniformly signed with a certificate that Windows still treated as trusted.
In combination, these actions allowed the attacker to establish and maintain persistent remote access while actively circumventing certificate revocations, security warnings, and trust‑based endpoint controls. By laundering trust through an external signing service and replacing revoked vendor‑signed binaries, the attacker preserved long‑term, stealthy access and reduced the likelihood of user awareness or control‑based detection.
Proofpoint researchers collaborated with security researcher @Squiblydoo to analyze the signing service and successfully revoke the associated certificate:
SignerName: STEPHEN WHANG, CPA, INC.
ValidFrom 5:00 PM 12/23/2025 ValidTo 4:59 PM 12/24/2026 SerialNumber 38 4B 49 3A B7 6F AE 54 F8 3A E6 BF A8 7E 5C 10 Thumbprint D45D60B20006BC3A39AE1761CB5F5F5B067B4EE5 CertIssuer Sectigo Public Code Signing CA EV R36
With persistent access in place, the actor conducted hands‑on-keyboard activity and tooling execution:
These actions indicate discretionary, operator‑driven targeting rather than purely automated malware execution.
During the intrusion, Proofpoint observed at least 13 PowerShell scripts executed by the threat actor which, collectively, focused on determining whether the compromised host belonged to a financially valuable user.
This telemetry provides the actor with rapid insight into a victim’s financial authority, payment access, and business role.
Across multiple scripts, Proofpoint identified consistent behaviors:
The scripts searched for indicators of access to the following platforms, among others:
The breadth of these targets strongly aligns with financially motivated theft, fraud, and cargo diversion operations tied to transportation workflows. In particular, targeting of fuel card services, fleet payment platforms, and freight brokerage systems indicates intent to enable crimes against the transportation industry, including freight diversion and cargo theft.
In late March, the attacker ran an additional PowerShell script through ScreenConnect’s custom property feature to quietly collect endpoint intelligence and report it back to the attacker through the existing remote‑access channel. It enumerated installed antivirus software and checked for the presence of high‑value financial, tax, accounting, and cryptocurrency applications. The results were automatically returned to the attacker’s ScreenConnect console without generating separate network traffic or alerts.
This extended intrusion highlights how financially motivated threat actors targeting transportation organizations operate well beyond initial access, prioritizing persistence, reconnaissance, and credential harvesting to identify opportunities for financial exploitation across transportation and related financial platforms. Portions of this activity are also consistent with preparatory behavior observed in freight theft and cargo diversion operations.
Notably, the use of a signing‑as‑a‑service capability underscores a growing trend toward attacker use of legitimate trust mechanisms to evade detection.
For transportation, logistics, and freight organizations, these findings reinforce the importance of monitoring for unauthorized remote management tools, suspicious PowerShell activity, and abnormal browser telemetry associated with financial platform access.
2049863 - SimpleHelp Remote Access Software Activity
2049805 - Simplehelp Remote Administration Suite HTTP Server Value in Response
2066799 - Kaseya Pulseway Domain in DNS Lookup (pulseway .s3-accelerate .amazonaws .com)
2066797 - Kaseya Pulseway RMM Domain in DNS Lookup (pulseway .com)
2066798 - Observed Kaseya Pulseway Domain (pulseway .com) in TLS SNI
2066800 - Observed Kaseya Pulseway Domain (pulseway .s3-accelerate .amazonaws .com) in TLS SNI
*First Uploaded to VirusTotal by Proofpoint
1f89a432471ec2efe58df788c576007d6782bbdf5b572a5fbf5da40df536c9f5
hxxps://carrier-packets-docs[.]com/FREEDOM_FREIGHT_SERVICES_CARRIERS_ONBOARDING.vbs
hxxps://qto12q[.]top/pdf.ps1
f4977bfeae2a957add1aaf01804d2de2a5a5f9f1338f719db661ac4f53528747
d9832d9208b2c4a34cf5220b1ebaf11f0425cf638ac67bf4669b11c80e460f58
7f54cf5e2beb3f1f5d2b3ba1c6a16ce1927ffecd20a9d635329b1e16cb74fb14*
de30bb1e367d8c9b8b7d5e04e5178f2758157302638f81480ba018331a6f853e*
af124i1agga.anondns[.]net
b861e3682ca3326d6b29561e4b11f930f4a9f10e9588a3d48b09aa6c36a8ea80
82d603c0b387116b7effdee6f361ca982c188de0c208e681e942300a0139c03f
8a3d6a6870b64767ad2cc9ad4db728abf08bae84726b06be6cb97faac6c14ae4*
screlay[.]amtechcomputers[.]net
3dcb89430bae8d89b9879da192351506f4fdb7c67e253a27f58b3bf52101cd4c*
signer.bulbcentral[.]com
services-sc-files.s3.us-east-2.amazonaws[.]com
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
