ANY.RUN observes a growing trend of phishing kit infrastructure being hosted on legitimate cloud and CDN platforms, rather than on newly registered domains. These campaigns often target enterprise users specifically, creating a global threat to businesses. The shift createsserious visibility challenges for security teams, as trusted platforms and valid indicators shield malicious activity from detection. 

For a deeper dive, read on and see the breakdown of such cases, along with tips on what works and what doesn’t. 

Key Takeaways 

• Modern phishing campaigns increasingly rely on trusted cloud infrastructure, not disposable domains. 

• AiTM phishing kits dominate enterprise-targeted attacks. 

• Cloudflare, Microsoft Azure, Google Firebase, and AWS are frequently abused. 

• Traditional IOCs like IPs, TLS fingerprints, and certificates are becoming unreliable. 

• Continuous threat intelligence and behavioral analysis are critical for detection. 

Enterprises Under Fire: AITM kits and Cloudflare Abuse 

The most widespread and dangerous phishing campaigns today are powered by AiTM (Adversary-in-the-middle kits). These toolsets help unfold phishing attacks where threat actors become a proxy between the victim and a legitimate service. 

• Follow ANY.RUN’s team on X to get weekly updates on the most widespread phishing kits 

A typical phishkit attack starts with an email containing a link (including in the form of a QR code) leading to attackers’ infrastructure. Most campaigns also involve a CAPTCHA challenge and a string of redirects as a means to avoid detection by AVs and static systems.Advanced evasion leads to a high rate of missed attacks for organizations that suffer from data theft as a result of this. 

ANY.RUN’s Interactive Sandbox provides security teams with the capabilities to quickly detect phishkit attacks thanks to interactive analysis. In addition to static detection, the sandbox lets SOC analysts safely follow the entire attack chain in an isolated VM and go past all the evasion layers to reveal the final malicious credential theft page or payload. 

The result for businesses that have adopted ANY.RUN’s solutions in their infrastructure is a lower risk of a data breach and a more effective SOC team that can quickly identify phishing attempts with a high degree of certainty. 

The top three most active phishing kits remain stable quarter to quarter. The list features: 

• Tycoon2FA: Phishing-as-a-service (PhaaS) platform designed to bypass multi-factor authentication (MFA). 

• Sneaky2FA: Adversary-in-the-Middle (AiTM) threat used in Business Email Compromise (BCE) attacks. 

• EvilProxy: Reverse-proxy phishing kit, often used for account takeover attacks aimed at high-ranking executives. 

Mostly these campaigns are hosted behind Cloudflare CDN infrastructure. You can find live examples using Threat Intelligence Lookup with queries like these: 

threatName:”tycoon” AND destinationIpAsn:”cloudflarenet” 

Use TI Lookup to strengthen alert triage and proactive threat hunting: 

• Accelerate detection and response: Correlate alerts with real-time threat intelligence to reduce triage time and missed threats. 

• Improve threat visibility: Gain deeper insight into emerging malware and attack trends across industries. 

• Stay ahead of risk: Proactively monitor relevant threats with automated alerts and expert intelligence reports. 

Why Treat Actors Choose Cloudflare 

For threat actors, Cloudflare abuse offers critical advantages: 

• Complicated detection: Cloudflare operates as both a CDN and reverse proxy. The real origin server (often a VPS) gets hidden behind Cloudflare’s IP addresses. SOC analysts only see trusted Cloudflare ASN, valid HTTPS, and ordinary CDN traffic. The original IP can’t be scanned, blocked, or easily linked to other campaigns. 

• Resistance to blocking and takedowns: Cloudflare’s IPs are nearly impossible to block without significant disruption. If a malicious domain is taken down, threat actors can register a new own right away and hide it behind Cloudflare just the same, without changing the basic infrastructure. 

