When a trusted trucking email delivers remote access

Overview#

In May 2026, Have I Been Squatted came across a business email compromise (BEC) campaign targeting US freight and logistics contacts.

The campaign used [email protected], a Microsoft 365 account belonging to a long-established, small US freight carrier. The earliest visible activity involved payload staging on Amazon S3, a "Bill of Lading (BOL)" PDF created, and phishing messages dispatched. We recovered one of those messages. The infrastructure and lure craft point to a coordinated operation against multiple freight contacts.

The actor used what appears to be a compromised carrier account to reach the carrier's business contacts. Because the send originated from the real Microsoft 365 tenant, SPF, DKIM, and DMARC all passed; the account was almost certainly taken over rather than spoofed, though the mechanism and timing are not something the available evidence can establish.

Recipients who clicked the link in the PDF attachment installed a legitimate N-able Advanced Monitoring Agent, pre-configured to register with the actor's own remote monitoring and management (RMM) account. Within minutes, the agent uploaded a full hardware and software inventory of the victim machine and activated remote script execution, patch management, and network discovery.

Impact#

If a recipient opened the PDF, clicked the link, and ran the EXE, the actor gained persistent remote access to that machine. That access is not limited to reading files. The installed agent supports remote script execution, software deployment, network mapping, and optional full remote desktop. For a freight operator, that is enough to monitor load board activity, intercept shipment details, and redirect cargo or payments.

How we got here#

We traced the chain from one recovered email through payload staging, sandbox execution, and the actor's N-central tenant. Compromise timing and total send volume remain unknown.

No individual step in the chain was sophisticated. The actor used a presumably compromised email account that freight contacts already trusted, a document type those contacts receive every day, and signed commercial software that does not look like malware because it is not. Assembled together, each layer reduced the odds that a recipient or a security tool would pause before the agent enrolled.

Step 1

Compromised carrier email

BOL 3998010.eml

Step 2

PDF lure

BOL_3998010_0526_Bennett_Trucking_Inc.pdf

Step 3

SFX wrapper

BOL_3998010_0526_Bennett_Trucking_Inc.EXE

Step 5

RMM capability

N-able Advanced Monitoring Agent

Step 4

Enrollment config

package.zip / settings.ini

1. Step 1

   Compromised carrier email

   BOL 3998010.eml

2. Step 2

   PDF lure

   BOL_3998010_0526_Bennett_Trucking_Inc.pdf

3. Step 3

   SFX wrapper

   BOL_3998010_0526_Bennett_Trucking_Inc.EXE

4. Step 4

   Enrollment config

   package.zip / settings.ini

5. Step 5

   RMM capability

   N-able Advanced Monitoring Agent

A trusted sender, weaponized#

The recovered email carried the subject BOL 3998010. The body contained a single line asking the recipient to review the attached Bill of Lading. The signature matched the carrier's public footprint down to the street address, phone, and fax. For anyone already doing business with that freight company, this was just another Tuesday morning message.

Freight carriers and their shippers have established relationships, and the actor exploited that trust as the delivery mechanism. By accessing one carrier's account, the actor could mail its business contacts and reach companies expecting exactly this document from that sender, each likely receiving a customized PDF with their own BOL reference.

Since the message came from a real Microsoft 365 tenant, SPF and DKIM passed. Exchange reported dmarc=bestguesspass because bennetttruckinginc.com publishes no DMARC policy for receivers to enforce. These are expected outcomes when an account is taken over rather than spoofed; the checks verify the tenant is genuine, not who operates it.

One detail stands out. The account connected to Microsoft's outbound relay as Anonymous (X-MS-Exchange-Organization-AuthAs: Anonymous), consistent with SMTP AUTH over a legacy connector, a compromised OAuth application, or a third-party send-as tool. Any of those paths can authenticate without triggering MFA.

"Bill of Lading" PDF and S3 payload staging#

The attachment, BOL_3998010_0526_Bennett_Trucking_Inc.pdf, did not carry malware directly. Three link annotations inside the document all pointed to the same URL on an actor-controlled Amazon S3 bucket.

https://connix-report[.]s3[.]us-east-2[.]amazonaws[.]com/BOL_3998010_0526_Bennett_Trucking_Inc[.]EXE

The attachment, a PDF, was styled as a routine file-sharing notification. It names the carrier, references a BOL number, and presents an "Access File" prompt designed to resemble a legitimate document portal. The construction suggests each target received its own version, assembled with a company name, BOL reference, and matching payload filename rather than a generic template sent to a list.

