How cheaters use rigged DeckMate 2 shuffling machines in poker games | Kaspersky official blog

/in

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.

What the DeckMate 2 automated card shuffler looks like

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.

The DeckMate 2 automated card shuffler built into a gaming table

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.

What the app showing the card order looks like

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 deny any 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.

Kaspersky official blog – ​Read More

Salty2FA & Tycoon2FA Hybrid: A New Phishing Threat to Enterprises 

/in

 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: 

Check recent analysis session 

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: 

threatName:”salty2fa” 

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



Start investigation 


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. 

Check analysis session with Salty2FA and Tycoon 

Fig.4: Suricata detection showing Tycoon indicators inside a Salty2FA analysis session 

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: 

With these baselines in mind, let’s take a closer look at the following analysis session: 

Check analysis session 

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



Sign up now  


Fig.7: Salty2FA class names 

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. 

Indicators of Compromise 

  • 1otyu7944x8[.]workers[.]dev 
  • xm65lwf0pr2e[.]workers[.]dev 
  • diogeneqc[.]pages[.]dev 
  • stoozucha[.]sa[.]com 
  • omvexe[.]shop 
  • lapointelegal-portail[.]pages[.]dev 
  • lathetai[.]sa[.]com 

References 

The post Salty2FA & Tycoon2FA Hybrid: A New Phishing Threat to Enterprises  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Threat Coverage Digest: New Malware Reports and 5K+ Detection Rules 

/in

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: 

  • 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 



Sign up for TI Lookup 


Behavior Signatures 

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. 

Here are the latest signatures added: 

JSGuLdr is a new threat currently targeting enterprises 
ANY.RUN’s Interactive Sandbox easily exposes CVE-2025-6216 attacks 

Detect malware & phishing in 60 seconds 

Integrate ANY.RUN’s Sandbox in your SOC



Try now


YARA Rules 

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. 

Suricata Rules 

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 
  • GravityRAT JA3 (sid:84000202): Identifies GravityRAT network activity by previously unlisted JA3 TLS fingerprint. 
  • SalatStealer JA3 (sid:84000205): Identifies SalatStealer network activity by previously unlisted JA3 TLS fingerprint. 

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. 

Start your 14-day trial of ANY.RUN today →         

The post Threat Coverage Digest: New Malware Reports and 5K+ Detection Rules  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Kaspersky Embedded Systems Security: what’s new?

/in

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 Security for 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 Security for 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 Security for Linux

We’ve also significantly enhanced the new Kaspersky Embedded Systems Security for 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 Security for 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 Security for Linux, mirroring the capability already available in the Windows version.
  • Add support for the ARM architecture to Kaspersky Embedded Systems Security for 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.

Kaspersky official blog – ​Read More

This month in security with Tony Anscombe – November 2025 edition

/in

Data exposure by top AI companies, the Akira ransomware haul, Operation Endgame against major malware families, and more of this month’s cybersecurity news

WeLiveSecurity – ​Read More

What parents should know to protect their children from doxxing

/in

Online disagreements among young people can easily spiral out of control. Parents need to understand what’s at stake.

WeLiveSecurity – ​Read More

How your dashcam can be hacked, and how to protect yourself from the attack | Kaspersky official blog

/in

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:

Kaspersky official blog – ​Read More

Microsoft Exchange on-premises hardening recommendations

/in

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
  • Lateral movement and server compromise, where the Exchange server becomes a foothold for network reconnaissance, malware hosting, and traffic tunneling
  • Long-term email exfiltration via specialized implants for Exchange

To truly grasp the complexity and variety of Exchange attacks, it’s worth reviewing research on the GhostContainer, Owowa, ProxyNotShell, and PowerExchange threats.

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.

Kaspersky official blog – ​Read More

Dell ControlVault, Lasso, GL.iNet vulnerabilities

/in

Dell ControlVault, Lasso, GL.iNet vulnerabilities

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed five vulnerabilities in Dell ControlVault 3 firmware and its associated Windows software, four vulnerabilities in Entr’ouvert Lasso, and one vulnerability in GL.iNet Slate AX.

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.    

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.     

Dell vulnerabilities

Discovered by Philippe Laulheret of Cisco Talos.

