Case studies / 01

A request from someone who had already left

The most important detail was not hidden in the bank account number. It was the person supposedly asking for the change.

An anonymously reported incident5 minute readWritten by NetOpiekun

A message reaches a company asking for a change to a bank account used for salary payments. It appears to come from someone authorised to issue such instructions. The account belongs to a criminal. The request concerns money, but according to the account shared with us, the attempt began earlier — with a USB drive.

The story starts outside the inbox

According to the account provided, malware reached a computer through USB storage and gained access to email correspondence. Information from those messages was then used to prepare a request impersonating an employee authorised to change bank details. The recipient was expected to carry out what appeared to be a routine business task.

Stolen correspondence can provide something more useful than an email address: context. It reveals who speaks to whom and which matters they handle. In this account, email was therefore more than a delivery channel. It also supplied information used in the attempted fraud.

One name did not fit

There was a detail that did not match the company’s situation. The employee supposedly requesting the change had previously been dismissed. This was no longer a person from whom such an instruction should be accepted.

That inconsistency stopped the fraud. According to the account provided, the attempt did not succeed. We do not know who noticed the discrepancy or what technical work followed. We do know which fact undermined the message’s credibility.

The practical lesson is that a plausible request is not enough. The sender must also still have authority to make the decision.

A credible message is not the same as an authorised instruction.

What opened the way to the attack

The reported entry point was an infected USB drive, followed by access to email. The aim was to use another person’s identity to redirect a salary payment. This describes the reported sequence, not the findings of a forensic investigation.

Without the original message, full headers and logs, we cannot determine whether it was sent through a compromised account or whether the sender details were forged. Nor do we know whether software analysed the correspondence automatically or a person used stolen information. The appearance of a former employee’s name alone does not prove that their account remained active.

Stop the instruction, then regain control

The following response is recommended for a similar incident; it is not a record of confirmed work at this company. First, put the account change on hold and verify the request outside the suspect conversation, using an existing trusted phone number or an agreed HR channel. Contact details supplied in the disputed message must not be used to authenticate it.

In parallel, an administrator should isolate the suspect computer from the network and preserve the message, logs and storage device for investigation. Do not plug the USB drive into another computer to test it. Where account compromise is confirmed or suspected, use a clean device to restrict access, revoke active sessions, change credentials, and review forwarding rules and account recovery methods. Returning the computer to service requires addressing the compromise, not merely deleting one file.

Block USB — but which access?

One appropriate prevention option here is centrally managed control of removable storage. That means USB drives and external disks, not automatically every port, keyboard or mouse. A policy can deny reading, writing and executing files on unapproved storage by default, with controlled exceptions for necessary devices.

Blocking writes alone does not prevent a malicious file being read. Disabling AutoRun alone does not replace storage access controls either. An administrator should test the policy on the computers in use and confirm that denied attempts are logged. Blocking storage reduces this route into a system; it does not remove malware already running or undo access to email.

Do not depend on a fortunate detail

An employee’s departure should trigger an established process for disabling access, ending sessions and removing permissions. Independently verifying bank detail changes and requiring approval from a second authorised person provide separate safeguards. These are recommendations for organising work, not a claim that this company lacked them.

Here, knowledge of who no longer worked for the organisation stopped the fraud. A reliable procedure should also work when the person being impersonated is still employed.

About this account

An editorial account based on an anonymous report shared with NetOpiekun. No forensic evidence or investigation report was provided. Events and outcome are attributed to that report; technical points requiring verification and recommended actions are distinguished. This is not a description of an intervention carried out by NetOpiekun.

Sources for the technical recommendations: Microsoft — Respond to a compromised cloud email account · Microsoft — Device control in Microsoft Defender for Endpoint · Microsoft — Device control walkthroughs