Security experts are poring over thousands of new Coronavirus-themed domain names registered each day, but this often manual effort struggles to keep pace with the flood of domains invoking the virus to promote malware and phishing sites, as well as non-existent healthcare products and charities. As a result, domain name registrars are under increasing pressure to do more to combat scams and misinformation during the COVID-19 pandemic.
By most measures, the volume of new domain registrations that include the words “Coronavirus” or “Covid” has closely tracked the spread of the deadly virus. The Cyber Threat Coalition (CTC), a group of several thousand security experts volunteering their time to fight COVID-related criminal activity online, recently published data showing the rapid rise in new domains began in the last week of February, around the same time the Centers for Disease Control began publicly warning that a severe global pandemic was probably inevitable.
“Since March 20th, the number of risky domains registered per day has been decreasing, with a notable spike around March 30th,” wrote John Conwell, principal data scientist at DomainTools [an advertiser on this site]. “Interestingly, legitimate organizations creating domains in response to the COVID-19 crisis were several weeks behind the curve from threat actors trying to take advantage of this situation. This is a pattern DomainTools hasn’t seen before in other crises.”
Security vendor Sophos looked at telemetry from customer endpoints to illustrate the number of new COVID-related domains that actually received traffic of late. As the company noted, one challenge in identifying potentially malicious domains is that many of them can sit dormant for days or weeks before being used for anything.
“We can see a rapid and dramatic increase of visits to potentially malicious domains exploiting the Coronavirus pandemic week over week, beginning in late February,” wrote Sophos’ Rich Harang. “Even though still a minority of cyber threats use the pandemic as a lure, some of these new domains will eventually be used for malicious purposes.”
CTC spokesman Nick Espinosa said the first spike in visits was on February 25, when group members saw about 4,000 visits to the sites they were tracking.
“The following two weeks starting on March 9 saw rapid growth, and from March 23 onwards we’re seeing between 75,000 to 130,000 visits per weekday, and about 40,000 on the weekends,” Espinosa said. “Looking at the data collected, the pattern of visits are highest on Monday and Friday, and the lowest visit count is on the weekend. Our data shows that there were virtually no customer hits on COVID-related domains prior to February 23.”
Milwaukee-based Hold Security has been publishing daily and weekly lists of all COVID-19 related domain registrations (without any scoring assigned). Here’s a graph KrebsOnSecurity put together based on that data set, which also shows a massive spike in new domain registrations in the third week of March, trailing off considerably over the past couple of weeks.
Not everyone is convinced we’re measuring the right things, or that the current measurements are accurate. Neil Schwartzman, executive director of the anti-spam group CAUCE, said he believes DomainTool’s estimates on the percentage of new COVID/Coronavirus-themed domains that are malicious are too high, and that many are likely benign and registered by well-meaning people seeking to share news or their own thoughts about the outbreak.
“But there’s the rub,” he said. “Bad guys get to hide amidst the good really effectively, so each one needs to be reviewed on its own. And that’s a substantial amount of work.”
At the same time, Schwartzman said, focusing purely on domains may obscure the true size and scope of the overall threat. That’s because scammers very often will establish multiple subdomains for each domain, meaning that a single COVID-related new domain registration could eventually be tied to a number of different scammy or malicious sites.
Subdomains can not only make phishing domains appear more legitimate, but they also tend to lengthen the domain so that key parts of it get pushed off the URL bar in mobile browsers.
To that end, he said, it makes perhaps the most sense to focus on new domain registrations that have encryption certificates tied to them, since the issuance of an SSL certificate for a domain is usually a sign that it is about to be put to use. As noted in previous stories here, roughly 75 percent of all phishing sites now have the padlock (start with “https://”), mainly because the major Web browsers display security alerts on sites that don’t.
Schwartzman said more domain registrars should follow the example of Los Angeles-based Namecheap Inc., which last month pledged to stop accepting the automated registration of website names that include words or phrases tied to the COVID-19 pandemic. Since then, a handful of other registrars have said they plan to manually review all such registrations going forward.
The Internet Corporation for Assigned Names and Numbers (ICANN), the organization that oversees the registrar industry, recently sent a letter urging registrars to be more proactive, but stopped short of mandating any specific actions.
Schwartzman called ICANN’s response “weak tea.”
“It’s absolutely ludicrous that ICANN hasn’t stepped up, and they will bear significant responsibility for any deaths that may happen as a result of all this,” Schwartzman said. “This is a CYA response at best, and dictates to no one that they should do anything.”
Michael Daniel, president of the Cyber Threat Alliance — a cybersecurity industry group that’s also been working to fight COVID-19 related fraud — agreed, saying more pressure needs to be applied to the registrar community.
“It’s really hard to do anything about this unless the registrars step up and do something on their own,” Daniel said. “It’s either that or the government gets involved. That doesn’t mean some [registrars] aren’t doing what they can, but in general what the industry is doing is nowhere near as fast as the bad guys are generating these domains.”
The U.S. government may well soon get more involved. Earlier this week, Senators Cory Booker (D-N.J.), Maggie Hassan (D-N.H.) and Mazie K. Hirono (D-Hawaii) sent letters to eight domain name company leaders, demanding to know what they were doing to combat the threat of malicious domains, and urging them to do more.
“As cybercriminals and other malevolent actors seek to take advantage of the Coronavirus pandemic, it is critical that domain name registrars like yours (1) exercise diligence and ensure that only legitimate organizations can register Coronavirus-related domain names and domain names referencing online communications platforms; (2) act quickly to suspend, cancel, or terminate registrations for domains that are involved in unlawful or harmful activity; and (3) cooperate with law enforcement to help bring to justice cybercriminals profiting from the Coronavirus pandemic,” the senators wrote.
Many U.S. government Web sites now carry a message prominently at the top of their home pages meant to help visitors better distinguish between official U.S. government properties and phishing pages. Unfortunately, part of that message is misleading and may help perpetuate a popular misunderstanding about Web site security and trust that phishers have been exploiting for years now.
For example, the official U.S. Census Bureau website https://my2020census.gov carries a message that reads, “An official Web site of the United States government. Here’s how you know.” Clicking the last part of that statement brings up a panel with the following information:
The text I have a beef with is the bit on the right, beneath the “This site is secure” statement. Specifically, it says, “The https:// ensures that you are connecting to the official website….”
Here’s the deal: The https:// part of an address (also called “Secure Sockets Layer” or SSL) merely signifies the data being transmitted back and forth between your browser and the site is encrypted and cannot be read by third parties.
However, the presence of “https://” or a padlock in the browser address bar does not mean the site is legitimate, nor is it any proof the site has been security-hardened against intrusion from hackers.
In other words, while readers should never transmit sensitive information to a site that does not use https://, the presence of this security feature tells you nothing about the trustworthiness of the site in question.
Here’s a sobering statistic: According to PhishLabs, by the end of 2019 roughly three-quarters (74 percent) of all phishing sites were using SSL certificates. PhishLabs found this percentage increased from 68% in Q3 and 54% in Q2 of 2019.
“Attackers are using free certificates on phishing sites that they create, and are abusing the encryption already installed on hacked web sites,” PhishLabs founder and CTO John LaCour said.
The truth is anyone can get an SSL certificate for free, and that’s a big reason why most phishing sites now have them. The other reason is that they help phishers better disguise their sites as legitimate, since many Web browsers now throw up security warnings on non-https:// sites.
KrebsOnSecurity couldn’t find any reliable information on how difficult it may be to obtain an SSL certificate for a .gov site once one has a .gov domain, but it is apparently not difficult for just about anyone to get their very own .gov domain name.
The U.S. General Services Administration (GSA), which oversees the issuance of .gov domains, recently made it a tiny bit more difficult to do so — by requiring all applications be notarized — but this seems a small hurdle for scam artists to clear.
Regardless, it seems the federal government is doing consumers a disservice with this messaging, by perpetuating the myth that the presence of “https://” in a link denotes any kind of legitimacy.
“‘Https’ does not mean that you are at the correct website or that the site is secure,” LaCour said. “It only indicates that the connection is encrypted. The server could still be misconfigured or have software vulnerabilities. It is good that they mention to look for ‘.gov’. There’s no guarantee that a .gov website is secure, but it should help ensure that visitors are on the right website.”
I should note that this misleading message seems to be present only on some federal government Web sites. For instance, while the sites for the GSA, the Department of Labor, Department of Transportation, and Department of Veterans Affairs all include the same wording, those for the Commerce Department and Justice Department are devoid of the misleading text, stating:
“This site is also protected by an SSL (Secure Sockets Layer) certificate that’s been signed by the U.S. government. The https:// means all transmitted data is encrypted — in other words, any information or browsing history that you provide is transmitted securely.”
Other federal sites — like dhs.gov, irs.gov and epa.gov — simply have the “An official website of the United States government” declaration at the top, without offering any tips about how to feel better about that statement.
Late last year saw the re-emergence of a nasty phishing tactic that allows the attacker to gain full access to a user’s data stored in the cloud without actually stealing the account password. The phishing lure starts with a link that leads to the real login page for a cloud email and/or file storage service. Anyone who takes the bait will inadvertently forward a digital token to the attackers that gives them indefinite access to the victim’s email, files and contacts — even after the victim has changed their password.
Before delving into the details, it’s important to note two things. First, while the most recent versions of this stealthy phish targeted corporate users of Microsoft’s Office 365 service, the same approach could be leveraged to ensnare users of many other cloud providers. Second, this attack is not exactly new: In 2017, for instance, phishers used a similar technique to plunder accounts at Google’s Gmail service.
Still, this phishing tactic is worth highlighting because recent examples of it received relatively little press coverage. Also, the resulting compromise is quite persistent and sidesteps two-factor authentication, and it seems likely we will see this approach exploited more frequently in the future.
In early December, security experts at PhishLabs detailed a sophisticated phishing scheme targeting Office 365 users that used a malicious link which took people who clicked to an official Office 365 login page — login.microsoftonline.com. Anyone suspicious about the link would have seen nothing immediately amiss in their browser’s address bar, and could quite easily verify that the link indeed took them to Microsoft’s real login page:
Only by copying and pasting the link or by scrolling far to the right in the URL bar can we detect that something isn’t quite right:
As we can see from the URL in the image directly above, the link tells Microsoft to forward the authorization token produced by a successful login to the domain officesuited[.]com. From there, the user will be presented with a prompt that says an app is requesting permissions to read your email, contacts, OneNote notebooks, access your files, read/write to your mailbox settings, sign you in, read your profile, and maintain access to that data.
According to PhishLabs, the app that generates this request was created using information apparently stolen from a legitimate organization. The domain hosting the malicious app pictured above — officemtr[.]com — is different from the one I saw in late December, but it was hosted at the same Internet address as officesuited[.]com and likely signed using the same legitimate company’s credentials.
PhishLabs says the attackers are exploiting a feature of Outlook known as “add-ins,” which are applications built by third-party developers that can be installed either from a file or URL from the Office store.
“By default, any user can apply add-ins to their outlook application,” wrote PhishLabs’ Michael Tyler. “Additionally, Microsoft allows Office 365 add-ins and apps to be installed via side loading without going through the Office Store, and thereby avoiding any review process.”
In an interview with KrebsOnSecurity, Tyler said he views this attack method more like malware than traditional phishing, which tries to trick someone into giving their password to the scammers.
“The difference here is instead of handing off credentials to someone, they are allowing an outside application to start interacting with their Office 365 environment directly,” he said.
Many readers at this point may be thinking that they would hesitate before approving such powerful permissions as those requested by this malicious application. But Tyler said this assumes the user somehow understands that there is a malicious third-party involved in the transaction.
“We can look at the reason phishing is still around, and it’s because people are making decisions they shouldn’t be making or shouldn’t be able to make,” he said. “Even employees who are trained on security are trained to make sure it’s a legitimate site before entering their credentials. Well, in this attack the site is legitimate, and at that point their guard is down. I look at this and think, would I be more likely to type my password into a box or more likely to click a button that says ‘okay’?”
The scary part about this attack is that once a user grants the malicious app permissions to read their files and emails, the attackers can maintain access to the account even after the user changes his password. What’s more, Tyler said the malicious app they tested was not visible as an add-in at the individual user level; only system administrators responsible for managing user accounts could see that the app had been approved.
Furthermore, even if an organization requires multi-factor authentication at sign-in, recall that this phish’s login process takes place on Microsoft’s own Web site. That means having two-factor enabled for an account would do nothing to prevent a malicious app that has already been approved by the user from accessing their emails or files.
Once given permission to access the user’s email and files, the app will retain that access until one of two things happen: Microsoft discovers and disables the malicious app, or an administrator on the victim user’s domain removes the program from the user’s account.
Expecting swift action from Microsoft might not be ideal: From my testing, Microsoft appears to have disabled the malicious app being served from officesuited[.]com sometime around Dec. 19 — roughly one week after it went live.
In a statement provided to KrebsOnSecurity, Microsoft Senior Director Jeff Jones said the company continues to monitor for potential new variations of this malicious activity and will take action to disable applications as they are identified.
“The technique described relies on a sophisticated phishing campaign that invites users to permit a malicious Azure Active Directory Application,” Jones said. “We’ve notified impacted customers and worked with them to help remediate their environments.”
Microsoft’s instructions for detecting and removing illicit consent grants in Office 365 are here. Microsoft says administrators can enable a setting that blocks users from installing third-party apps into Office 365, but it calls this a “drastic step” that “isn’t strongly recommended as it severely impairs your users’ ability to be productive with third-party applications.”
PhishLabs’ Tyler said he disagrees with Microsoft here, and encourages Office 365 administrators to block users from installing apps altogether — or at the very least restrict them to apps from the official Microsoft store.
Apart from that, he said, it’s important for Office 365 administrators to periodically look for suspicious apps installed on their Office 365 environment.
“If an organization were to fall prey to this, your traditional methods of eradicating things involve activating two-factor authentication, clearing the user’s sessions, and so on, but that won’t do anything here,” he said. “It’s important that response teams know about this tactic so they can look for problems. If you can’t or don’t want to do that, at least make sure you have security logging turned on so it’s generating an alert when people are introducing new software into your infrastructure.”