The Dell ControlVault is a hardware-based security solution designed for user authentication functions. Talos reported five vulnerabilities, as follows:

  • TALOS-2025-2173 (CVE-2025-31649) is a hard-coded password vulnerability. A specially crafted ControlVault API call can lead to an execution of privileged operation.
  • TALOS-2025-2174 (CVE-2025-31361) is a privilege escalation vulnerability. A specially crafted WinBioControlUnit API call can lead to privilege escalation.
  • TALOS-2025-2175 (CVE-2025-36460-CVE-2025-36463) covers multiple out-of-bounds read and write vulnerabilities. A specially crafted WinBioControlUnit API call can lead to memory corruption.
  • TALOS-2025-2188 (CVE-2025-32089) is a buffer overflow vulnerability. A specially crafted ControlVault API call can lead to an arbitrary code execution.
  • TALOS-2025-2189 (CVE-2025-36553) is a buffer overflow vulnerability. A specially crafted ControlVault API call can lead to memory corruption.

Entr’ouvert Lasso vulnerabilities

Discovered by Keane O’Kelley and another member of Cisco Advanced Security Initiative Group.

Lasso is a free (GNU General Public License) C library that defines processes for federated identities, single sign-on, and related protocols.

TALOS-2025-2193 (CVE-2025-47151) is a type confusion vulnerability, where a specially crafted SAML response can lead to an arbitrary code execution.

TALOS-2025-2194 (CVE-2025-46404), TALOS-2025-2195 (CVE-2025-46784), and TALOS-2025-2196 (CVE-2025-46705) are denial of service vulnerabilities. Specially crafted SAML responses can lead to a denial of service in all three cases.

GL.iNet Slate AX vulnerability

Discovered by Lilith >_> of Cisco Talos.

Slate AX (GL-AXT1800) is a Wi-Fi 6GB travel router. Cisco Talos discovered a firmware downgrade vulnerability, TALOS-2025-2230 (CVE-2025-44018), in the OTA Update functionality. A specially crafted .tar file can lead to a firmware downgrade. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.

Cisco Talos Blog – ​Read More

Care that you share

/in

Care that you share

Welcome to this week’s edition of the Threat Source newsletter.

Back in April, I wrote about the risks of unintentionally leaking information while using search engines. Since then, I’ve been thinking: Life doesn’t just happen in front of a keyboard. There’s a social side, too (or so I’m told). With Thanksgiving around the corner, it seems the perfect time to flip the script and focus on a different but related concept: Care that you share. 

For my non-American friends, who may be enjoying just another Thursday, stick with me. This season brings heightened risks everywhere. Many teams are running with skeleton crews, whether due to holiday mode (family, turkey, football, days off) or the year-end compliance push (hello, NIS2 and DORA). At the same time, on the other side of the fence, attackers ramp up their efforts; globally, Black Friday and similar events are peak periods for phishing campaigns, often targeting credentials with fake employee perk emails and other seasonal lures. 

So, why emphasize “care that you share?” 

Recently, I visited a university of applied sciences to give a guest lecture and learn more about the projects students are working on. It was a great experience, though preparing for an audience of students (not my usual crowd) was challenging. What do they already know? What topics interest them? Should I give them some history of STIX/TAXII? Geopolitical tensions? Honestly speaking, none of this was interesting to me when I was a student. I chose to start simple, discussing what threats and the DKIW pyramid were, and then focusing on CVE, CVSS, and KEV — one of my favorite topic clusters. 

To my surprise, not only did the students engage and ask questions, but they also stuck around late on a Friday afternoon, diving into discussions about software supply chain risks and beyond. I don’t remember ever staying at university past 6:00 p.m. on a Friday as a student! A week later, when they presented their projects — many centered on authentication, TOTP, and SmartCards — I was genuinely impressed by their ideas and the real-world problems they were addressing. 

“Care that you share” is a mindset that helps us appreciate the knowledge exchange that happens in person, too. 

Whether sharing stories over dinner, IOCs over email, or ideas in a classroom, let’s all take a moment to consider not just what we share, but how and why we share it. I’ll admit, I sometimes hesitate to share certain stories myself, worried they might seem too obvious or uninteresting, or maybe even dumb. But more often than not, those moments of openness lead to the best conversations and new perspectives. 

This rings especially true during busy or understaffed times, when teams are stretched thin. It’s tempting to keep things to ourselves to avoid “bothering” others. In reality, sharing a helpful tip, a concern, or just a quick update can make all the difference for colleagues who might be juggling extra responsibilities or missing context. 

So this holiday season, care that you share. Thoughtful communication isn’t just about protecting information — it’s also about supporting each other, especially when resources are limited. You never know who might benefit from what you have to offer, yourself included. 

