Phishing Incident Report: Facts and Timeline  – ANY.RUN’s Cybersecurity Blog

On June 21, we announced on our official X page that our company had been hit by a phishing attack.  

Today, we are providing the first results of our investigation into what happened. We want to share a full account of the events with our community and what we will be undertaking to strengthen our security.  

In this post, we will cover: 

• An incident overview 

• The timeline of the attack 

• Our response actions 

Let’s start with a summary of what happened. 

How We Discovered the Incident 

On the evening of June 18, 2024, all ANY.RUN staff members received a phishing email from an internal employee. The email was sent to the entire contact list of the said employee and led to a malicious page with a JS script masquerading as a Microsoft sign-in form. 

It soon became clear that an employee’s account had been compromised and was being used by an unauthorized entity to carry out a post-breach business email compromise (BEC) campaign. 

After implementing all necessary response measures, we promptly began our investigation into the incident. 

Incident Summary

The earliest signs of unusual account activity were discovered to date back to May 27, 2024, at 07:37:09 (UTC), when an unauthorized entity first logged into the compromised account from IP 45[.]61[.]169[.]4 (Sheridan, Wyoming, US).  

The investigation revealed that the initial compromise happened through an AiTM phishing and BEC campaign. The employee received an email with a phishing link from a client who had been compromised. Due to insufficient access controls and flaws in our multi-factor authentication (MFA) policies, an unauthorized entity was able to register their own mobile device for the compromised account in the MFA service and retain access. 

Over the next 23 days, the unauthorized entity repeatedly accessed the compromised employee’s mailbox. We also discovered that they used PerfectData Software, an application that enabled them to potentially take a backup of the entire mailbox. 

Here is a detailed timeline of the incident. 

Incident Timeline 

Initial Compromise 

May 23, 2024 

One of our sales team employees received an email via a third-party service from a client with whom they had previous communication. The email contained a link. 

May 27, 2024, 07:37 

The employee took the precaution of uploading the email to the sandbox to check whether the link it contained posed any threat. 

The link in the email led to a trusted but compromised website with a fake login form. However, the employee’s sandbox environment was not set up in MITM proxy mode, which would allow decryption of HTTPS traffic. This prevented Suricata IDS from detecting the malicious content and tagging the website as malicious. 

Acting without proper consideration for consequences, the employee entered their actual login credentials and MFA in the login form on the fake page right inside the sandbox environment.

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

They then replied to the client that they could not access the content sent.

At this point, the threat actor gained access to the employee’s account for the first time. 

Persistence 

May 27, 2024, 08:22 

The attacker was able to add their own mobile device to the MFA service for the compromised account, allowing them to maintain access.

Data Access & Exfiltration

June 5, 2024 

The attacker installed the PerfectData Software application (Azure App ID: ff8d92dc-3d82-41d6-bcbd-b9174d163620) and used it to steal the contents of the compromised email account. 

Phishing Attack

June 18, 2024, 17:16 

The attacker sent out emails that were similar to the original one to the entire contact list of the employee. 

These links had been already present in our Threat Intelligence database for over a week. However, they were identified during sandbox analysis sessions conducted by free users. These users lacked access to the most recent operating system version and the MITM proxy, tools that could have made it possible to recognize these domains as harmful in advance. 

Our Response Actions 

Revocation of Access 

• Identification of Compromised Accounts/Systems: Using Azure audit and sign-in logs suspicious activities were confirmed. 

• Timeframe: Unauthorized activities were detected on June 18, 2024, 17:18:00. Access was terminated by June 18, 2024, 17:21:55. 

• Method of Revocation: Compromised and affected accounts were disabled. Additionally, compromised and affected accounts credentials were reset and active sessions revoked. 

• Impact: Immediate revocation of access halted potential lateral movement, preventing further unauthorized activities and data exfiltration attempts. 

Containment Strategy 

• Short-term Containment: As part of the initial response, additional accounts activity monitoring was conducted, hindering any lateral movement by the threat actor. 

• Long-term Containment: The next phase of containment involves a more robust implementation of access controls, more restrictive MFA and conditional access policies and continuous access evaluation, ensuring that only compliant and trusted devices are allowed by access policies. 

• Effectiveness: The containment strategies were deemed successful in limiting the incident’s impact, but not in detecting or preventing similar incidents from happening again in the future. 

Eradication Measures 

Persistence artifacts removal: 

• Identification: During the investigation following artifacts were observed to be confirmed or potential persistence techniques: 
  • Adversary controlled MFA devices (T1098.005) 
  • PERFECTDATA SOFTWARE application 
  • Outlook Rules (T1137.005) 

• Removal Techniques: All identified artifacts were manually removed. 

• Verification: Post-removal, no unauthorized activity was observed or detected. 

Recovery Steps 

No data or system integrity was affected, so no recovery processes were initiated. 

We also requested a report from the company that was the source of the phishing attack but did not receive a response from them. 

Indicators of Compromise 

IP addresses 

8 different IP addresses, listed below, were used to access the compromised account over 23 days. 

• 45.61[.]169[.]4 (Sheridan, Wyoming, US) 

• 40.83[.]133[.]199 (San Jose, California, US) 

• 172.210[.]145[.]129 (Boydton, Virginia, US) 

• 162.244[.]210[.]90 (Dallas, Texas, US) – the main VPS used in the attack, which was taken down on our request. 

• 52.162[.]121[.]170 (Chicago, Illinois, US) 

• 68.154[.]52[.]201 (Boydton, Virginia, US) 

• 140.228[.]29[.]111 (Ada, Ohio, US) 

• 52.170[.]144[.]110 (Washington, Virginia, US) 

URLs 

• https://www.dropbox[.]com/scl/fi/vimfxi3mq0fch1u232uvp/Here-is-your-incoming-voice-mail-information_.paper?rlkey=69qgqvpkxn3mdvydkr8cgcd83&dl=0 

• https://batimnmlp[.]click/m/?cmFuZDE9Yldwa2IyRmFZa3hDVWc9PSZzdj1vMzY1XzNfbm9tJnJhbmQyPVJsQjJXbWRPZFZsTE1BPT0mdWlkPVVTRVIyMDA1MjAyNFVOSVFVRTA2MjQwNTIwMjQyMDI0MjAyNDA1MjAyNDA2MjQmcmFuZDM9UlRGWGFUSlNkVFJ0ZWc9PQ==N0123N[EMail] 

• https://www.reytorogroup[.]com/r/?cmFuZDE9YXpkcVJIbHpZa0kwVVE9PSZzdj1vMzY1XzNfbm9tJnJhbmQyPVVIb3libFEyWjA5NFNBPT0mdWlkPVVTRVIyMDA1MjAyNFVOSVFVRTA2MjQwNTIwMjQyMDI0MjAyNDA1MjAyNDA2MjQmcmFuZDM9VEdscFdFSTNVVzlzZFE9PQ==N0123N%5bEMail%5d 

• https://threemanshop[.]com/jsnom.js 

The Investigation Is Ongoing 

We’ve decided to disclose this incident to the community to show our dedication to stopping such events in the future. 

Our next step is to analyze the phishing sample and share our comprehensive findings with you. 

This situation will be used as an opportunity to make our security stronger and improve our products for everyone’s benefit.