The Home of the Security Bloggers Network

Home » Security Boulevard (Original) » News » Garmin Pays Ransom to Evil Corp – Despite Russian Sanctions

Last month’s multi-day Garmin outage outrage still echoes through the news cycle. This week, it’s emerged that Garmin caved in to pressure and paid several million dollars in ransom to WastedLocker-wielding criminals.

As if that wasn’t bad enough, it turns out the group of Russian delinquents—hilariously known as Evil Corp—is on a U.S. Treasury sanctions list. So it would be illegal for an American company to pay such a ransom.

Good job Garmin is domiciled in Switzerland, eh? In today’s SB Blogwatch, we wonder if that matters, given its Nasdaq listing (GRMN).

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: dungarees and wine.

What’s the craic? Alexander Martin runs in with this breathless exclusive—“Garmin ‘paid multi-million dollar ransom’”:

 Earlier this week [we] reported that Garmin had obtained the decryption key to recover its files from the WastedLocker [ransomware]. Security sources believe [WastedLocker was] developed by individuals linked to Evil Corp, a cyber crime group based in Russia that was sanctioned by the US Treasury last December. … According to people with knowledge of the matter, speaking … on the condition of anonymity, Garmin … sought the services of Arete IR, a firm that claims that the links between the WastedLocker ransomware and sanctioned individuals have not been proven … citing inconclusive evidence. … The US government has not yet made a public attribution linking WastedLocker to the sanctioned individuals. … Neither Garmin nor Arete IR disputed that the payment was made when offered the opportunity. … A representative for Arete told [me] they could not comment, [and] Garmin told [me] it had no additional comment.

But Lawrence Abrams says it was a different intermediary—“Confirmed: Garmin received decryptor for WastedLocker”:

 On July 23rd, 2020, Garmin suffered a worldwide outage where customers could not access their connected services, including the Garmin Connect, flyGarmin, Strava, inReach solutions. … The decryptor enclosed in the package includes references to both cybersecurity firm Emsisoft and ransomware negotiation service firm Coveware. When [we] reached out to Coveware, we were told that they do not comment on any ransomware incidents. … To obtain a working decryption key, Garmin must have paid the ransom to the attackers. It is not known how much was paid, but … an employee [said] the original ransom demand was for $10 million. … Garmin has not responded to our queries.

 We can make inferences about what happened, but we don’t know for sure. It’s possible Garmin paid an insurance company or a security company. But it’s also possible Garmin paid directly, or that [Alexander Martin’s] report is wrong.

So what is WastedLocker? Andrew Brandt and Mark Loman question its parentage—“WastedLocker’s techniques point to a familiar heritage”:

 There are behavioral traits that ransomware routinely exhibits that security software can use to decide whether the program is malicious. … The author of the WastedLocker ransomware cleverly constructed a sequence of maneuvers meant to confuse and evade behavior based anti-ransomware solutions. … Modern ransomware spends an inordinate amount of time attempting to thwart security controls. … WastedLocker uses a trick to make it harder for behavior based anti-ransomware solutions to keep track of what is going on: using memory-mapped I/O to encrypt a file. … This also means that the writing is not done in the context of the process but in the context of the system. … Some of the specific techniques … mirror the subroutines we’ve seen previously used by another ransomware, Bitpaymer, and in the Dridex trojan – too closely to have been a coincidence. … While none of these alone, or even in combination, is enough to definitively say that, for instance, the same creator was responsible for both ransomware, the number of similarities is so striking as to raise questions. … IoC sample: BCDAC1A2B67E2B47F8129814DCA3BCF7D55404757EB09F1C3103F57DA3153EC8.

And Fedor Sinitsyn has this “technical analysis”:

 The use of crypto-ransomware in targeted attacks has become an ordinary occurrence lately. … An increase in the activity of [WastedLocker] was noticed in the first half of this year. … The Garmin incident is the next in a series of targeted attacks on large organizations involving crypto-ransomware. Unfortunately, there is no reason to believe that this trend will decline in the near future. That is why it is crucial to: … 1. Use up-to-date OS and application versions 2. Refrain from opening RDP access … 3. Use modern endpoint security solutions … 4. Improve user education in the field of cybersecurity … 5. Use a reliable data backup scheme … IoC 2cc4534b0dd0e1c8d5b89644274a10c1.