• Built-in anti-analysis techniques: Even in mass mailing cases, the CDN helps sustain the activity and lowers the risk of VPS’s takedown. It also provides easy-to-use anti-analysis and access control techniques, such as CAPTCHA, Turnstile, geo fencing, ASN and User-Agent filtering, and blocking of automated scanners and sandboxes. 

Because TLS termination happens at Cloudflare, SSL certificates and TLS session’s fingerprints like JA3S lose value as indicators for SOC analysts. IP- and TLS-based detection becomes inefficient, and the only remaining leads for analysts are domains and their reputation. 

Implications and Recommendations for Decison-Makers 

• Attackers increasingly rely on trusted platforms to evade detection, reflecting cloud-based phishing growth to a mainstream technique. 

• In many cases, there’s a clear intent to target large companies specifically. 

• Traditional detection methods and static IOCs aren’t sufficient for a strong defense strategy. 

• Effective detection requires non-stop monitoring of phishing campaigns, as well as constantly updated signature databases. 

Interactive sandboxing combined with threat intelligence solutions enable analysts to uncover evasive phishing threats and helps achieve: 

• Early warning through global intelligence: Learn from real-world incidents across industries to anticipate threats before they reach your organization. 

• Faster, more confident triage: Enrich alerts with proven historical evidence to reduce false positives and unnecessary escalations. 

• Deeper visibility into real threats: Observe malicious behavior as it unfolds to uncover evasive techniques that static analysis often misses. 

• Operational efficiency at scale: Eliminate manual correlation across multiple sources and streamline investigations within a single workflow. 

• Stronger SOC performance: Support analysts at all levels while accelerating the full security operations lifecycle, from detection to response. 

Modern Phishing: No Longer Seen by the Naked Eye 

Until recently, a typical phishing attack looked like this: 

View analysis 

As shown above, the login form is hosted on a newly registered domain, not legitimate Microsoft 365 one (e.g., windows[.]net, microsoftonline[.]com, office[.]net, or live[.]com). This clearly indicates phishing. 

But modern phishing threats are significantly more complex and therefore dangerous. In many cases, even the domain name stops being a reliable IOC. That’s what can be observed in this sample: 

View analysis 

In this analysis, login form is hosted on legitimate Microsoft Azure Blob Storage, complicating the chance of detection. This sample belongs to Tycoon2FA, which we’ve discussed in detail in this article. 

In the POST request below, the victim’s encrypted password is transmitted from Microsoft Azure page to an attacker-controlled server: 

The response from a malicious reserve proxy returns a “wrong password” message, mimicking Microsoft’s legitimate authentication flow. 

Trends: Rapid Growth of Cloud-Hosted Threats 

At the time of writing, it’s been a week the previous publication of these findings. Since then, the amount of similar phishing cases has nearly doubled. 

You can find examples of this trend on TI Lookup: 

threatName:”tycoon” AND domainName:”*.blob.core.windows.net” 

On average, SOC teams from the US and Europe encounter Tycoon-based phishing abusing trusted Microsoft infrastructure multiple times a day, indicating a growing rise in their activity.  

Sneaky2FA Targeting Enterprises 

Similar behavior is observed in Sneaky2FA campaigns, commonly hosted at Google Firebase Storage: 

View analysis 

As well as at AWS CloudFront: 

View analysis 

What differentiates Sneaky2FA from Tycoon2FA is its focus on large companies, not mass campaigns. The kit excludes free personal email addresses hosted on gmail.com, yahoo.com, and outlook.com, focusing only on corporate emails.  

EvilProxy: Different Threat, Same Method 

In addition to Tycoon2FA and Sneaky2FA, EvilProxy also demonstrates similar abuse of trusted cloud platforms: 

View analysis 

The underlying strategy is similar and involves hiding malicious activity behind legitimate infrastructure. 

Cephas: Beyond Mainstream 

Another example of a Microsoft 365 phishing abusing a trusted cloud infrastructure was found among less common phishkits, such as Cephas.  

View analysis 