The PDF was a simple Word document exported with links pointing to an external URL; no exploit, no embedded JavaScript, no attempt at obfuscation. What carries it is the framing. Freight staff receive BOLs and secure-attachment notifications from established carriers every day, and a recipient expecting routine paperwork from a known sender has limited reason to check where the link goes before clicking.

The S3 bucket connix-report was publicly accessible at the time of discovery, though directory listing was not enabled. The bucket name references "Connix", a legitimate global logistics provider, though no connection has been established and this appears to be actor-created staging infrastructure. An abuse report was submitted to AWS. PDF metadata recorded a creation timestamp several hours before the phishing email was sent.

The filename conventions matched the targeting with the real BOL number (3998010), real company name, and plausible date suffix (0526). The same naming logic extended to the S3 key, making the EXE look like a document export rather than an executable file.

Pre-configured N-able installer#

The downloaded file (BOL_3998010_0526_Bennett_Trucking_Inc.EXE, 4.4 MB) is a self-extracting archive containing:

├── agent.exe       (4.3 MB)  - N-able Advanced Monitoring Agent installer
└── package.zip     (12.8 KB) - Actor-supplied config package
    ├── settings.ini            - Pre-seeded actor account credentials
    └── images/                 - Installer UI assets

The bundled settings.ini registers the agent directly to the actor's N-able account at install time:

[GENERAL]
SERVER1=https://upload1.am.remote.management/
[email protected]
AGENTMODE=1

[AUTOINSTALL]
ON=1
SITEID=477678

[DEBUG]
VERBOSE=1

What the agent did on install#

We ran the EXE in a sandbox. The sequence below comes from the agent's debug.log:

1. 14:12:55. agent.exe launches and checks in to upload1.am.remote.management via HTTPS (Action=checkin, [email protected], SiteID=477678)
2. 14:12:56. Initial check-in returns "Invalid VAR/Server combination". The agent falls back to a secondary server and pulls the monitoring template from the actor's N-able dashboard
3. 14:13 to 14:18. Sub-components install silently: ScriptRunner (N-central's remote PowerShell and batch execution channel), Patch Management Service Controller, Request Handler Agent, MSP Connect (downloaded from N-able's CDN), and Network Management (Avery)
4. 14:16+. Beaconing begins on a 30-minute interval

Within minutes, the agent uploaded a full asset inventory (assetscan.xml) and monitoring check-in data (247_Upload.xml). Transmitted fields included hostname, IP address, MAC address, operating system build, logged-in user, CPU and RAM, disk capacity, installed software list (names, versions, install dates), and network adapter details.

After installation, the live agent configuration included:

[email protected]
DEVICEID=3902698
GUID=611f0cb93e43dafc5c8f4a20441c111e
DEVICE_UUID=0DDD84C7-8B40-4C2A-989B-8A4E066C1447

[RBM]
MSPID=90c109ee5de37da5575d5c96cddd720b
MASTER_ADDRESS=https://us-master.rbm.system-monitor.com
TERRITORY=AM

