ThinkNode M9 SD Card Malware: What We Actually Know

Elecrow shipped some ThinkNode M9 units with a Windows worm on the included microSD card. They’ve published a security advisory acknowledging it, they’re offering replacements and refunds, and the M9 itself is not compromised.

The advisory contains no file hashes, no affected batch range, no serial numbers, and no malware family name. That gap is most of what this post is about.

Full disclosure on the lens, same as last time. I lead security at my day job and do vulnerability research on the side, so supply chain contamination in hobby hardware is squarely the kind of thing I read carefully. We do not own an M9 and we have not handled an affected card. Everything below comes from public sources: Elecrow’s advisory, the community tooling that responded to it, and MITRE ATT&CK. Where a claim is somebody’s pattern match rather than a confirmed finding, it is labeled that way, because the difference matters.

If you have read our MeshCore disclosure writeup, this is the same exercise: map what is actually known, separate it from what is being repeated, and work out how worried an operator should be.

What Elecrow Says Happened

The advisory is short, and the root cause is more specific than most disclosures of this kind manage.

Per Elecrow, “the issue originated during the factory flashing of map data onto the TF cards. A gap in production-environment security protection caused some memory cards to be contaminated with a worm virus.” So the contamination did not come from a random machine on the floor. It came from the step that writes map tiles onto the cards.

The malware targets Windows only, and Elecrow says it “spreads mainly through storage devices such as TF cards and USB drives by copying itself onto them. It cannot spread directly over a network.” On an uninfected card, “before insertion, the TF card contains only one new file, test file.txt.” The malicious autorun.inf is hidden and the payload is disguised as a shortcut.

Elecrow also describes what the payload does if it runs on an unprotected machine: attempt to modify the registry to launch at startup, disable or interfere with antivirus processes, steal sensitive information such as account credentials, and spread further by infecting other USB drives and TF cards. That is their characterization rather than a third-party analysis, and they published it instead of glossing over the impact.

Several things in the advisory cut in the reader’s favour, and a fair post has to carry them:

• The virus is dormant on the card and does not run on the M9. Normal use of the radio is not a risk.
• Connecting the M9 to a computer over USB-C is safe. The card is the vector, not the device.
• On a Windows PC with working antivirus, the malware is “usually blocked and removed immediately,” and Elecrow states that as long as you do not double-click the disguised file, you will not be infected.

Their precautions list adds two that are easy to miss. Do not disassemble the M9 yourself to get the card out. And do not use the ESP’s Wi-Fi to copy files off the card to your computer over FTP, which is a second path that would move the payload onto your machine without the card ever leaving the device.

Remediation comes in three routes: return for a replacement, with replacements shipping from September 23; keep the device and remove the malware yourself using their guides, which are split by firmware with separate Meshtastic and MeshCore instructions, a flash tool, and video walkthroughs; or return for a refund processed within 24 hours of receipt. They also publish instructions for wiping personal data off the device before sending it back.

Credit where it is due. The company found a problem in its own supply chain, said so publicly, named the specific production step rather than hiding behind “an issue was identified,” described the payload behaviour honestly, and offered a refund path. Plenty of vendors would have quietly swapped stock.

How This Class of Malware Works

Nothing here is novel, which is part of why it is worth explaining plainly.

An autorun.inf is a plain text file at the root of removable media that tells Windows what to do when the volume is mounted or opened. It was a devastating vector in the 2000s, and it is much less so now: Windows 7 and later disabled AutoRun for non-optical removable media, so on a current, patched system an autorun.inf on an SD card does not simply execute the moment you insert it. Its presence in this sample is partly vestigial, and partly insurance against whatever unpatched or misconfigured machine it eventually lands on.

Which means the disguised shortcut is doing the real work. The actual executable is hidden, the thing you can see looks like a folder or a document, and clicking that visible item runs the hidden one. Some families go further and hide the genuine files on the card, replacing each with a shortcut of the same name, so the card looks normal until you inspect it properly. That path does not depend on AutoRun at all. It depends on you double-clicking what looks like your own map folder.

The practical consequence for an M9 owner: the worm cannot run on the radio. An ESP32-S3 has no ability to execute a Windows binary. The card is inert in the device. It becomes live the moment the card goes into a Windows machine.

What the Community Found, and How Confident to Be

On September 18, the wadamesh project shipped a release that added an SD card scanner in direct response to this incident, and its release notes carry the most specific technical description currently public.

Per those notes, the infected cards seen so far carry a hidden autorun.inf at the root that launches a program called xlfqf.pif, triggered on open, explore, and autoplay, with lines of random junk interspersed to throw off simple scanners. The release describes this as matching “the pattern of the long-known Sality worm, which disables antivirus software, steals credentials and infects other programs on the PC.”

Read that carefully, because the wording is more careful than the way it will get repeated. It says the pattern matches Sality. It does not say the sample was identified as Sality by a lab, and neither the release nor Elecrow claims a confirmed family attribution.

Two observations from the security side.

The .pif extension is consistent with the rest of the picture. A PIF is a legacy Windows shortcut-to-DOS-program file that Windows will execute while many users read it as a harmless shortcut, and it has been a staple of removable-media worms for two decades. The junk-line padding is also a real and old technique, aimed at signature matching rather than at behavioural detection.

