In an industrial network, malicious activity can be hard to tell apart from normal data exchange between devices. Malicious actors routinely rely on legitimate tools and the Living-off-the-Land technique, so a single network connection may show no known signs of an attack: the device uses a familiar protocol and transmits ordinary data. An anomaly can hide in subtle details: the data source, the time of access, or the volume of transferred data may be atypical for a particular device. However, to detect this kind of anomaly, you need to understand the roles of the devices at both ends of the connection and know which network activity patterns are typical for them.

But an organization’s asset inventory data is often incomplete, which makes it harder to catch unauthorized connections in time. Suppose monitoring detects a host that regularly exchanges data with programmable logic controllers (PLCs). Its IP address is known, but the inventory does not specify what role it plays: is it an engineering workstation, a process data server, or a piece of contractor’s equipment? The host may also have been on the industrial network for a long time, with its record going out of date after a network upgrade.

In the joint OT asset inventory guidance released by CISA and its partners in 2025, inventorying devices and classifying them by role are treated as part of OT asset management. For organizations, this is one of the most important areas: according to the SANS 2025 ICS security survey, 50% of respondents had deployed or significantly expanded ICS inventory and visibility tools over the previous 12 months, and 54% named them as investment priorities for the next 12–24 months.

Device inventory in Kaspersky Industrial CyberSecurity for Networks

In Kaspersky Industrial CyberSecurity for Networks, the Asset Discovery technology is the foundation of asset visibility. Passive network traffic analysis detects devices and their interactions, while recognition rules help determine the device category and extract available information about it, such as the vendor, model, or software version. Exactly which attributes the system can obtain depends on the protocol and the traffic it observes. We covered this in more detail at the Kaspersky Industrial Cybersecurity Conference.

The product also supports active polling modules (APMs): where polling is allowed, they can request additional configuration and firmware version details from devices. This kind of inventory is far more detailed than a list of IP addresses.

However, even accurate hardware information doesn’t always explain what function a host performs in a specific industrial facility. Gaps appear for various reasons. Some devices send identifying information only at startup or during configuration, while others rarely communicate. Proprietary protocols can’t always be parsed, and encryption may leave only connection metadata for analysis. If the monitoring system doesn’t receive traffic from every segment of the industrial network, some network activity goes unobserved. Active polling doesn’t suit every device or every operating condition.

When there isn’t enough direct information about a device, its category can be refined by looking at the patterns of its recurring network interactions. Analyzing these interactions is the job of Machine Learning Event Processor (MLEP), a service included in Kaspersky Industrial CyberSecurity for Networks 5.0. This machine-learning-based event processor can both refine device categories and detect anomalies in their network behavior.

What data does MLEP analyze?

To compare device behavior, you don’t need to store every packet as a separate observation (a data object) in the ML model. MLEP represents network sessions as a sequence of short 15-second fragments. For each fragment, MLEP stores information about the endpoints (IP, MAC, and port), the direction of data exchange, the protocol, and the number and size of the packets transmitted. Together these make up an event, which then gets a timestamp. Traffic thus becomes a sequence of events showing which hosts a device communicated with, when, and how communication intensity changed.

Aggregating data into events also sets the method’s limits. An aggregated fragment can’t be used to reconstruct the exact order of individual packets or the content of commands. MLEP can draw conclusions about a new protocol only if another KICS technology has managed to recognize it. That said, comparing stable network connections and changes in exchange volume doesn’t require a detailed record of every packet. These observations form the basis of the device’s behavioral history.

From observations to MLEP results

Each object has its own behavioral history, and one object’s history can’t be applied to another. But the principles of behavior analysis, along with some common rules, work across different objects.

Let’s look at how this works in MLEP, which is built on a spiking neural semantic network (NSN).

Event identification

Neurosemantic networks structure information as a multilayer ordered graph, where the data in each consecutive layer builds on the data in the previous one. The nodes of this graph — that is, the units of information in each layer — act as neurons.The NSN creates dedicated channels to handle different event parameters (port, IP, and so on). Unique parameter values for each channel are stored as neurons in layer 0. The event itself, which consists of a set of parameter values, is stored as a neuron in layer 1 of the network. If an event occurs for the first time, neurogenesis creates a new neuron with input connections to the corresponding parameter neurons. This lets the network learn and operate on the event stream at the same time. If the event has occurred before, the network activates the same neuron that was created when the event first appeared. This way, the network identifies each event precisely. Each neuron that corresponds to an event also collects basic statistics: when it was last activated and how many times it has been activated.
 

Event history

In NSN-based event processing, layer 2 and above store sequences of events over time: recurring patterns and the full history. However, categorization and statistical anomaly detection don’t require storing the full packet sequence or a detailed timeline of every network event. As we noted earlier, events are themselves aggregates, which means the order of network packets has already been averaged out. So MLEP keeps history only temporarily, within each episode (30,000 aggregated events by default), which saves computing resources.

Statistics processing in MLEP

MLEP processes statistics mainly through specialized listener neurons on layer −1 (minus one) of the network. Attention heads and monitors are built on these neurons.

When an event arrives, the corresponding neuron is activated, and the network instantly knows whether that neuron is new or was created earlier. Each attention head subscribes to the events or event features it needs and takes in only the activations of the matching neurons. If an event occurs for the first time, all heads are notified and then decide whether to subscribe (grow a connection to the relevant neuron) and receive information about activations of such neurons from then on.

It is called a spiking network because activation information is a spike, not a number. This spike tells the head that something it’s interested in has happened.

