Russian Phishing Email Analysis

Step-by-step analysis of three Russian phishing emails. This writeup is written over several days in my free time. You will see varying dates in tool output and screenshots. I am using a modified Flare-VM install for this analysis.

Russian Phishing Email Analysis
Suspect Email.

In this write up I'm analyzing artifacts that I received from a friend and colleague in cyber security. I've worked with them in the past and they are currently working as a SIEM/SOAR Content Engineer. We're both American, and they have no ties to Russia. Neither of us can figure out how they ended up on the mailing list for this campaign. These samples were sent with the explicit understanding that - aside from what you see here  - no personal or identifying information would be posted in this analysis.

They told me they received 3 emails to their personal Gmail account a few days apart that were obvious spam/fishing, and appeared to be in the Russian language. I was provided with the .eml files for each of them. Note that I've censored the "from" addresses, because at this point I don't know if the sending addresses are the actual attacker or victims who's emails have been compromised. I was also provided with the screenshots you see in the title card, as well as the one below.

This writeup is written over several days in my free time. You will see varying dates in tool output and screenshots. I am using a modified Flare-VM install for this analysis. If you want to try your hand at the analysis, the pdf files from the emails are available for download at the bottom of this post.

Screenshot of the suspect emails.

Initial Analysis

Examining the .eml files and extracting the attachments.

Opening the .eml files with notepad++ revealed some basic information. Each of them was sent from a Gmail email address, and each email was sent to multiple people. Two of them were sent to 7 email addresses and one to 11 email addresses. All of them were sent from different email addresses that do not appear in any of the "to" sections. In the image below, the black censored emails are unique, the yellow email is our reporter's email, and the blue emails are addresses that are held in common between the various emails.

Email to/from metadata from the three .eml files, censored. Color choices are not a coincidence.

All of the Top Level Domains (TLDs) for every email involved are your standard Gmail domain: Gmail[.]com. This initially leads me to two potential spreading techniques that may be in play. It's important to note that both of the following could be true, just one of them, or neither.

1. This is something that spreads by hijacking other victim's email accounts and then spreads using their contacts.

2. Each spam message is intentionally only sending to addresses that are in the same domain; regardless of how the "from" email account itself came to be.

When quickly examining the other email headers, nothing unusual is immediately obvious and each appears to be sent from a real Gmail address (even Gmail seems to think so per the original report I received). Each of the emails contains an attachment listed as a pdf file that appear rather similar initially, but are confirmed to be different after manually extracting the base64 for each one via notepad++.

File comparison for each of the attachments encoded in base64.

After using a quick certutil call via PowerShell to decode the files back into their original form, I have three likely malicious .pdf files. I gave them the same names that the email metadata had for each of them - and this is an important thing to do. Some malware samples use metadata about themselves during their execution, such as using their file name or file hash in as a or part of a decryption/encryption key.

Using certutil via PowerShell to decode the files.

I make a quick reorganization to split each piece of the extraction up into their respective parts of the initial analysis. I also give each file the name they had from the original .eml attachment metadata.

File organization.

Before I move on to actually analyzing the the .pdf files themselves, I put varying parts from the raw text content of each email into google translate to see if I can discover anything useful. Unfortunately, it was unable to make any sense of anything. Various words were detected as belonging to various languages but still nothing that made sense as one cohesive statement or meaning. The exact contents are below:

EMAIL: "0 EZW WF12 ONIR N12 TU B7 RUXG F83 V P.eml"

4 UFY8 PPWT
VS  Fupo Puvge Felytec Bitukisu ZykybiV  Pydino Bedukido Nukupuri Lycybodo
EMAIL: "8 FPA O71 UJSJ F.eml"

5 ZP82 XYFB17 TT21 A6 UHS
Y  Jyjolyhi Zecifity Xugo QykfoI  Dulifu Wyju Xidky VyhliA  Kugfu

EMAIL: "16 W T3 E VG28 SF UJ27 CWV RW.eml"

