The Malware Pretending to Be a Font File

A phishing campaign flagged by Fortinet's FortiGuard Labs has been ticking along since March, and it relies on a small piece of misdirection that keeps paying off: the payload arrives with a .ttf extension so it reads as a TrueType font. It is not a font. It is a Lua script, and it loads remote access trojans and infostealers onto Windows machines.

The setup is the usual furniture. Emails pretending to come from known companies, pitches about business cooperation, prompts about payments, a malicious archive attached. Inside sits a JavaScript file padded with junk code, string-array mapping and control-flow flattening. All of that noise is there to slow down both human analysts and the AI-assisted review tools that increasingly do the first pass.

What happens when it runs

Once the JavaScript executes, it copies itself into %PUBLIC%\Libraries, sets a scheduled task for persistence, and drops either a LuaJIT interpreter or an AutoIt executable alongside the file dressed up as a font. From there the two routes diverge, but the Lua path is where the operators have clearly been spending their time.

The script reverses itself, applies symbol substitution, decodes Base64, then runs a custom ROT cipher keyed off the first byte of the ciphertext. A build that appeared in June added page-by-page decryption handled by a Vectored Exception Handler, meaning the shellcode is only unwrapped as the CPU actually reaches for it. The final payload rides in on Donut shellcode and runs entirely in memory. Disk-based tools have almost nothing to inspect.

Four payloads, one goal

Victims end up with one of four tools: Remcos, Agent Tesla, XWorm, or a Snake Keylogger variant sold under the name Best Private LOGGER. Different badges, same job. All four exist to harvest credentials, keystrokes, browser data, and whatever else can be quietly bagged from a working machine.

Jason Soroko of Sectigo made the sensible observation that a file extension is not proof of what a file actually is, and that each stage of this chain looks unremarkable on its own. It is the sequence that does the damage. A .ttf file sitting in a folder is not suspicious. A JavaScript file with a lot of obfuscated content is not, on its own, a smoking gun. A Lua interpreter running on an endpoint might be entirely legitimate. Put them in order and something ugly emerges.

The bit worth thinking about

Names and extensions are decoration. What matters is what a file does once it runs, which script interpreters are allowed to execute on your endpoints in the first place, and how much a stolen credential can actually reach before something asks the user to prove they are still who they say they are.

There is also a quieter point in the loader design. The operators clearly understand that a lot of first-line analysis now involves an AI reading suspicious code and offering a summary. The junk code, the control-flow flattening, the layered decryption stages are not just for humans. They are there because the attackers assume a language model will look at this before an analyst does. That is a shift worth noticing.

The people clicking the archive are still the entry point. Whatever the loader does after that, the story starts with an email that looked plausible enough to open.