Sality as an attribution is plausible but unproven. Sality is a genuine, long-lived polymorphic file infector that does disable security software and does spread via removable media, so the behavioural description is not wrong about Sality. It is also a description that fits a wide family of autorun worms. What does raise confidence is that Elecrow arrived at the same behaviour independently: their advisory lists registry persistence, antivirus interference, credential theft, and propagation to other removable drives, without naming a family. Two separate descriptions agreeing on what it does is meaningful. Neither one establishes what it is. Searching for xlfqf.pif returns no entry in any public malware encyclopedia, which means either the filename is randomized per sample, or nobody has published an analysis of this specific one.

The Part That Bothers Me: No Indicators

Here is what does not exist anywhere in public, as of this writing.

No MD5, SHA1, or SHA256 for the payload. No hash for the autorun.inf. No VirusTotal submission that we could find. No affected batch, production date range, or serial range. No named detection from any vendor. No sample published for independent analysis.

That is a real problem, and it is worth being precise about why rather than just complaining.

Without a hash, nobody downstream can act. A user cannot verify whether the file they are looking at is the known bad one or something unrelated. A defender who supports a few dozen mesh hobbyists cannot write a detection or sweep their fleet. The community tool authors writing scanners right now are working from a filename and a behaviour description rather than from a fingerprint, which makes their tools heuristic by necessity. And nobody outside Elecrow can independently confirm or refute the Sality attribution that is already circulating.

Without an affected batch range, every M9 owner has to treat their card as suspect. That is a worse outcome for Elecrow than publishing the range would have been, because it converts a scoped recall into a blanket one.

None of this requires a mature security program. Pulling a SHA256 off the file takes one command. Uploading one sample to VirusTotal takes a browser. The bar here is genuinely low, and clearing it would let dozens of people help.

Why the Targeting Is Unusually Tight

Most contaminated-media incidents rely on a victim happening to plug the media into a computer. This one has a tighter loop than that, and it is the reason the incident is worth more than a forum post.

The cards were contaminated during the factory step that writes map data. Map data is also the reason an owner puts the card in a computer: you pull it out to load or update tiles. The contamination vector and the user workflow are the same activity, at opposite ends of the supply chain. A card that gets infected while being loaded with maps, and is then handed to someone whose reason to touch it is loading maps, is about as well-aimed as an accident gets.

The population matters too. Mesh hobbyists skew toward people who also run a home lab, hold credentials for a community repeater network, and move the same USB drives between machines. Elecrow’s own payload description includes credential theft. On that kind of machine, that is not a nuisance.

None of which means panic is warranted. Working antivirus catches this, and not double-clicking the disguised file is sufficient to avoid it. The risk concentrates on the person running an unprotected Windows box, which in this hobby is a smaller group than it used to be but is not nobody.

Where This Sits in ATT&CK

This maps cleanly to T1091, Replication Through Removable Media, which covers both Initial Access and Lateral Movement on Windows.

The technique description is worth quoting, because it anticipates this scenario precisely. For Initial Access, ATT&CK lists “manual manipulation of the media, modification of systems used to initially format the media, or modification to the media’s firmware itself.” A production machine that formats and writes SD cards, and that is itself infected, is the middle case, word for word.

The company this technique keeps is instructive: Stuxnet, Conficker, Agent.btz, Raspberry Robin, and a long list of state-associated toolkits all appear as T1091 procedure examples. That is not a claim that anyone targeted Elecrow. It is a reminder that removable media remains an effective vector precisely because it crosses boundaries that network controls do not.

The relevant mitigations are unglamorous and effective. Disable Autorun (M1042). Use Attack Surface Reduction rules to block untrusted executables from running off removable drives (M1040). Limit removable media where it is not needed (M1034).

What To Do If You Have One

Practical, in order.

Do not plug the card into a Windows machine to “check it.” That is the exact action the malware is waiting for. If you have already done it, run a full scan with something current, and change credentials that were stored in a browser on that machine.

Take the replacement or the refund if you want the problem to just be over. Elecrow is offering both, and swapping the card costs you nothing but shipping time. If you are shopping for something else in the meantime, our MeshCore devices list covers what we actually run.

If you want to inspect it, do it somewhere the malware cannot win. A Linux or macOS machine will not execute a Windows PIF, so mounting the card there to look is dramatically safer than doing it on Windows. Show hidden files, look at the root of the card for autorun.inf and anything with a .pif, .lnk, .exe, .scr, or .vbs extension, and check whether your visible files are actually shortcuts.

If you do find the sample, hash it and submit it. Publishing a SHA256 would be the single most useful thing anyone in this community does this week, and it would close the gap Elecrow left open.

Reformatting the card resolves it. This is a file-based worm rather than a boot-sector or firmware infection, so a format clears it, and even a quick format removes the files. A full format is belt-and-braces if you want it. Reload the maps from a source you trust. Elecrow’s own guides cover this path.

What We Would Want From Elecrow

A short follow-up would close this out properly: the SHA256 of the payload and the autorun.inf, the affected production window or batch identifiers, and the detection name once an AV vendor assigns one. If they have a sample, giving it to VirusTotal would let every security product on the market recognize it.

They handled the disclosure itself better than a lot of companies do. Finishing it with indicators would turn a decent response into a genuinely good one.

If you are new to this side of the hobby, the MeshCore getting started guide is the gentler entry point. And if you are running an M9, we would like to hear what you find on the card, particularly if you get as far as a hash. We will update this post if indicators surface, and we will say so clearly if the Sality attribution turns out to be right or wrong.