This confirms the trend, which solidifies cloud platform abuse as a standard technique, not a one-off case. 

To find more phishing domains based on Microsoft Azure, use the following TI Lookup query: 

threatName:”phishing” AND domainName:”*blob.core.windows.net” 

Phishing hosted on trusted cloud infrastructure is becoming increasingly widespread. The risk for large organizations grows daily, and detecting this type of attacks at early stages is made possible through continuous monitoring of phishing campaigns.  

ANY.RUN provides this visibility by delivering continuous signature updates and empowering SOC teams in 195 countries to detect sophisticated phishing threats for maximum business protection. 

About ANY.RUN 

ANY.RUN develops advanced solutions for malware analysis and threat hunting, trusted by 600,000+ cybersecurity professionals worldwide. 

Its interactive malware analysis sandbox enables hands-on investigation of threats targeting Windows, Linux, and Android environments. ANY.RUN’s Threat Intelligence Lookup and Threat Intelligence Feeds help security teams quickly identify indicators of compromise, enrich alerts with context, and investigate incidents early. Together, the solutions empowers analysts to strengthen overall security posture at enterprises.  

Request ANY.RUN access for your company  

Frequently Asked Questions (FAQ) 

The post Enterprise Phishing: How Attackers Abuse Microsoft & Google Platforms  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Not every cybersecurity practitioner thinks it’s worth the effort to figure out exactly who’s pulling the strings behind the malware hitting their company. The typical incident investigation algorithm goes something like this: analyst finds a suspicious file → if the antivirus didn’t catch it, puts it into a sandbox to test → confirms some malicious activity → adds the hash to the blocklist → goes for coffee break. These are the go-to steps for many cybersecurity professionals — especially when they’re swamped with alerts, or don’t quite have the forensic skills to unravel a complex attack thread by thread. However, when dealing with a targeted attack, this approach is a one-way ticket to disaster — and here’s why.

If an attacker is playing for keeps, they rarely stick to a single attack vector. There’s a good chance the malicious file has already played its part in a multi-stage attack and is now all but useless to the attacker. Meanwhile, the adversary has already dug deep into corporate infrastructure and is busy operating with an entirely different set of tools. To clear the threat for good, the security team has to uncover and neutralize the entire attack chain.

But how can this be done quickly and effectively before the attackers manage to do some real damage? One way is to dive deep into the context. By analyzing a single file, an expert can identify exactly who’s attacking his company, quickly find out which other tools and tactics that specific group employs, and then sweep infrastructure for any related threats. There are plenty of threat intelligence tools out there for this, but I’ll show you how it works using our Kaspersky Threat Intelligence Portal.

A practical example of why attribution matters

Let’s say we upload a piece of malware we’ve discovered to a threat intelligence portal, and learn that it’s usually being used by, say, the MysterySnail group. What does that actually tell us? Let’s look at the available intel:

First off, these attackers target government institutions in both Russia and Mongolia. They’re a Chinese-speaking group that typically focuses on espionage. According to their profile, they establish a foothold in infrastructure and lay low until they find something worth stealing. We also know that they typically exploit the vulnerability CVE-2021-40449. What kind of vulnerability is that?

As we can see, it’s a privilege escalation vulnerability — meaning it’s used after hackers have already infiltrated the infrastructure. This vulnerability has a high severity rating and is heavily exploited in the wild. So what software is actually vulnerable?

Got it: Microsoft Windows. Time to double-check if the patch that fixes this hole has actually been installed. Alright, besides the vulnerability, what else do we know about the hackers? It turns out they have a peculiar way of checking network configurations — they connect to the public site 2ip.ru:

So it makes sense to add a correlation rule to SIEM to flag that kind of behavior.

Now’s the time to read up on this group in more detail and gather additional indicators of compromise (IoCs) for SIEM monitoring, as well as ready-to-use YARA rules (structured text descriptions used to identify malware). This will help us track down all the tentacles of this kraken that might have already crept into corporate infrastructure, and ensure we can intercept them quickly if they try to break in again.

