Case study · Forensic incident response
An online-sales business asked for forensic help after deceptive file-sharing emails went out from an accountant’s Google Workspace account. The account was the symptom. The investigation record showed that the accountant’s Windows workstation had been under remote control for three weeks through two legitimate support products, and that the phishing was sent from the workstation’s own signed-in browser. This anonymized account sets out what the evidence showed, how the two halves were tied together, and what the evidence could not settle.
Published Last reviewed
Starting condition
On the day the incident was noticed, the accountant’s account sent a “shared a file for your review” message to about 55 recipients, inside and outside the business. Six colleagues clicked. The link pointed at the same web domain that, three weeks earlier, had served the file which started everything. Nobody had noticed that earlier event, because nothing on the workstation was built to notice it.
The engagement began as account abuse and became an endpoint investigation. A forensic triage collection of the workstation, including five historical volume shadow copies, was taken with KAPE, and the Google Workspace audit trail was reviewed alongside the application logs the remote-support software had left behind. The two timelines below are what that record supports.
Days are counted from the first observed endpoint event. Times are normalized to UTC in the case record because the workstation clock, the Google audit console and the investigators each displayed a different zone; the three-hour offset between endpoint and audit times was the first thing to resolve.
Figure 1 · Two lanes, one operator
The account abuse happened while the workstation was under remote control.
Workstation
Google account
How access was gained
None of the tools involved is malware. That is what made the intrusion quiet.
An executable downloaded from an attacker-controlled web page landed in the user’s Downloads folder. Its download-origin metadata named the page; its Prefetch record shows it ran. It carried a valid vendor code signature and installed a remote-management agent, FleetDeck, in under 30 seconds. A valid signature says who published a file, not whether its installation was authorized.
Within fifteen minutes a ScreenConnect client was installed from a plain-HTTP URL and an operator labelled “Administrator” was issuing remote commands. That evening the same operator installed a second ScreenConnect client, giving the attackers two independent persistent channels in case one was found.
Between Day 12 and Day 21 the ScreenConnect transfer log recorded nine further executables sent to the workstation with Run, RunElevated or RunSilentElevated requested, several of them more than once. The transfer and the request to run are confirmed. Whether each one executed, and what it did, could not be established from the surviving artifacts.
The user’s account was a local administrator, so the installers needed no further prompt. There was no endpoint detection, no Sysmon and no retained process-creation logging, so no alert fired and no process lineage survived to show which program launched which.
The account side
On Day 5 a sign-in with the account’s passkey failed, a recovery code was sent to the user’s personal mailbox, the passkey was removed and the security notifications were deleted within minutes. 2-step verification was not enforced on the account, so after that step the password alone was enough.
On Day 19 a new session appeared: Windows, Chrome, password-only. From then until containment it read business and security mail and deleted what it did not want seen. On Day 22, inside a 50-minute remote session on the workstation, the account prepared the phishing campaign, sent it in batches, deleted the sent copies, and a second operator later handled the replies and bounces.
How the attackers obtained the password is not proven. Three mechanisms fit the record and the evidence does not separate them: a password saved in the workstation’s browser profile and read through the remote-control session; the personal recovery mailbox being signed in on the same browser, which would have exposed the recovery code without any separate compromise; or a credential obtained somewhere else entirely. The user could not be reached for interview, so the first-hand account that might have settled it is unavailable.
Correlation
Three independent observations converge. Each on its own would be suggestive; together they make remote operation of the signed-in browser the best-supported explanation.
The suspicious Google session came from a temporary IPv6 address that the workstation still held in its deprecated-address list at collection time. A match on the office /64 prefix would only identify the network; a match on the full temporary address points at one host.
The session’s platform and browser description matched the workstation, not a second device on the same network.
Every burst of mailbox activity on Day 22, from campaign preparation to deletion of bounces, fell inside a recorded ScreenConnect session on the workstation. The timing lines up to the minute once the three clocks are normalized.
No keystroke-level record exists, so no individual email can be attributed to a specific operator action. Cookie theft, token replay and the exact login mechanism remain unproven. The case record labels this a high-confidence inference, not an observed fact.
Method
A preliminary report written while the investigation is still open has to be honest about what kind of statement each finding is. Four labels do that work.
The same discipline applied to time. Windows events were displayed in the client’s local zone, Google audit events in the console’s display zone, and the two differed by three hours. Every time in the record carries its source display value and its UTC equivalent, with exact seconds kept where the source supplied them and approximate values marked as such.
| Label | What it means | Example from this case |
|---|---|---|
| Direct observation | Visible in command output captured during the investigation | Hosts file, proxy settings, listening services and DNS configuration on the workstation |
| Confirmed in the record | An artifact-backed finding reported by the investigation, not re-verified from the raw artifact for this report | Installer events, ScreenConnect connection and transfer logs, Google sign-in and Gmail audit entries |
| Inference | An interpretation supported by relationships between observations, with a stated confidence | Remote operation of the signed-in browser; execution of the downloaded lure |
| Unresolved | Evidence does not yet establish the answer | Whether financial systems were reached; what the nine executables did; how the password was obtained |
Containment and what was lost
On Day 22 the Google password was reset, every active session and token was revoked and the account was suspended; an attempt with the old password failed afterwards. Both ScreenConnect services were stopped and disabled rather than uninstalled, preserving them as evidence. The FleetDeck agent was removed once it was discovered. Live checks then found no running remote-management process and no established attacker connection.
After the investigation the workstation was disconnected from every network and later reformatted. That ends the attackers’ access to it, and it also ends any possibility of further acquisition: no full disk image or memory capture was taken, so the KAPE triage collection and its shadow copies are the only surviving endpoint evidence. The report records that trade-off plainly, together with the fact that the removal of FleetDeck and the rebuild happened without recorded times, operator or method.
What containment did not do is close the wider scope. The six colleagues who clicked, the user’s personal mailbox, the accounting platform that had been sending bank-detail change notices to the compromised inbox, the business bank, and the SMS-forwarding configuration at the telephony provider all remained open review items when the report was written.
Why the attack succeeded
Legal and business follow-up
An incident like this triggers duties that no amount of forensic work discharges. The report lists them as determinations for counsel; this is a summary, not legal advice.
Lessons
Boundary
Client and user identities, hostnames, account and session identifiers, the delivery domain, attacker infrastructure, file names and hashes, and calendar dates are withheld or substituted. Days are numbered from the first endpoint event. Nothing here would let a reader find the client or reuse the attackers’ infrastructure.
The underlying case record is a preliminary forensic report prepared while the investigation was open. Its original artifacts were not re-examined for this page, and no attacker identity, malware family, financial loss or exfiltration volume is asserted here or there.
Common questions
No. Both are commercial remote monitoring and management products used by IT support teams every day, and the installer in this case carried a valid vendor signature. What made them dangerous was who installed them and why. An unexpected remote-management agent on a business machine should be treated as unauthorized access until someone can say who approved it.
Because there was nothing for it to recognize. Signed, legitimate installers, run by a local administrator, create services exactly as they would in an authorized deployment. Catching this class of intrusion needs behavioral monitoring, process-creation logging and an approved-software baseline, none of which existed on the workstation.
The evidence says no. The Google session that sent it came from the workstation’s own temporary IPv6 address, matched the workstation’s platform and browser, and ran entirely inside recorded remote-control sessions. The best-supported explanation is that the attackers drove the accountant’s already signed-in browser. That is a high-confidence inference rather than an observed fact, and the report says so.
Yes, eventually. A machine that has run nine unknown executables under remote control cannot be trusted again. The question is sequence: the collection taken before the rebuild is now the only endpoint evidence, and no full image or memory capture exists. Isolate, acquire, document, then rebuild.
Reset the password and revoke every session and token from a device you trust, suspend the account if the platform allows it, and warn recipients from a different account. Then stop treating it as an email problem: find the device the mailbox was signed in on, take it off the network without wiping it, and get the evidence collected before anyone rebuilds it.
The method does. Hosting accounts, control panels and WordPress installations are compromised through the same pattern of legitimate tooling, weak factors and missing logs, and the same discipline of labelled evidence, normalized time and verified containment is what the server and WordPress incident reports on this site are built on.