An attention head is configured according to scenarios — the situations that MLEP should send alerts about. The core of a head’s configuration is a query, which filters incoming information and serves as the subscription criterion. Unlike regular database queries, this query runs on the stream, so it can react to an event instantly.

Attention heads work very much like the semantics of ordinary human language. A query has a subject of attention (one or more grammatical subjects) and conditions (the other parts of the sentence). In the infrastructure of an industrial enterprise, the subjects are devices on the network, and the conditions are various aspects of network communication, such as ports, protocol, and average packet size. If a head has many subjects (for example, if it’s interested in every device on an industrial network), it fans out: it creates a child head for each individual value of the subject of attention, that is, each device. The child head then watches a specific device and reports to the parent head.

Attention heads don’t accumulate or process statistics. They only filter event streams. When an attention head receives a relevant event, it activates and sends a spike to the monitor subscribed to that head.

Monitors, in turn, have stacks for accumulating and processing events. They can also have their own queries and post-filter information from the head. For example, they can select only new events from those filtered by the head.

There are several types of monitors:

• Stat monitors track changes in the average count of specific events (for example, device activity) over time intervals typical for those events, or in the average values of numeric event parameters (for example, changes in device traffic volume).
• Monitors work from the event alone: they fire when an event has occurred a certain number of times within a given interval, or has occurred for the first time.
• Similar-behavior monitors work with heads that can generalize events, that is, extract just a few parameters whose combination is shared (generalized) across many events.

MLEP uses these monitor types to implement scenarios for categorizing devices and detecting their anomalous behavior:

1. For categorization, MLEP uses attention heads and monitors that identify common behavior across different assets and group devices accordingly. MLEP then takes information from Asset Discovery about the known categories of some assets and extends those categories to other assets in the same group. Because a device can show different types of activity, it may land in several groups. MLEP then makes a weighted assessment across all relevant groups.
   

   Groups of devices with similar network behavior

   At the final stage, the system verifies that assigning the category to the asset is permissible. This is again done by special rule monitors loaded into the NSN at system startup. The rules rely on asset metadata available from Asset Discovery and APMs.

2. MLEP takes a similar approach to anomaly detection: an attention head and a monitor define an anomaly scenario, often loosely. When a monitor activates on such a scenario, MLEP generates an alert about unusual behavior.

The current version of MLEP ships with preconfigured heads and monitors.

The functional dynamic diagram below shows how events from devices on an industrial network are processed.

MLEP in practice: how behavior helps complete the asset inventory

At a facility with several similar production lines, device information may be more complete on some lines than on others. On one line, devices are identified as PLCs, while on another, after an upgrade, some hosts show up only as addresses: the available traffic didn’t provide enough information to determine their category. Still, these devices communicate with the same types of HMIs and process data collection servers. Their communication directions, frequency, and volumes may be similar.

That’s where MLEP comes in. It takes the categories of already known assets and matches recurring features of their network behavior against those of uncategorized devices. When the observed interactions turn out to be similar, MLEP can add a category for that host to the inventory.

Once the category is refined, the industrial network map provides more context about the equipment on the network. When analyzing network activity, the analyst immediately sees the device’s suggested category and can skip looking up each IP address in the design diagrams. This approach is especially useful where equipment changes faster than the documentation is updated.

The suggested category is also checked against existing device information and defined constraints. This helps filter out some contradictory options, but prediction quality still depends on how much of the traffic is visible, especially if the device communicates only rarely.

Anomalous activity and streaming statistics

Investigations of real-world attacks show that attackers actively use both standard tools and permitted protocols. You don’t always need to know an attacker’s specific technique in advance to spot potentially malicious activity. Signature-based detection helps find known signs of an attack, but it doesn’t assess how typical an observed interaction is for a particular device. MLEP compares current activity with the device’s usual network profile: which hosts it communicates with, which protocols it uses, when and how much data it transmits, its average packet size, and so on. The changes it detects help guide the direction of the investigation. Correlating these changes with other events and the operational context helps determine whether malicious actions could be behind them. When investigating an incident that has already been detected, anomalies help reconstruct the sequence of actions.

The first version of MLEP comes with six preconfigured monitors, one for each type of deviation from the device’s usual network profile:

Anomaly	How it helps with event analysis
New external host	Flags a new external connection that wasn’t previously seen in the device’s observed behavior, even if the IP address isn’t listed among known IoCs. Helps check whether this connection appeared at the same time as other suspicious events.
New combination of destination address and port	Shows that the device has begun using a service it hasn’t used before. Once an incident has been detected, this helps trace new connections after the more critical events have been analyzed.
Unusually large volume of data sent	Highlights data transfers that are atypical for the device and helps correlate their timing and direction with other events.
Atypical activity time	Shows that the device was active at a time that’s unusual for it. In an already detected incident, this helps reconstruct the timeline of actions around the main alert.
New protocol	Helps spot a new method of communication, even when the device is communicating with familiar hosts.
Activity with signs of scanning	Shows that the device has started contacting an unusually large number of neighboring hosts. This signal helps reveal possible reconnaissance ahead of attempts to access equipment.

During an investigation, anomalies help reconstruct the sequence of changes: when a specific host established new connections, switched protocols, increased its data transfer volume, or shifted its operating hours. Matching events by device and time shows an analyst how activity unfolded around an incident that has already been detected.

This is especially useful when some of the attacker’s actions fell outside the monitored scope or didn’t trigger other KICS technologies. Correlating these changes with the device’s role, protocol analysis data, and events from other technologies gives the analyst a more complete timeline. Behavioral anomalies show exactly where to look for the missing links and which network interactions need attention.

