Attackers use Morse Code to Supplement Phishing Campaign

Microsoft’s ever-popular Office 365 has been a favored target for many hackers. This is partly due to the popular application enjoying widespread adoption in both the corporate and government spheres as employees use many of the bundled applications for daily work life and the ability to easily share documents. In the past, we have seen both ransomware campaigns and phishing actively target users of the product. Microsoft’s 365 Defender Threat Intelligence Team now warns of another phishing campaign using a novel, if somewhat dated, encryption method.

According to the article published by the security team, the attackers are leveraging morse code along with several other encryption techniques to obfuscate code and evade detection while the attackers harvest credentials.

Researchers noted,

“This phishing campaign exemplifies the modern email threat: sophisticated, evasive, and relentlessly evolving. The HTML attachment is divided into several segments, including the JavaScript files used to steal passwords, which are then encoded using various mechanisms. These attackers moved from using plaintext HTML code to employing multiple encoding techniques, including old and unusual encryption methods like Morse code, to hide these attack segments. Some of these code segments are not even present in the attachment itself. Instead, they reside in various open directories and are called by encoded scripts.”

Researchers have compared this attack campaign to a jigsaw puzzle. The code is separated into various segments, with each segment appearing harmless by itself.

It is only when the puzzle is completed the segments joined that threat posed by the code is uncovered. This was done so that the HTML code base can slip past some security solutions. The segments discovered by researchers include:

• Segment 1 – Email address of the target
• Segment 2 – Logo of the targeted user’s organization from logo[.]clearbit[.]com, i[.]gyazo[.]com, or api[.]statvoo[.]com; if the logo is not available, this segment loads the Microsoft Office 365 logo instead.
• Segment 3 – A script that loads an image of a blurred document, indicating that sign-in has supposedly timed out.
• Segment 4 – A script that prompts the user to enter their password, submits the entered password to a remote phishing kit and displays a fake page with an error message to the user.

The primary objective of the phishing campaign is to steal credentials, namely username and password combinations. However, in later iterations of the campaign, with attacks dating back to July 2020, attackers were also looking to steal IP addresses and locations. These are used to gain important information that can assist in future compromise attempts. Attackers will further look to steal company logos and associated names to make future phishing emails appear more authentic.

The primary hook and bait used by the attackers are generating fake emails that look like fake payment notices. The attachments were made to mimic popular file formats typically used by organizations when sending billing and payment information. This was typically the .xls format so that victims would expect some form of Excel file.

If the user clicks and downloads the attachment, they are presented with an Office 365 login screen. This is fake and is the credential harvester of the malware. The login screen also includes a notification saying that their session has been timed out and thus are required to log in again. Once the password is entered the user is told that it is the wrong password. This gives the phishing kit enough time to harvest the entered credentials. Researchers noted that,

“Email-based attacks continue to make novel attempts to bypass email security solutions. In the case of this phishing campaign, these attempts include using multilayer obfuscation and encryption mechanisms for known existing file types, such as JavaScript. Multilayer obfuscation in HTML can likewise evade browser security solutions.”

The Changing Attack Segment Encoding

The attack so far resembles many other phishing campaigns researchers across security firms see ad nauseum. What makes this phishing campaign different enough to warrant an investigation of the level of code encoding the attackers built-in to avoid detection.

As alluded to above the HTML is divided into separate sections with each being encoded differently. Segments 1 and 2 contain encoded information about a target user’s email address and organization. Not only do these details enhance a campaign’s social engineering lure, but they also suggest that the attackers have conducted prior recon on the target recipients.

The attackers have also been more than willing to change up encoding techniques to keep one step ahead of security technologies. Researchers analyzing the campaign have discovered ten separate and distinct iterations of the campaign since its discovery.

The first of which just used plaintext HTML. Essentially the bottom rung of any sneaky encoding. This was soon upgraded in the next iteration using Escape. It was not until August 2020 that the attackers really upgraded their encoding campaign.

This phase is characterized by the attackers removing the phishing kit from the HTML and hosting it on websites to be retrieved during infection. By November the segments containing the JavaScript hosted on third-party websites were encoded using two methods, first in Base64, then in ASCII.

By February of this year Morse code, a series of dots and dashes to represent characters, was added as another level of encoding on top of what had been done before. This was then again changed to use Escape then Morse code. The use of such a dated encoded method may be quaint according to some, given the levels of encoding available to attackers.

The last major update to the encoding routine was through the use of a “wrapper”. This is done by wrapping the HTML attachment in encoding. Researchers noted,

“For example, in the March 2021 wave (“Invoice”), the user mail ID was encoded in Base64. Meanwhile, the links to the JavaScript files were encoded in ASCII before encoding it again with the rest of the HTML code in Escape…This was seen again in the May 2021 iteration, as described previously. In the June 2021 wave, (“Outstanding clearance slip”), the link to the JavaScript file was encoded in ASCII while the domain name of the phishing kit URL was encoded in Escape. The entire HTML attachment was then encoded using Base64 first, then with a second level of obfuscation using Char coding (delimiter:Comma, Base:10).”

Microsoft researchers have provided several mitigation strategies to protect against this campaign and others. These involve,

• Turn on Safe Attachments policies to check attachments to inbound email. Enable Safe Links protection for users with zero-hour auto purge to remove emails when a URL gets weaponized post-delivery.
• Avoid password reuse between accounts and use multi-factor authentication (MFA), such as Windows Hello, internally on high-value systems. In addition, always enable MFA for privileged accounts and apply risk-based MFA for regular ones. Finally, require MFA for local device access, remote desktop protocol access/connections through VPN and Outlook Web Access.These steps limit the value of harvested credentials, as well as mitigate internal traversal after credential compromise and further brute-force attempts made by using credentials from infected hosts.
• Educate end users on consent phishing tactics as part of security or phishing awareness training. Training should include checks for poor spelling and grammar in phishing emails or the application’s consent screen, as well as spoofed app names and domain URLs, that are made to appear to come from legitimate applications or companies.

Lastly, researchers advise that if not already enabled Office 365 users enable mail flow rules or group policies that strip html or .htm or other file types that the business does not encounter in daily operations.

Further, Office 365 has the option to include anti spam policies that add allowed senders, domains, and IP addresses to the policy. This prevents unknown IP addresses, domains, and senders from sending information to the end user. This feature can be further improved by adding trusted organizations to the list.

▼ Show Discussion