What is a trojan?¶
A trojan is software presented as legitimate, useful or harmless while concealing an unauthorised function.
The name describes the deception. It does not tell you exactly what the hidden code did, whether it ran successfully or who was responsible.
Compare the promise with the behaviour¶
Suppose a website offers a free PDF converter called QuickConvert. The application really does convert a document, so the user's initial experience looks convincing. Endpoint records also show it creating an unadvertised background process, establishing automatic startup and contacting an unrelated external service.
A trojan can perform the promised task and the hidden task. “It worked as advertised” does not settle what else the software did.
This is a fictional teaching example. The application and activity are not a real product or incident.
Preserve the way trust was created¶
The presentation helps explain why the software was installed or opened. Retain where available:
- the source page, message or app-store listing;
- displayed name, icon, publisher and claimed purpose;
- prompts, warnings and instructions shown to the user;
- original installer or package and its hash;
- signature and certificate information;
- installation and execution events; and
- the hidden files, processes, permissions, persistence and connections.
The promised function and concealed function should be described separately. That keeps the evidence useful if the software turns out to be modified legitimate software, a repackaged installer or an entirely fabricated product.
Do not turn execution into informed consent¶
A process running under a user's account shows the security context used by the system. It does not prove that the person understood or agreed to the concealed behaviour.
Likewise, software from an unofficial source is not automatically a trojan. Establish the deceptive presentation and the unauthorised function through the actual package and incident records.
| Evidence | What it may establish |
|---|---|
| Advert, message or installer presentation | What the recipient was led to expect |
| Package analysis | The visible and concealed capabilities present |
| Process and configuration records | Which code ran and what it changed |
| Network and account records | Which external service or account the code used |
| Device and user context | Who had an opportunity to install or interact with it |
Personal attribution and responsibility may require communications, access opportunity and wider case evidence. The trojan label does not supply them.
Start with the mismatch between what the software appeared to offer and what it actually did. Preserve both sides of that comparison, then use the process, network and account records to prove execution, effect and personal attribution in their own right.
