Threat Summary & Threat Actor Attribution
The DomainTools Security Research Team, in the course of monitoring newly registered Coronavirus and COVID labeled domain names, discovered a website luring users into downloading an Android application under the guise of a COVID-19 heat map. Analysis on the application showed that the APK contained ransomware. SSL certificates of the malicious domain (coronavirusapp[.]site) link the site to another domain (dating4sex[.]us) which is also serving the malicious application. The linked site has registration information pointing to an individual in Morocco.
We have reverse-engineered CovidLock’s decryption key, and have released it publicly for any victims affected by this ransomware: “4865083501“
If you would prefer to listen to The DomainTools Research team discuss their analysis, it is featured in our recent episode of Breaking Badness, which is included at the bottom of this post.
Web Attack Vector
The Lure
The coronavirusapp[.]site domain initially contained an iframe sourcing directly from infection2020[.]com (a website from an independent developer for tracking US-based COVID-19 news) and a small banner above that encouraged the installation of the malicious application for real time updates.
After a few days the site was changed to using resources from DoMobile, a provider of various legitimate Android applications, but the same malicious application was being served from this new site.
As of the release of this report the page is still serving the malicious Android application.
Additional Investigation
The coronavirusapp[.]site domain was originally registered on March 8, 2020 using domain privacy to obscure the registrant details. The site is hosted on Wrathost, a provider of cheap shared hosting. For that reason the domain is on an IP address shared with over 100 other domains not related. However, looking at the Let’s Encrypt SSL certificate for the domain revealed one other domain that was also serving up the malicious Android application: dating4sex[.]us.
The dating4sex[.]us site contained an open directory that contained other Android applications and content found in the original domain’s malicious APK. Pulling historicalized WHOIS records for the domain showed that the registrant claims to be an individual in Morocco. The registrant’s email rolling8dice@gmail[.]com also ties to an additional 158 domains almost all of which are now inactive save for the ones we have included in the IoC table below. All of the defunct domains tie back to a single domain through old SSL certificates that looks to be a now discontinued campaign.
The site also serves up an additional APK marked as EroFlix, a pornography Android application that is distributed around the Internet. Searches across reddit and elsewhere show that the previous APK was being spammed across multiple websites as well as the dating4sex[.]us domain being submitted along with it being watermarked on images submitted to pornographic image forums. The long run history of that campaign, now looking disabled, suggests that this COVID-19 scam is a new venture and experiment for the actor behind this malware.
CovidLock Ransomware Analysis:
CovidLock is a new Android ransomware that conducts a lock-screen attack against its victims.
As a bit of background, Android applications are generally written in Java. The Java class bytecode is converted to dex bytecode using a Dex compiler. From there, the dex bytecode is ingested and executed in the Android Runtime (ART).
When analyzing a malicious Android APK, there are two main components I look at: the bytecode and the resources. To begin static analysis of the APK, let’s decode it using ‘apktool’.
We have a decoded APK with close to original code and resources for static analysis.
CovidLock’s Android Manifest
AndroidManifest.xml is one of the most important files to analyze in Android malware. This file contains information about the permissions that an Android application requires to access, as well as the entry point of the application and application activities. We can glean quite a bit of information just from this file alone.
CovidLock’s Manifest File Content
We have several takeaways here with CovidLock: we can tell that it has a persistence mechanism to survive reboots, looks to see if the running user is an administrator, and asks to operate with administrative privileges.
CovidLock Perisistence
Android applications can listen for the BOOT_COMPLETED broadcast to ensure the application will be activated upon device start up, and this is how CovidLock achieves its persistence mechanism. This is also listed on the MITRE ATT&CK mobile framework as technique ‘T1402’ for reference.
CovidLock Privilege Escalation
As noted in the AndroidManifest XML file, the CovidLock application requests access to the permission: BIND_DEVICE_ADMIN. Once a user allows CovidLock’s request, this permission provides nearly full control of the device to CovidLock.
CovidLock’s authors do this by luring the victim to enable full device control via the within the application itself by asking if you want to enable the application in Accessibility to monitor COVID-19 stats, as well as when a victim wants to know when a known COVID-19 patient is near your vicinity.
This is a pretty clever lure from a phishing standpoint.
Additionally, we can view the decompiled Java code array of said permissions as well as how they are being called in CovidLock.
As part of the privilege escalation process, CovidLock attempts to determine if the user is currently running as an administrator and if not will attempt to request permissions to do so.
CovidLock – Network Operations & Ransom Note
Inspecting the packet capture’s DNS flags responses, we get the following benign behavior from CovidLock. We can see that CovidLock does not make any unusual DNS requests during its infection process until it reaches a specific interaction phase with the victim.
From a malware analysis perspective, we generally are looking for any type of DNS request with an unusual or unique domain name. In most cases, a DNS request to an unknown or suspicious domain are preemptive to C2 (Command and Control) operations from an attacker’s infrastructure.
What we do see, though, is a DNS lookup and HTTP communication to a ‘bit.ly’ shortened URL. We can correlate this with URI calls in the CovidLock code.
Tracing the network operations of that ‘bit.ly’ link, we can see a redirection to a pastebin site ‘https://pastebin.com/zg6rz6qT’.
Inspecting the web content, we can see this is part of the dynamically generated ransomware note that is sent to the users lock screen. Although, as we see later this is one of two ransomware notes stored on Pastebin used by CovidLock.
The ‘Pastebin’ site displays a paste that shows the attackers BitCoin wallet ID, and the rest of the ransomware note. The data from the pastebin site gets pulled into the dynamically generated ransom note that gets pushed to the victim’s screen post-lock.
Leveraging Pastebin to store the ransom Bitcoin wallet ID allows the attacker to change which wallet gets used, if they choose to edit their Pastebin post.
Ransom note extracted from CovidLock
Combined with the data from the Pastebin URL, we have the dynamically generated note with complete images and content.
Although, it’s not immediately clear the victim has to select the “Web Designus” button to be navigated to the another Pastebin site containing the actual ransom decryption instructions.
We have no data to suggest that the CovidLock author actually provides the static decryption key (“4865083501”) to victims or not.
Tracking CovidLock’s Bitcoin Wallet
Looking at the Bitcoin wallet ID extracted from CovidLock, we can see that no victims as of today (03/15/2020) have currently paid the ransom.
The DomainTools security research team is actively monitoring the BitCoin wallets and other infrastructure associated with CovidLock for any changes.
Remediating Compromised Devices
CovidLock’s author did not bother implementing any type of obfuscation of the key in the application’s source code. While it’s easy to write about how this is not sophisticated from a malware development standpoint, it’s important to note that CovidLock is still effective at its lock-screen attack.
CovidLock’s ‘verify PIN’ function
Tracking CovidLock’s Email
We have not found any indication that the e-mail address associated with the CovidLock author has been detected in other attacks or malware via OSINT sources and is likely unique to this campaign.
The DomainTools security research team is continuing to monitor the CovidLock ransomware and associated infrastructure and will provide updates as needed.
MITRE ATT&CK on CovidLock
| Technique | TID | URL |
| Drive-By Compromise T1 | T1456 | https://attack.mitre.org/techniques/T1456/ |
| App Auto Start Device Boot | T140 | https://attack.mitre.org/techniques/T1402/ |
| Device Lockout | T1446 | https://attack.mitre.org/techniques/T1446/ |
Indicators of Compromise
| IOC Type | IOC |
| Domain | coronavirusapp[.]site |
| Domain | dating4sex[.]us |
| Domain | dating4free[.]us |
| Domain | perfectdating[.]us |
| Domain | redditdating[.]us |
| URL – Ransomware Note 1 | https://pastebin[.]com/zg6rz6qT |
| URL – Ransomware Note 2 | https://pastebin[.]com/GK8qrfaC |
| APK MD5 | 69a6b43b5f63030938c578eec05993eb |
| APK SHA256 | c844992d3f4eecb5369533ff96d7de6a05b19fe5f5809ceb1546a3f801654890 |
| Email Address | [email protected] |
The DomainTools Security Research Team Discusses Their Analysis:
Research Conducted By:
Chad Anderson, Senior Security Researcher
Tarik Saleh, Senior Security Engineer & Malware Researcher