3 WOUVT1 V
G  Wegu Fuvolix HutyPN  Fucypepi Qusupyg

Static & Behavioral Analysis

Static and Behavioral analysis of each of the recovered .pdf attachments.

Beginning to look at the .pdf files themselves, I'm going to do two things:

  1. Verify that they are actually .pdf files by opening them in, once again, notepad++. This is a common tool so far in this writeup, because like .eml files, PDF files are actually rather easy to conduct basic static analysis on. The basic metadata and structure is largely human-readable. You can even find "quick-kills" by looking for obvious things like the "/OpenAction" call or javascript objects.
  2. Conduct a hash search for each on various open-source detection tools like Virus Total and Hybrid Analysis. NOTE: I am NOT uploading the artifacts, just searching each pdf's hash within the systems to see if they have been uploaded previously.

I'm able to quickly verify that each file appears to be valid .pdf files due to the "%PDF" magic values and pdf compliant architecture of the files. I also have additional information on how they were created with a software tag of "Synopse PDF engine 1.18.6228". Each file has similar indecipherable words/nonsense just as the emails do, however each also have a "CreationDate" tag that contains a value close to the respective email sent times from the .eml files.

Attached .pdf "producer" element tags.

Of the three files, only one has a hash-match online.  It is "0TKPbITb 25882.pdf". The hit is on Virus Total and at the time of writing it has absolutely no detection rating, 0 out of 59 anti-virus engines found this file to be malicious.  It was first submitted on May 4th, 2022 - five days prior to the me receiving the report and two days after the creation time listed in the file's metadata. Instead of going through this line-by-line (it's quite extensive) I'm going to just link to the virus total history so you can read it for yourself if interested.

With all three of the .pdf files open in notepad++, I begin to search for common tags used in exploits, such as "/OpenAction", "/JavaScript",  and "/Action", among others. The first one with any hits is "/URI. Each of the three files has a link to a different Google Docs document. Note that while it says there's two hits per file, it's the same line - it's hitting twice because the search item is repeated twice per line.

These may also provide an additional sliver of evidence to one of my hypothesis that these might spread in-part using compromised Gmail accounts. My reasoning: Later on in behavioral analysis if I may find that they each belong to the Gmail account that sent the respective phishing email containing the link. This is of course still just a hypothesis.

Hits for some google docs URIs.

Taking note of these to safely grab using a VPN when I get to behavioral analysis, I continue looking for other quick kills. Each of the files contains a varying number of named streams (found searching for "/Name"). Each name is randomized, and all are listed as either Images or Fonts, however almost all of these appear to be too small to actually be meaningful by themselves. The only one that is obviously a true image is the first object stream. Each doc has 28, 36, and 40 of them.

Named object streams.

One thing I did find however, is that there is a "/MediaBox" element tag that seems to reference many of these in each file, compiling them into larger objects. Each document has 5, 6, and 7 of them.

MediaBox elements that seem to be compiling many randomly-named object streams.

Rather than attempt to manually extract each of these streams, decode them, reassemble them, and try to ID them all statically I'm going to try some offline behavioral analysis before going down that rabbit hole. Before getting into this section, I have not observed thus-far from static analysis any reason to expect anything other than standard behavior from my tools.

First, I'm going to take a snapshot before shutting down the VM to remove it's NIC. After I restart it I will open each of the .pdfs with a few behavioral tools running. These tools include:

  1. Procmon from sysinternals to capture system events like file/registry read & write, additional threads created, other processes spawned, those additional thread/process's system events... etc. Typically the output is parsed by another tool known as ProcDot that visualizes these events to assist in human analysis.
  2. Fiddler, a program that tracks http(s) traffic in a very user-friendly way. It was originally intended for developers of web applications and was developed and distributed by Microsoft's web browser development team.
  3. Fakenet-NG is a program that will simulate a network connection and route traffic through it. It has the capability to respond to most of the common requests an application or malware will send including DNS queries, ftp connectins, and a variety of of http requests. It will also output pcap if all of the traffic just like Wireshark would.