In the event list, anomalies detected by MLEP are marked with an AI label. Each event shows its name, source, destination, timestamp, and the ID of the triggered scenario.

Conclusion

In an industrial network, whether behavior is anomalous depends on the host where it occurs and that host’s place in the industrial process. The repetitive nature of many communications makes a change in normal data exchange easier to spot, while knowing a device’s function and criticality helps gauge the possible consequences. Taken together, these observations make network traffic more than a list of connections: it helps assess new events in the context of a specific facility, even without an attack scenario known in advance. Machine learning technologies are well suited to this kind of comprehensive analysis, as they can process and organize huge streams of heterogeneous data. Starting with version 5.0, Kaspersky Industrial CyberSecurity for Networks handles this function with MLEP, which works effectively alongside the product’s existing functionality.

Internet governance bodies are likely to accelerate work to prepare the domain name system (DNS) so it can remain secure once quantum computers can challenge conventional encryption. John Crain, ICANN’s chief technology officer, last week told The Register that he is aware of efforts within the organization, and at other internet governance bodies, to consider what happens once commercially available quantum computers become capable of easily deciphering encrypted information. Those machines theoretically pose a risk to DNSSEC, the Domain Name System Security Extensions that adapt PKI to the job of verifying the veracity of DNS records. The CTO said he’s aware of predictions that such computers could come online “at the turn of the decade” and that he has therefore changed his view of when the DNS needs to be made quantum safe. “If you asked me years ago, I would have said we probably need to be ready in ten years,” Crain said. “Now, maybe it's less than that. I don't know if it's three years or five, but it's probably not ten”. One way to quantum-proof DNSSEC is to use larger keys that even a quantum computer will struggle to crack. Doing so, however, runs into message size limits in the DNS. “If we go for larger key sizes, that means larger zones, larger packets, larger responses,” Crain said. It can also mean traffic being carried by multiple TCP packets, instead of the single UDP messages DNS prefers. Crain said ICANN, the IETF, and other internet governance bodies are aware of this challenge and have begun preliminary work to address it. “Being prepared to go from UDP to TCP is going to take a few years,” he told The Register at ICANN’s annual meeting in Bali last week. “We're probably a few years away from being able to deploy in a predictable manner.” The internet community has, however, seen that the problem is becoming more acute. “We're going to ramp up the speed of development,” Crain said. Internet registry reform nears At ICANN’s Bali conference, The Register also met Jia-Rong Low, in his capacity as chair of the Number Resource Organization, the peak body for the world’s five regional internet registries (RIRs), AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC. The topic of that conversation was Internet Coordination Policy 2 (ICP-2), the document that governs RIRs. In its current form, ICP-2 describes the formation of a new RIR but no other part of its operations. After strife at AFRINIC raised the possibility of the African registry failing, the NRO decided to update ICP-2 so it covered the entire lifecycle of an RIR, from formation through to possible derecognition. Work on ICP-2 has moved through several rounds of public consultation. It has reached the status of a recommended draft. Low told The Register work on the document has proven “very challenging” to develop entirely with remote work. Last week’s ICANN meeting, he said, offered a venue for in-person collaboration that he hopes will result in work accelerating. The revised document defines four stages in the life of an RIR: recognition, audit, emergency continuity operations, and derecognition. The last three are additions to ICP-2 and give ICANN a major role as an independent overseer of RIRs. Low is hopeful a final document will be ready for review by the end of 2026, and ready for implementation not long afterwards. Scammers target trustworthy-sounding domains like .bank or .pharmacy Phisherfolk and other scammy scum strive to register authoritative-sounding domains as part of their efforts to trick victims. ICANN defines some global top level domains (GTLDs) as “Category 1” strings, because they pertain to regulated sectors – such as .bank, .doctor, and .university – or are felt to need special safeguards because like .sucks they create the potential for bullying. In a session at the ICANN meeting, Siôn Lloyd, ICANN’s principal security, stability and resiliency scientist, said the organization has investigated whether certain top level domains attract more abuse. He found that Category 1 GTLDs are more likely to be targeted by DNS abusers and therefore have a 45 percent higher chance of abuse than other domains. Happily, Category 1 domains are also less likely to have high abuse volumes. ICANN is currently working on a policy (PDP1) that will require domain registrars to take extra action against owners of domains that facilitate abuse, and another (PDP2) that will regulate automated domain registration. More GTLDs, more often? The Register heard plenty of chat at the meeting about ICANN’s new round of applications for GTLDs, which seems to be progressing well. Across various panels and sessions, we also heard references to ICANN’s past statements that new GTLD application rounds should be more frequent and take place at a predictable cadence, along with some suggestions that this round of applications is the template for future rounds. ®

