Wiper Malware Used in Attack Against Iran’s Train System

Critical Infrastructure Security , Cybercrime , Endpoint Security

Operational Security Mistakes Left Clues About Developer’s Skills, But Not Identity

Wiper Malware Used in Attack Against Iran's Train System
Tehran’s rail station. (Photo: Mostafa Asgari via Wikimedia Commons/CC)

Nearly three weeks ago, Iran’s state railway operator was hit with a cyberattack that was disruptive and – somewhat unusually – also playful.

See Also: Live Webinar | Improve Cloud Threat Detection and Response using the MITRE ATT&CK Framework

The attack caused train services to be disrupted as well as the transport ministry’s website to go down, Reuters reported.

But the attack wasn’t just designed for disruption. Attackers also programmed screens at train stations to show a number for travelers to call for more information about the problems.

The phone number, 64411, is for the office of Iran’s supreme leader, Ali Khamenei. In other words, as noted by Juan Andres Guerrero-Saade, a threat researcher at security firm SentinelOne, flashing his work phone number on train station screens was an “epic troll.”

SentinelOne says it has recovered components of the malware used in the attack. In a technical teardown of the code, Guerrero-Saade writes that it turns out to be a previously unseen type of “wiper” malware, so called because it is designed to erase data and brick computers.

Due to several mistakes by whoever coded the wiper, however, SentinelOne says it was able to learn a bit more about the mysterious attackers than they might have intended.

Also helpful, it says, was a a Farsi-language analysis of the malware published by an Iranian antivirus firm called Aman Pardaz Software Company, following the attack. Thanks to the information it contained, SentinelOne was able to identify some pieces of malware from code they’d seen in the wild, giving them samples to study.

Wiper Malware Teardown

In general, however, wiper malware can be extremely difficult to recover, Guerrero-Saade tells Information Security Media Group.

“Part of the issue with wiper malware is that it’s doing its best to wipe away data which often includes traces of itself,” he says, not least by targeting the master boot record. “Particularly with components like MBR corrupters, if it works, it’s going to be difficult to get anything from that box without some forensic analysis. For most of the attack steps, samples were readily available but there were bound to be blind spots.”

But the malware developer made several operational security mistakes that led to the identification of peripheral information concerning the malware, including in their choice of a name for the attack code: Meteor.

SentinelOne has nicknamed the malware “MeteorExpress” and says it wreaks havoc via three steps. First, “Metor encrypts the filesystem based on an encrypted configuration.” Next, an executable named nti.exe corrupts the master boot record, which is the first code a computer looks for when booting an operating system, after the BIOS runs. Finally, another executable called mssetup.exe locks the system.

It’s unclear how many machines in Iran became infected with the malware. But Guerrero-Saade says attackers pushed MeteorExpress to other computers on the network using Active Directory’s Group Policy, so “it’s possible it hit all the machines in their IT network.”

Painful Recovery

As if corrupting the MBR wasn’t enough to disrupt a system, MeteorExpress also appears to have been designed to make recovery painful. For example, the malware also deletes volume shadow copies, the Windows backup feature, and also removes the infected computer from the Windows domain, Guerrero-Saade writes.

But signs of sloppiness abound with MeteorExpress. Notably, developers failed to tidy their code, compiling the binary without having first excised debug strings used for internal testing, Guerrero-Saade says.

“The latter is an indication that despite whatever advanced practices the developers have in their arsenal, they lack a robust deployment pipeline that ensures such mistakes do not happen,” he writes. “Moreover, note that this sample was compiled six months before its deployment and the mistake was not caught.”

The malware also includes other functionality which – for unknown reasons – was not used against Iran’s train system. That includes the ability to change passwords, disable screensavers, terminate processes, disable recovery mode and install a screenlocker.

So Whodunit?

Despite the clues recovered by SentinelOne, accurately attributing the attack remains unlikely. The geopolitical situation in Iran and the region of course means there could be many potential candidates.

But attackers did know their target, including features of the domain controller and even the type of backup system used, which was from the vendor Veeam, Guerrero-Saade says.

“That implies a reconnaissance phase that flew entirely under the radar and a wealth of espionage tooling that we’ve yet to uncover,” he writes.

But the malware’s code – what it does well, what it didn’t do well and what it failed to conceal – leaves a somewhat difficult-to-decipher picture, Guerrero-Saade says.

“On the one hand, we have a new, externally configurable wiper packed full of interesting capabilities, involving a mature development process, and redundant means to accomplish their goals,” he writes. “On the other hand, we see an adversary that doesn’t yet have a handle on their deployment pipeline, using a sample of their malware that contains extensive debug features and burning functionality irrelevant to this particular operation.”