There's no indication that these files contain executable code at this point in my analysis, so I'm not expecting much if any useful information from these tools.

First page of the .PDFs.

Each file's first page is identical, however each image has what appears to be a series of randomly changed pixels, likely to evade simple hash detection. Running the Russian text through Google Lens gives the following translation:

Successful Man

Stop working for pennies!

Our portal has collected the best methods for earnings. Actual schemes for residents of the Russian Federation and Kazakhstan.

Hurry up while there is confusion in the world.
Everything works remotely!
Follow the link below and see for yourself.

OPEN SITE

The various behavioral analysis tools showed no unusual activity when each file was opened with Adobe, as suspected from static analysis. The pdf does appear to just be a simple phishing attempt, with various methods to make it difficult to write effective basic email and host A/V signatures. The small and fonts compiled into various Media Boxes appear on additional pages. I can't identify any reason for them other than signature evasion.

Additional pages within the pdf have varying content like this.

At this point, I need to visit the google docs link to progress in the investigation. I revert back to a snapshot from before I removed the NIC (and opened the files) and switch to a commercial VPN, routing all connections through it. After I've done this, I click the links in each .pdf.

Each document has a separate link to google docs (the same ones discovered previously), however each link has the same document hosted by unknown accounts:

Google doc's document.

Once again translating with Google Lens:

Site security verified
by Google Protect

Go to the site

Once again, there was no unusual activity with this document. Just a plain phishing link with fake security.

Each document links to the exact same hxxp[:]//go[.]helloclick6[.]online/* path, and use Google's open redirect (hxxps[:]//www[.]google[.]com/url?q=). From what I can tell, this is just due to the basic behavior of Google docs.

Attempting to follow the link, Cloudflare presents a warning that the website has been reported as phishing. The warning screen has an option to dismiss and bypass it.

Cloudflare warning page.

I dismiss the warning and continue, however the webpage simply presents a 404 error. I checked the page source code to make sure it wasn't hiding some JavaScript, and it was clean.

This is a good point to put in a plug for a browser plugin called "NoScript".  This plugin will prevent the retrieval and execution of JavaScript without explicitly being allowed by the user - and you can pick and choose which sources to allow and which to deny. I don't use this in my malware reversing lab for a couple reasons, but I do everywhere else. It's not useful for basic users due to the need to review actual JavaScript and source URLs. However I highly recommend it for any IT worker who will bother taking the time to review and approve/block JavaScript.

404 error page source.

It seems I'm too late to the party to get the second stage. However, there's still more analysis to do. This domain may reveal some information, and if it is relatively unknown I may have to report it on common open source cyber security intel platforms.

Open Source Research

Attempting to find additional information without having a second stage payload.

Starting with a basic Whois lookup:

Domain Name: HELLOCLICK6.ONLINE
Registry Domain ID: D288314354-CNIC
Registrar WHOIS Server: whois.reg.ru
Registrar URL: https://www.reg.ru/
Updated Date: 2022-04-14T19:23:30.0Z
Creation Date: 2022-04-05T12:32:34.0Z
Registry Expiry Date: 2023-04-05T23:59:59.0Z
Registrar: Registrar of Domain Names REG.RU, LLC
Registrar IANA ID: 1606
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registrant Organization: Private Person
Registrant State/Province: Penzenskaya
Registrant Country: RU
Registrant Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Admin Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Tech Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Name Server: JOAQUIN.NS.CLOUDFLARE.COM
Name Server: KINSLEY.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Billing Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registrar Abuse Contact Email: email@reg.ru
Registrar Abuse Contact Phone: +7.4955801111
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2022-05-22T18:20:57.0Z <<<