At this point the actor had continuous visibility into CPU, RAM, disk, and service state on a 30-minute poll cycle through the 24/7 monitoring module. Remote Background Management (RBM) was active, giving the actor remote script and command execution. Patch management was enabled, meaning software could be pushed to the device at will. Avery (N-able's network discovery module) began mapping local network hosts. The asset inventory ran on a daily schedule. Take Control, which delivers full remote desktop via TeamViewer integration, was configured but had not yet been activated. The system tray icon was suppressed; the agent ran silently as a Windows service named Advanced Monitoring Agent and persists across reboots. An RSA public key under the [KEY] section in settings.ini cryptographically protects uninstall authorization, meaning that the agent cannot be removed without the actor's private key.

What the actor configured next#

A second sandbox snapshot, taken roughly eight hours after install, showed the actor's N-central account had pushed a full monitoring template to the device within about a minute of the agent coming online.

The template arrived as 20 fmplugin (Faster Monitoring Plugin) config JSON files, standard N-central monitoring checks delivered as structured configs rather than arbitrary scripts. Each config had a matching results file confirming execution. The checks covered antivirus status, disk space and I/O, CPU and memory thresholds, seven service monitors on a 30-minute interval, and Application, Security, and System event log collection.

One check in particular stands out. The actor enabled HACKER_ALERT, a failed-login monitor on the Security event log targeting event codes 4625, 4768, 4771, 4772, 4776, and 4777. It is a stock N-able check, but enabling it means the actor's N-central dashboard surfaces authentication failures on the victim machine, including activity from incident responders working the endpoint.

Patch management was configured in report-only mode. All categories were set to Manual approval, vulnerability scanning ran in Report mode, and VulnerabilityScanMode was off. The posture is consistent with a surveillance phase before any payload delivery through the patch channel, which can change with a few clicks in N-central.

The install log recorded a SCRIPTCONTENTSYNCSTATUS=FAILED entry. ScriptRunner, N-central's arbitrary script execution component, failed to sync its script catalog from the server. That is a separate channel from fmplugin; the monitoring template was confirmed delivered and executed regardless.

Campaign timeline#

All activity clustered on two days in May 2026. The payload was staged hours before the phishing send, and the actor's monitoring template deployed within a minute of the agent first connecting.

• Day 1 (May 19) — EXE uploaded to S3, PDF created, phishing email dispatched
• Day 2 (May 20) — Agent installed in sandbox, N-central monitoring template pushed within one minute, first checks executed, extended snapshot taken eight hours later, abuse reports submitted
• Day 6 (May 25) — AWS removed the offending bucket

Why legitimate RMM is hard to catch#

Abusing commercial RMM tools gives the actor several operational advantages that custom malware cannot match. CISA advisory AA23-025A documents the same technique class:

• Traffic blends with legitimate enterprise RMM connections
• Binaries are signed and typically not flagged as malware
• Command and control runs entirely over the vendor's own cloud infrastructure
• Uninstall is cryptographically protected, making removal difficult for victims

The actor's N-able account email ([email protected]) belongs to Norvado, a small Wisconsin cooperative ISP. Norvado issued a public fraudulent email alert in October 2022 warning that @cheqnet.net accounts were being used in fraudulent activity.

OSINT on the stokes487 handle is consistent with a real residential subscriber in Wisconsin, not an actor-generated alias. With reasonable confidence, this is a hijacked mailbox rather than infrastructure the actor created. The username pattern (last name followed by a number) matches Norvado's residential account naming convention. The most probable scenario is account takeover through credential stuffing, phishing, or Norvado's legacy webmail portal. The actor abused that mailbox to register an N-able trial, creating separation between the RMM tenant and any actor-owned infrastructure. The underlying subscriber is an innocent third party.

Detections built around file signatures will typically find nothing in situations like this. Unexpected N-able agent registrations, unfamiliar MSP IDs in agent configs, and outbound connections to upload*.am.remote.management from hosts with no authorized RMM are the indicators worth hunting.

Freight sector under parallel pressure#

Freight and logistics companies are facing pressure from multiple directions. Our Diesel Vortex report documented a separate operation that harvested over 1,600 credentials from load boards and logistics portals. The actors and techniques differ, Diesel Vortex used phishing-as-a-service infrastructure while this campaign relied on a compromised carrier account and signed RMM software, but the victim class and underlying motive are the same.

The FBI and IC3 warned in April 2026 of cyber-enabled strategic cargo theft using compromised carrier accounts and RMM tools. Proofpoint documented the same playbook in November 2025. The technique continues to be leveraged into May 2026.

Response actions#

Following analysis, we submitted abuse reports to disrupt the infrastructure identified in this campaign:

We welcome reports from organizations that encounter related activity. N-able has confirmed the tenant was a malicious trial and suspended the account. Endpoints that already registered to Site ID 477678 may still need local remediation.

TTPs and IOCs#

Recommendations#

For trucking and logistics organizations:

• Treat unexpected BOL or load board attachments from known contacts with the same scrutiny as messages from unknown senders. BEC against compromised accounts bypasses domain authentication.
• Block or alert on executable downloads from cloud storage URLs (e.g. *.s3.*.amazonaws.com) in email-linked contexts.
• Maintain an inventory of authorized RMM agents. Any unexpected N-able, ScreenConnect, or SimpleHelp installation on a workstation is a high-severity incident.
• Enable phishing-resistant MFA (FIDO2/passkeys) on all Microsoft 365 accounts, especially admin and shared mailboxes. Legacy SMTP AUTH and OAuth app registrations that bypass MFA are common BEC enablers.
• Publish and enforce a DMARC policy (p=reject or p=quarantine) on all sending domains.

For defenders and security teams:

• Hunt for SITEID=477678 or [email protected] in N-able configuration files across the fleet, including on endpoints compromised before N-able suspended the account.
• Report sightings of the actor N-able account ([email protected], Site 477678) to N-able abuse if additional victim endpoints appear.
• Report compromised Microsoft 365 tenants to Microsoft abuse channels.

Contact#

For questions, to share related intelligence, or to report sightings of this campaign, contact [email protected].

For press inquiries, contact [email protected].

Evidence has been preserved and shared with relevant parties. Sensitive data has been redacted where appropriate. We welcome collaboration with threat researchers, law enforcement, and other parties with a legitimate interest in this activity.