Britain is threatening subsea cable saboteurs with up to 14 years in prison and unlimited fines, having apparently decided that Victorian-era laws aren't quite up to the job of keeping Russian submarines away from critical infrastructure. The government on Thursday set out plans to overhaul legislation dating back to 1885 and introduce tougher penalties for damaging the underwater cables and pipelines that keep Britain's internet and energy supplies running. According to Whitehall, subsea cables carry around 99 percent of the UK's international data traffic, while underwater pipelines account for 74 percent of its gas supply. Yet much of this infrastructure is protected by laws written when the telegraph was cutting-edge technology. The Submarine Telegraph Act 1885 originally imposed a £100 maximum fine for damaging a cable through culpable negligence. That might have been a reasonable deterrent back then, but it's unlikely to give today's would-be saboteurs much pause. Under the proposals, those who intentionally damage critical subsea energy or telecoms infrastructure could face up to 14 years behind bars. The proposals also set tougher penalties, including unlimited fines, for reckless or negligent damage. Subsea telecoms operators would face new legal duties to identify and manage security risks, while ministers would gain powers to direct companies and cable repair providers to take action where necessary and proportionate to protect national security. The government also wants to regulate fiber-optic sensing technology, which uses subsea cables to detect activity at sea but could pose a security risk if sensitive data falls into hostile hands. Unsurprisingly, Russia features prominently in Whitehall's thinking. In April, British forces exposed a covert Russian submarine operation near critical undersea infrastructure. The operation reportedly involved an attack submarine acting as a decoy while two specialist vessels surveyed Britain's cable routes. "The threats we face have changed dramatically, with suspicious Russian activity around critical undersea infrastructure, yet some of the laws protecting these vital connections date back more than a century," said telecoms minister Ian Murray. The plans aren't entirely new. In May, the government announced its intention to toughen penalties and introduce security obligations for cable operators. Thursday's White Paper spells out the proposed penalties and how far ministers could go in directing operators to act. It also follows warnings from Parliament's Joint Committee on the National Security Strategy, which concluded last year that Britain was insufficiently prepared for a coordinated attack on its subsea infrastructure. MPs and peers warned that government assessments focused too heavily on individual cable failures, rather than what might happen if attackers simultaneously targeted connections to Europe and across the Atlantic. Russian submarines aren't responsible for every severed cable. Fishing boats and ships dragging their anchors do most of the damage, accounting for up to 97 percent of faults, according to previous government estimates. And even when sabotage is suspected, catching those responsible is another matter. Britain already has laws allowing life sentences for serious acts of state-backed sabotage, but they're not much use if nobody can prove who did it. That's rather difficult when the crime scene is at the bottom of the sea. And it might prove equally difficult to extradite suspects from enemy nation states. None of this is law yet. The government has opened a 12-week consultation on the plans, after which ministers will decide how to proceed. Whether the threat of a lengthy prison sentence will trouble Russian submariners is debatable. Even so, after 140 years, Britain's subsea cable laws are finally getting dragged out of the Victorian era. ®

ICANN has started testing authentication schemes that will allow law enforcement agencies to make urgent requests for non-public WHOIS information – when needed to address threats to life, critical infrastructure, or child exploitation. Domain registrars collect information about their customers and in the past that data was publicly available in WHOIS records. Some domain registrars offer services that substitute their own contact details, to preserve customer privacy. In recent years, laws like GDPR mean registrars are sometimes required to hide WHOIS data. That’s fair enough but makes it hard for law enforcement to contact a domain holder if their resources are being misused – intentionally or otherwise – for purposes such as hosting malware, acting as command-and-control infrastructure for malware, or facilitating phishing. ICANN’s definition for the kind of behaviour it thinks justifies urgent requests for WHOIS info is “imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation.” The org has convened an Input Group on Law Enforcement Agency Authentication Mechanisms to consider the issue, and that group yesterday explained its progress during ICANN’s annual meeting in Bali, Indonesia. At this point, readers may have concerns that this proposal could allow law enforcement authorities to make inappropriate requests for WHOIS information. Several factors may ease such concerns. One is that representatives of domain registrars Namecheap and Verisign spoke during the session about the proposal, and both were supportive. Another is that the Input Group’s work is largely technical. Once it devises a mechanism to allow requests, other groups within ICANN dedicated to policy will work out acceptable use and related issues. This is the way internet governance gets done! Specialists work on their own bits of a problem and then collaborate to create a robust system that works at a technical level, is practical, and enforceable in multiple jurisdictions. How they’ll do it At this point, ICANN’s preferred approach is to use Security Assertion Markup Language (SAML) so that authenticated users at law enforcement agencies can log into the governance org’s Registration Data Request Service (RDRS) and file requests to access non-public WHOIS info. ICANN is already testing this approach with the FBI and Interpol but is open to other authentication mechanisms to allow other agencies access RDRS. The Input Group’s aim is to publish a spec those agencies can conform to. ICANN will pass requests filed in RDRS to whichever registrar sold the domain. The registrar will have 24 hours to consider the request – or up to 72 hours for complex queries. Registrars will also be able to deny requests if they feel the query does not meet the urgency threshold. Register readers might worry that a colossal agency like the FBI could flood RDRS with requests from thousands of individual agents, swamping domain registries. ICANN’s plan is to avoid that by requiring law enforcement agencies to nominate certain personnel who are permitted to make requests, and to enforce that permission using a token shared during SAML handshakes. The content of that token is the kind of policy question that the Input Group expects others at ICANN to finalize later. Another issue under consideration is how to protect the identity of law enforcement workers who make RDRS requests, as ICANN feels they could become targets of harassment (or worse) if their requests to see WHOIS data include email addresses. ®

