Analysis of the Phishing Campaign: Behind the Incident – ANY.RUN’s Cybersecurity Blog

In this post we detail our comprehensive investigation into the phishing campaign encountered by our company. Our aim is to help others better understand this ongoing threat and take steps to protect themselves.

Here are some key findings: 

• We found around 72 phishing domains pretending to be real or fake companies. These domains created believable websites that tricked people into sharing their login details. 

• The attack was sophisticated, using advanced techniques like direct human interaction to deceive targets. 

• We analyzed several fake websites and reverse-engineered their web-facing application. 

• At the end of the post, you will find a list of IOCs that can be used for improving your organization’s security. 

Now, let’s examine the campaign in detail, starting with the attack chain. 

Attack Chain 

The attack involved four main stages: 

1. Our client’s account compromise. 

2. Phishing email sent from the breached client to our employee. 

3. Credential theft of our employee using a fake website. 

4. Distribution of phishing emails from the compromised account to its contact list. 

We will explore each step of the attack and the methods used. 

Incoming Phishing Email from a Client 

On May 27, 2024, while checking the inbox as part of their regular routine, one of our employees came across an email from an existing client. The message appeared as follows: 

In this email, the attacker posing as our client asks our employee to listen to a voice message, whose transcript is unavailable. The link to the recording is provided at the top of the email. 

From a phishing perspective, the email is expertly crafted to establish trust through several elements: 

• The email originates from a domain familiar to the recipient. 

• The sender’s full name, phone number, and contact details are provided. 

• The sender’s job title aligns with the overall message purpose. 

• The email is professionally written, with minimal grammatical errors and a non-pushy tone. 

• Information about the audio message, its duration, and the previous day’s send date imply the urgency to listen to it promptly. 

• The company values serve as a fitting conclusion to the email. 

The email appears to be carefully designed, but there are two suspicious things to note: 

• The most obvious one is an external link leading to another website, hidden behind the “Play voice mail here” text. While sharing links isn’t unusual, it’s still something to be cautious about. 

• The second thing is harder to spot. The email came from an account that had never contacted our colleague before. However, this isn’t uncommon when dealing with multiple departments in a client’s company, who have different responsibilities. 

After considering all the aspects of the email, our colleague made the right decision – to upload the email to the sandbox and proceed with further actions in an isolated and secure environment. 

Phishing Website 

Upon uploading the email to the sandbox and following the link, our colleague landed on a Microsoft login page. At this point, things became less straightforward than they were in the email. 

The key factors that made it appear trustworthy for the employee included: 

• A valid active certificate and no browser warning about visiting a known phishing domain. 

• A Microsoft login page which visually seems legitimate and indistinguishable from the real one. 

• At that moment, the sandbox did not alert the employee that they were opening a phishing site (This prompted us to rethink our service design and add proper mechanisms for addressing this to the roadmap). 

On top of that, since the employee was attempting to access the audio message from an external location rather than their own computer, where they were already logged in to Microsoft services, it seemed natural to go through the login process again. 

NOTE: Real credentials should never be used in a malware sandbox or any similar setting.    

URL Inconsistency 

Yet, the first significant mistake was made here – not enough attention was paid to the URL in the browser’s address bar. Despite appearing “legitimate,” it has no connection to the email sender, Microsoft services, or our company’s infrastructure. 

Upon closer examination, if we navigate to the domain’s main page, we find a WordPress site created using a template: 

With the help of WayBack Machine, a digital archive of websites, we can see that the website has been updated only once, which should prompt vigilance: 

Plus, the site’s blog contains articles about code debugging techniques that are unrelated to the site’s primary theme – clothing production: 

It’s worth noting that the site’s color scheme resembles the client’s web page design. 

Interestingly, a search on Google brought up a post by the website creator: 

Although we cannot definitively say at this moment whether this website was purposefully created for phishing or compromised, the likelihood of the former is high. 

2FA Completion 

From here, everything proceeded as in a typical service authentication process. The employee entered their login and password, making the second mistake – completing the two-factor authentication by entering the secret code from the authenticator app: 

Here, it’s essential to note that two-factor authentication did not protect against this proxy-style phishing attack. All entered data was sent to the attacker’s server, where the actual authentication took place, rather than in the secure sandbox environment. 

