An invoice, a shared file or a message supposedly from IT support: email attacks often begin with something familiar. The dangerous action comes later – downloading a program, completing a supposed security check or approving someone else’s access.
Thinking only of a “virus in an attachment” misses part of the risk. Malware can steal information, enable remote access or encrypt files. Other attacks take over an account without installing software on the computer. Organisations therefore need to protect both devices and identities.
What recent observations show
Microsoft’s review of the second quarter of 2026 describes multi-stage email attacks combining different file formats and apparently trustworthy services. One campaign observed in June used an attached email and subsequent redirects to deliver a malicious script file. The first visible link did not reveal the eventual destination. Source: Microsoft, Q2 2026 email threat landscape.
The scenarios below are fictional illustrations. They do not describe incidents involving SITsolutions clients and do not rank attacks by frequency.
1. The document that asks you to run a program
An employee is expecting documents relating to an order. A plausible message provides a download link. The destination asks them to extract an archive and run a supposed document viewer. Reading a document has suddenly become installing software.
The warning sign is the change of activity: an invoice or meeting record should not require an unknown program, disabled protection or ignored security warnings. A plausible filename does not establish that a file is a document.
In practice, confirm unexpected requests through a known contact channel. Obtain required software through your organisation’s IT process. Technical controls should restrict unapproved programs and cover downloads as well as direct email attachments.
2. The fake security check: ClickFix
A link opens a page claiming that there is a technical fault or a check to prevent automated access. The user is told to copy text into a system tool to “fix” it. This can cause the user to execute malware themselves. Microsoft describes this deception, known as ClickFix, in connection with email links and HTML attachments, among other delivery methods. Source: Microsoft, analysis of ClickFix.
A website requesting system commands to view a document or complete a CAPTCHA is a clear reason to stop. Employees do not need to understand or test those instructions. Close the page and contact IT.
A useful training rule is never to paste commands from emails or websites into system tools. A familiar logo or polished instructions do not replace verification through your own support team.
3. The QR code that approves someone else’s access
A supposed HR notification contains a PDF with a QR code. Scanning it leads to a request to sign in. With device code phishing, even a provider’s genuine sign-in page can be part of the process: entering a supplied code authorises access initiated by the attacker. Proofpoint documented such campaigns in spring 2026. Source: Proofpoint, device code phishing.
A genuine sign-in page does not establish that the reason for signing in is legitimate. Employees should not enter unsolicited device codes to supposedly release a document. Open business portals through known bookmarks and verify unusual approval requests independently.
IT should establish whether device code authentication is needed and where it can be restricted. Multi-factor authentication remains important, but does not replace checking which access a person is approving.
4. The message in a familiar context
A fictional project team receives a reply that fits an ongoing discussion. The sender appears familiar and the wording is flawless. Yet the message unexpectedly requests a different download route or announces new bank details.
A process-based question helps: Does the requested action match the agreed way of working? Familiarity alone is not sufficient grounds for approval. Sensitive changes should be checked using a previously recorded telephone number; replying to the same message is not independent verification.
This example also shows the limits of the term “virus attack”: a fraudulent payment requires no malware at all. Technical detection and reliable approval procedures need to work together.
Protection needs several layers
For practical implementation, we recommend reviewing these points with IT:
- Email and downloads: Do controls cover dangerous file types, redirects and threats identified after delivery? Is there a defined process for quarantined messages?
- Workstations: Are operating systems and applications current, permissions limited and security alerts followed up?
- Accounts: Are strong authentication methods in use, preferably phishing-resistant options such as FIDO2 security keys or appropriately configured passkeys? Are additional approvals and unnecessary authentication flows restricted?
- Business processes: Are changes to payment details, confidential disclosures and remote access independently verified?
- Recovery: Are backups protected against unauthorised changes, and have restores been tested in practice?
No single measure covers every scenario. Up-to-date anti-malware protection remains valuable; approving someone else’s account access requires different controls from executing a malicious file.
If something has already happened
Stop the activity and immediately contact the designated IT or security team. Describe what happened as accurately as possible: was a message merely read, a link opened, a file run or a sign-in approved? Clicking a link does not automatically mean a device is infected.
If malware execution is suspected, IT should isolate and investigate the device under the incident response procedure. Where an identity may be compromised, the team should review active sessions, granted permissions and forwarding rules, amongst other things. Changing a password alone does not necessarily terminate every existing form of access.
Employees should avoid attempting their own clean-up or circulating suspicious files to warn colleagues. Prompt, factual reporting helps more than blame.
Turn scenarios into a process you can test
A useful next step is a short joint exercise: a suspicious message is reported – who takes ownership, what information is needed, and how quickly can the device or account be secured? This reveals whether technical measures and responsibilities work together.
Our article “Phishing at work: Turning training into confident action” explains how training supports this response. SITsolutions helps organisations connect information security, clear training and practical working procedures.
As at 9 October 2026. The linked analyses document the attack patterns described; vendor observations do not represent the entire threat landscape. The examples and operational recommendations are our own practical interpretation.