What if malware could decide whether to attack your computer simply by checking your screen resolution? That sounds unusual, but TrickBot used this technique to recognize security testing environments and change its behavior.
An expert take by Ethan Cross, HakTechs.com Lead Analyst
TrickBot’s screen resolution trick became particularly interesting in November 2021, when researchers reported a phishing campaign that moved anti-analysis checks into a malicious HTML email attachment. Instead of exposing the same malicious download to everyone, the attachment behaved differently depending on the environment in which it opened.
The technique was not a new attack discovered in 2026. Its key developments were documented in 2020 and 2021. However, the case remains valuable because it shows how attackers can make automated malware analysis miss dangerous behavior.
Key Takeaways
- TrickBot used screen resolution as an anti-analysis signal. Researchers documented samples in 2020 that stopped running when they detected resolutions of 800×600 or 1024×768.
- The 2021 phishing campaign added a new twist. Its malicious HTML attachment could redirect virtualized environments to a legitimate news website instead of delivering the expected malware download.
- The technique targeted a weakness in automated analysis. A sandbox might see harmless-looking behavior even though a regular user’s computer could receive a malicious file.
- HTML smuggling made the delivery process harder to inspect. Attackers used browser capabilities to assemble or deliver malicious content after an attachment was opened.
- Screen resolution alone cannot prove that a device is safe or virtualized. Effective detection requires multiple security signals, not one environmental check.
What Is TrickBot Malware, and Why Is It Dangerous?
TrickBot is a modular malware family first identified in 2016. It began as a banking Trojan designed to steal financial information but developed into a more versatile cybercrime tool.
Unlike malware that performs just one action, TrickBot can use different components to carry out several tasks. According to Microsoft’s analysis of TrickBot, its operators used the malware for credential theft, network reconnaissance, lateral movement, and the delivery of additional malicious software.
Its historically documented capabilities include:
- Credential theft: Collecting passwords and authentication information that attackers can use to access accounts or systems.
- Network movement: Helping attackers reach additional computers after compromising an initial device.
- Malware delivery: Downloading additional malicious tools or payloads onto an infected machine.
- Persistent access: Establishing mechanisms that can allow malicious activity to continue or return later.
- Ransomware support: Providing access that other criminals have used in attacks involving ransomware such as Ryuk.
These capabilities explain why researchers took TrickBot’s attempts to avoid analysis seriously. A missed detection could leave much more than a simple banking credential theft attempt undiscovered.
How Did TrickBot’s Screen Resolution Trick Change?
The most important detail is that the screen resolution technique developed in two stages. The first involved a malware sample checking its environment. The later variation brought environment-dependent behavior into a phishing attachment.
The 2020 discovery: Malware checks the screen size
On July 1, 2020, BleepingComputer reported that MalwareLab researcher Maciej Kotowicz had identified a TrickBot sample checking its host computer’s display resolution.
The reported sample looked for two specific values:
- 800×600 pixels
- 1024×768 pixels
When the malware found either resolution, it terminated its execution. Those display settings were associated with certain default virtual machine configurations used in malware research.
By stopping before its more dangerous behavior became visible, the malware could make analysis less useful. The original findings are documented in BleepingComputer’s July 2020 TrickBot report.
The 2021 twist: The attachment changes its behavior
On November 26, 2021, researchers reported another variation involving TrickBot phishing emails. This time, the environment check was associated with the HTML attachment used during the delivery process.
A threat researcher known as TheAnalyst, a member of the Cryptolaemus research group, observed a malicious attachment that behaved differently in physical and virtual environments.
On a physical computer, the attachment could deliver a ZIP archive containing a TrickBot executable. In the observed virtual environment, it redirected the browser to the legitimate American Broadcasting Company (ABC) website instead.
That was the twist: the suspicious attachment could present harmless-looking activity to a security researcher while continuing a malicious delivery process on a potential victim’s machine.
The behavior was documented in BleepingComputer’s November 2021 investigation.
| Feature | 2020 Technique | 2021 Variation |
|---|---|---|
| Primary detection point | TrickBot malware sample | Malicious HTML email attachment |
| Environment assessment | Checks specific screen resolutions | Uses environment-dependent checks during delivery |
| Suspicious environment behavior | Stops malware execution | Redirects to a legitimate website |
| Regular computer behavior | May continue malicious execution | May receive a malicious ZIP download |
| Main security concern | Incomplete malware analysis | Misleading analysis before payload delivery |
These observations describe specific historical samples and campaigns. They do not establish that every TrickBot variant used the same checks or that all virtual machines received the harmless-looking response.
Why Would Malware Check a Computer’s Screen Resolution?
Security researchers often investigate suspicious files inside virtual machines, or VMs. A virtual machine is a software-created computer that runs within another computer and can provide an isolated environment for testing.
Automated security tools use similar environments, commonly called sandboxes, to observe what potentially malicious files do when opened or executed.
However, testing environments sometimes have characteristics that differ from ordinary desktop computers. Attackers may try to recognize those characteristics before revealing their malware’s full behavior.
Why were 800×600 and 1024×768 important?
Some virtual machines historically started with basic display settings, especially when additional guest software or graphics drivers were not installed.
The resolutions 800×600 and 1024×768 were particularly useful clues in the original TrickBot sample because some research environments used those settings.
But neither resolution proves that a machine is virtualized. A real computer may use an older monitor, accessibility configuration, or other unusual display setting. Likewise, a modern VM can use a high-resolution display.
The technique works by making a guess about the environment. It does not magically identify whether a security researcher is watching.
What other clues can malware examine?
Screen size is only one possible indicator. Malware that tries to recognize an analysis environment may inspect:
- Hardware characteristics such as processor and memory information.
- System names and configuration details.
- Services and software associated with virtual machines.
- Network adapter information.
- Signs of normal user activity or automated testing.
MITRE ATT&CK classifies this general behavior under T1497.001: Virtualization/Sandbox Evasion — System Checks.
These checks help attackers decide whether to continue, stop, delay, or change malicious activity. They are not reliable enough individually to establish the nature of a system.
How Did the Malicious HTML Attachment Work?
The 2021 campaign combined phishing with environment-aware delivery. Understanding the sequence explains why the attack was difficult for some automated defenses to evaluate.
- The victim received a deceptive email. The documented campaign used a bogus insurance-purchase alert. It included an HTML attachment intended to make the recipient investigate the supposed transaction.
- The attachment opened in a web browser. The HTML content displayed a loading message and provided a password supposedly needed to access the document.
- The content assessed its environment. The observed delivery behavior changed depending on whether the attachment was opened in a physical or virtualized environment.
- A suspicious environment received a different result. Rather than receiving the expected malicious archive, the analysis environment was redirected to the legitimate ABC website.
- A regular machine could receive the malicious archive. The reported attack delivered a ZIP archive containing the TrickBot executable, creating an opportunity for further infection if the victim continued through the malicious execution process.
One important distinction: downloading a ZIP archive does not automatically mean that the malware inside has executed. The next stage depends on the exact payload, browser, operating system protections, and any further user actions.
What role did HTML smuggling play?
HTML smuggling is a technique that uses legitimate browser features to assemble or deliver malicious content from HTML and JavaScript.
Rather than sending an obvious executable attachment directly, attackers can place encoded content in an HTML file. When that file is processed in a browser, it can create or trigger the download of another file.
This creates a challenge for security tools that mainly inspect file types or known malicious signatures before an attachment reaches the endpoint.
In its November 11, 2021 research on HTML smuggling, Microsoft documented the technique being used to deliver TrickBot and other malware families.
The screen-resolution checks added another possible layer of evasion: not only could a malicious file be assembled through browser behavior, but the delivery process itself could behave differently during analysis.
Why Is This Technique a Problem for Malware Sandboxes?
A sandbox is designed to answer a basic question: what happens when a suspicious file is opened or executed?
If the file recognizes the sandbox and deliberately changes its behavior, the answer may not match what happens on a real victim’s computer.
This can cause several problems for defenders:
- Incomplete behavioral evidence: The sandbox might never observe the actual malicious payload being delivered or executed.
- Misleading results: A redirect to a legitimate website may look less suspicious than a malicious archive download.
- Delayed investigation: Researchers may need additional evidence to understand why different systems produce different outcomes.
- Detection gaps: Security systems that rely too heavily on one automated test may fail to recognize a dangerous campaign.
However, sandbox evasion does not mean all security products become ineffective. Email filtering, static analysis, endpoint protection, network monitoring, and behavior-based detection can identify threats at different stages.
The lesson is not that sandbox technology should be abandoned. It is that one apparently harmless sandbox result should not be treated as proof that an unknown file is safe.
Could TrickBot Still Use These Tricks Today?
The screen-resolution findings discussed here come from 2020 and 2021. They should not be presented as a newly discovered November 2026 campaign without separate evidence.
TrickBot’s broader development history has continued to attract research attention. For example, on July 22, 2026, FortiGuard Labs published an analysis of TrickBot variants using DNS tunneling for command-and-control communication.
That research described obfuscation and other techniques, but it does not establish that the recently studied samples also used the historical screen-resolution-based phishing trick.
This distinction matters. Malware families can reuse old methods, adopt new ones, or combine several techniques, but each claim about a particular campaign needs evidence from that campaign.
What remains relevant is the general weakness exposed by the original discovery: attackers can alter their behavior when they suspect they are being analyzed.
How Can Security Teams Detect and Defend Against Similar Attacks?
No single security setting can reliably stop every environment-aware malware campaign. Defenders have better results when they examine the whole delivery and execution chain.
1. Inspect unexpected HTML attachments
Email security systems should examine suspicious HTML and HTM attachments, especially those that impersonate invoices, purchase alerts, insurance notices, or other business documents.
Security teams can also investigate attachments that unexpectedly generate executable content, scripts, or compressed archives. Not every HTML attachment is malicious, so detection should consider the sender, content, and resulting behavior together.
2. Monitor downloaded files and process activity
Endpoint detection and response tools, commonly called EDR, can help connect several events that might appear harmless when viewed separately.
For example, defenders may examine an unusual sequence involving an email attachment, a browser-generated download, execution of a newly downloaded program, and suspicious network communication.
The combination provides stronger evidence than a screen-resolution check or file extension alone.
3. Avoid depending on one sandbox result
When researchers encounter conflicting evidence, they can examine file structure, email metadata, endpoint activity, and network behavior alongside dynamic analysis.
Qualified malware analysts may also validate suspicious behavior across carefully controlled analysis environments. Such work should take place only in isolated, authorized research systems.
MITRE’s detection strategy for virtualization and sandbox evasion describes looking for unusual combinations of system-discovery activity rather than depending on one signal.
4. Strengthen email and endpoint protections
Organizations should maintain several protective layers:
- Keep operating systems, browsers, and endpoint security software updated.
- Use email filtering that analyzes suspicious attachments and links.
- Restrict unnecessary execution of downloaded scripts and programs.
- Apply least-privilege access so users do not routinely operate with administrator permissions.
- Use multifactor authentication to reduce the damage from stolen passwords.
- Maintain protected, tested backups in case an infection leads to wider compromise.
These measures do not guarantee prevention, but they reduce the number of opportunities attackers have to turn a malicious attachment into a serious incident.
What Should You Do If You Opened a Suspicious HTML Attachment?
The appropriate response depends on what happened after the attachment was opened. Simply viewing an HTML file is not the same as executing a downloaded malware payload, although malicious content can create other risks.
- Stop interacting with the attachment. Do not enter passwords, open downloaded archives, or launch unexpected files.
- Report the message. If the computer belongs to a business, notify its IT or security team and keep the suspicious email available for investigation.
- Check for unexpected downloads. Look for files created after the attachment was opened, but do not open or execute them to investigate.
- Run an updated security scan. Use trusted endpoint security software. A clean result is reassuring but does not always rule out a compromise.
- Isolate the device if infection is suspected. If you executed a suspicious payload or see signs of compromise, disconnect the affected computer from the network and contact a qualified responder.
- Protect potentially exposed accounts. Change affected passwords from a known-clean device and review account activity if credentials may have been stolen.
For business incidents, preserve useful evidence and let the response team determine whether other devices or accounts are affected. Do not immediately wipe a potentially compromised system without considering evidence preservation and recovery requirements.
Microsoft’s incident response guidance explains how organizations can assess affected devices, isolate systems, and plan recovery.
Frequently Asked Questions
Does TrickBot infect a computer based only on its screen resolution?
No. Screen resolution was used as a clue to identify certain testing environments. The historical technique helped some samples decide whether to continue malicious behavior, but the resolution itself was not an infection method.
Can changing my screen resolution protect me from TrickBot?
No. Although a documented 2020 sample stopped running at two particular resolutions, that behavior was specific to the observed sample. Changing display settings is not a dependable malware defense, and other variants may behave differently.
Is TrickBot a virus or a Trojan?
TrickBot is generally classified as a Trojan and modular malware family. Unlike a traditional self-replicating virus, it has commonly relied on phishing, other malware, and additional attack methods for delivery and propagation. It can also support further malicious activity after infection.
Can antivirus software detect malware that uses sandbox evasion?
Yes. Avoiding one sandbox does not necessarily bypass signature detection, file analysis, endpoint behavioral monitoring, or other security controls. However, no single antivirus or sandbox product can promise to identify every malware variant.
Is an HTML email attachment always dangerous?
No. HTML is a legitimate format used by websites and some business applications. However, unexpected HTML email attachments deserve caution because attackers can use them for phishing, credential theft, deceptive redirects, and malicious downloads.
Conclusion
TrickBot’s screen resolution trick illustrates how something as ordinary as a display setting can become part of a malware evasion strategy.
The original 2020 technique used specific screen resolutions to recognize likely analysis environments. The 2021 variation went further by introducing environment-dependent behavior into a malicious HTML attachment, allowing a suspicious file to produce very different results on different systems.
The broader lesson remains important: security tools must look beyond one file, one sandbox run, or one apparently harmless action. Combining email inspection, endpoint monitoring, system activity, and sound incident response gives defenders a better chance of detecting malware that tries to hide its real intentions.