America wants its allies to come together and help it lead the way in defining 6G communications standards, with security and resilience seen as key goals for next-generation networks. The latest effort to corral international work on 6G comes from the US National Telecommunications and Information Administration (NTIA), which says it is pursuing the objectives of a December 2025 memo from President Trump on "Winning the 6G Race." That memo didn't identify who America is racing against, but it is a fair bet that it is China, which gained a lead during the development of 5G technology. Huawei in particular is understood to hold more declared 5G standard-essential patent families than any other company. The NTIA says it is launching this initiative alongside more than 20 governments, including several European nations like the UK and the Nordic countries, Japan, South Korea, and Australia. The Nordics are significant as they are home to telecoms equipment suppliers Nokia and Ericsson. These governments have all pledged to strengthen cooperation on 6G over the next 12 months and beyond in support of greater security, interoperability, and resilience for next-generation networks, the NTIA claims. "The Call to Action for 6G Leadership and Security reflects an unprecedented level of international coordination on the future of communications technology," stated NTIA administrator Arielle Roth. "By working now with trusted partners, we will ensure that next generation networks reflect our shared security interests, strengthen our competitiveness, and drive innovation." So after President Trump has spent 18 months since inauguration disparaging and threatening America's "trusted partners," the US has decided it would really like their help in becoming the world leader in 6G technology. Isn't that nice? The initiative lays out specific milestones on strategic coordination over the next year or so, as 6G moves toward commercialization. These include engaging with the telecoms industry to understand the "political and economic landscape" for 6G networks and meetings to identify the potential for more coordinated approaches. It also calls for a big meeting in 2027 to review joint progress, where the partners are expected to evaluate funding strategies, share information on 6G research and development, assess 5G and 6G technical and cybersecurity risks, and promote common 6G policies. All of this seems aimed at coordinating positions on the spectrum needed for 6G ahead of the next World Radiocommunication Conference (WRC-27). Scheduled for October 18 to November 12 in Shanghai next year, the conference will consider which frequency bands are made available for next-generation mobile networks. But it isn't the first attempt at international collaboration over the next-gen wireless standard. The US-UK Tech Prosperity Deal, agreed last year, proposed greater cooperation in a range of science and technology areas including 6G, but this was put on ice by President Trump after just a few months over trade disagreements. Earlier this year, the Global Coalition on Telecommunications (GCOT) unveiled a set of security and resilience principles it wanted to see baked into 6G from the start. The organization includes many of the same nations as the latest US scheme. "This is a clear attempt by the US and its allies to shape the 6G landscape before commercial networks arrive," PP Foresight founder and analyst Paolo Pescatore told The Register. "The priority is to embed security, resilience, interoperability, and supply-chain diversity from the outset, rather than repeat the costly mistakes and geopolitical tensions that defined the 5G era. "Although China is not explicitly mentioned, the strategic intent is obvious: to reduce dependence on high-risk suppliers and to ensure that trusted nations have greater influence over standards, investment, and innovation. However, this remains a political framework rather than a binding agreement." The first 6G deployments could arrive as soon as 2029, with the US and South Korea likely to lead in early adoption, according to a report from Juniper Research earlier this year. Despite this, the exact characteristics that will define 6G networks have yet to be thrashed out. Bodies representing the mobile networks want to see a smooth and cost-effective migration path for their members, avoiding the mistakes made with 5G, while the GSMA has already put it out there that 6G networks may need up to three times the spectrum currently allocated to meet the anticipated demands for data. ®

A Brazilian tech firm that specializes in protecting networks from distributed denial-of-service (DDoS) attacks has been enabling a botnet responsible for an extended campaign of massive DDoS attacks against other network operators in Brazil, KrebsOnSecurity has learned. The firm’s chief executive says the malicious activity resulted from a security breach and was likely the work of a competitor trying to tarnish his company’s public image.

For the past several years, security experts have tracked a series of massive DDoS attacks originating from Brazil and solely targeting Brazilian ISPs. Until recently, it was less than clear who or what was behind these digital sieges. That changed earlier this month when a trusted source who asked to remain anonymous shared a curious file archive that was exposed in an open directory online.

The exposed archive contained several Portuguese-language malicious programs written in Python. It also included the private SSH authentication keys belonging to the CEO of Huge Networks, a Brazilian ISP that primarily offers DDoS protection to other Brazilian network operators.

Founded in Miami, Fla. in 2014, Huge Networks’s operations are centered in Brazil. The company originated from protecting game servers against DDoS attacks and evolved into an ISP-focused DDoS mitigation provider. It does not appear in any public abuse complaints and is not associated with any known DDoS-for-hire services.

Nevertheless, the exposed archive shows that a Brazil-based threat actor maintained root access to Huge Networks infrastructure and built a powerful DDoS botnet by routinely mass-scanning the Internet for insecure Internet routers and unmanaged domain name system (DNS) servers on the Web that could be enlisted in attacks.

DNS is what allows Internet users to reach websites by typing familiar domain names instead of the associated IP addresses. Ideally, DNS servers only provide answers to machines within a trusted domain. But so-called “DNS reflection” attacks rely on DNS servers that are (mis)configured to accept queries from anywhere on the Web. Attackers can send spoofed DNS queries to these servers so that the request appears to come from the target’s network. That way, when the DNS servers respond, they reply to the spoofed (targeted) address.

By taking advantage of an extension to the DNS protocol that enables large DNS messages, botmasters can dramatically boost the size and impact of a reflection attack — crafting DNS queries so that the responses are much bigger than the requests. For example, an attacker could compose a DNS request of less than 100 bytes, prompting a response that is 60-70 times as large. This amplification effect is especially pronounced when the perpetrators can query many DNS servers with these spoofed requests from tens of thousands of compromised devices simultaneously.

The exposed file archive includes a command-line history showing exactly how this attacker built and maintained a powerful botnet by scouring the Internet for TP-Link Archer AX21 routers. Specifically, the botnet seeks out TP-Link devices that remain vulnerable to CVE-2023-1389, an unauthenticated command injection vulnerability that was patched back in April 2023.

