“Killware”: Is it just as bad as it sounds?

On October 12, after interviewing US Secretary of Homeland Security Alejandro Mayorkas, USA TODAY’s editorial board warned its readers about a dangerous new form of cyberattack under this eye-catching headline:

“The next big cyberthreat isn’t ransomware. It’s killware. And it’s just as bad as it sounds.”

But while “killware” sounds scary, the term itself is unhelpful when describing the many types of cyberattacks that, like USA TODAY wrote, “can literally end lives,” and that’s because nearly any type of hack, no matter the intention, can result in death. Complicating this is the fact that the known cyberattacks that have allegedly led to deaths already have a category: ransomware. Further, the term “killware” can confuse antivirus customers seeking reassurance that their own vendor is protecting them from this threat, but antivirus vendors do not stop attacks based on intent, they stop attacks based on method.

As an example, Malwarebytes Director of Threat Intelligence Jerome Segura said that Malwarebytes does not have any specific Indicators of Compromise (IOCs) for “killware” and that, instead, “we continue to protect our customers with our different layers of protection.”

“Many of our layers are ‘payload indifferent’ meaning we block the attack regardless of what it is meant to do (it could be to ransom, it could be to destroy MBRs, or anything in between). We don’t focus on that end payload so much as blocking how an attacker might get there.”

Think of it like this: Locksmiths don’t develop one set of locks to prevent robberies and another set of locks to prevent assault—they develop locks to primarily prevent break-ins, no matter what an invader has planned.

“Killware” is too loose a term to be useful

In February, an employee for a water treatment facility in Oldsmar, Florida, saw the mouse on his computer screen moving around without his involvement. The employee, according to Wired, thought this was somewhat normal, as his workplace used a tool that allowed for remote employees and supervisors to take control of computers at the plant itself. But when the employee saw the cursor move around a second time in the same day, he reportedly saw an attempt by an intruder to maliciously increase the chemical levels at the water treatment facility, upping the amount of sodium hydroxide—which can be corrosive in high quantities—to dangerous levels.

In USA TODAY’s article about “killware,” Secretary Mayorkas pointed directly to this cyberattack. It was different than other cyberattacks, Mayorkas said, because it “was not for financial gain but rather purely to do harm.”

But if the attack was truly meant to harm or even kill people—which it very well may have—what good does it do to associate it with this new “killware” category? “Killware,” after all, still has the “ware” suffix in it, meaning that it should have at least some relationship to a piece of software, or a program, or perhaps many lines of code.

The breach at the Oldsmar water plant, however, may have involved no malware at all. No spear-phishing attack against an executive’s personal device. No surreptitious implantation of spyware to collect admin credentials. No initial breach and lateral movement. Instead, there’s a frustratingly simpler theory: Reused passwords across the entire water treatment plant for a crucial, remote access tool.

Following the attack at the Oldsmar facility, the state of Massachusetts issued a cybersecurity advisory notice to public water suppliers, detailing a few basic cybersecurity flaws that may have played a role in the attack. As the state said in its advisory:

“The unidentified actors accessed the water treatment plant’s [supervisory control and data data acquisition (SCADA)] controls via remote access software, TeamViewer, which was installed on one of several computers the water treatment plant personnel used to conduct system status checks and to respond to alarms or any other issues that arose during the water treatment process. All computers used by water plant personnel were connected to the SCADA system and used the 32-bit version of the Windows 7 operating system. Further, all computers shared the same password for remote access and appeared to be connected directly to the Internet without any type of firewall protection installed.”

Further, in testifying about the attack to the House Committee on Homeland Security, former Cybersecurity and Infrastructure Security Agency Director Chris Krebs said that the attack was “very likely” caused by “a disgruntled employee,” wrote Washington Post report Ellen Nakashima.

So, the attack may have come from a former employee, who may already have possessed the remote access credentials, which were already the same credentials for every user at the water treatment facility, which also lacked firewall protections.

What part of this attack chain, then, should be labeled “killware”?

Truthfully, none, and that’s because labeling anything as “killware” ignores the basic facts about cybersecurity defenses. Cybersecurity vendors do not categorize or identify attacks based on their final intentions. A reused password is a bad idea, but it isn’t a bad idea that can only be used to harm people. Lacking firewalls protections, similarly, are poor practice, but they aren’t poor practice that can only be used to threaten people’s lives.

In fact, even if cybersecurity vendors wanted to categorize attacks by intention, how could they?

Earlier this year, a bereaved mother filed a lawsuit against a hospital in Alabama that, she claims, failed to provide adequate care to her baby because the hospital was hamstrung by a ransomware attack. The hospital’s inability to properly care for her baby, the lawsuit said, eventually led to her child’s death. Nearly a year prior, a patient’s death during a ransomware attack on a German hospital brought similar allegations—though no lawsuits—but those allegations fell apart in the months following the attack, as the chief public prosecutor tasked with investigating the attack concluded that, even without the treatment delays caused by the ransomware attack, the patient likely would have died.

Neither of these situations involved hackers whose end goal was purely to harm or kill people. The intent, as is clear in almost every single ransomware attack, is to get paid. Ransomware attacks on hospitals, specifically, may use the threat of death as leverage for their end goal, but even the threat of death does not alter the end goal, which is to get paid potentially millions of dollars. If we even tried to use the “killware” term on these attacks, they wouldn’t fit, despite the end result.

Finally, labeling attacks as “killware” does a disservice to both cybersecurity vendors and the public because, if “killware” is a term that requires understanding an attacker’s intent, then “killware” must be applied after an attack has already happened. Good cybersecurity tools don’t just clean up an attack after it’s happened, they actually prevent attacks from happening in the first place. How then, possibly, could a cybersecurity provider prevent an attack that, by its definitional nature, cannot be determined until it’s already happened?

Remember the human

“Killware,” as a term, helps no one and it only increases panic. It conjures up images of hackers gone amok and dark-web-trained serial killers who work with nothing but a laptop—images that might actually be a better fit for over-dramatized procedural cop dramas on TV.

Importantly, “killware” fails to recognize that, already, attacks on computers, machines, devices, and networks have a dramatic impact on the people who use them. Ransomware attacks already cause tremendous emotional and mental harm to the people tasked with cleaning them up. Online scams already ruin people’s lives by emptying their bank accounts.

We do not need a new term that focuses even more on the attacker in cyberthreats. What we need is to remember that cyberattacks, already, are attacks against people, no matter their intent.

The post “Killware”: Is it just as bad as it sounds? appeared first on Malwarebytes Labs.