After completing the authentication, the employee was redirected to the Outlook website with a message stating “something went wrong.” Thinking that something indeed went wrong (remember, the audio transcript was unavailable – confirming that something was actually broken), the employee decided to leave it be. 

The employee emailed the client, stating that they were unable to listen to the audio and requested that the voice message be resent in text form. 

Outgoing Phishing Emails 

On June 18, 2024, emails were sent from the compromised employee’s account to both staff members and clients on their contact list: 

As shown in the screenshot above, the outgoing email’s quality is significantly inferior to the initial one. 

Several details stand out, pointing to the phishing nature of the email: 

• Numerous spelling, grammar, and logical errors, such as the name “Randy” being written in lowercase, the missing verb “is,” etc. 

• The email is not addressed to a specific recipient and was identical for each receiver. 

• The signature in the email does not match the name of the audio message sender. 

• The company name Delaware does not correspond to the company mentioned in the signature. 

• Sloppy formatting and inconsistent fonts. 

The link provided in the email leads to the Dropbox file-sharing service, which also should raise suspicion. 

Note-Taking Dropbox Paper App  

As is often the case, publicly accessible file and note-sharing services are frequently exploited for criminal purposes by malicious actors. 

In our example, the attacker created a note claiming that the user who opened the link allegedly had a voice message that they needed to listen to by following the link: 

As seen in the screenshots above, the note was created separately from the sent emails, as the sender’s name and company name differ from those mentioned in the email. 

Double-clicking the note reveals information about the authors – Rick and Christina, whom we have not encountered before. 

Plus, Dropbox has a feature that, if the user is logged in, allows seeing all previous document viewers: 

Upon clicking the link provided in the note, the user is directed to a phishing site with a Microsoft login page that strongly resembles the one seen previously, except for the domain name: 

From here, everything proceeds as it did with the first email – the user is asked to enter their credentials, which are then sent to the attacker’s server, where the actual authentication takes place.

Technical Analysis 

In this section, we will focus on analyzing the phishing site used by the attacker. 

URL Analysis 

Let’s start by analyzing the URL that led our colleague to the phishing page. It appeared as follows: 

hxxps://www[.]reytorogroup[.]com/r/?<BASE64>N0123N%5bEMail%5d 

The parameterized part of the URL request consists of three parts: 

1. <Base64> – Encoded parameters; 

2. N0123N – Separator of encoded parameters and email; 

3. %5bEMail%5d – Victums email address, in case of a targeted attack. 

CyberChef helps us decode Base64: 

Decoding the Base64 part of the URI reveals several parameters: 

UID is a composite identifier that is generated during the link creation stage and used for identifying stolen data via web socket. The structure of the parameter is as follows: 

SV is a composite parameter that determines the design style of the phishing page. The right-hand side of the parameter takes one of the values listed in the table below: 

Our investigation revealed that this type of URL address is being used throughout the entire active phishing campaign. For example, in the link sent to our customers: 

hxxps://batimnmlp[.]click/m/?cmFu<REDACTED>GWGFUSlNkVFJ0ZWc9PQ==N0123N[EMail] 

Page Behavior Analysis 

Unfortunately, we do not have a decrypted version of the traffic for the original page that was used to gain initial access to our colleague’s account (it is currently inactive). 

Yet, since the phishing campaign is still active, we will use a similar fresh link from another session for analysis. 

The First Stage 

The process begins with the identification of the user, for which the web server returns a fingerprint script when the malicious URL is initially loaded: 

The script gathers information about the user’s environment, including screen properties, window properties, navigator properties, location, console, document attributes, timezone offset, WebGL information, and more. 

The script then exfiltrates the gathered information by submitting it via a hidden form using a POST request to the same URL. An example of the submitted data is shown in the screenshot below: 

The Second Stage 

The second stage involves the attacker’s server returning a new page with heavily obfuscated JavaScript in response to the client’s POST request: 

