Trojans Guide: How Trojan Malware Works and How to Defend Against It

A trojan is malicious software disguised as something the victim wants, so that the victim runs it themselves. Unlike a worm it does not spread on its own: it relies on deception, such as a fake installer, a cracked game or an invoice attachment, to get one click. This explainer starts with the plain-language idea, then gives practitioners the delivery routes, the main trojan types, how EDR and application control catch them, and how to respond. It is written for SOC analysts, endpoint engineers and security leads; the wider taxonomy of malware lives in the Malware Guide and is not repeated here.

Key takeaways

• Trojan describes delivery, not payload. The defining trait is disguise plus user execution (MITRE ATT&CK T1204.002 Malicious File); what runs afterwards may be a downloader, a banking module, an infostealer or a backdoor.
• Most trojans are a first stage. Families such as Emotet (S0367) and QakBot (S0650) began as banking trojans and became loaders for other criminals, so a "commodity" trojan alert can be the start of a ransomware intrusion.
• Disguise beats signatures. Trojans borrow trusted names and locations (T1036.005), signed binaries and popular software brands, so detection has to rest on behaviour, reputation and what is allowed to run.
• Application control is the strongest preventive control. If unapproved executables cannot run, a fake installer fails regardless of how convincing it looks (NIST CSF 2.0 PR.PS-05, SP 800-53 CM-7(5)).
• Response includes identity. Many trojans steal browser passwords and session cookies (T1555.003, T1539), so reimaging the device without resetting credentials and revoking sessions leaves the attacker logged in.

What it is

The name comes from the wooden horse of Greek legend: the danger is hidden inside a gift the defenders carry through the gate themselves. NIST SP 800-83 Rev. 1 describes a trojan horse as a self-contained, non-replicating program that appears benign but has a hidden malicious purpose. Three properties separate a trojan from other malware:

• Disguise: it presents as a legitimate program, document, update or utility, often copying the name, icon and folder of real software.
• User execution: the victim, or an administrator, launches it. ATT&CK records this as T1204.002 Malicious File, typically following T1566.001 Spearphishing Attachment or T1566.002 Spearphishing Link.
• No self-replication: a trojan does not copy itself to other hosts; a worm does. Spread after the first host comes from the operator using stolen credentials or deploying further tools.

"Trojan" is therefore a label about how malware arrives. Vendors attach it to many families, which is why one sample can be called a trojan, a downloader and a stealer by different engines.

Common trojan types

How it works

Delivery routes

• Email attachments and links: invoices, shipping notices and shared-document lures, often in archives, disk images or script files that bypass simple attachment filters. See the Phishing Guide.
• Fake installers and malvertising: search adverts and look-alike download sites for popular tools (browsers, remote support, PDF editors, AI clients) serve a trojanised installer. ATT&CK tracks the advertising step as T1583.008 Malvertising. See the Malvertising and SEO Poisoning Guide.
• Cracked and pirated software: key generators, game cheats and "free" licensed tools are a long-standing infostealer channel, and users often disable protection to run them.
• Compromised websites: fake browser-update pages and drive-by downloads (T1189). See the Drive-by Downloads Guide.
• Supply chain: a compromised vendor build or package repository delivers the trojan inside software the organisation already trusts.

What happens after the click

1. Decoy: the user often sees what they expected, a working installer, a document or an error message, so nothing feels wrong.
2. Staging: a script or small loader decodes and runs the real payload, frequently through PowerShell or a signed system binary. See the Fileless Malware Guide and the Living off the Land Guide.
3. Persistence: registry Run keys or the Startup folder (T1547.001), scheduled tasks (T1053.005) or a new service (T1543.003), named to look like a vendor updater (T1036.005).
4. Command and control: the implant checks in over HTTPS (T1071.001) to receive tasks and further tools (T1105). Detection of this phase is covered in the Command and Control (C2) Guide.
5. Objectives: credential and cookie theft, banking fraud, hands-on intrusion, or handing access to a ransomware affiliate.

Why it matters

NIST SP 800-83 describes malware as the most common external threat to most hosts. Trojans matter specifically because they convert one person's trust into an organisational foothold. Two outcomes dominate. First, the trojan is the opening stage of a larger intrusion: law enforcement and CISA reporting have repeatedly tied ransomware to earlier loader infections. Second, the stolen data is identity: the Snowflake breach was driven by credentials harvested by infostealers on endpoints, some infected years earlier, then replayed against accounts that had no MFA. The SolarWinds SUNBURST compromise shows the other extreme: a signed, trojanised update that no user training could have stopped.

Detection: what to monitor

In Microsoft Defender for Endpoint, attack surface reduction rules target several of these behaviours directly, including "Block executable content from email client and webmail", "Block all Office applications from creating child processes", "Block JavaScript or VBScript from launching downloaded executable content" and "Block executable files from running unless they meet a prevalence, age, or trusted list criterion" (the last needs cloud-delivered protection). Each supports audit mode. See the EDR Guide and the Sysmon Guide.

Prevention: choosing controls

