People entrust neural networks with their most important, even intimate, matters: verifying medical diagnoses, seeking love advice, or turning to AI instead of a psychotherapist. There are already known cases of suicide planning, real-world attacks, and other dangerous acts facilitated by LLMs. Consequently, private chats between humans and AI are drawing increasing attention from governments, corporations, and curious individuals.
So, there won’t be a shortage of people willing to implement the Whisper Leak attack in the wild. After all, it allows determining the general topic of a conversation with a neural network without interfering with the traffic in any way — simply by analyzing the timing patterns of sending and receiving encrypted data packets over the network to the AI server. However, you can still keep your chats private; more on this below…
How the Whisper Leak attack works
All language models generate their output progressively. To the user, this appears as if a person on the other end is typing word by word. In reality, however, language models operate not with individual characters or words, but with tokens — a kind of semantic unit for LLMs, and the AI response appears on screen as these tokens are generated. This output mode is known as “streaming”, and it turns out you can infer the topic of the conversation by measuring the stream’s characteristics. We’ve previously covered a research effort that managed to fairly accurately reconstruct the text of a chat with a bot by analyzing the length of each token it sent.
Researchers at Microsoft took this further by analyzing the response characteristics from 30 different AI models to 11,800 prompts. A hundred prompts were used: variations on the question, “Is money laundering legal?”, while the rest were random and covering entirely different topics.
By comparing the server response delay, packet size, and total packet count, the researchers were able to very accurately separate “dangerous” queries from “normal” ones. They also used neural networks for the analysis — though not LLMs. Depending on the model being studied, the accuracy of identifying “dangerous” topics ranged from 71% to 100%, with accuracy exceeding 97% for 19 out of the 30 models.
The researchers then conducted a more complex and realistic experiment. They tested a dataset of 10,000 random conversations, where only one focused on the chosen topic.
The results were more varied, but the simulated attack still proved quite successful. For models such as Deepseek-r1, Groq-llama-4, gpt-4o-mini, xai-grok-2 and -3, as well as Mistral-small and Mistral-large, researchers were able to detect the signal in the noise in 50% of their experiments with zero false-positives.
For Alibaba-Qwen2.5, Lambda-llama-3.1, gpt-4.1, gpt-o1-mini, Groq-llama-4, and Deepseek-v3-chat, the detection success rate dropped to 20% — though still without false positives. Meanwhile, for Gemini 2.5 pro, Anthropic-Claude-3-haiku, and gpt-4o-mini, the detection of “dangerous” chats on Microsoft’s servers was only successful in 5% of cases. The success rate for other tested models was even lower.
A key point to consider is that the results depend not only on the specific AI model, but also on the server configuration on which it’s running. Therefore, the same OpenAI model might show different results in Microsoft’s infrastructure versus OpenAI’s own servers. The same holds true for all open-source models.
Practical implications: what does it take for Whisper Leak to work?
If a well-resourced attacker has access to their victims’ network traffic — for instance, by controlling a router at an ISP or within an organization — they can detect a significant percentage of conversations on topics of interest simply by measuring traffic sent to the AI assistant servers, all while maintaining a very low error rate. However, this does not equate to automatic detection of any possible conversation topic. The attacker must first train their detection systems on specific themes — the model will only identify those.
This threat cannot be dismissed as purely theoretical. Law enforcement agencies could, for example, monitor queries related to weapons or drug manufacturing, while companies might track employees’ job search queries. However, using this technology to conduct mass surveillance across hundreds or thousands of topics isn’t feasible — it’s just too resource-intensive.
In response to the research, some popular AI services have altered their server algorithms to make this attack more difficult to execute.
How to protect yourself from Whisper Leak
The primary responsibility for defense against this attack lies with the providers of AI models. They need to deliver generated text in a way that prevents the topic from being discerned from the token generation patterns. Following Microsoft’s research, companies including OpenAI, Mistral, Microsoft Azure, and xAI reported that they were addressing the threat. They now add a small amount of invisible padding to the packets sent by the neural network, which disrupts Whisper Leak algorithms. Notably, Anthropic’s models were inherently less susceptible to this attack from the start.
If you’re using a model and servers for which Whisper Leak remains a concern, you can either switch to a less vulnerable provider, or adopt additional precautions. These measures are also relevant for anyone looking to safeguard against future attacks of this type:
Use local AI models for highly sensitive topics — you can follow our guide.
Configure the model to use non-streaming output where possible so the entire response is delivered at once rather than word by word.
Avoid discussing sensitive topics with chatbots when connected to untrusted networks.
Remember that the most likely point of leakage for any chat information is your own computer. Therefore, it’s essential to protect it from spyware with a reliable security solution running on both your computer and all your smartphones.
Here are some more articles explaining what other risks are associated with using AI, and how to configure AI tools properly:
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2025-12-04 11:06:402025-12-04 11:06:40Protecting LLM chats from the eavesdropping Whisper Leak attack | Kaspersky official blog
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2025-12-03 04:06:552025-12-03 04:06:55MuddyWater: Snakes by the riverbank
Imagine you’ve been invited to a private poker game with famous athletes. Who would you trust more to shuffle the deck — a dealer or a specialized automated device? Fundamentally, this question boils down to what you’ve more faith in: the dealer’s honesty or the machine’s reliability. Many poker players would likely prefer the specialized device — it’s clearly harder to bribe or coerce than a human dealer. However, back in 2023, cybersecurity researchers demonstrated that one of the most popular shuffler models — the DeckMate 2 made by Light & Wonder — is actually quite easy to hack.
Two years later, law enforcement found traces of these devices being rigged not in a lab, but out in the wild. This post details how the DeckMate 2 shuffler works, why its design facilitates cheating, how criminals weaponized this hack, and what… basketball has to do with it all.
How the DeckMate 2 automated card shuffler works
The DeckMate 2 automatic shuffler went into production in 2012. Since then, it’s become one of the most popular models, used in nearly every major casino and private poker club in the world. The device is essentially a black box roughly the size of an average office shredder, and typically installed underneath the poker table.
The DeckMate 2 is a professional automated card shuffler that quickly shuffles the deck while simultaneously verifying that all 52 cards are present and no extras have been slipped in. Source
On the table surface, only a small compartment is visible where the cards are placed for shuffling. Most ordinary players probably don’t realize that the “underwater” portion of this “iceberg” is significantly larger and more complex than it appears at first glance.
This is what the DeckMate 2 looks like when installed in a gaming table: all the fun stuff is hidden beneath the surface. Source
After the dealer places the deck inside the DeckMate 2, the machine runs the cards through a reading module one by one. At this stage, the device verifies that the deck contains all 52 cards and nothing except them — if that’s not the case the connected screen displays an alert. Afterward, the machine shuffles the cards and returns the deck to the dealer.
The DeckMate 2 takes just 22 seconds to both shuffle a deck and check the cards while it’s at it. The check for missing or extra cards uses an internal camera that scans every card in the deck — and this camera is also involved in sorting the deck. It’s hard to imagine the practical use for that last feature in card games — one might assume the designers added it just because they could.
Jumping ahead, this camera is what literally allowed both researchers and malicious actors to see the sequence of the cards. The previous model, the Deck Mate, didn’t have such a camera, and thus offered no way to peek at the card order.
To keep hackers out, the DeckMate 2 uses a hash check designed to confirm that the software hasn’t been altered after installation. Upon startup, the device calculates the hash of its firmware and compares it to the reference stored in its memory. If the values match, the machine assumes its firmware is unmodified and proceeds; if not, the device should recognize a tampering attempt.
Additionally, the DeckMate 2 design includes a USB port, which is used for loading firmware updates. DeckMate 2 devices can also be rented from the manufacturer Light & Wonder rather than purchased outright, often under a pay-per-use plan. In this case, they’re usually equipped with a cellular modem that transmits usage data to the manufacturer for billing.
How the researchers managed to compromise the DeckMate 2
Long-time readers of our blog have likely already spotted several flaws in the DeckMate 2 design that the researchers exploited for their proof-of-concept. They demonstrated it at the Black Hat cybersecurity conference in 2023.
The first step in the attack involved connecting a small device to the USB port. For their POC, the researchers used a Raspberry Pi microcomputer, which is smaller than an adult’s palm. However, they noted that with sufficient resources, malicious actors could execute the same attack using an even more compact module — the size of a standard USB flash drive.
Once connected, the device discreetly altered the DeckMate 2’s code and seized control. This also granted the researchers access to the aforementioned internal camera intended for verifying the deck. They could now view the exact order of the cards in the deck in real time.
This information was then transmitted via Bluetooth to a nearby phone, where an experimental app displayed the sequence of cards.
The experimental app created by the researchers: it receives the card order via Bluetooth from the hacked DeckMate 2. Source
The exploit relies on the cheater’s accomplice wielding the phone with the app installed on it. This person can then use subtle gestures/signals to the cheating player.
What enabled the researchers to gain this degree of control over the DeckMate 2 was a vulnerability in its hard-coded passwords. For their experiments, they purchased several second-hand shufflers, and one of the sellers provided them with the service password intended for DeckMate 2 maintenance. The researchers extracted the remaining passwords — including the root password — from the device’s firmware.
These system passwords on the DeckMate 2 are set by the manufacturer, and are highly likely to be identical for all devices. While studying the firmware code, the researchers discovered that the passwords were hard-coded into the system, making them difficult to change. As a result, the same set of passwords —known to a fairly wide circle of people — likely protects the majority of machines in circulation. This means that nearly all of the devices could be vulnerable to the attack developed by the researchers.
To bypass the hash check, the researchers simply overwrote the reference hash stored in memory. Upon startup, the device would compute the hash of the altered code, compare it to the now equally altered reference value, and deem the firmware authentic.
The researchers also noted that models equipped with cellular modems could potentially be hacked remotely — via a fake base station that the device would connect to instead of a real cell tower. While they didn’t test the viability of this attack vector, it doesn’t seem implausible.
How the mafia used rigged DeckMate 2 machines in real poker games
Two years later, the researchers’ warnings received a real-world confirmation. In October 2025, the U.S. Department of Justice indicted 31 people for organizing a series of fraudulent poker games. According to the case documents, in these games, a criminal group used various technical means to obtain information about their opponents’ hands.
These means included cards with invisible markings paired with phones, special glasses, and contact lenses capable of covertly reading these marks. But more importantly for the context of this post, the scammers also used hacked DeckMate 2 machines configured to secretly transmit information about which cards would end up in each player’s hand.
And this is where we finally get to the part about basketball and NBA athletes. According to the indictment, the scheme involved members of several mafia families, as well as former NBA players.
According to the investigation, the scammers set up a series of high-stakes poker games over several years in various U.S. cities. Wealthy victims were lured by the opportunity to play at the same table as NBA stars (who denyany wrongdoing). Investigators estimate that the victims lost a total of over $7 million.
Disclosed documents contain a truly cinematic account of how the scammers used the hacked DeckMate 2 machines. Instead of rigging other people’s DeckMate 2 devices via a USB port, as the researchers demonstrated, the criminals used pre-hacked shufflers. One episode even details mafia members taking a compromised device from its owner at gunpoint.
Despite this… peculiar modification to the first step of the attack, the core essence remained largely the same as the researchers’ POC. The hacked DeckMate 2 machines transmitted information to a remote operator, who in turn sent it to a participant’s phone. The criminals referred to this operator as the “quarterback”. The scammer would then use subtle signals to direct the course of the game.
What lessons we can learn from this tale
In their comments to journalists, the manufacturers of DeckMate 2 stated that following the research into the device’s hackability, they implemented several changes to both the hardware and software. These improvements included disabling the exposed USB port, and updating the firmware verification routines. Surely, licensed casinos have installed these updates. Well, let’s just hope they have.
However, the state of such devices used in private poker clubs and illegal casinos remains highly questionable. These places often employ second-hand DeckMate 2 machines without updates or proper maintenance, making them particularly vulnerable. And that’s not even considering cases where the house itself might have a motive to rig the machines.
Despite all the intriguing details of the DeckMate 2 hack, it’s based on fairly typical precursors: reused passwords, a USB port, and, of course, unlicensed gambling venues. In this regard, the only advice for gambling enthusiasts is to stay away from illegal gaming clubs.
The broader takeaway from this story is that pre-set system passwords should be changed on any device — whether it’s a Wi-Fi router or a card shuffler. To generate a strong, unique password and remember it, use a reliable password manager. By the way, you can also use Kaspersky Password Manager to generate one-time codes for two-factor authentication.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2025-12-02 18:06:412025-12-02 18:06:41How cheaters use rigged DeckMate 2 shuffling machines in poker games | Kaspersky official blog
Phishing kits usually have distinct signatures in their delivery methods, infrastructure, and client-side code, which makes attribution fairly predictable. But recent samples began showing traits from two different kits at once, blurring those distinctions.
That’s exactly what ANY.RUN analysts saw with Salty2FA and Tycoon2FA: a sudden drop in Salty activity, the appearance of Tycoon indicators inside Salty-linked chains, and eventually single payloads carrying code from both frameworks. This overlap marks a meaningful shift; one that weakens kit-specific rules, complicates attribution, and gives threat actors more room to slip past early detection.
Let’s examine how this hybrid emerged, why it signals a shift in 2FA phishing, and what measures defenders should take in response.
Key Takeaways
Salty2FA activity collapsed abruptly in late October 2025, dropping from hundreds of weekly uploads to ANY.RUN’s Interactive Sandbox to just a few dozen.
New samples began showing overlapping indicators from both Salty2FA and Tycoon2FA, including shared IOCs, TTPs, and detection rule triggers.
Code-level analysis confirmed hybrid payloads: early stages matched Salty2FA, while later stages reproduced Tycoon2FA’s execution chain almost line-for-line.
Salty2FA infrastructure showed signs of operational failure, forcing samples to fall back to Tycoon-based hosting and payload delivery.
The overlap aligns with earlier hypotheses suggesting a possible connection to Storm-1747, who are known operators of Tycoon2FA.
Attribution remains essential: Distinguishing between these “2FA” phishing kits helps analysts maintain accurate hunting hypotheses and track operator behavior.
Defenders should update detection logic to account for scenarios where Salty2FA and Tycoon2FA appear within the same campaign or even a single payload.
More cross-kit overlap is likely, meaning future phishing campaigns may blend infrastructures, payloads, and TTPs across frameworks.
Part 1: Numbers Don’t Lie – A Sudden Drop in Salty2FA Activity
It all started around the end of October 2025, when the number of the ANY.RUN sandbox submissions showing activity linked to Salty2FA dropped sharply compared to previous periods.
Weekly phishing reports (see the company’s X posts) show that, despite the usual fluctuations in overall upload volume, the average number of Salty2FA-related analysis sessions consistently stayed in the range of several hundred per week.
However, once November began, the decline became dramatic: By November 11, 2025, Salty2FA had fallen to the bottom of the weekly threat rankings, with only 51 submissions, compared to its typical 250+ per week.
Fig.1: Salty2FA activity chart
Along with indicators of compromise (IOCs) and hunting rules, the ANY.RUN sandbox’s network block previously triggered a near-constant alert tied to Salty-specific HTTP activity.
Fig.2: Last sandbox analyses showing detection of Salty2FA TTPs
This refers to the Suricata rule sid:85002719. If we filter Public submissions for analysis sessions where this rule fired, the most recent match dates back to 2025-11-01:
The first assumption was obvious: the detection logic became outdated, the framework received an update, and analysts simply hadn’t refreshed the signatures in time. But what about infrastructure indicators or domains?
While IOCs sit lower on the Pyramid of Pain than Tools/TTP coverage, they are easy to track at scale and often remain in use long enough to provide meaningful visibility. They often remain active for some time, leaving repeated traces in the data. These recurring indicators make it easier for analysts to track the threat, update its context, and perform wider hunting to uncover new related domains, behaviors, and activity patterns.
The plan was simple: search for recent analysis sessions tagged with the threat name in ANY.RUN’s Threat Intelligence Lookup, examine changes in the kit’s behavior and client-side code, and then update the detection methods:
Fig.3: TI Lookup provides a complete overview of the latest Salty2FA attacks
But then things became even more unusual. In almost every analysis executed after November 1, the samples were either completely non-functional (examples 1, 2, 3) or behaved in ways that didn’t align with Salty2FA at all.
Catch attacks early with instant IOC enrichment in TI Lookup
Power your proactive defense with data from 15K SOCs
For example, one analysis session showed the use of an ASP.NET CDN, which is not typical for this kit. It started to look as if someone had flipped a switch and taken a significant part of the framework’s infrastructure offline.
A shutdown, maybe? Not exactly.
Alongside this decline, analysts also began seeing more sessions where the verdict included both Salty2FA and Tycoon2FA; two phishing kits that offer similar capabilities but differ in how they’re built and operated.
And this didn’t resemble a simple misattribution. The Tycoon2FA indicators were supported by long-validated detection logic, including rules that flag DGA-generated domains tied to the kit’s fast-flux infrastructure.
This raised another hypothesis: a possible merging of infrastructure between the operators behind these PhaaS platforms. To verify it, we took another look at the JavaScript code used in the phishing pages.
The results turned out to be very interesting!
Part 2: When Two Kits Become One: A Deep Look at the Hybrid Payload
To understand what changed inside this new wave of submissions, we compared the code to earlier versions of both kits. For reference, the previous analyses are available here:
Fig.5: ANY.RUN’s Sandbox exposes phishing attempts in seconds
The activity begins with the phishing page hosted on Cloudflare Pages Dev; a platform intended for front-end development and static site hosting, but one that threat actors frequently abuse due to how easy it is to deploy content there.
A closer look reveals several familiar artifacts: “motivational quotes” embedded in the markup and class names generated using a simple “word + number” pattern. These elements closely resemble the older (and certainly not harmless) Salty2FA codebase:
Fig.6: Salty2FA “Quotes”
Detect phishing threats in under 60 seconds
Integrate ANY.RUN’s Sandbox in your SOC
Scrolling a bit further down, we see the trampoline code responsible for retrieving and loading the next payload stage into the DOM; a sequence identical to the older Salty implementation.
But here’s the interesting part: the code contains comments noting that the initial payload may fail to load, in which case the script should fetch the payload from an alternative URL. That fallback URL is written directly into the code with no obfuscation whatsoever.
Fig.8: Trampoline code in an older Salty sample
Fig.9: Trampoline code in the new Salty sample
After decoding the function argument, we get the address hxxps[://]omvexe[.]shop//; an IOC associated with Salty2FA. However, the payload will never be retrieved. When the script attempts to resolve the domain name, the DNS response is SERVFAIL, which differs from NXDOMAIN (non-existent domain).
SERVFAIL indicates an issue on the server side; for example, incorrect NS records or delegation problems where the resolver cannot determine which authoritative DNS server is responsible for the domain.
Fig.10: Salty2FA domain resolution errors
In other words, the Salty infrastructure is experiencing issues, and the script switches to a fallback plan, loading the page from the hardcoded secondary address.
After the initial failure, the script switches to a direct request to hxxps[://]4inptv[.]1otyu7944x8[.]workers[.]dev/, which delivers the next stage.
The first part of this stage contains obfuscated anti-analysis checks, implemented through Base64 decoding followed by an eval() call.
The second part is obfuscated using a Base64-XOR technique and contains the next portion of the payload:
Fig.11: Payload from the “alternative” execution path
After the code above runs, the page content is replaced, and new DOM elements are injected to mimic Microsoft’s official authentication page. The script also reinstates several common defense mechanisms; for example, blocking keyboard shortcuts that open DevTools and performing execution-timing checks designed to detect debugging attempts using breakpoints.
Fig.12: Blocking DevTools keyboard shortcuts
What’s more interesting is that traces of Salty2FA are still present here; in particular, the familiar “salted” source code comments:
Fig.13: Salty2FA traces inside the payload’s source code
At the bottom of the page, there is a two-line script that once again executes Base64-decoded code via eval():
Fig.14: Another obfuscated code snippet
Finally, we hit the plot twist: the next stage loads code that mirrors the last steps of the Tycoon2FA execution chain almost line for line. The variable values, the order of functions, the way each component is implemented; all of it matches what earlier analyses and reports have already documented for this PhaaS platform.
Here are some of the clearest similarities between this sample and Tycoon:
Fig.15: Variable set with predefined values
Fig.16: Data-encryption function with hardcoded IV/key
Fig.17: Function for encoding stolen data as binary octets
Fig.18: Dynamic URL routing using RandExp patterns
Fig.19: POST request to a server using a characteristic DGA-generated domain name
It was also noted that some test data was not fully removed from the code, and several sections appear to be entirely commented out, as if the phishing kit operator was making quick edits or testing new functionality but didn’t have time to finish refining it.
Fig.20: Test data inside the code
Fig.21: Fully commented-out function
Fig.22: Disabled IP logging inside one of the 2FA-handling routines
Taken together, this provides clear evidence that a single phishing campaign, and, more interestingly, a single sample, contains traces of both Salty2FA and Tycoon, with Tycoon serving as a fallback payload once the Salty infrastructure stopped working for reasons that are still unclear.
So, what does the appearance of this kind of hybrid in the wild mean for PhaaS attribution, for the operators behind these frameworks, and for phishing threat hunting more broadly? Could this point to multiple groups working together within the same operation, especially given earlier assumptions that Storm-1747 (the Tycoon operators) might also be connected to Salty2FA? Or does it suggest that the major PhaaS kits may ultimately be run by the same people?
Part 3: Are All These “Some2FA” Frameworks Really the Same?
Even though forensic work occasionally uncovers samples that include “a little bit of everything,” proper attribution between different phishing-kit families still matters. Being able to tell one kit from another ensures analysts don’t lose the unique traces that belong to a specific framework and don’t appear anywhere else. Those unique markers allow TI and Threat Hunting teams to build and test focused hypotheses, because trying to hunt under the umbrella of “all phishing attacks in the world” simply doesn’t work.
Clear attribution also helps teams collect and share fresh threat intelligence, write detection rules that map to the upper layers of the Pyramid of Pain, and keep those rules effective for as long as possible.
Attribution becomes even more valuable when you look at how it helps track shifts in the behavior and motivation of the groups running these kits. With Salty2FA, for example, there has already been speculation that Storm-1747 may be responsible for maintaining, or even creating, the framework. If that’s true, then the known TTPs, victim profiles, and operational patterns associated with Tycoon2FA would also apply to attacks involving Salty2FA. That overlap can significantly shorten detection and response times.
It also leads to a practical expectation: if the activity of one kit suddenly drops off, defenders should be ready for a surge in another kit that’s likely controlled by the same operators. That means updating detection logic, running new threat-hunting sweeps, carrying out security audits and awareness training, and reviewing incident-response playbooks that reflect Storm-1747’s known TTPs.
How Should SOC Teams Respond to This Shift?
For SOC teams, the appearance of Salty2FA–Tycoon2FA hybrids calls for a shift in how these campaigns are detected, correlated, and investigated. When a phishing kit can fall back to a different framework mid-execution, defenders need to adapt their processes accordingly.
1. Treat Salty2FA and Tycoon2FA as part of one threat cluster: The overlap in infrastructure, indicators, and execution stages means detections tied to one kit may surface activity from the other. Correlation rules and enrichment pipelines should consider both families together.
2. Build hunting hypotheses that account for fallback payloads: If Salty infrastructure becomes unavailable, the same campaign may pivot into Tycoon2FA without leaving a clear break. Threat hunting should look for these transitions to avoid missing supporting evidence.
3. Rely more on behavior than static IOCs: Hybrid kits weaken simple signature-based workflows. DOM manipulation patterns, execution-stage logic, DGA activity, and fast-flux domains remain more stable than standalone indicators.
4. Refresh IR playbooks to reflect mixed execution chains: Playbooks should include scenarios where multiple frameworks appear in the same campaign, or where an incident involves a sequence of payloads from different kits.
5. Expect faster TTP propagation: If Storm-1747 is indeed behind both frameworks, changes observed in Tycoon2FA may quickly appear in Salty2FA as well. SOC teams should monitor these shifts to stay ahead of detection gaps.
In short, the rise of hybrid 2FA phishing kits means defenders should prepare for campaigns that operate more flexibly, more modularly, and with a higher tolerance for infrastructure failures; traits that align with increasingly mature threat groups.
Supporting Detection and Response with ANY.RUN
ANY.RUN provides SOC teams with the visibility and speed needed to keep up with hybrid phishing kits. With interactive analysis and real-time intelligence in one workflow, SOC analysts can validate attribution, tune detections, and respond with confidence:
Fast investigation of complex threats: Analysts see initial malicious activity in about 60 seconds in 90% of cases, even for multi-stage phishing kits.
Immediate access to fresh IOCs: ANY.RUN’s Threat Intelligence Feeds aggregate newly observed domains, URLs, IPs, and artifacts from 15,000 organizations and a community of more than 600,000 analysts worldwide, providing early visibility into indicators.
Deep inspection of mixed execution chains: The interactive sandbox gives full visibility into each stage of the attack.
One-click enrichment with TI Lookup: Analysts can instantly view historical use, related samples, and broader activity patterns around any indicator.
Reliable correlation signals: Shared domains, DGA patterns, and reused client-side code become immediately visible across public and private submissions.
Together, these capabilities give SOC analysts a clearer, faster way to deal with hybrid phishing campaigns. They help teams spot changes early, run more focused hunts, and respond before attackers manage to regain traction.
Conclusion
In this analysis, we reviewed a case where payloads from Salty2FA and Tycoon2FA appeared together, following a sharp decline in Salty2FA activity. This kind of overlap may indicate operational issues on the Salty side, or, just as plausibly, suggest that both frameworks are operated by the same group, namely Storm-1747.
Going forward, we should expect to see more overlap in indicators of compromise, TTPs, and victim organizations across phishing campaigns involving these kits. For that reason, defenders should revisit their detection logic and develop hunting hypotheses that account for traces of both Salty and Tycoon appearing within the same context.
About ANY.RUN
ANY.RUN is a leading provider of interactive malware analysis and threat intelligence solutions used by security teams around the world. The service combines real-time sandboxing with a rich intelligence ecosystem that includes TI Feeds, TI Lookup, and public malware submissions.
More than 500,000 analysts and 15,000 organizations rely on ANY.RUN to speed up investigations, validate TTPs, collect fresh IOCs, and understand emerging threats through live, behavior-based analysis.
By giving defenders an interactive view of how malware behaves from the very first second of execution, ANY.RUN helps teams detect attacks faster, make informed decisions, and strengthen their overall security posture.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2025-12-02 11:06:442025-12-02 11:06:44Salty2FA & Tycoon2FA Hybrid: A New Phishing Threat to Enterprises
November was a packed month for detection coverage. We rolled out new behavioral insights, broadened our visibility across multiple threat families, and strengthened rulesets at every layer. On top of that, our analysts uncovered and documented a new phishing wave targeting Italian organizations through malicious PDF attachments, now fully mapped in a dedicated TI report.
Let’s walk through the full set of improvements we delivered this month.
Threat Intelligence Reports
In November, we published several new TI Reports covering threats that are currently targeting companies around the world. The four of them are open to everyone:
RoningLoader, HoldingHands, Snowlight: APT-Q-27 loader chain, stealthy RAT, and Linux VShell dropper enabling cross-platform compromise of enterprise and server environments.
PDFChampions, Efimer, BTMOB: Malvertising-based browser hijacker, Tor-hosted cryptocurrency stealer, and Android MaaS trojan abusing Accessibility to drain banking, fintech, and wallet applications.
Monkey, Phoenix, NonEuclid: AI-generated Linux ransomware, espionage-focused backdoor, and dual-use RAT–ransomware illustrating convergence of state-aligned techniques and financially motivated crimeware.
Valkyrie, Sfuzuan, Sorvepotel: Windows stealer MaaS, adaptable backdoor, and WhatsApp-propagating campaign weaponizing social trust and messaging channels for large-scale infection.
We also wrote an extensive report exclusively for the TI Lookup Premium subscribers. It goes in-depth on a phishing campaign aimed specifically at Italian organizations across transportation, tourism, telecom, IT, and government sectors. The activity relies on PDF attachments disguised as official documents, each redirecting victims to counterfeit Microsoft login pages built to harvest corporate credentials.
Recent TI report covering phishing of Italian organizations
The report outlines:
A consistent lure pattern using Italian-language prompts inviting recipients to “review” or “sign” a document
PDF filenames following a shared template: Allegato_Ufficiale_<variable>.pdf
Brand impersonation, including well-known Italian companies, to raise credibility
Redirect chains leveraging both compromised domains and attacker-controlled infrastructure (e.g., phebeschool.org, mircosotfonilne.ru, vorn.revolucionww.com)
Browser fingerprinting behavior tied to data collection on victim systems
Email templates localized in Italian, with urgent subject lines pushing immediate action
We also included ready-to-use TI Lookup queries so analysts can surface related samples quickly, track the filename cluster, and follow the network infrastructure across recent public analysis sessions.
Power your SOC with fresh threat intel
from 15K organizations and 500K analysts
In November, we expanded the malicious behavior coverage of ANY.RUN’s Interactive Sandbox with 52 new signatures across ransomware families, loaders, post-exploitation tools, and suspicious PowerShell activity. These additions help analysts surface malicious behavior earlier, reduce repeated checks, and speed up root-cause discovery.
We added 9 YARA rules in November to improve early detection of ransomware, RAT families, and network-proxy tooling. These rules help analysts flag suspicious samples even before execution, making triage faster and more reliable.
In November, we added 2,184 new Suricata rules, strengthening network-level detection for RAT traffic, stealer activity, and modern phishing techniques. These additions expand coverage for TLS fingerprinting and browser-based deception tactics.
A Suricata rule used for detecting GravityRAT in ANY.RUN’s Sandbox
Browser-in-the-Browser phishing attack (sid:85005418): Detects a phishing technique that simulates new browser window with legitimate domain within the actual browser window.
About ANY.RUN
ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, is used by more than 500,000 analysts across 15,000 organizations worldwide. The service helps teams investigate threats in real time, follow full execution chains, and surface critical behavior within seconds.
Analysts can detonate samples, interact with them as they run, and immediately pivot into network traces, file system changes, registry activity, and memory artifacts. With continuously updated detection coverage, including new behavioralsignatures, YARA rules, Suricata rules, and TI insights, teams get faster answers and clearer visibility with less manual effort.
Whether you’re running day-to-day investigations, handling escalations, or tracking emerging campaigns, ANY.RUN gives SOC teams, DFIR analysts, MSSPs, and researchers a practical way to reduce uncertainty and make decisions with confidence.
What generates the fastest profit for cybercriminals? Attacking systems that can help them access confidential information or finances directly. Therefore, it’s no surprise that entire groups of cybercriminals specialize in embedded systems: primarily ATMs full of cash, payment systems where transactions can be intercepted, medical equipment where personal data is processed and stored, and so on. All these devices often have less than an adequate level of security (both cyber and physical), making them a convenient target for attackers.
The classic challenge of protecting embedded systems running Windows is that their hardware typically becomes obsolete much slower than their software. These are often expensive devices that organizations won’t replace simply because the operating system has stopped receiving updates. The result is a high percentage of embedded devices with limited resources due to their narrow specialization, outdated software, and an operating system that’s no longer supported by manufacturer.
The end of support for Windows 10 is exacerbating this last issue. A multitude of devices that are perfectly capable of performing their primary functions for years to come will never be able to upgrade to Windows 11 — simply because they lack a TPM module.
The situation isn’t much better in the market for embedded Linux devices. Those built on x86 processors generally have newer hardware — but even that becomes outdated over time. Furthermore, many new embedded systems running Linux are based on the ARM architecture, which has its own specific requirements and challenges.
Because of these unique characteristics, standard endpoint security solutions are a poor fit. Protecting these devices requires a product equipped with technologies that can effectively counter modern threats targeting embedded systems. At the same time, it must be capable of running not only on modern hardware with the latest OS versions, but also on resource-constrained devices, and should be able to provide ideal stability in “unattended” mode, plus compatibility with specific embedded software. Ideally, it should be manageable from the same console as the rest of owner’s IT infrastructure, and support integration with corporate SIEM systems. As you’ve probably guessed, we’re talking about Kaspersky Embedded Systems Security.
How Kaspersky Embedded Systems Security can help
We’ve talked repeatedly in this blog about the specific challenges of securing embedded systems, and our take on the same. However, Kaspersky Embedded Systems Security continues to evolve. In late November, we released a sweeping product update that enhances both the Windows and Linux versions.
What’s new in Kaspersky Embedded Systems Securityfor Windows
Our experts have overhauled the solution’s codebase, adding a range of advanced threat detection and blocking mechanisms. The cornerstone of this update is a full-fledged behavioral analysis engine, which powers several technologies essential for modern device protection:
Our non-invasive Automatic Exploit Prevention technology, already proven in other products, is a reliable tool for blocking the exploitation of known and new vulnerabilities. It’s been instrumental in helping our experts discover numerous zero-day vulnerabilities in past years.
Our advanced Anti-Cryptor technology serves as an additional layer of defense against ransomware. Leveraging the behavioral engine, it now more effectively detects and blocks local attempts to encrypt files.
Our Remediation Engine is designed to roll back malicious changes made to a device. Even if attackers manage to bypass other security mechanisms and execute malicious code, its activity would be promptly detected, and all changes it made reverted. This is also particularly effective in combating ransomware.
Another technology added to the updated Kaspersky Embedded Systems Securityfor Windows is BadUSB Attack Prevention. In a BadUSB attack, a malicious device that mimics a legitimate input peripheral — most often a keyboard — is connected to the target system. Through this device, the attacker can then cause all sorts of problems: input their own commands, intercept data entered from other devices (such as the login credentials of a service technician), cause denial of service, and more. This threat is especially relevant for embedded systems installed outside a company’s physical security perimeter. A BadUSB device plugged into the port of a standalone ATM in a remote rural area can go unnoticed for months and, unless blocked by a security solution, inflict significant damage.
We’ve also added our firewall to the solution. This allows administrators to control network access for specific applications via rules based on predefined trust levels for that software. Since an embedded device typically has a limited set of tasks, it makes sense to only permit network access for the applications that genuinely need it to function properly, while blocking all others. This not only makes life harder for attackers attempting to communicate with command-and-control (C&C) servers or exfiltrate data, but also reduces the risk of the system being used as a platform to attack the rest of the corporate infrastructure.
Finally, for administrator convenience, we’ve added a security status indicator, or a “traffic light”. This provides an at-a-glance assessment of how thoroughly each device is configured, showing whether all critical protection technologies are enabled, or if an administrator needs to review the settings and check the device’s security posture.
What’s new in Kaspersky Embedded Systems Securityfor Linux
We’ve also significantly enhanced the new Kaspersky Embedded Systems Securityfor Linux. While most of the improvements boost the effectiveness of existing protection mechanisms, one fundamental change is our revamped application allowlist control system. It now uses certificate-based signing to streamline the process of updating the system and the applications required by the embedded device.
Unlike Windows, Linux systems don’t have a universal, ready-made certificate infrastructure that we could simply support. Therefore, at the request of one of our largest customers, we built our own. As a result, there’s no longer a need to regularly create and completely redeploy a full golden system image to every device — though, of course, you can continue to do this if your company needs it for any reason. Now, you simply need to sign a new application with your certificate, and the allowlist system in Kaspersky Embedded Systems Security will accept it and allow it to run without any further issues.
Another new technology in Kaspersky Embedded Systems Securityfor Linux is Web Threat Protection. The average usage model for embedded systems implies that it’s not the most useful feature on a device without a direct user. However, in practice, there are scenarios where embedded systems do use web protocols. For instance, some PoS devices require access to a corporate web-based CRM system, and the medical terminal can communicate in the same way with the internal portal that manages patient data. Such system could be compromised by attackers to perform a watering hole attack — infecting machines that connect to it. Furthermore, this protection is essential when using Kaspersky Embedded Systems Security on a regular computer with an outdated OS and no hope of updating it, rather than on an embedded system.
Future development plans for Kaspersky Embedded Systems Security
The next major product update is scheduled for the first quarter of 2026. In it, we plan to:
Achieve full compatibility between Kaspersky Embedded Systems Security and the Kaspersky Managed Detection and Response This will allow our SOC experts to assist companies that use embedded devices in detecting complex, stealthy threats, and providing recommendations for effective incident mitigation.
Integrate the BadUSB attack prevention technology into Kaspersky Embedded Systems Securityfor Linux, mirroring the capability already available in the Windows version.
Add support for the ARM architecture to Kaspersky Embedded Systems Securityfor Linux, enabling us to provide comprehensive protection for the new energy-efficient embedded systems that are rapidly gaining market share.
You can learn more about Kaspersky Embedded Systems Security on the official product page.
Data exposure by top AI companies, the Akira ransomware haul, Operation Endgame against major malware families, and more of this month’s cybersecurity news
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2025-11-29 10:06:412025-11-29 10:06:41This month in security with Tony Anscombe – November 2025 edition
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2025-11-28 17:06:402025-11-28 17:06:40What parents should know to protect their children from doxxing
Dashcams, popular in some countries and while illegal in others, are typically seen as insurance in case of an accident or roadside dispute. But a team of Singaporean cybersecurity researchers have a different take. They see offline (!) dashcams as a suitable foundation for… a mass surveillance system — moreover, one that can broaden automatically. They presented the details of their research at the Security Analyst Summit 2025.
The espionage potential of a dashcam
So, how can offline device be used for surveillance? Well, though it’s true that most dashcams aren’t equipped with a SIM card or 4G/5G connectivity — even inexpensive models have Wi-Fi. This allows the driver’s phone to connect to the device through a mobile app to adjust settings, download videos, and for other purposes. And as it turns out, many dashcams allow authentication to be bypassed, meaning a malicious actor can connect to them from their own device and then download the stored data.
An attacker has a lot to gain from this. First, there’s the high-resolution video, which clearly shows license plates and road signs. Some dashcam models also record the car’s interior, and others feature wide-angle lenses and/or rear-facing cameras. Second, dashcams can record audio — primarily conversations — inside the vehicle. Third, these video and audio recordings are tagged with precise timestamps and GPS tags.
Therefore, by downloading data from a dashcam, someone could track the owner’s movements, obtain images of the locations where they drive and park, find out what they talk about in the car, and often get photos and videos of the vehicle’s passengers or people near the car. Naturally, for targeted surveillance, a hacker would need to compromise a specific dashcam, while for mass surveillance, they’d need to compromise a large number of devices.
Attack vectors for dashcams
The researchers began their experiments with a popular Thinkware dashcam, but quickly widenend the scope of the study to include two dozen models from 15 or so different brands.
They discovered many similarities in how the different devices operate. The initial connection is typically made to a Wi-Fi access point created by the dashcam itself, using the default SSID and password from the manual.
Most of the models tested by the researchers had a hardcoded password, allowing an attacker to establish a connection with them. Once connected, a hacker gains access to a familiar setup found in other IoT gadgets: an ARM processor and a lightweight Linux build. The attacker then has a whole arsenal of proven tricks to choose from to bypass the manufacturer’s authentication — designed to distinguish the owner from an unauthorized user. At least one of these methods typically works:
Direct file access. While the minuscule web server in the dashcam waits for a client to send a password at the official entry point, malicious requests for direct video downloads often go through without a password check
MAC address spoofing. Many dashcams verify the owner’s identity by checking the unique MAC address of their smartphone’s Wi-Fi adapter. The attacker can first intercept this address over the airwaves, and then spoof it in their own requests, which is often enough to establish a connection
Replay attack. By simply recording the entire Wi-Fi data exchange between the dashcam and the owner’s smartphone during a legitimate connection, an attacker can later replay this recording to gain the needed permissions
Most online services have been protected against these types of attacks for years if not decades. However, these classic vulnerabilities from the past are still frequently discovered in embedded devices.
To allow users to quickly review recorded files on their phone screen, or even watch a live feed from the camera, dashcams typically run several servers similar to those used on the internet. An FTP server enables quick file downloads, while an RTSP server streams live video, and so on. In theory, these servers have their own password-based security to protect them from unauthorized access. In practice, they often use a default, hardcoded password that’s identical for every unit of that model — a password that can be easily extracted from the manufacturer’s mobile app.
The one-hack-fits-all situation
Why are researchers convinced that these devices can be hacked on a massive scale? Due to two key factors:
Just a few popular dashcam models account for the lion’s share of the market. For instance, in Singapore, nearly half of all dashcams sold are from the brand IMAKE
Different models, sometimes from different brands, have very similar hardware and software architecture. This is because these dashcam manufacturers source their components and firmware from the same developer
As a result, a single piece of malicious code designed to try a few dozen passwords and three or four different attack methods could successfully compromise roughly a quarter of all dashcams in a real-world urban environment.
In the initial version of the attack, the researchers modeled a semi-stationary scenario. In this setup, an attacker with a laptop would be located at a place where cars stop for a few minutes, such as a gas station or a drive-through. However, further research led them to a more alarming conclusion: everything needed for the attack could be run directly on the dashcam itself! They managed to write code that operates like a computer worm: an infected dashcam attempts to connect to and compromise the dashcams in nearby cars while on the move. This is feasible when vehicles travel at similar speeds, for instance in heavy traffic.
From mass compromise to mass surveillance
The authors of the study didn’t stop at just proving that the hack was possible; they developed a complete system for harvesting and analyzing data. The data from compromised dashcams can be harvested to one central location in two ways: by sending the data directly to the attackers’ computer located at, say, a gas station, or by exploiting the built-in cloud-enabled features of some dashcams.
Some dashcam models are equipped with an LTE module, allowing the malicious code to send data directly to the botnet owner. But there’s also an option for simpler models. For example, a dashcam can have functionality to upload data to a smartphone for syncing it to the vendor cloud, or the compromised device can forward the data to other dashcams, which then relay it to the attacker.
Sometimes, inadequate cloud storage security allows data to be extracted directly — especially if the attacker knows the user identifiers stored within the camera.
The attacker can combine several methods to analyze the harvested data:
Extracting GPS metadata from photos and videos
Analyzing video footage to detect road signs and recognize text — identifying specific streets and landmarks
Using a Shazam-like service to identify music playing in the car
Leveraging OpenAI models to transcribe audio and generate a concise summary of all conversations inside the vehicle
The result is a brief, informative summary of every trip: the route, travel time, and topics that were discussed. At first glance, the value of this data seems limited because it’s anonymous. In reality, de-anonymization isn’t a problem. Sometimes the owner’s name or license plate number is explicitly listed in the camera’s settings. Furthermore, by analyzing the combination of frequently visited locations (like home and work), it’s relatively straightforward to identify the dashcam owner.
Conclusions and defense strategies
The recent revelations about the partnership between Flock and Nexar underscore how dashcams could indeed become a valuable link in a global surveillance and video monitoring system. Flock operates the largest network of automated license plate reader cameras for police in the United States, while Nexar runs a popular network of cloud-connected dashcams designed to create a “crowdsourced vision” of the roads.
However, the mass hacking of dashcams could lead to a much more aggressive and malicious data-harvesting effort, with information being abused for criminal and fraudulent schemes. Countering this threat is primarily the responsibility of vendors, which need to adopt secure development practices (Security by Design), implement robust cryptography, and employ other technical controls. For drivers, self-defense options are limited, and heavily dependent on the specific features of their dashcam model. We list them below in order of the most to least radical:
Purchase a model without LTE, Wi-Fi and Bluetooth capabilities. This is the most secure option
Completely disable Wi-Fi, Bluetooth, and other communication features on the dashcam
Disable audio recording and, ideally, physically disable the microphone if possible
Turn off parking mode. This feature keeps the dashcam active at all times to record incidents while the car is parked. However, it drains the car’s battery and, very likely, keeps the Wi-Fi on — significantly increasing the risk of a hack
Check the available Wi-Fi settings on the dashcam:
If there’s an auto-shutoff for Wi-Fi after a certain period, set it to the shortest time possible
If you can change the default Wi-Fi password or network name (SSID), be sure to do so
If there’s an option to hide the network name (often referred to as Hidden SSID, Wi-Fi Broadcast Off, or Stealth Mode), enable it
Regularly update your dashcam firmware and its paired smartphone app. This increases the chances that vulnerabilities — like those described in this article — will be patched when you install a newer version.
Modern cars are susceptible to other types of cyberattacks too:
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2025-11-27 17:06:422025-11-27 17:06:42How your dashcam can be hacked, and how to protect yourself from the attack | Kaspersky official blog
Few cybersecurity experts would dispute that attacks on Microsoft Exchange servers should be viewed as inevitable, and the risk of compromise remains consistently high. In October, Microsoft ended support for Exchange Server 2019, making Exchange Server Subscription Edition (Exchange SE) the only supported on-premises solution for 2026. Despite this, many organizations continue to operate Exchange Server 2016, 2013, and even more antiquated releases.
For threat actors, Exchange is an irresistible target. Its popularity, complexity, abundance of settings, and, most importantly, its accessibility from external networks make it susceptible to a wide range of attacks:
Infiltration of mailboxes via password spraying attacks or spearphishing
Account compromise via outdated authentication protocols
Theft of specific emails by injecting malicious mail flow rules through Exchange Web Services
Hijacking of employee authentication tokens or message forgery by exploiting flaws in the Exchange mail processing infrastructure
Exploitation of Exchange vulnerabilities to execute arbitrary code (deploy web shells) on the server
Making it harder for attackers to compromise Exchange and reducing the impact of a successful attack is not impossible, but requires a wide range of measures — from simple configuration changes to effort-intensive authentication protocol migrations. A joint review of priority defense measures was recently published by CISA (the Canadian Centre for Cyber Security) and other cybersecurity regulators. So how do you start hardening your on-premises Exchange server?
Migrating away from EOL versions
Both Microsoft and CISA recommend transitioning to Exchange SE to receive timely security updates. For organizations unable to make the switch immediately, a paid Extended Security Updates (ESU) subscription is available for versions 2016 and 2019. Microsoft emphasizes that upgrading from 2016 or 2019 to Exchange SE is comparable in complexity to installing a standard Cumulative Update.
If for any reason you need to keep an unsupported version in operation, it should be thoroughly isolated from both internal and external networks. All mail flow should be routed through a specially configured email security gateway.
Regular updates
Microsoft releases two Cumulative Updates (CUs) per year, along with monthly security hotfixes. A key task for Exchange administrators is to establish a process for deploying these updates without delay, as threat actors are quick to weaponize known vulnerabilities. You can track the release schedule and contents of these updates on the official Microsoft page. To verify the health and update status of your Exchange installation, use tools like SetupAssist and the Exchange Health Checker.
Emergency mitigations
For critical, actively exploited vulnerabilities, temporary mitigation guidance is typically published in the Exchange blog and on the Exchange mitigations page. The Emergency Mitigation (EM) service should be enabled on your Exchange Mailbox servers. EM automatically connects to the Office Config Service to download and apply mitigation rules for urgent threats. These measures can quickly disable vulnerable services and block malicious requests using URL rewrite rules in IIS.
Secure baselines
A uniform, organization-wide set of configurations optimized for an organization’s needs must be applied not only to Exchange servers but also to mail clients across all platforms and their underlying operating systems.
Since the recommended security baselines differ for various OS and Exchange versions, the CISA guide references the popular, freely available CIS Benchmarks and Microsoft instructions. The latest CIS Benchmark was created for Exchange 2019, but it’s also fully applicable to Exchange SE — since the current Subscription Edition doesn’t differ in its configurable options from Exchange Server 2019 CU15.
Specialized security solutions
A critical mistake many organizations make is not having EDR and EPP agents on their Exchange servers. To prevent vulnerability exploitation and the execution of web shells, the server needs to be protected by a security solution like Kaspersky Endpoint Detection and Response. Exchange Server integrates with the Antimalware Scan Interface (AMSI), which enables security tools to effectively process server-side events.
Application allowlisting can significantly hinder attackers attempting to exploit Exchange vulnerabilities. This feature comes as standard in most advanced EPP solutions. However, if you need to implement it with native Windows tools, you can restrict untrusted applications via App Control for Business or AppLocker.
To protect employees and their machines, the server should use a solution like Kaspersky Security for Mail Server to filter mail traffic. This addresses several challenges that the out-of-the-box on-prem Exchange lacks the tools for — such as sender authentication via SPF, DKIM and DMARC protocols, or protection against sophisticated spam and spearphishing.
If for any reason a full EDR isn’t deployed on the server, it’s essential to at least activate the default anti-virus, and ensure the Attack Surface Reduction (ASR) rule “Block Webshell creation for Servers” is enabled.
To prevent server performance degradation when running default anti-virus, Microsoft recommends excluding specific files and folders from scans.
Restricting administrative access
Attackers often escalate privileges by abusing access to the Exchange Admin Center (EAC) and PowerShell remoting. Best practice dictates making these tools accessible only from a fixed number of privileged access workstations (PAWs). This can be enforced via firewall rules on the Exchange servers themselves, or by using firewall. The built-in Client Access Rules in Exchange can also offer limited utility in this scenario, but they can’t counter PowerShell abuse.
Adopting Kerberos and SMB instead of NTLM
Microsoft is gradually phasing out legacy network and authentication protocols. Modern Windows installations disable SMBv1 and NTLMv1 by default, with future versions slated to disable NTLMv2. Starting with Exchange SE CU1, NTLMv2 will be replaced with Kerberos, implemented using MAPI over HTTP, as the default authentication protocol.
IT and security teams should conduct a thorough audit of legacy protocol usage within their infrastructure, and develop a plan for migration to modern, more secure authentication methods.
Modern authentication methods
Beginning with Exchange 2019 CU13, clients can leverage a combination of OAuth 2.0, MFA, and ADFS for robust server authentication — a framework known as Modern Authentication, or Modern Auth for short. This way, a user can only access a mailbox after successfully completing MFA through ADFS, with the Exchange server then receiving a valid access token from the ADFS server. Once all users have migrated to Modern Auth, Basic authentication should be disabled on the Exchange server.
Enabling Extended Protection
Extended Protection (EP) provides a defense against NTLM relay attacks, Adversary-in-the-Middle, and similar techniques. It enhances TLS security by using a Channel Binding Token (CBT). If an attacker steals credentials or a token, and attempts to use them in a different TLS session, the server terminates the connection. To enable EP, all Exchange servers must be configured to use the same version of TLS.
Extended Protection is active by default on new server installations starting with Exchange 2019 CU14.
Secure TLS versions
The entire server infrastructure, including all Exchange servers, should be configured to use the same TLS version: 1.2 or, ideally, 1.3. Microsoft provides detailed guidance on optimal configuration and necessary prerequisite checks. You can use the Health Checker script to verify the correctness and uniformity of these settings.
HSTS
To ensure all connections are protected by TLS, you should additionally configure HTTP Strict Transport Security (HSTS). This helps prevent certain AitM attacks. After implementing the Exchange Server configuration changes as recommended by Microsoft, all connections to Outlook on the web (OWA) and the EAC will be forced to use encryption.
Download domains
The Download Domains feature provides protection against certain cross-site request forgery attacks and cookie theft by moving attachment downloads to a domain other than one hosting the organization’s Outlook on the web. This separates the loading of the UI and message list from downloading file attachments.
Role-based administration model
Exchange Server implements a Role-Based Access Control (RBAC) model for privileged users and administrators. CISA notes that accounts with AD administrator privileges are often also used to manage Exchange. In this configuration, a compromise of the Exchange server immediately leads to a full domain compromise. So it’s critical to use split permissions and RBAC to separate Exchange management from other administrative privileges. This reduces the number of users and administrators with excessive privileges.
PowerShell stream signing
Administrators frequently use PowerShell scripts known as cmdlets to modify settings and manage Exchange servers via the Exchange Management Shell (EMS). Remote PowerShell access should ideally be disabled. When it is enabled, command data streams sent to the server must be protected with certificates. As of November 2023, this setting is enabled by default for Exchange 2013, 2016, and 2019.
Protection of mail headers
In November 2024, Microsoft introduced enhanced protection against attacks involving the forgery of P2 FROM mail headers, which made emails appear to victims as if they were sent from a trusted sender. New detection rules now flag emails where these headers have likely been manipulated. Administrators mustn’t disable this protection, and should forward suspicious emails bearing the X-MS-Exchange-P2FromRegexMatch header to security experts for further analysis.
