Trojans, drive-by downloads, phishing and smishing

Getting the user to do it for you

A Trojan horse is a program that appears to do something useful and carries a hidden malicious function alongside it. Its defining trick is not technical: it accomplishes indirectly what the attacker cannot do directly, by exploiting the legitimate authorisations of whoever runs it. If you cannot read a file the accounts clerk can read, get the accounts clerk to run your program.

Three models:

1. It continues the original function and adds a malicious one — a genuinely working utility that also copies your documents.
2. It continues the original function but modifies it — a login program that authenticates you correctly and records the password; a process lister that lists everything except the attacker’s processes.
3. It replaces the original entirely.

A Trojan that installs itself by exploiting a vulnerability can look very like a worm. The line is replication: a Trojan does not replicate itself.

The mechanisms that do not need to be opened

• Drive-by download — a flaw in the browser or a plugin is exploited so that merely viewing a page installs malware. Note what it does not do: it does not actively propagate. It sits on the page and waits for visitors. A worm seeks; a drive-by waits.
• Watering hole — the attacker researches the intended victims, works out which sites they visit, compromises one of those, and waits. The code may even be written to infect only the intended targets and leave everyone else alone.
• Malvertising — the attacker buys a paid advertisement carrying the malicious payload, sometimes running it for only a few hours. The crucial fact for incident response: this compromises no host site at all, so "we were not breached" and "our visitors were infected from our page" are both true at once.
• Clickjacking — transparent or opaque layers are overlaid so that a click, or even a keystroke, is routed to a frame the attacker controls.

The lure family

Phishing broadcasts a message masquerading as a trusted source, usually claiming that urgent action is required, to very large numbers of recipients, on the expectation that some fraction of them are customers of the brand being impersonated. Spear-phishing researches its recipients and crafts each message for its specific target, quoting real projects, real colleagues and real deadlines, and disguising an attachment as the sort of office document that person would expect. Whaling is spear-phishing aimed at a senior executive. Smishing delivers the same lure by SMS; vishing delivers it by voice call.

Worked example 1 — the document that asks to launch a program

You receive an e-mail from someone you know, referring to the project you are currently working on, with a PDF attached. Opening the PDF pops a dialog headed "Launch File", containing several blank lines, a scroll bar, and the instruction to click Open to view the document.

Work it in three parts.

What is the threat? A "Launch File" prompt is not a rendering prompt. The document is asking the reader’s permission to execute an external program through an embedded launch action. If you click Open, that program runs with your own privileges — everything your account can read, write or reach on the network, it can too. That is arbitrary code execution, and the PDF is a Trojan dropper: the document you were promised is the cover story.

Why the blank lines and the scroll bar? Because the dialog is showing you a command line, and the attacker has padded it with whitespace so the real command is scrolled out of the visible region. The blank space is not a formatting accident; it is the concealment. The scroll bar is the tell that there is more text than the dialog is showing.

How would you check it safely? Never by pressing Open. Every safe check keeps the file from executing on your machine: inspect the PDF’s structure with a document analyser and read the embedded objects and the launch action directly; open it inside an isolated virtual machine or sandbox with no network access and observe what it tries to do; or compute the file’s hash and submit it to a multi-engine scanner rather than sending the document itself, if the contents may be sensitive.

And who else got it? The message names your current project and comes from a plausible sender. That research is what distinguishes spear-phishing from phishing, and research does not scale. The honest answer is very few — plausibly the handful of people on that project — not "millions". A mass phishing run cannot afford to know what you are working on.

Worked example 2 — the text message

A text message says your Costco membership has earned a dividend, and links to https://costco.wholesaledividend.com/claim.

Read the host right to left. The registrable domain is the last two labels before the first slash: wholesaledividend.com. Everything to the left of it is a subdomain, and subdomains are chosen freely by whoever owns the domain. So costco. here is not Costco; it is a label the attacker typed. The decisive tell is that the registrable domain is not costco.com — and no amount of familiar-looking text to its left changes that.

The delivery channel is SMS, so the attack is smishing. The plausible mechanism is a bulk SMS gateway or a spoofed sender ID, sending to numbers from a breached or purchased list — often driven from a botnet so the sending pool is disposable.

What to do splits on how sure you are. If you are unsure: do not click anything, and reach the company through a channel you already trust — the number on your card, or the app you already have installed. Never a contact detail supplied by the suspect message itself. If you are sure it is fraudulent: do not reply (a reply confirms the number is live), report it to your carrier’s spam-reporting short code and to the impersonated brand, block the sender, and delete it.

The exercise below turns "read it right to left" into code, so the rule stops being a habit and becomes a check you can run.