Malicious domains in the exposed Python attack scripts included DNS lookups for hikylover[.]st, and c.loyaltyservices[.]lol, both domains that have been flagged in the past year as control servers for an Internet of Things (IoT) botnet powered by a Mirai malware variant.

The leaked archive shows the botmaster coordinated their scanning from a Digital Ocean server that has been flagged for abusive activity hundreds of times in the past year. The Python scripts invoke multiple Internet addresses assigned to Huge Networks that were used to identify targets and execute DDoS campaigns. The attacks were strictly limited to Brazilian IP address ranges, and the scripts show that each selected IP address prefix was attacked for 10-60 seconds with four parallel processes per host before the botnet moved on to the next target.

The archive also shows these malicious Python scripts relied on private SSH keys belonging to Huge Networks’s CEO, Erick Nascimento. Reached for comment about the files, Mr. Nascimento said he did not write the attack programs and that he didn’t realize the extent of the DDoS campaigns until contacted by KrebsOnSecurity.

“We received and notified many Tier 1 upstreams regarding very very large DDoS attacks against small ISPs,” Nascimento said. “We didn’t dig deep enough at the time, and what you sent makes that clear.”

Nascimento said the unauthorized activity is likely related to a digital intrusion first detected in January 2026 that compromised two of the company’s development servers, as well as his personal SSH keys. But he said there’s no evidence those keys were used after January.

“We notified the team in writing the same day, wiped the boxes, and rotated keys,” Nascimento said, sharing a screenshot of a January 11 notification from Digital Ocean. “All documented internally.”

Mr. Nascimento said Huge Networks has since engaged a third-party network forensics firm to investigate further.

“Our working assessment so far is that this all started with a single internal compromise — one pivot point that gave the attacker downstream access to some resources, including a legacy personal droplet of mine,” he wrote.

“The compromise happened through a bastion/jump server that several people had access to,” Nascimento continued. “Digital Ocean flagged the droplet on January 11 — compromised due to a leaked SSH key, in their wording — I was traveling at the time and addressed it on return. That droplet was deprecated and destroyed, and it was never part of Huge Networks infrastructure.”

The malicious software that powers the botnet of TP-Link devices used in the DDoS attacks on Brazilian ISPs is based on Mirai, a malware strain that made its public debut in September 2016 by launching a then record-smashing DDoS attack that kept this website offline for four days. In January 2017, KrebsOnSecurity identified the Mirai authors as the co-owners of a DDoS mitigation firm that was using the botnet to attack gaming servers and scare up new clients.

In May 2025, KrebsOnSecurity was hit by another Mirai-based DDoS that Google called the largest attack it had ever mitigated. That report implicated a 20-something Brazilian man who was running a DDoS mitigation company as well as several DDoS-for-hire services that have since been seized by the FBI.

Nascimento flatly denied being involved in DDoS attacks against Brazilian operators to generate business for his company’s services.

“We don’t run DDoS attacks against Brazilian operators to sell protection,” Nascimento wrote in response to questions. “Our sales model is mostly inbound and through channel integrator, distributors, partners — not active prospecting based on market incidents. The targets in the scripts you received are small regional providers, the vast majority of which are neither in our customer base nor in our commercial pipeline — a fact verifiable through public sources like QRator.”

Nascimento maintains he has “strong evidence stored on the blockchain” that this was all done by a competitor. As for who that competitor might be, the CEO wouldn’t say.

“I would love to share this with you, but it could not be published as it would lose the surprise factor against my dishonest competitor,” he explained. “Coincidentally or not, your contact happened a week before an important event – ​​one that this competitor has NEVER participated in (and it’s a traditional event in the sector). And this year, they will be participating. Strange, isn’t it?”

Strange indeed.

A hacktivist group with links to Iran’s intelligence agencies is claiming responsibility for a data-wiping attack against Stryker, a global medical technology company based in Michigan. News reports out of Ireland, Stryker’s largest hub outside of the United States, said the company sent home more than 5,000 workers there today. Meanwhile, a voicemail message at Stryker’s main U.S. headquarters says the company is currently experiencing a building emergency.

Based in Kalamazoo, Michigan, Stryker [NYSE:SYK] is a medical and surgical equipment maker that reported $25 billion in global sales last year. In a lengthy statement posted to Telegram, a hacktivist group known as Handala (a.k.a. Handala Hack Team) claimed that Stryker’s offices in 79 countries have been forced to shut down after the group erased data from more than 200,000 systems, servers and mobile devices.

“All the acquired data is now in the hands of the free people of the world, ready to be used for the true advancement of humanity and the exposure of injustice and corruption,” a portion of the Handala statement reads.

The group said the wiper attack was in retaliation for a Feb. 28 missile strike that hit an Iranian school and killed at least 175 people, most of them children. The New York Times reports today that an ongoing military investigation has determined the United States is responsible for the deadly Tomahawk missile strike.

Handala was one of several hacker groups recently profiled by Palo Alto Networks, which links it to Iran’s Ministry of Intelligence and Security (MOIS). Palo Alto says Handala surfaced in late 2023 and is assessed as one of several online personas maintained by Void Manticore, a MOIS-affiliated actor.

Stryker’s website says the company has 56,000 employees in 61 countries. A phone call placed Wednesday morning to the media line at Stryker’s Michigan headquarters sent this author to a voicemail message that stated, “We are currently experiencing a building emergency. Please try your call again later.”

A report Wednesday morning from the Irish Examiner said Stryker staff are now communicating via WhatsApp for any updates on when they can return to work. The story quoted an unnamed employee saying anything connected to the network is down, and that “anyone with Microsoft Outlook on their personal phones had their devices wiped.”

