Google on Monday disclosed details about an ongoing campaign carried out by a government-backed threat actor from North Korea that has targeted security researchers working on vulnerability research and development.
The internet giant’s Threat Analysis Group (TAG) said the adversary created a research blog and multiple profiles on various social media platforms such as Twitter, Twitter, LinkedIn, Telegram, Discord, and Keybase in a bid to communicate with the researchers and build trust.
The goal, it appears, is to steal exploits developed by the researchers for possibly undisclosed vulnerabilities, thereby allowing them to stage further attacks on vulnerable targets of their choice.
“Their blog contains write-ups and analysis of vulnerabilities that have been publicly disclosed, including ‘guest’ posts from unwitting legitimate security researchers, likely in an attempt to build additional credibility with other security researchers,” said TAG researcher Adam Weidemann.
In one instance, the actor used Twitter to share a YouTube video of what it claimed to be an exploit for a recently patched Windows Defender flaw (CVE-2021-1647), when in reality, the exploit turned out to be fake.
The North Korean hackers are also said to have used a “novel social engineering method” to hit security researchers by asking them if they would like to collaborate on vulnerability research together and then provide the targeted individual with a Visual Studio Project.
This Visual Studio Project, besides containing the source code for exploiting the vulnerability, included a custom malware that establishes communication with a remote command-and-control (C2) server to execute arbitrary commands on the compromised system.
What’s more, TAG said it observed several cases where researchers were infected after visiting the research blog, following which a malicious service was installed on the machine, and an in-memory backdoor would begin beaconing to a C2 server.
With the victim systems running fully patched and up-to-date versions of Windows 10 and Chrome web browser, the exact mechanism of compromise remains unknown. But it’s suspected that the threat actor likely leveraged zero-day vulnerabilities in Windows 10 and Chrome to deploy the malware.
“If you are concerned that you are being targeted, we recommend that you compartmentalize your research activities using separate physical or virtual machines for general web browsing, interacting with others in the research community, accepting files from third parties and your own security research,” Weidemann said.
In 1982, when SMTP was first specified, it did not contain any mechanism for providing security at the transport level to secure communications between mail transfer agents.
Later, in 1999, the STARTTLS command was added to SMTP that in turn supported the encryption of emails in between the servers, providing the ability to convert a non-secure connection into a secure one that is encrypted using TLS protocol.
However, encryption is optional in SMTP, which implies that emails can be sent in plaintext. Mail Transfer Agent-Strict Transport Security (MTA-STS) is a relatively new standard that enables mail service providers the ability to enforce Transport Layer Security (TLS) to secure SMTP connections and to specify whether the sending SMTP servers should refuse to deliver emails to MX hosts that that does not offer TLS with a reliable server certificate. It has been proven to successfully mitigate TLS downgrade attacks and Man-in-the-Middle (MitM) attacks.
SMTP TLS Reporting (TLS-RPT) is a standard that enables reporting issues in TLS connectivity experienced by applications that send emails and detect misconfigurations. It enables the reporting of email delivery issues that take place when an email isn’t encrypted with TLS. In September 2018, the standard was first documented in RFC 8460.
Why Do Your Emails Require Encryption in Transit?
The primary goal is to improve transport-level security during SMTP communication, ensuring the privacy of email traffic. Moreover, encryption of inbound messages addressed to your domain enhances information security, using cryptography to safeguard electronic information.
Furthermore, man-in-the-middle attacks (MITM) like SMTP Downgrade and DNS spoofing attacks, have been gaining popularity in recent times and have become a common practice among cybercriminals, which can be evaded by enforcing TLS encryption and extending support to secure protocols.
How Is a MITM Attack Launched?
Since encryption had to be retrofitted into SMTP protocol, the upgrade for encrypted delivery has to rely on a STARTTLS command. A MITM attacker can easily exploit this feature by performing an SMTP downgrade attack on the SMTP connection by tampering with the upgrade command by replacing or deleting it, forcing the client to fall back to sending the email in plaintext.
After intercepting the communication a MITM attacker can easily steal the decrypted information and access the content of the email. This is because SMTP being the industry standard for mail transfer uses opportunistic encryption, which implies that encryption is optional and emails can still be delivered in cleartext.
MITM attacks can also be launched in the form of a DNS Spoofing Attack:
As DNS is an unencrypted system, a cybercriminal can replace the MX records in the DNS query response with a mail server that they have access to and are in control of, thereby easily diverting the DNS traffic flowing through the network.
The mail transfer agent, in that case, delivers the email to the server of the attacker, enabling him to access and tamper with the email content. The email can be subsequently forwarded to the intended recipient’s server without being detected.
When you deploy MTA-STS, the MX addresses are fetched over DNS and compared to those found in the MTA-STS policy file, which is served over an HTTPS secured connection, thereby mitigating DNS spoofing attacks.
Apart from enhancing information security and mitigating pervasive monitoring attacks, encrypting messages in transit also solves multiple SMTP security problems.
Achieving Enforced TLS Encryption of Emails with MTA-STS
If you fail to transport your emails over a secure connection, your data could be compromised or even modified and tampered with by a cyber attacker.
Here is where MTA-STS steps in and fixes this issue, enabling safe transit for your emails as well as successfully mitigating cryptographic attacks and enhancing information security by enforcing TLS encryption.
Simply put,MTA-STS enforces the transfer of emails over a TLS encrypted pathway. In case an encrypted connection cannot be established, the email is not delivered at all, instead of being delivered in cleartext.
Furthermore, MTAs fetch and store MTA-STS policy files, which securely serve the MX addresses making it more difficult for attackers to launch a DNS spoofing attack.
MTA-STS offers protection against :
- Downgrade attacks
- Man-In-The-Middle (MITM) attacks
- It solves multiple SMTP security problems, including expired TLS certificates and lack of support for secure protocols.
- DNS Spoofing attacks
Major mail service providers, such as Microsoft, Oath, and Google, support MTA-STS. Google, being the largest industry player, attains center-stage when adopting any protocol, and the adoption of MTA-STS by google indicates the extension of support towards secure protocols and highlights the importance of email encryption in transit.
Troubleshooting Issues in Email Delivery with TLS-RPT
SMTP TLS Reporting provides domain owners with diagnostic reports (in JSON file format) with elaborate details on emails addressed to your domain and are facing delivery issues, or couldn’t be delivered due to a downgrade attack or other issues, so that you can fix the problem proactively.
As soon as you enable TLS-RPT, acquiescent Mail Transfer Agents will begin sending diagnostic reports regarding email delivery issues between communicating servers to the designated email domain.
The reports are typically sent once a day, covering and conveying the MTA-STS policies observed by senders, traffic statistics as well as information on failure or issues in email delivery.
A newly discovered Android malware has been found to propagate itself through WhatsApp messages to other contacts in order to expand what appears to be an adware campaign.
“This malware spreads via victim’s WhatsApp by automatically replying to any received WhatsApp message notification with a link to [a] malicious Huawei Mobile app,” ESET researcher Lukas Stefanko said.
The link to the fake Huawei Mobile app, upon clicking, redirects users to a lookalike Google Play Store website.
Once installed, the wormable app prompts victims to grant it notification access, which is then abused to carry out the wormable attack.
Specifically, it leverages WhatApp’s quick reply feature — which is used to respond to incoming messages directly from the notifications — to send out a reply to a received message automatically.
Besides requesting permissions to read notifications, the app also requests intrusive access to run in the background as well as to draw over other apps, meaning the app can overlay any other application running on the device with its own window that can be used to steal credentials and additional sensitive information.
The functionality, according to Stefanko, is to trick users into falling for an adware or subscription scam.
Furthermore, in its current version, the malware code is capable of sending automatic replies only to WhatsApp contacts — a feature that could be potentially extended in a future update to other messaging apps that support Android’s quick reply functionality.
While the message is sent only once per hour to the same contact, the contents of the message and the link to the app are fetched from a remote server, raising the possibility that the malware could be used to distribute other malicious websites and apps.
Stefanko said the exact mechanism behind how it finds its way to the initial set of directly infected victims is not clear; however, it’s to be noted the wormable malware can potentially expand from a few devices to many others incredibly quickly.
If anything, the development once again underscores the need to stick to trusted sources to download third-party apps, verify if an app is indeed built by a genuine developer, and carefully scrutinize app permissions before installation.
But the fact the campaign cleverly banks on the trust associated with WhatsApp contacts implies even these countermeasures may not be enough.