The root domain was first registered on April 5th using a Russian registrar. The name servers in use are Cloudflare's, though I'm already aware it's using them due to the warning message. If I hadn't gotten that, this would be a good time note down that an abuse report should be sent to them following the conclusion of analysis. I will still send another report in despite them already having at least one, including this writeup with it - additional evidence and reports can't hurt.

Checking common tools and information repositories, Alien Vault has zero reports though it does tag the domain as suspicious. Noting here to also submit a report to Alien Vault.

Alien Vault information page.

It's a similar story over on Virus Total when searching the domain. I'll have to leave a community report here as well.

Virus Total results.

Hybrid Analysis appears to have a report on it and tags it as malicious, however it doesn't have much useful information. The report shows that it was returned a server 400 error, rather than a 404.

Any.run has a report, however it's pretty similar to Hybrid Analysis's.

The domain appears to be relatively unknown, with only a few results when using quotes - using quotes in a google search will make google only return results with an exact match. Each result is one of the tools already discussed.

Domain is relatively unknown.

Dropping the subdomain only adds one extra result that appears to have domains created listed by date.

Unrelated domain

Within the list, there's a few that jump out: helloclick6[.]online is present, as well as helloclick8[.]online, helloclick9[.]online. There's also hellosaturday9[.]com though it may simple be a coincidence.

Both of the helloclick domains have identical registration information to helloclick6.

Helloclick9:

Domain Name: HELLOCLICK9.ONLINE
Registry Domain ID: D288314359-CNIC
Registrar WHOIS Server: whois.reg.ru
Registrar URL: https://www.reg.ru/
Updated Date: 2022-04-14T19:23:30.0Z
Creation Date: 2022-04-05T12:32:36.0Z
Registry Expiry Date: 2023-04-05T23:59:59.0Z
Registrar: Registrar of Domain Names REG.RU, LLC
Registrar IANA ID: 1606
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registrant Organization: Private Person
Registrant State/Province: Penzenskaya
Registrant Country: RU
Registrant Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Admin Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Tech Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Name Server: JOAQUIN.NS.CLOUDFLARE.COM
Name Server: KINSLEY.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Billing Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registrar Abuse Contact Email: email@reg.ru
Registrar Abuse Contact Phone: +7.4955801111
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2022-05-22T19:02:35.0Z <<<

Helloclick8:

Domain Name: HELLOCLICK8.ONLINE
Registry Domain ID: D288314364-CNIC
Registrar WHOIS Server: whois.reg.ru
Registrar URL: https://www.reg.ru/
Updated Date: 2022-04-14T19:23:30.0Z
Creation Date: 2022-04-05T12:32:36.0Z
Registry Expiry Date: 2023-04-05T23:59:59.0Z
Registrar: Registrar of Domain Names REG.RU, LLC
Registrar IANA ID: 1606
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registrant Organization: Private Person
Registrant State/Province: Penzenskaya
Registrant Country: RU
Registrant Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Admin Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Tech Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Name Server: JOAQUIN.NS.CLOUDFLARE.COM
Name Server: KINSLEY.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Billing Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registrar Abuse Contact Email: email@reg.ru
Registrar Abuse Contact Phone: +7.4955801111
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2022-05-22T19:03:49.0Z <<<

Unfortunately, there's nothing more I can find on these domains I can find in open-source research, and there aren't any DNS records for them. The hellosaturday9[.]com address did not appear related based on basic Whois information.

End of the Road

Without anything else to go on and no executable artifacts recovered, I'm out of reasonable options to continue analysis. I could attempt some rather aggressive offensive-style enumeration against the one online domain like fuzzing and brute-forcing to look for additional subdomains and any other pages on the webserver, but there's no justification for that kind of action at this point. I can't even be sure that the next stage would actually be malware and not some other kind of scam.

I'll take what I have and file reports with the various OSINT tools I mentioned previously. I'll add links to these below for the publicly accessible ones:

AlienVault - Open Threat Exchange
Learn about the latest cyber threats. Research, collaborate, and share threat intelligence in real time. Protect yourself and the community against today’s emerging threats.