“Multiple sources have said that systems in the Cork headquarters have been ‘shut down’ and that Stryker devices held by employees have been wiped out,” the Examiner reported. “The login pages coming up on these devices have been defaced with the Handala logo.”

Wiper attacks usually involve malicious software designed to overwrite any existing data on infected devices. But a trusted source with knowledge of the attack who spoke on condition of anonymity told KrebsOnSecurity the perpetrators in this case appear to have used a Microsoft service called Microsoft Intune to issue a ‘remote wipe’ command against all connected devices.

Intune is a cloud-based solution built for IT teams to enforce security and data compliance policies, and it provides a single, web-based administrative console to monitor and control devices regardless of location. The Intune connection is supported by this Reddit discussion on the Stryker outage, where several users who claimed to be Stryker employees said they were told to uninstall Intune urgently.

Palo Alto says Handala’s hack-and-leak activity is primarily focused on Israel, with occasional targeting outside that scope when it serves a specific agenda. The security firm said Handala also has taken credit for recent attacks against fuel systems in Jordan and an Israeli energy exploration company.

“Recent observed activities are opportunistic and ‘quick and dirty,’ with a noticeable focus on supply-chain footholds (e.g., IT/service providers) to reach downstream victims, followed by ‘proof’ posts to amplify credibility and intimidate targets,” Palo Alto researchers wrote.

The Handala manifesto posted to Telegram referred to Stryker as a “Zionist-rooted corporation,” which may be a reference to the company’s 2019 acquisition of the Israeli company OrthoSpace.

Stryker is a major supplier of medical devices, and the ongoing attack is already affecting healthcare providers. One healthcare professional at a major university medical system in the United States told KrebsOnSecurity they are currently unable to order surgical supplies that they normally source through Stryker.

“This is a real-world supply chain attack,” the expert said, who asked to remain anonymous because they were not authorized to speak to the press. “Pretty much every hospital in the U.S. that performs surgeries uses their supplies.”

John Riggi, national advisor for the American Hospital Association (AHA), said the AHA is not aware of any supply-chain disruptions as of yet.

“We are aware of reports of the cyber attack against Stryker and are actively exchanging information with the hospital field and the federal government to understand the nature of the threat and assess any impact to hospital operations,” Riggi said in an email. “As of this time, we are not aware of any direct impacts or disruptions to U.S. hospitals as a result of this attack. That may change as hospitals evaluate services, technology and supply chain related to Stryker and if the duration of the attack extends.”

According to a March 11 memo from the state of Maryland’s Institute for Emergency Medical Services Systems, Stryker indicated that some of their computer systems have been impacted by a “global network disruption.” The memo indicates that in response to the attack, a number of hospitals have opted to disconnect from Stryker’s various online services, including LifeNet, which allows paramedics to transmit EKGs to emergency physicians so that heart attack patients can expedite their treatment when they arrive at the hospital.

“As a precaution, some hospitals have temporarily suspended their connection to Stryker systems, including LIFENET, while others have maintained the connection,” wrote Timothy Chizmar, the state’s EMS medical director. “The Maryland Medical Protocols for EMS requires ECG transmission for patients with acute coronary syndrome (or STEMI). However, if you are unable to transmit a 12 Lead ECG to a receiving hospital, you should initiate radio consultation and describe the findings on the ECG.”

This is a developing story. Updates will be noted with a timestamp.

Update, 2:54 p.m. ET: Added comment from Riggi and perspectives on this attack’s potential to turn into a supply-chain problem for the healthcare system.

Update, Mar. 12, 7:59 a.m. ET: Added information about the outage affecting Stryker’s online services.

Koi has developed an endpoint security solution that Palo Alto will use to enhance its products.

The post Palo Alto Networks to Acquire Koi in Reported $400 Million Transaction appeared first on SecurityWeek.

Why AI's Biggest Risk Isn't Technical

This article is based on a conversation with Nikesh Arora on the 100th episode of the Threat Vector podcast.

"Most technologists think about technology, not about cybersecurity," Nikesh Arora says. "Cybersecurity is kind of like insurance. Let's go make great things happen, and let's make sure on the way we purchase insurance."

Coming from the CEO of the world's largest cybersecurity company, it's the quiet part said out loud, and it explains why AI deployment is racing ahead while security scrambles to keep up.

Earlier this year, Arora spoke with a CIO entirely focused on AI deployment challenges: building viable products, training models, measuring customer impact. Security never came up once. "If you're still going through the motion, trying to understand, ‘Can I actually make this thing work?’ You're not worried about security," Arora notes. The logic is brutal but consistent: Why secure something that might not even function?

In the Threat Vector podcast’s 100th episode milestone, Arora speaks with host David Moulton:

• Why the gap between innovation and security keeps widening.
• How to read inflection points before they're obvious.
• What separates organizations that prepare from those that scramble.

The Gap That Keeps Growing

The disconnect isn't new. It's the same psychology that makes airport security feel like overhead – necessary friction that slows down what should be seamless. But with AI, the gap is widening at an unprecedented pace.

Consider the infrastructure buildup happening right now. Nvidia has become a $4 trillion company selling chips that can't stay in stock. Hundreds of billions of dollars are flowing into AI-computer infrastructure. Cloud providers are buying out entire methane gas companies to power their data centers.

Yet organizations are treating AI security as something to bolt on later. That same CIO told Arora: "We worked on some stuff ourselves, and we're just jerry-rigging some things to make sure this happens securely."