Kaspersky Threat Intelligence Portal provides a ton of additional reports on MysterySnail attacks, each complete with a list of IoCs and YARA rules. These YARA rules can be used to scan all endpoints, and those IoCs can be added into SIEM for constant monitoring. While we’re at it, let’s check the reports to see how these attackers handle data exfiltration, and what kind of data they’re usually hunting for. Now we can actually take steps to head off the attack.

And just like that, MysterySnail, the infrastructure is now tuned to find you and respond immediately. No more spying for you!

Malware attribution methods

Before diving into specific methods, we need to make one thing clear: for attribution to actually work, the threat intelligence provided needs a massive knowledge base of the tactics, techniques, and procedures (TTPs) used by threat actors. The scope and quality of these databases can vary wildly among vendors. In our case, before even building our tool, we spent years tracking known groups across various campaigns and logging their TTPs, and we continue to actively update that database today.

With a TTP database in place, the following attribution methods can be implemented:

1. Dynamic attribution: identifying TTPs through the dynamic analysis of specific files, then cross-referencing that set of TTPs against those of known hacking groups
2. Technical attribution: finding code overlaps between specific files and code fragments known to be used by specific hacking groups in their malware

Dynamic attribution

Identifying TTPs during dynamic analysis is relatively straightforward to implement; in fact, this functionality has been a staple of every modern sandbox for a long time. Naturally, all of our sandboxes also identify TTPs during the dynamic analysis of a malware sample:

The core of this method lies in categorizing malware activity using the MITRE ATT&CK framework. A sandbox report typically contains a list of detected TTPs. While this is highly useful data, it’s not enough for full-blown attribution to a specific group. Trying to identify the perpetrators of an attack using just this method is a lot like the ancient Indian parable of the blind men and the elephant: blindfolded folks touch different parts of an elephant and try to deduce what’s in front of them from just that. The one touching the trunk thinks it’s a python; the one touching the side is sure it’s a wall, and so on.

Technical attribution

The second attribution method is handled via static code analysis (though keep in mind that this type of attribution is always problematic). The core idea here is to cluster even slightly overlapping malware files based on specific unique characteristics. Before analysis can begin, the malware sample must be disassembled. The problem is that alongside the informative and useful bits, the recovered code contains a lot of noise. If the attribution algorithm takes this non-informative junk into account, any malware sample will end up looking similar to a great number of legitimate files, making quality attribution impossible. On the flip side, trying to only attribute malware based on the useful fragments but using a mathematically primitive method will only cause the false positive rate to go through the roof. Furthermore, any attribution result must be cross-checked for similarities with legitimate files — and the quality of that check usually depends heavily on the vendor’s technical capabilities.

Kaspersky’s approach to attribution

Our products leverage a unique database of malware associated with specific hacking groups, built over more than 25 years. On top of that, we use a patented attribution algorithm based on static analysis of disassembled code. This allows us to determine — with high precision, and even a specific probability percentage — how similar an analyzed file is to known samples from a particular group. This way, we can form a well-grounded verdict attributing the malware to a specific threat actor. The results are then cross-referenced against a database of billions of legitimate files to filter out false positives; if a match is found with any of them, the attribution verdict is adjusted accordingly. This approach is the backbone of the Kaspersky Threat Attribution Engine, which powers the threat attribution service on the Kaspersky Threat Intelligence Portal.

Kaspersky official blog – ​Read More

A significant number of modern incidents begin with account compromise. Since initial access brokers have become a full-fledged criminal industry, it’s become much easier for attackers to organize attacks on companies’ infrastructure by simply purchasing sets of employee passwords and logins. The widespread practice of using various remote access methods has made their task even easier. At the same time, the initial stages of such attacks often look like completely legitimate employee actions, and remain undetected by traditional security mechanisms for a long time.

