In early 2013, cybercriminals began deploying in Mexico what some security experts described as one of the most advanced pieces of malware that's ever been built to steal money from ATMs. Nicknamed Ploutus, it evolved to become the first ATM malware that could be controlled remotely by a mobile phone.
Ploutus, which appeared in Latin America and was built in a way that suggested that its developers spoke Spanish, could only target ATMs made by NCR, which is one of the industry's biggest manufacturers. It was coded to interact with an obscure kind of ATM management software from NCR called Aptra.
"It's not nice when bad people use our software to attack ATMs."
Four years later, that's changed. Ploutus has gone "multivendor" with a new version that's compatible with a type of middleware deployed by banks at ATMs around the world, according to a new report from FireEye. This development vastly expands cybercriminals' list of potential targets.
Coding Ploutus to do that "is not an easy thing," says Daniel Regalado, a senior staff malware researcher at FireEye, which published its findings on Jan. 12. "They [the cybercriminals] really understand how the middleware works."
To understand why the latest version, called Ploutus-D, poses an increased threat, it's important to cover some ATM technical basics.
First, most of the world's ATMs run on Windows. Out of the box, however, Windows isn't equipped to interact with an ATM's hardware. For that, there's a layer of add-on software and APIs called Extension for Financial Services, or XFS, which facilitates communications between the ATM's hardware - such as displays and PIN pads - and the host Windows system.
Above XFS is a layer of middleware designed to interact with XFS. Typically, vendors write their own middleware, such as NCR's Aptra. For banks, this is somewhat inconvenient, because any that deploy ATMs from a variety of vendors must then revamp their custom-built middleware to work with each.
As an alternative, however, financial institutions in as many as 80 countries use middleware from an Edinburgh, Scotland-based company called KAL. Its middleware, Kalignite, works on most ATMs manufactured by 40 vendors.
Now, attackers appear to also be seeking that ease of use. Indeed, the appearance of Ploutus-D reveals that attackers appear to have closely studied Kalignite's source code, FireEye's Regalado says. For example, the malware developers have added libraries allowing Ploutus-D to issue commands via Kalignite to query how much money is in an ATM's cassettes or open its dispenser.
"They are not exploiting Kalignite, they are just using it," Regalado says. "They just use the middleware, same as they did with Aptra back in the day."
The sample of Ploutus-D analyzed by FireEye only targeted cash machines made by Diebold and did have code specific to how that vendor references its ATM cassettes. But only small code changes would be needed to target ATMs built by other manufacturers, and the compatibility with Kalignite would greatly expand attackers' target pool. "Tomorrow, they can change [the code] to NCR," Regalado says.
KAL Recommends ATM 'Security Lockdown'
KAL's CEO, Aravinda Korala, tells me that FireEye gave him a heads-up before it published the research. "It's not nice when bad people use our software to attack ATMs," he says.
Because the Ploutus malware isn't exploiting any software vulnerabilities in Kalignite, there's not much KAL can do. But Kalignite comes with a set of features called "security lockdown" that are designed to harden ATMs against attacks.
These features mandate that Windows' BitLocker full-disk encryption be enabled, app whitelisting is used and that USB ports be locked down. And KAL recommends that banks always follow these security tenets. But Korala says some don't undertake the measures for a variety of reasons, most typically centering on trading security for convenience.
"They don't want to impact their people," he says. "Security obviously makes it harder for them to do some of the day-to-day stuff."
Attackers Crave Cabinet Access
Financial institutions potentially at risk are those that use Kalignite but which have failed to follow KAL's security recommendations.
On the criminal side, however, launching an attack with Ploutus-D isn't necessarily easy. First, they need to identify ATMs running Kalignite, which may be tricky prior to opening up the ATM.
If attackers do find that it's running Kalignite, infecting the ATM still requires a relatively invasive operation. Attackers must gain access to the inside of the machine and hook up an external keyboard on an open port. Next they have to enter an activation code supplied by whomever is in charge of the Ploutus operation to enable the malware.
Access to an ATM's internal components can be accomplished by either breaking the lock or bribing someone to provide a key. Video surveillance cameras have caught some in the act of installing Ploutus. But it's a far more risky procedure than last year's ATM attacks in Thailand and Taiwan.
Affected ATMs in those regions were infected with malware after attackers exploited the banks' internal networks and virtually navigated to the cash machine, pushing malicious updates. Other thieves could then quickly relieve the ATMs of their cash, using either special payment cards or using remotely transmitted codes, either of which could be used to enable the malware and tell it to instruct the ATM to begin dispensing its cash (see 'Ripper' ATM Malware: Where Will Cybercriminals Strike Next?).
In contrast with Ploutus, the ATM malware used in Thailand spoke directly to the XFS framework, but only on machines made by NCR, Regalado says. Why that was the case remains something of a mystery, he says, but it's possible that ATMs from other manufacturers have been configured to bar rogue interactions with XFS.
NCR couldn't be immediately reached for comment on that analysis.