• Application control (allowlisting): App Control for Business or AppLocker on Windows only permits approved code; the NCSC recommends centrally managing devices so only enterprise-trusted applications run. Strongest control, highest operational effort. See the Application Allowlisting Guide.
• Reputation-based execution: the prevalence ASR rule or Smart App Control style cloud reputation (Microsoft's Intelligent Security Graph) blocks unknown binaries with less policy maintenance. A practical middle step for organisations that cannot yet maintain an allowlist.
• Behavioural EDR: needed everywhere, because signed or trusted software can still be trojanised.
• Removing local admin rights: many fake installers need elevation; standard users stop a share of them and limit what the rest can do. See the Local Administrator Password Solution (LAPS) Guide.
• Software sourcing: an internal software catalogue or company portal removes the reason to search the web for installers, which is the malvertising entry point.
• Macro and script restrictions: the NCSC advises disabling or constraining macros and scripting, for example PowerShell Constrained Language mode.

Small organisations usually get most value from a managed EDR service, standard-user accounts, the reputation ASR rule and a software portal. Large organisations should aim for enforced application control on servers and high-risk user groups first (administrators, finance, developers with build access), then widen.

Rolling out controls

1. Inventory the software actually running (EDR or application control in audit mode) for two to four weeks.
2. Enable the ASR rules above in audit mode; review the hits and add narrow, file-specific exclusions only.
3. Move to warn or block on a pilot ring (IT and security staff), then a business pilot ring, then everyone, with a rollback plan: the same policy reverted to audit mode by device group.
4. Build an allowlist policy from the audit data, signed by publisher where possible, and enforce on servers and privileged workstations first.
5. Publish a self-service software catalogue and a fast exception route so users do not look for workarounds.

Responding to a trojan infection

1. Contain: isolate the device from the network through EDR while keeping its EDR connection (Defender for Endpoint "Isolate device"; "Restrict app execution" allows only Microsoft-signed code).
2. Scope: collect the investigation package, identify the first file, its source URL or email, and search the estate for the same hash, domain and persistence name.
3. Treat identity as stolen: reset passwords for every account used on the device, revoke sign-in sessions and refresh tokens, and rotate any keys or tokens stored there. See the Leaked Credential Response Playbook.
4. Eradicate: reimage rather than clean when the trojan had time to fetch further stages; cleaning is acceptable only for a blocked or quickly removed first stage with no follow-on activity.
5. Close the route: block the domain or advert source, add the lure to email rules, and fix the control gap that allowed execution.

Metrics that show it is working

• Percentage of endpoints with ASR rules in block mode, and with application control enforced, by device group.
• Number of executions blocked from user-writable paths per month, and the share that were genuine business software (a measure of policy quality).
• Mean time from first execution to device isolation.
• Percentage of trojan incidents where credentials and sessions were reset within 24 hours of detection.
• Number of software requests served through the internal catalogue versus web downloads.

Common misconceptions

• "Antivirus will catch it": trojans are repacked constantly and often signed. Relying on signatures alone, without behaviour rules or execution control, is the most common gap.
• "It was only adware or a commodity trojan": closing a loader alert as low severity without checking for follow-on downloads ignores how often loaders precede ransomware.
• "Reimaging fixes it": wiping the laptop does nothing about the cookies, tokens and passwords already uploaded. The Snowflake case shows stolen credentials stay useful for years if never rotated.
• "Only careless users get infected": administrators and developers download tools more than anyone, and a trojanised vendor update needs no user mistake at all.
• "Signed means safe": code signing proves who signed, not intent; SUNBURST was signed and shipped as a normal update.
• "Exclusions are harmless": broad folder exclusions added to quieten EDR give trojans a safe place to run. See the EDR Tuning and Exclusions Management Guide.

Related concepts

• Worm: self-replicating malware; a trojan is not. Some families combine both.
• Remote access trojan (RAT): a trojan whose payload is interactive remote control. See the Remote Access Trojans (RATs) Guide.
• Dropper and loader: the staging components many trojans use. See the Malware Loaders and Droppers Guide.
• Potentially unwanted program (PUP): bundled software that is unwanted but not clearly malicious; EDR products usually handle it under a separate policy.
• Keylogger: a common trojan module. See the Keyloggers Guide.

Framework mapping

Practitioner checklist

• Enable ASR rules for email executables, Office child processes, script-launched downloads and low-prevalence executables in audit mode, then block.
• Enforce application control on servers and privileged workstations, and plan wider rollout from audit data.
• Remove local administrator rights from standard users and manage remaining local admin passwords with LAPS.
• Offer an internal software catalogue and block or warn on newly registered download domains.
• Alert on executions from Downloads, %TEMP% and mounted images, and on persistence created soon after a download.
• Treat every loader or trojan alert as a potential intrusion until follow-on activity is ruled out.
• Include password reset, session revocation and token rotation in the trojan response runbook.
• Review EDR exclusions quarterly and remove broad folder or process exclusions.

Standards and references

• NIST: SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops
• MITRE ATT&CK: User Execution, Malicious File (T1204.002)
• MITRE ATT&CK: Masquerading, Match Legitimate Resource Name or Location (T1036.005)
• NCSC: Mitigating malware and ransomware attacks
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Application Control for Windows
• Microsoft Learn: Take response actions on a device
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Malware Guide · Infostealer Threat Guide · Remote Access Trojans (RATs) Guide · Application Allowlisting Guide · Incident Response Guide