All of which makes Jay A hem and haw:

 Doesn’t say much about the corporate IT of Garmin if they don’t have basic protection on the desktop and internal standards to stop this. Who gives admin access to everyone on the desktop these days anyway? That could have stopped a lot of the spread. … No confidence in Garmin IT at this point. How do they know that they aren’t infected by something else now after paying for the code to decrypt the files. Very well could have unlocked phase 2. Wipe all the machines and restore from backup.

But should you pay? No, says Omers:

 Paying the ransom is generally bad because it encourages the malicious actors since their attacks work and pay off. It’s also possible they’ll leave backdoors or other malicious software on your network. … The best course of action is to burn down ransomed systems and restore from backup and if not possible, when a public decryption tool is available use that. If backups and a public decryption tool are both not available it’s generally considered best to cut one’s losses. As we’ve seen time and time again that doesn’t often happen though.

 This is a terrible trend that finances criminals, enabling them to target more and more victims. I’d go as far as to suggest this makes them an accessory … to future crimes by the same ***holes.

 Agreed. If there were lives on the line, that would be a different matter. But accessing exercise data is not worth encouraging the criminals.

But sdinfoserv has real-world insights for you:

 Backups don’t matter. Backups save you from hardware failures, but if you need your data back fast from an encryption attack, you pay. Period. … To restore, you have to rebuild the infrastructure machine by machine — restorting data only … to a sandbox environment. Scan it, test it, then move it to an air-gapped production environment. It’s slow, painful and expensive. You’re dollars ahead paying the scammers, and if it’s your customer facing, revenue generating systems … affected, payment is your only option.

Meanwhile, AvitarX compares paying the ransom with DR:

 Probably as easy as deciding not to worry about backups.

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected] . Ask your doctor before reading. Your mileage may vary. E&OE. 30.

Image sauce: rottonara (via Pixabay)

Richi Jennings is a foolish independent industry analyst, editor, and content strategist. A former developer and marketer, he’s also written or edited for Computerworld, Microsoft, Cisco, Micro Focus, HashiCorp, Ferris Research, Osterman Research, Orthogonal Thinking, Native Trust, Elgan Media, Petri, Cyren, Agari, Webroot, HP, HPE, NetApp on Forbes and CIO.com. Bizarrely, his ridiculous work has even won awards from the American Society of Business Publication Editors, ABM/Jesse H. Neal, and B2B Magazine.

richi has 388 posts and counting.See all posts by richi

Step 1 of 6 16% Have security concerns slowed or prevented your use of Kubernetes? Yes, security concerns are preventing us from deploying Kubernetes Yes, but we are moving forward and working to improve Kubernetes security No, we know how to secure Kubernetes No, but we still have security concerns What are your top Kubernetes security concerns? Pod security policy management Image supply chain integrity Configuration errors Over provisioning of permissions Writing and enforcing security policies Runtime threat/incident detection What are your greatest challenges securing Kubernetes? Lack of the necessary K8s security skills Time and resources to address K8s security Point K8s security solutions don't fit into our DevOps workflows Current vendors we use do not adequately address K8s security Lack the understanding of K8s security policy best practices Is Kubernetes pod security a priority for your organization? Yes, we have an funded, active project Yes, it is a priority for 2023 Somewhat, we address on a project-by-project basis No, but we know we need to do more with Kubernetes security No, not currently a significant issue What are your sources for Kubernetes policy management? Open source software Kubernetes native Pod Security Policies Commercial security product offering Cloud service provider security offerings Do not have a solution at this time What role is responsible for Kubernetes security in your organization? Development DevOps DevSecOps Security Platform Engineering Δ