Thought leadership. Threat analysis. Cybersecurity news and alerts.
Threat Focus: WastedLocker Ransomware
Garmin, an American multinational company that markets GPS navigation and wireless devices and applications, has reported a global outage on its systems since last July 23.
Last July 23, Garmin announced that it was experiencing an outage that affected Garmin Connect – a service that syncs users' activity and data to the cloud and other devices. Garmin also announced that the outage affected the company's call centers, cutting off the company's ability to respond to any calls, emails and online chats.
Last July 26, Garmin followed up its July 23 announcement. The statement said the company "has no indication that this outage has affected your data, including activity, payment or other personal information."
flyGarmin, Garmin's service that offers navigational software to pilots, in a separate statement said that last July 23 it also experienced a similar outage in which users couldn't access flyGarmin's website and call centers. flyGarmin specified that its Connext services, in particular, weather, data from the on-board Central Maintenance Computer (CMC), position reports were down; and Garmin Pilot apps, in particular, flight plan filing (unless connected to FltPlan, account syncing, database concierge) were down.
Based on its July 26 update, flyGarmin said that its website and mobile app are now operational, and that customer support can handle limited calls, but emails and chat supports are still unavailable.
While Garmin remains silent on what caused the global outage of its systems, BleepingComputer and TechCrunch reported that sources familiar with the Garmin outage investigation and company employees point to the direction that Garmin fell victim to WastedLocker ransomware.
A Garmin employee told BleepingComputer that they first learned of the attack when they arrived at their office last Thursday morning. As devices were being encrypted, employees were told to shut down any computer on the network, including computers used by remote workers that were connected via virtual private network (VPN), to prevent additional devices from being encrypted. As shown by the photo sent by a Garmin employee to BleepingComputer, the ".garminwasted" extension was appended to the file name of every encrypted file.
WastedLocker ransomware was first tracked in the wild in May of this year. This ransomware was named after the filename it creates which includes an abbreviation of the victim’s name and the word "wasted".
One of the known methods used by the group behind the WastedLocker ransomware is the use of fake software update that shows up on the users' computer screen when visiting certain legitimate websites. Malicious code is inserted by the group behind the WastedLocker ransomware on vulnerable websites, prompting unsuspecting users to click on the fake software updates that show up on their trusted websites.
Once a user clicks on this fake software update, the WastedLocker ransomware activates CobaltStrike – a commercial penetration testing tool that can be used by ethical security researchers as well as by malicious actors. This commercial penetration testing tool uses tools such as Metasploit and Mimikatz.
Metasploit is an open-source tool for probing vulnerabilities on networks and servers. It can easily be customized and used with most operating systems.
Mimikatz, meanwhile, is another open-source tool that gives out passwords as well as hashes and PINs from memory. This tool makes it easy for attackers to conduct post-exploitation lateral movement within a victim's network.
After exploring the weak spots and access credentials, the WastedLocker ransomware is then dropped into the victim's network or server. With WastedLocker ransomware, it isn't possible to get backup copy on the affected computer as this malicious software deletes shadow copies – the default backups made by Windows operating systems.
Security researchers, including those from Malwarebytes and Fox-IT, named Evil Corp Group as the group behind WastedLocker ransomware. Most of today's ransomware groups openly admit that they steal victims' data prior to encrypting files. These ransomware groups publish or auction the data belonging to victims that are unwilling to pay the ransom.
According to Malwarebytes, the group behind the WastedLocker ransomware "does not exfiltrate stolen data and publish or auction the data that belong to 'clients' that are unwilling to pay the ransom".
Fox-IT, meanwhile, said that the group behind WastedLocker ransomware “has not appeared to have engaged in extensive information stealing or threatened to publish information about victims”. "We assess that the probable reason for not leaking victim information is the unwanted attention this would draw from law enforcement and the public," Fox-IT said.
The group behind WastedLocker ransomware demands ransom payment ranging from US$500,000 to over $10 million in Bitcoin. One of the sources of BleepingComputer said that the ransom demand in exchange for decryption keys that could unlock the encrypted files of Garmin is priced at US$10 million.
In December 2019, the U.S. Treasury Department, sanctioned Evil Corp by way of prohibiting U.S. persons in dealing with the group. The U.S. Treasury Department said that "U.S. persons are generally prohibited from engaging in transactions with them [Evil Corp]." Engagement, in this case, could be mean that US individuals or organizations are prohibited in engaging with Evil Corp, such as via ransom payment.
The sanction of the U.S. Treasury Department’ came after leaders and members of the Evil Corp were charged for developing and distributing the malicious software (malware) called "Dridex". The U.S. Treasury Department said that Dridex infected computers and harvested login credentials from hundreds of banks and financial institutions in over 40 countries, causing more than US$100 million in theft.
Twitter Attributes Latest Hack to Its Systems to Social Engineering
Last July 15th, verified Twitter accounts, including that of Amazon CEO Jeff Bezos and Former U.S. President Barack Obama, tweeted similar content, saying that they've decided to give back to their community by giving back twice the Bitcoin amount (limited to US $50 million) for every Bitcoin that will be sent to a particular Bitcoin address.
The tweets were later removed – a confirmation that the tweets were part of a scam and that the involved verified Twitter accounts were, in fact, hacked. A total of 393 transactions sent varying amounts of Bitcoin to the indicated Bitcoin address. Whoever orchestrated the campaign earned 12.8 Bitcoins, valued at US $117,473 as of July 18, 2020.
How Twitter Was Hacked?
In a blog post dated July 18, 2020, Twitter attributed the hacking of the 130 verified Twitter accounts to social engineering. "At this time, we believe attackers targeted certain Twitter employees through a social engineering scheme," Twitter said.
The company, however, didn't elaborate how the social engineering was carried out by attackers. Twitter defined social engineering as the "intentional manipulation of people into performing certain actions and divulging confidential information."
According to Twitter, the intentional manipulation of a small number of Twitter employees enabled the attackers to access the company's internal systems using the credentials of the targeted Twitter employees, and "getting through" the company's two-factor authentication (2FA) protection.
Twitter said the attackers were able to view personal information including phone numbers and email addresses – information that were accessible to some of the targeted employees. Out of the 130 hacked verified accounts, Twitter added, 45 of those accounts, the attackers were able to login to the account, send tweets and initiate a password reset.
In accounts taken over by the attackers, the company said that the attackers may have been able to view additional information. The company also added that the attackers attempted to sell some of the hacked accounts.
The July 15th cyber incident at Twitter isn't the first hacking incident that the company experienced. Nearly a year ago, the Twitter account of its CEO Jack Dorsey was hacked.
After taking over Dorsey's Twitter account @jack, attackers fired off nearly two dozen tweets and retweets. "The phone number associated with the account was compromised due to a security oversight by the mobile provider," Twitter said in a statement. "This allowed an unauthorized person to compose and send tweets via text message from the phone number."
The above-mentioned statement from Twitter on how its CEO's account was hacked describes a typical SIM swap attack – a type of cyberattack in which a mobile phone company employee switches a victim’s phone number to a new phone number that's under the attacker’s control.
This type of attack is carried out in two ways. One method is by calling a customer help line of the mobile phone company and pretend to be the intended victim. The other method is by paying off phone company employees to do the phone number switches. There have been reports that attackers paid off phone company employees to do the phone number switching for as low as US $100.
SIM swap plays a big role in an attack that tries to bypass text message-based 2-factor authentication, an authentication method that requires additional authentication, that is, on top of the usual username and password requirement, a user can only login to an account by providing a one-time code – a code that's sent to the phone number provided by a user. In a SIM swap attack, by changing the target's phone number to the phone number controlled by the attacker, the one-time code is sent to the new phone number controlled by the attacker.
In September 2019, the U.S. Federal Bureau of Investigation (FBI) warned its partner organizations about SIM swapping. According to the FBI, between 2018 and 2019, the most common tactic used by attackers in circumventing the 2-factor authentication was through SIM swapping.
In 2019, a report came out that Twitter left its internal systems exposed to outsiders by failing to apply the latest security update of a particular software. This time, however, bug bounty hunters found the vulnerability and responsively disclosed the vulnerability to Twitter.
In a blog post dated September 2, 2019, security researchers at DEVCORE reported that they were able to perform on Twitter's internal systems remote code execution – the ability to access someone else's computing device and make changes to it regardless of where this computing device is geographically located. The researchers said they initially gained access to Twitter's internal system by exploiting an unpatched Pulse Secure VPN used by the company.
The security researchers at DEVCORE are the same researchers that discovered the remote code execution vulnerability in Pulse Secure VPN products and reported this vulnerability to the software vendor Pulse Secure. The same researchers also discovered and reported the security vulnerabilities in the VPN products of OpenVPN and Fortinet.
"During our research, we found a new attack vector to take over all the clients [computers or software that accesses a service made available by a server]," security researchers at DEVCORE said. "It’s the 'logon script' feature. It appears in almost EVERY SSL VPNs, such as OpenVPN, Fortinet, Pulse Secure… and more. It can execute corresponding scripts to mount the network filesystem or change the routing table once the VPN connection established. Due to this 'hacker-friendly' feature, once we got the admin privilege, we can leverage this feature to infect all the VPN clients!"
The researchers also reported that they bypassed the 2-factor authentication as Twitter enabled the Pulse Secure VPN's roaming session feature, which allows a session from multiple IP locations. "Due to this 'convenient' [roaming session] feature, we can just download the session database and forge our cookies to log into their system!"
Prior to going public, the security researchers at DEVCORE reported to Twitter their findings via the company's bug bounty program.
Social engineering is a significant risk for most organizations and individuals alike. This is why we’ve created a blog post with 52 cybersecurity tips for businesses and individuals to help mitigate key risks.
How DDoS Threat Landscape Has Evolved Over Time
Through the years, distributed denial-of-service (DDoS) – a form of cyberattack originating from multiple systems and overwhelming one specific service or website using malicious data or requests – has evolved and grown stronger and more prevalent.
Evolution of the DDoS Threat Landscape
The Morris Worm
DDoS threat has been around ever since humanity decided to interconnect computers. The malicious software dubbed as “Morris worm”, which was unleashed prior to the invention of the World Wide Web, is considered by some as the first DDoS attack.
Morris worm replicated a copy of itself and propagated itself at a remarkable speed to computers belonging to a number of the prestigious colleges and public and private research centers that made up the ARPANET – an early prototype for the internet. On November 2, 1988, in just 24 hours, the Morris worm affected an estimated 6,000 of the approximately 60,000 computers that were then connected to ARPANET.
The unleashing of the Morris worm resulted in slowing to a crawl vital military and university functions and delayed emails for days. The creator of the Morris worm, then 23-year-old Cornell University graduate student Robert Tappan Morris unleashed out the worm by exploiting security vulnerabilities in a specific version of the Unix operating system. The worm was also unleashed by attempting to break into user accounts on an infected machine using brute force attacks, that is, guessing weak passwords similar to modern-day brute force attacks.
MafiaBoy DDoS Attack
While not the first DDoS attack in the World Wide Web era, the DDoS attacks carried out by MafiaBoy, then 15-year old Michael Calce from Montreal, Canada, were notable as this teenager launched a series of high-profile DDoS attacks in February 2000 against large commercial websites, including eBay, Amazon and E*Trade. In carrying out his DDoS attacks, Calce modified the code written by another hacker. Calce compromised nearly 200 university networks and brought this under his control to launch DDoS attacks against specific targets.
In the book "Mafiaboy: A Portrait of the Hacker as a Young Man", Calce wrote that he scanned the internet for university-owned servers withsecurity weaknesses that he could exploit. "Once I found at least one, I ran a program I had found called Hunter to hijack that computer's connection."
In the age of Internet of Things (IoT), the DDoS attacks carried out Mirai stand out. Mirai is a malicious software (malware) that compromises poorly secured IoT devices such as wireless routers and security cameras into a botnet to conduct large-scale DDoS attacks. A botnet refers to a network of compromised computers coordinating as one to carry out instructions at the direction of their master – a malicious threat actor.
On September 30, 2016, Mirai source code was leaked online by one of its authors, Paras Jha. The Mirai source code was later used by different malicious actors in launching DDoS attacks.
Mirai exploits the habit of IoT users of not changing the default login details. At its height, nearly 400,000 IoT devices were hijacked by Mirai for DDoS attacks.
One notable DDoS attack utilizing the Mirai source code was the DDoS attack on internet infrastructure services provider Dyn DNS (now Oracle DYN) in October 2016. The DDoS attack on this internet infrastructure, which enslaved 100,000 devices including IP cameras and printers, disrupted the services of major websites such as Amazon, Netflix, Reddit, Spotify and Twitter.
Memcached-Based DDoS Attacks
In February 2018, DDoS attackers used a new attack method that exploited a lesser number of devices but produced a bigger punch. GitHub reported on February 28, 2018 that GitHub.com was unavailable from 17:21 to 17:26 UTC and intermittently unavailable from 17:26 to 17:30 UTC due to a DDoS attack. The DDoS attack on GitHub peaked at 1.35 Tbps – then setting the record of the largest DDoS attack.
In analyzing the DDoS attack on GitHub, Cloudflare reported that the attack on GitHub exploited 5,729 memcached servers that were inadvertently made accessible on the internet. Memcached is an open-source distributed memory caching system for speeding up applications.
"Launching such an attack [by exploiting Memcached] is easy," Cloudflare said. "First the attacker implants a large payload on an exposed memcached server. Then, the attacker spoofs the 'get' request message with target Source IP. In practice, we've seen a 15 byte request result in a 750kB response (that's a 51,200x amplification)."
With nearly 100,000 Memcached servers exposed to the internet, Cloudflare said at that time that it's expecting to see much larger attacks in the future.
Days after the GitHub attack, NetScout reported an even larger DDoS attack, victimizing a US-based service provider. This time peaking at 1.7Tbps. "The attack utilized a Memcached ... Reflection & Amplification vector to accomplish such a massive attack," NetScout said.
CLDAP-Based DDoS Attack
In the 1st quarter of 2020, Amazon reported that in February of this year, it detected and mitigated a DDoS attack targeting an AWS customer. The DDoS attack, Amazon said, peaked at 2.3 Tbps and caused three days of “elevated threat".
According to Amazon, the DDoS attack on one of its AWS customers exploited Connection-less Lightweight Directory Access Protocol (CLDAP) web servers. CLDAP is used to connect, search, and modify internet-shared directories. DDoS attackers have made CLDAPexploitation as part of their arsenal since 2016.
Imperva's 2019 Global DDoS Threat Landscape Report found that large-scale DDoS attacks were outside of the norm. "Overall, we saw attacks that were smaller, shorter, and more persistent," Imperva said. "While this trend may be indicative of attackers’ attempts to wreak havoc before a mitigation service kicks in, it’s no match for Imperva, where time to mitigation is near zero."
Many companies that call us have fallen victim to a DDoS attack, and paid ransom to cybercriminals to stop the attacks and resume normal business operations.
Protect your website, web applications and your network today and avoid costly business interruptions.
Using state of the art technology, our team will mitigate a DDoS attack in just 10-seconds, protecting your revenues, your assets and your reputation.
‘Wiping & Ransom’ Attack Targets Cloud Data Stored in MongoDB Databases
Data stored in the cloud isn't off limits to cybercriminals. A new report showed that a malicious actor held for ransom nearly half of all MongoDB databases exposed online.
A recent ZDNet report showed that a malicious actor has uploaded ransom notes on 22,900 MongoDB databases left exposed online without a password. This nearly 23,000 MongoDB databases represents nearly 47% of all MongoDB databases exposed online.
MongoDB is a document database in which documents can be searched by their field’s key, making this type of database flexible. This database can be deployed, operated and scaled in the cloud via cloud hosting services.
The report showed that the attacker scanned the internet using an automated script to search for exposed MongoDB databases; contents of the exposed databases were then wiped out; and victims were asked to pay 0.015 bitcoin (approximately USD 136 as of July 4, 2020).
The attacker then gave victims 2 days to pay the ransom to get back their wiped data and further threatened to leak victims' data in case of non-payment of the ransom. The attacker also threatened victims that the data leak will be reported to the local General Data Protection Regulation (GDPR) enforcement authority.
Under GDPR, organizations that are found to have failed to protect customers’ private data and such failure lead to a data breach could receive a hefty fine from local enforcement authority. In July 2019, UK’s Information Commissioner’s Office (ICO) announced its intention to fine British Airways £183.39m under GDPR for data breach. In July 2019 also the ICO similarly announced its intention to fine Marriott International, Inc. more than £99 million under GDPR for data breach.
Victor Gevers, a security researcher at the GDI Foundation, told ZDNet that the initial attacks didn't include the data wiping step. The wiping feature, Gevers said, was later added to the malicious actor's arsenal in attacking MongoDB databases. The ZDNet report said that the series of attacks on MongoDB databases started back in December 2016.
In a January 2017 blog post, Andreas Nilsson, Director of Product Security at MongoDB, acknowledged the attacks on unsecured MongoDB databases running openly on the internet. Said attacks, Nilsson said, erased database content and demanded from victims to pay ransom before the content can be restored.
In September 2017, Davi Ottenheimer, who leads the Product Security at MongoDB, in a blog post said that the company is aware of a new wave of attacks searching for misconfigured and unmaintained MongoDB databases. Ottenheimer said that the compromised MongoDB databases were left unsecured and connected to the internet with no password on their administrator account. This new wave of attacks, Ottenheimer said, doesn't indicate a new risk, just new targets.
"This [wiping and ransom of MongoDB databases] is not ransomware. Database does not get encrypted. It only gets replaced," Gevers told Bleeping Computer. "This is someone who does [this] manually or with a simple Python script."
According to Gevers, thousands of MongoDB databases are left exposed without a password online as these MongoDB instances used the old version of the MongoDB software in which the default configuration left the database open to external connections via the internet. "The most open and vulnerable MongoDBs can be found on the AWS platform because this is the most favorite place for organizations who want to work in a devops way," Gevers said. "About 78% of all these hosts were running known vulnerable versions."
How to Secure Data Stored in the Cloud
Unsecured and misconfigured data stored in the cloud isn't limited to MongoDB databases. In February 2018, BBC reported that security researchers have posted "friendly warnings" to users of Amazon's cloud data storage service whose private content has been made public to correct their settings that exposed data. "Please fix this before a bad guy finds it," one message left by security researcher said.
Here are some of the cybersecurity best practices in securing MongoDB databases deployed in the cloud via cloud hosting services and other data stored in different cloud platforms:
Like any online accounts, MongoDB databases deployed in the cloud and other data stored in the cloud via other cloud platforms need strong authentication methods. At the very least, protect the database with strong authentication method such as a strong password. These days cyberattacks often start with simple internet scanning. It’s important to protect cloud databases at its basic level with a strong password. It's also important to add extra layer of protection via multi-factor authentication.
The principle of least privilege is a security concept that limits access to the bare minimum to perform a task. For instance, a user is granted access only to specific database resources and operations and outside these defined role assignments, the user has no access to the other components of the database.
Use Firewall to control inbound and outbound traffic to your organization's databases. Use IP whitelisting to allow access only from trusted IP addresses.
It's important to keep a backup copy of the critical data stored in the cloud offline in case something happens beyond your organization's control that could prevent access to data stored in the cloud.
It's also important to audit data stored in the cloud, keeping track of the access and changes made to settings and data. A reliable audit system records these access and changes which can later on be used for forensic analysis and to make proper adjustments and controls.
Steve E. Driz, I.S.P., ITCP