Relying solely on account protection measures and password policies isn’t an option. There’s always a chance that attackers will get hold of employees’ credentials using various phishing attacks, infostealer malware, or simply through the carelessness of employees who reuse the same password for work and personal accounts and don’t pay much attention to leaks on third-party services.

As a result, to detect attacks on a company’s infrastructure, you need tools that can detect not only individual threat signatures, but also behavioral analysis systems that can detect deviations from normal user and system processes.

Using AI in SIEM to detect account compromise

As we mentioned in our previous post, to detect attacks involving account compromise, we equipped our Kaspersky Unified Monitoring and Analysis Platform SIEM system with a set of UEBA rules designed to detect anomalies in authentication processes, network activity, and the execution of processes on Windows-based workstations and servers. In the latest update, we continued to develop the system in the same direction, adding the use of AI approaches.

The system creates a model of normal user behavior during authentication, and tracks deviations from usual scenarios: atypical login times, unusual event chains, and anomalous access attempts. This approach allows SIEM to detect both authentication attempts with stolen credentials, and the use of already compromised accounts, including complex scenarios that may have gone unnoticed in the past.

Instead of searching for individual indicators, the system analyzes deviations from normal patterns. This allows for earlier detection of complex attacks while reducing the number of false positives, and significantly reduces the operational load on SOC teams.

Previously, when using UEBA rules to detect anomalies, it was necessary to create several rules that performed preliminary work and generated additional lists in which intermediate data was stored. Now, in the new version of SIEM with a new correlator, it’s possible to detect account hijacking using a single specialized rule.

Other updates in the Kaspersky Unified Monitoring and Analysis Platform

The more complex the infrastructure and the greater the volume of events, the more critical the requirements for platform performance, access management flexibility, and ease of daily operation become. A modern SIEM system must not only accurately detect threats, but also remain “resilient” without the need to constantly upgrade equipment and rebuild processes. Therefore, in version 4.2, we’ve taken another step toward making the platform more practical and adaptable. The updates affect the architecture, detection mechanisms, and user experience.

Addition of flexible roles and granular access control

One of the key innovations in the new version of SIEM is a flexible role model. Now customers can create their own roles for different system users, duplicate existing ones, and customize a set of access rights for the tasks of specific specialists. This allows for a more precise differentiation of responsibilities among SOC analysts, administrators, and managers, reduces the risk of excessive privileges, and better reflects the company’s internal processes in the SIEM settings.

New correlator and, as a result, increased platform stability

In release 4.2, we introduced a beta version of a new correlation engine (2.0). It processes events faster, and requires fewer hardware resources. For customers, this means:

• stable operation under high loads;
• the ability to process large amounts of data without the need for urgent infrastructure expansion;
• more predictable performance.

TTP coverage according to the MITRE ATT&CK matrix

We’re also systematically continuing to expand our coverage of the MITRE ATT&CK matrix of techniques, tactics, and procedures: today, Kaspersky SIEM covers more than 60% of the entire matrix. Detection rules are regularly updated and accompanied by response recommendations. This helps customers understand which attack scenarios are already under control, and plan their defense development based on a generally accepted industry model.

Other improvements

Version 4.2 also introduces the ability to back up and restore events, as well as export data to secure archives with integrity control, which is especially important for investigations, audits, and regulatory compliance. Background search queries have been implemented for the convenience of analysts. Now, complex and resource-intensive searches can be run in the background without affecting priority tasks. This speeds up the analysis of large data sets.

We continue to regularly update Kaspersky SIEM, expanding detection capabilities, improving architecture, and adding AI functionality so that the platform best meets the real-world conditions of information security teams, and helps not only to respond to incidents, but also to build a sustainable protection model for the future. Follow the updates to our SIEM system, the Kaspersky Unified Monitoring and Analysis Platform, on the official product page.

Kaspersky official blog – ​Read More