Interestingly, the “html” tag of the page contains additional information about the location of the WebSocket for connecting in the “point” attribute (base64 decoded: https://2moniunesson[.]com). A complete list of the WebSocket servers we have collected can be found in Appendix 2. 

The page also contains the identifier “USER09062024UNIQUE0456060914202420240609560414” (which we analyzed earlier) in the “sti” attribute. The “vic” attribute contains the victim’s email address from the URL in the case of a targeted attack. 

The first part of the script can be easily deobfuscated in two consecutive steps using the services hxxps://deobfuscate[.]io and hxxps://obf-io.deobfuscate[.]io: 

As a result, we obtain a script that loads the “socket.io” library.  

The second part of the script can be “fed” to ChatGPT, which will explain that the script “jsnom.js” is embedded and executed in the page: 

Analysis of the main phishing script 

The script “jsnom.js” contains the main logic of the phishing page. It is also obfuscated, but after applying the same deobfuscation services and further processing with GPT, we get absolutely clean and ready-to-analyze code: 

Script Logic 

Next, we will analyze the logic of the script that dynamically updates the appearance of the site depending on its state. 

First, the script embeds a new style into the <head> block and adds content and forms to the <body> block. The page starts looking similar to the Microsoft authentication service. 

Second, after the user enters their email, the script checks its validity using a regular expression. The domain part is checked against a blacklist that includes about 15 addresses. If the domain is found in the blacklist, then after a 1-second delay, an error message is displayed: 

If the email passes all checks, then a connection is established with the web socket and the entered information is sent to the server. The user is shown a progress bar for processing the request. 

If the server-side verification is successful, the server responds with a similar JSON, but with the addition of “socketId” and the creation of “phish_groupid”. The user is then prompted to enter their account password. 

The server additionally sends a JSON containing the background image of the web page (backgroundImage) that needs to be set, the name of the authentication stage (phish_state), and the address of the page (endUrl) to which the user needs to be redirected after the completion of the authentication data collection: 

When the user enters their password, it is also sent to the server for remote authentication: 

Communication with the server ends with receiving information via web-socket about the successful interception of the session: 

Analysis Results 

Analysis of the code revealed that in addition to intercepting the login and password, there is also the possibility of passing two-factor authentication, where the server will ask for a one-time code.  

In this case, the client will actually authenticate on the attacker’s server, rather than on their own host machine. In this situation, two-factor authentication does not prevent the account from being hijacked. 

Is this an updated “Greatness phishkit”? 

Based on the structure of the WebSocket request and the analyzed scripts, we might assume that the current phishing kit was stored on the Greatness infrastructure (Cloudflare Public R2.dev Bucket), but in an updated variant. 

This is confirmed by the correlation of the page content with the attributes of the “html” tag: 

It is also indirectly confirmed by the structure of the GET request using the keywords “USER” and “UNIQUE”: 

Threat Landscape Expansion and Further Analysis 

During our investigation, we discovered many lures, including Word documents, PDFs, HTML pages, that lead users into a trap. 

We have compiled a list of 72 domains (see Appendix 2) that are suspected to be attacker domains, as well as a list of web-socket servers. This list is constantly being updated, indicating that the phishing campaign is still active. 

If you need to conduct your own research, you can submit a query to TI Lookup to search for sessions launched by users in our sandbox: 

CommandLine:"?cmFuZDE9" 

You can create a broader, hunting-search query that will significantly increase the amount of detected phishing instances using web-sockets. 

DomainName:"aadcdn.msftauth.net" and DomainName:"cdn.socket.io" 

To search for WebSocket servers, you can use third-party search services and the following example search string:

hash:52c1e7a2c36be28c42455fe1572d7d7918c3180cad99a2b82daa2a38a7e7bb23 AND page.domain:(/([0-9]{1,2}|one|two|three|four|five|six|seven|eight|nine|ten)[a-z]{3,9}-?[a-z]{3,9}.com/) 

Recommendations on Protecting Against Such Attacks 

Phishing may be an old tactic, but it remains a major threat to end user security. While there are many tips available online for protecting against phishing attacks, we would like to especially highlight these two: 

• Two-factor authentication is an essential, but insufficient method of protection, 

• It is necessary to check the URL when entering logins and passwords on any websites. 

We encourage you to reflect on our experiences and make better decisions when coming across suspicious content. 

As of now, we have a clear understanding of the attack timeline and the campaign behind it. Based on these findings, we will develop and share our next steps to make our security stronger and improve our products for everyone’s benefit. 

Appendix 1 – Lures Used in the Phishing Campaign 

View screenshots of lures in our GitHub repo: https://github.com/anyrun/blog-scripts/tree/main/IOC/Images  

Links to analysis sessions: 

Appendix 2 – Domains Used in the Phishing Campaign 

Phishing pages domains 

WebSocket C2 domain list