The one big thing 

Last week, Cisco Talos announced an initiative to retire outdated ClamAV signatures to reduce database sizes and improve efficiency by focusing on currently relevant threats. Starting Dec. 16, 2025, the “main.cvd” and “daily.cvd” databases will be cut roughly in half, offering smaller downloads and reduced resource usage. Retired signatures may be reintroduced if old threats reappear, and only supported ClamAV container images will remain available on Docker Hub to enhance security and management. 

Why do I care? 

Smaller signature databases mean faster updates, lower bandwidth and storage requirements, and improved performance, especially on resource-constrained systems. By focusing detection on active threats, ClamAV can more efficiently protect against current malware without being bogged down by obsolete signatures. 

So now what? 

We will continue to monitor the activity of retired signatures and will restore any that are needed to protect the community. Stay attentive and request the reinstatement of retired signatures if older threats reappear. In the meantime, we recommend that ClamAV container image users select a feature release tag rather than a specific minor release tag to stay up to date with security updates and bug fixes. 

Top security headlines of the week 

Second Sha1-Hulud wave affects 25,000+ repositories via npm preinstall credential theft 
The new supply chain campaign, dubbed Sha1-Hulud, has compromised hundreds of npm packages, uploaded to npm between November 21 and 23, 2025. The attack has impacted popular packages from Zapier, ENS Domains, PostHog, and Postman, among others. (The Hacker News) 

FBI: Cybercriminals stole $262M by impersonating bank support teams  
Since January 2025, the FBI’s Internet Crime Complaint Center (IC3) has received over 5,100 complaints, with the attacks impacting individuals, as well as businesses and organizations across all industry sectors. (Bleeping Computer) 

Everest ransomware claims breach at Spain’s national airline Iberia with 596 GB data theft 
The group states that the data covers millions of customers in multiple countries, and says it had long-term access with the ability to read and alter bookings. (HackRead) 

CISA warns of active spyware campaigns hijacking high-value Signal and WhatsApp users 
CISA on Monday issued an alert warning of bad actors actively leveraging commercial spyware and remote access trojans (RATs) to target users of mobile messaging applications. (The Hacker News) 

LINE messaging bugs open Asian users to cyber espionage 
Researchers discovered critical vulnerabilities that open the door to three main buckets of compromise: message replay attacks, plaintext and sticker leakage, and, most concerningly, impersonation attacks. (Dark Reading) 

Can’t get enough Talos? 

Talos Takes: When you’re told “no budget” 
From configuring what you already have, to open-source strategies, to the impact of cybersecurity layoffs, this episode is packed with practical guidance for securing your organization during an economic downturn. 

Humans of Talos: On epic reads, lifelong learning, and empathy  
In this episode, Bill Largent shares what drew him to Talos, how his love of reading has shaped his cybersecurity ethos, and the key insights he shares for the next generation of cybersecurity professionals. 

The TTP: How Talos built an AI model into one of the internet’s most abused layers 
Hazel talks with Talos researcher David Rodriguez about how adversaries use DNS tunneling to sneak data out of networks, why it’s so difficult to spot in real time, and how Talos built an AI model to detect it without breaking the internet. 

Upcoming events where you can find Talos 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: d933ec4aaf7cfe2f459d64ea4af346e69177e150df1cd23aad1904f5fd41f44a 
MD5: 1f7e01a3355b52cbc92c908a61abf643 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=d933ec4aaf7cfe2f459d64ea4af346e69177e150df1cd23aad1904f5fd41f44a 
Example Filename: cleanup.bat 
Detection Name: W32.D933EC4AAF-90.SBX.TG 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
Example Filename: e74d9994a37b2b4c693a76a580c3e8fe_1_Exe.exe  
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
Example Filename: ck8yh2og.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
MD5: aac3165ece2959f39ff98334618d10d9  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
Example Filename: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974.exe  
Detection Name: W32.Injector:Gen.21ie.1201 

SHA256: 26fa67db9a00f07600abe950d2ea0aed0ea7a0b49a0b5a452e3175ffa33970ff  
MD5: 71da0bf3094e3ed17bc5a1c78de80933  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=26fa67db9a00f07600abe950d2ea0aed0ea7a0b49a0b5a452e3175ffa33970ff  
Example Filename: cleanup.bat  
Detection Name: W32.26FA67DB9A-90.SBX.TG 

Cisco Talos Blog – ​Read More