Arora's response:

Jerry rig, production, and security don't work together as three terms.

Reading Signals Before They're Obvious

Arora has watched enough technology cycles to recognize the pattern. "You start seeing signs early, and then you look around, you don't see enough impact. You say, okay, maybe this is going to be just a passing shower. But you don't realize that over time this thing's getting more and more momentum."

The signs around AI are adding up:

• Individual behavior has shifted.
  Arora went from never talking to ChatGPT or Gemini to conducting 10-15 conversations daily. During a recent Tokyo trip, he used Gemini as his primary navigation tool, asking it to rank sumo wrestling shows for his kids rather than "trying to go read 14 websites and figure out what makes sense."
• The spend is massive and accelerating.
  Not just chips, entire energy infrastructures are being rebuilt to support AI compute needs.
• Consumer and enterprise adoption are both surging.
  From coding assistants to business analysis, use cases are expanding faster than security models can adapt.

"This thing's going to change our life fundamentally," Arora tells Moulton. "We're not seeing it at scale in our customers just yet. That doesn't mean we can sit back and wait."

Arora understands the risks involved in being late to new technology.

You have to not just anticipate where the trend is going. You have to prepare your organization and the resources to get there. Otherwise, the risk is that Silicon Valley will go fund those people who are thinking purely about the new world... and one of them's going to hit. Then you'll be two years behind with no organization, no resources deployed against it.

The Bets That Paid Off

When Arora joined Palo Alto Networks seven and a half years ago, he wrote two words on a piece of paper: cloud and AI. The company was a firewall business. Those two inflection points would require fundamental transformation, and, just as with AI now, being late was not an option.

If you don't get the network transformation right, 80% of our business will falter.

That insight drove a strategic bet on moving from point products to platform thinking, consolidating security tools rather than adding to the sprawl.

The platform approach wasn't about vendor consolidation for its own sake. It was about correlation. Unit 42® data shows that 70% of incidents now span three or more attack surfaces. When attacks move across endpoints, networks, cloud services and applications simultaneously, fragmented security creates gaps that attackers exploit ruthlessly.

Today we have coverage for 80 plus percent of the industry, which means our customers can come talk to us about a myriad of problems, and we can actually cross-correlate across all the different things we do.

With AI deployments touching every part of the technology stack, that cross-correlation becomes essential. Data flows between training environments and production systems. Models access APIs across cloud and on premises infrastructure. Applications consume AI services from multiple providers. Security that can't see and correlate across that entire landscape will miss the threats that matter most.

First Principles Over Tradition

What drives Arora's ability to spot inflection points isn't just pattern recognition, it's his refusal to accept how things have always been done.

His pet peeve: "Somebody said, well, this is how we've traditionally done it." The response reveals his approach: "You use the word traditional. I use the historical context saying, yeah, sure, they used to dig fields with picks and shovels, and now they use tractors."

This thinking drove Palo Alto Networks to reimagine SOC performance. The industry accepted four days as the normal time to detect and remediate security incidents. Arora called that unacceptable. "We need to get it to be real time."

The result was a fundamentally different architecture that analyzes data as it arrives rather than waiting for problems to appear, enabling 1-minute detection and response instead of four days.

Traditionally, SOCs would analyze the problem when the problem appeared. We said forget it. We're going to analyze everything to see if there's a problem. That architecture fundamentally transformed what we do compared to everybody else in the market.

The same first-principles approach needs to apply to AI security. Organizations can't simply extend existing security models and hope they work.

What Comes Next

With ransomware attacks now completing in as little as 25 minutes (100 times faster than just three years ago, according to Unit 42 research) reactive security simply can't keep pace. Organizations need security that thinks and responds at machine speed, built into AI deployments from day one.

"AI has become the biggest inflection point in current technology," Arora observes. Organizations are too busy deploying to worry about security. That's human nature. But it's also the moment when security teams need to stay in lockstep.

The question isn't whether to secure AI, it's whether security will be designed in or bolted on. The former takes strategic thinking now. The latter takes crisis management later.

Our job at Palo Alto and our industry is to make sure as they go build these experimental ideas into real production capability that we're staying in lockstep with them and saying, ‘Oh, by the way, here's something that can secure what you just built in a way that is not gonna get you into trouble.’

Listen to the full conversation between Nikesh Arora and David Moulton, senior director of thought leadership for Cortex^® and Unit 42, on the 100th episode of Threat Vector.

The post When Security Becomes an Afterthought appeared first on Palo Alto Networks Blog.

John talked about how we’d attack, here’s how you can defend against those attacks. Grab the slides here: https://blackhillsinformationsecurity.shootproof.com/gallery/6843799/

The post PODCAST: Attack Tactics Part 2 appeared first on Black Hills Information Security, Inc..

💾

Jordan Drysdale & Kent Ickler// Jordan and Kent are back with more blue team madness! The shameless duo continue their efforts to wrangle decades old attacks against wireless networks. The […]

The post WEBCAST: Stop Sucking at Wireless appeared first on Black Hills Information Security, Inc..

Ethan Robish // In this series of posts, I’ll discuss how I segmented my home network using VLANs and how I moved away from using a risky consumer-grade router at […]

The post Home Network Design – Part 1 appeared first on Black Hills Information Security, Inc..

Christine Sorensen // Let’s talk about Mary. Mary Watson is a girl in her twenties and just graduated from Midtown University with her bachelors in Fashion Merchandising. Mary is now […]

The post Mining Mary’s Social Media Antics for Social Engineering appeared first on Black Hills Information Security, Inc..