The U.S. State Department has posted a $10 million reward for Amir Yaryab, a senior Iranian official accused of leading the Islamic Revolutionary Guard Corps Cyber-Electronic Command (IRGC-CEC) Cyber Operations Command and directing multiple hacking groups targeting critical infrastructure across the United States, Europe and the Middle East.
According to the Rewards for Justice program, Yaryab allegedly oversees cyber operations conducted by IRGC-CEC-affiliated groups including CyberAv3ngers, Dadeh Afzar Arman (DAA) and Mehrsam Andisheh Saz Nik (MASN). U.S. officials accuse these groups of using malware and conducting cyber and cyber-enabled information operations against civilian infrastructure worldwide.
$10 Million Reward for Amir Yaryab
The $10 million reward for Amir Yaryab seeks information leading to his identification or location. The offer applies to individuals acting at the direction or under the control of a foreign government who participate in malicious cyber activities against U.S. critical infrastructure in violation of the Computer Fraud and Abuse Act.
[caption id="attachment_113961" align="aligncenter" width="600"] Image Source: https://rewardsforjustice.net/[/caption]
Yaryab is also accused of directing Shahid Hemmat and Shahid Shushtari, two groups linked to cyberattacks against U.S. organizations. The sectors allegedly targeted include defense, news, shipping, travel, energy, financial services and telecommunications.
The six Iranian officials named in the advisory are linked to Iran's Islamic Revolutionary Guard Corps and its Cyber-Electronic Command.
Iranian Cyberattacks Target PLCs
The allegations also involve attacks against programmable logic controllers (PLCs), highlighting concerns around Iranian cyberattacks targeting industrial systems rather than focusing only on data theft.
U.S. officials said Iranian-linked hackers compromised industrial control systems, specifically targeting the Vision series of PLCs manufactured by Israel-based Unitronics. These devices are used across water and wastewater, energy, food and beverage, manufacturing and healthcare sectors.
The attackers exploited default credentials on the devices and left anti-Israel messages. Some of the compromises reportedly rendered the PLCs inoperative.
The CyberAv3ngers group, which is linked to the IRGC-CEC, claimed responsibility for attacks against Unitronics Vision PLCs in October 2023. Beginning in November 2023, the group compromised default credentials in PLCs across the United States and left messages on the devices' digital screens.
CyberAv3ngers Attacks Critical Infrastructure
CyberAv3ngers has also claimed responsibility for attacks affecting other infrastructure. In October 2023, the group claimed it had breached ORPAK Systems, a provider of gas station solutions in Israel. The group said it had obtained the company's database and intended to publish it through its Telegram channel.
The attack was reported to have disconnected 200 gasoline pumps from the system in the occupied Palestinian territories.
In December 2023, CyberAv3ngers also claimed to possess and sell 1TB of data allegedly linked to Israel's electricity infrastructure. The group advertised the dataset for 5 Bitcoin, with an initial 100GB portion also offered at the same price.
U.S. Agencies Warn of PLC Cyberattacks
Concerns over critical infrastructure attacks involving PLCs continued into 2026. A joint advisory issued on April 7 by the FBI, CISA, NSA and other agencies warned that Iran-linked threat actors were actively exploiting internet-facing PLCs.
The advisory said several organizations had experienced operational disruptions and financial losses after attackers interfered with industrial processes.
The developments come amid broader U.S. actions against Iranian-linked cyber activity. The Justice Department accused Iran-connected hackers of breaching employee email accounts associated with the Department of Labor, the Federal Energy Regulatory Commission and multiple United Nations organizations. The Treasury Department also sanctioned Iranian nationals over cyberattacks targeting critical infrastructure.
The State Department's reward offer places Amir Yaryab and the alleged activities of IRGC-CEC-linked groups at the center of the U.S. effort to identify individuals responsible for malicious cyber activity targeting critical infrastructure.
The CISA and FBI, along with cybersecurity agencies from Australia, Canada, New Zealand and the U.K., have released new guidance on outage communications for service providers dealing with major IT and OT outages. The guide calls for prompt, factual and audience-specific communication during disruptions caused by malicious cyber activity or non-malicious events.
Titled “Communicating Under Pressure: Best Practices for Service Providers,” the guidance says effective communication is critical to limiting operational impact when IT and OT outages affect customers, network defenders, critical infrastructure owners and operators, and the public. It recommends that organizations clearly communicate what is known, what remains unknown and what is still under investigation, while providing frequent updates as circumstances change.
Outage Communications Should Start With Facts
The agencies recommend that service providers establish an outage communications plan before an incident occurs. The plan should define incident thresholds, escalation paths, target audiences and procedures for status pages, customer and partner notices, and regulatory communications. Organizations are also advised to establish cross-functional incident teams involving engineering and operations, communications, legal, risk and compliance, and customer support.
The guidance calls for clearly defined roles, including an incident lead, communications lead and spokesperson. It also recommends parallel workstreams so technical teams can focus on diagnosing and remediating the root cause while communications teams manage external messaging and leadership handles strategy and regulatory requirements.
For organizations responding to cyber incidents, the guidance places particular emphasis on balancing transparency with operational security. If malicious activity is suspected or confirmed, external communications should not compromise investigations, containment efforts or other response activities. Organizations are also advised against making premature conclusions when the root cause remains under investigation.
Service Providers Urged to Tailor Messages
The guidance recommends segmenting communications for technical teams, executives and the public. Audiences can include enterprise IT teams and security operations centers, employees and customers, government partners and regulators, critical infrastructure owners and operators, as well as the media and general public.
During an outage, organizations should lead with a concise summary covering affected systems, user impact, scope and the known cause without speculation. The agencies also advise against vague descriptions such as “service degradation” and recommend messaging that can be understood quickly during high-pressure situations.
Transparency is another central principle. Service providers are advised to state what they know and do not know, use a single source of truth such as a status page, and focus communications on actionable guidance rather than reputation management. Customers should be told what actions they need to take or clearly informed when no action is required.
The guidance also calls for continuous, time-stamped updates that show the incident timeline, actions taken, and recovery milestones. Organizations should maintain a single status page and align external messaging with legal, contractual and sector-specific reporting obligations.
Agencies ultimately frame effective outage communications around five principles: immediate acknowledgement, technical and actionable information, transparency, accountability, and continuous updates. For service providers, the guidance positions communication as an important part of incident response, alongside technical remediation and recovery.
Each service declined to answer questions about how many bases are affected by the outages, referring all questions to the Defense Department. Pentagon officials did not respond to questions.
However, a defense official said the department is aware of a “possible refrigeration disruption at some Defense Commissary Agency commissaries.” The official was not authorized to comment publicly and spoke on the condition of anonymity.
All speculation at this point, but it’s hard to come up with another explanation for the coincidence.
CISA red teams fully compromised two critical infrastructure orgs. One SOC isolated hosts in minutes; the other never detected the breach.
CISA published an advisory (AA26-237A) documenting two simultaneous red team assessments at critical infrastructure organizations. Both organizations lost full domain control and had their cloud environments compromised. One of them didn’t know until CISA told them afterward.
“The Cybersecurity and Infrastructure Security Agency (CISA) conducted simultaneous red team assessments at two organizations and observed different defensive outcomes. In both environments, the red team achieved full domain compromise and accessed sensitive business systems (SBSs) and cloud resources.” states CISA. “Organization A failed to detect or contain the activity, but Organization B rapidly identified initial compromise attempts, isolated affected systems, and forced the red team into an assume breach model.”
Organization A is a Government Services and Facilities Sector entity. Organization B operates in the Water and Wastewater Systems Sector. The red team used comparable techniques against both. The difference in outcome was entirely about detection and response, not the sophistication of the attack.
At Organization A, the red team found a web application that still used default credentials. They used it to send phishing emails from a trusted internal address and gained access to four workstations. From there, they exploited a misconfigured Active Directory Certificate Services template with the ESC1 flaw. This allowed a low-privileged user to request certificates for other users, including administrators. They then reached all the targeted sensitive business systems without anyone noticing. After moving into the cloud, they even read SOC staff emails to see if the attack had been detected. It hadn’t.
“Without well-defined baselines and alert filtering, false positives and routine alerts overwhelm defenders, obscuring real threats.” CISA continues. “Organizations that tune alerts to highlight anomalies and filter out normal business activity enable defenders to focus on genuine incidents and respond rapidly.”
Organization A’s SOC was receiving thousands of false positive alerts, many at higher severity than the actual intrusion alerts the red team was generating. Staff eventually reviewed SCCM-related alerts from real red team activity, couldn’t identify the system’s owner or function, and marked it a false positive.
The red team confirmed the miss by reading SOC email. Then they used keyloggers and screenshot capture on SOC workstations to make sure nothing was coming. Nothing was. The organization had multiple separate SOCs with different EDR solutions and no cross-team visibility, which meant that even if one team noticed something, there was no mechanism to act on it across the relevant systems.
“Detection tools are only as effective as the people, processes, and procedures supporting them. SOC staff should not operate in silos and should have clear authority unhindered by bureaucracy to effectively contain and resolve incidents.” add CISA.
At Organization A, SOC analysts were managing systems they didn’t fully understand and had no written escalation procedures, so their default response to ambiguity was to wait. At Organization B, staff triaged, investigated, coordinated with engineering, and reimaged machines before handing them back to users.
At Organization B, the red team still found important security gaps. They discovered a password stored in plain text inside an XML file on an SCCM distribution point. They used the related service account to gain powerful rights over a domain controller and then performed a DCSync attack, obtaining the krbtgt hash. This allowed them to create Golden Tickets and impersonate users across the domain.
They also found a path into the OT network through RDP files pointing to a bastion host. Using FTP credentials found on a jump server, they connected to the bastion through SSH. The bastion had no outbound internet access, so their payload could not run, and the SOC quarantined the host. Still, the access path was there.
Both organizations also had the same cloud security problem: neither had enabled Conditional Access for workload identities. This Microsoft feature applies access controls to applications and service accounts, not just human users. Without it, applications with broad Microsoft Graph permissions can bypass normal Conditional Access rules. CISA’s red team used this gap in both organizations to access emails across the companies.
In Organization A, the team also found AWS IAM credentials stored in users’ home directories with no expiration date. Those credentials could remain valid indefinitely, creating another long-term risk.
In Organization B’s cloud environment, the red team abused Seamless SSO by using Kerberos tickets obtained via DCSync to authenticate to Azure without needing any user’s cleartext password. They found a disabled AD-synced account that owned an application with permission to read, write, and send emails for every user in the tenant. They re-enabled the account, DCSynced its credentials, added a client secret to the application, and could then access the full mailbox of every employee from the public internet. Organization B’s detections flagged the AzureHound tool by user agent and caught anomalous Microsoft Graph API request volumes, but those controls arrived after the initial cloud access was already established.
CISA recommends several practical steps to improve security. These include hardening ADCS by disabling CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT on templates and limiting who can enroll, setting the Machine Account Quota to zero when there is no operational need, and removing cleartext credentials from workstations and network shares.
Organizations should also enable Conditional Access for workload identities, create procedures to revoke tokens, and treat SCCM and similar endpoint management platforms as Tier 0 assets, giving them the same level of protection as domain controllers.
The full advisory also maps each red team technique to its MITRE ATT&CK identifier and compares how well the two organizations detected the different stages of the attacks.
NSA, CISA, FBI, DOE, and EPA warn of active AI-assisted attacks against Siemens S7 PLCs across US critical infrastructure sectors.
Five U.S. federal agencies issued a joint advisory this week warning of an active hacking campaign against Siemens S7 Series programmable logic controllers. The advisory, CISA AA26-231A, is co-signed by NSA, FBI, DOE, and EPA and covers every S7 generation, from the S7-200 to the S7-1500 F-series safety controllers.
The advisory is direct about one thing from the first paragraph: this is not a theoretical risk.
“The threat actors are conducting reconnaissance and capability development against U.S.-based Siemens PLC installations using AI-generated exploitation scripts disguised as legitimate monitoring tools. The actors leverage Internet scanning services to find Internet-exposed PLCs running outdated software or that are otherwise poorly protected.” reads the advisory. “The U.S. critical infrastructure sectors most targeted by this threat activity include Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. This is not a theoretical risk—it is an active threat. “
The key detail is how the attackers try to hide their activity. They make their scripts look like legitimate OT monitoring software, making it harder for security teams to notice them while they map the target environment.
The tools themselves are not custom malware. The attackers use the open-source snap7.dll and python-snap7 libraries, which are legitimate industrial automation tools. These libraries can communicate directly with Siemens PLCs over S7comm on TCP port 102, allowing access to PLC memory, configuration data and ladder logic programs.
“Using AI to generate exploitation scripts represents an evolution in threat actor capabilities, dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts and malicious tools. In addition, AI enables adversaries to rapidly leverage additional attack vectors and adapt to defensive measures.” continues the advisory. “Threat actors can easily collect public information about vulnerabilities and weaknesses, find exposed and exploitable PLCs, and use AI-generated scripts to act on that information. If PLCs are exposed to the Internet, they are at high risk for exploitation.”
Researchers warn that a defender who patches a vulnerability may now find the attacker’s tooling already adapted before the change window closes.
The observed activity breaks into two phases. Actors use scanning services like Censys and ZoomEye to locate Internet-exposed PLCs, then run read operations to understand the target environment before any writes happen. The authoring agencies assess this as pre-positioning: the actors are building a map and testing their techniques against specific CPU models, refining as they go, before they’re ready to cause disruption.
The target list covers Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. The Defense Industrial Base is also named, given its use of S7-series hardware. If these actors move from read to write, the potential consequences include process disruption, equipment damage, and safety incidents through manipulation of interlocks or emergency shutdown systems, and cascading effects across interconnected supply chains.
The advisory flags third-party exposure as a specific problem. Asset owners who rely on system integrators or managed service providers for remote PLC access may not know their controllers are reachable from the Internet. If an external support partner holds credentials for your S7 devices and you haven’t recently verified that those connections are segmented and monitored, this advisory is a good prompt to check.
There are several clear signs defenders can monitor. They should look for S7comm connections from devices that are not normally used for engineering, PLC read or write activity outside scheduled maintenance, and scans of multiple IP addresses on TCP port 102. It is also worth checking for Python processes loading snap7.dll on systems where it should not be present. Connections from unexpected countries or locations should also raise an alert.
On the mitigation side, the agencies prioritize inventory first, then patching with Internet-facing controllers at the top of the queue. Block TCP port 102 at the perimeter firewall, require password protection on all controllers, configure protection levels to limit what an unauthenticated or low-privilege session can read or write, and deploy ICS-aware monitoring capable of baselining legitimate S7comm behavior. Disabling the PLC web server where it’s not needed and limiting simultaneous S7comm sessions also appear in the guidance, alongside TIA Portal’s know-how protection and complete restart protection features.
The advisory closes by recommending direct engagement with Siemens ProductCERT for model-specific hardening and patch compatibility verification, which matters in OT environments where a firmware update can interact badly with third-party integrations and can’t simply be rolled back.
Iran-linked hackers targeted Water Infrastructure in New Jersey and Alabama, bringing confirmed attacks to at least 12 states, with limited disruption.
The wave of cyberattacks targeting US water infrastructure has reached New Jersey and Alabama, bringing the confirmed count to at least 12 states since late July. The attacks are linked to Iranian hackers targeting industrial control systems made by Rockwell Automation and potentially other major vendors. Minnesota was the first to confirm over 30 affected water systems, followed by Michigan, South Dakota, and Georgia, and now two more states.
“The City of Cape May Sewer Department and the Borough of Woodbine Water Department reported the attacks on Thursday. Officials said the attacks happened nearly simultaneously early in the morning on July 27.” reports Fox29 “Both systems were impacted for approximately 12 hours.”
Water kept running in both New Jersey districts throughout the incident, and tests afterward confirmed no impact on water quality or safety. Cape May city manager Paul Dietrich told Fox29 that hackers changed settings to prevent remote access to the system, but did not take control of the systems to do anything — which is a meaningful distinction, and not the kind anyone wants to be making about their water supply.
“Cybersecurity experts say hackers could control a lot after breaking into a local water system. ‘They’re actually having the ability to control the water pressure, meaning that they could increase the pressure and cause flooding, or they could decrease the pressure so that you would have a reduced pressure, or ultimately, have no water flow at all,’ said Ian Marlow, CEO of FITECH.” continues Fox29.
In Alabama, the Childersburg Water, Sewer and Gas system was hit the same day, July 27, with hackers targeting industrial control systems. The attack didn’t disrupt water services there either. Neither department’s customer data was accessed in New Jersey, and no significant service disruption was reported in Alabama.
“The Childersburg Water, Sewer, and Gas Board reported that its computerized monitoring and control network was targeted in a cyberattack late last month, prompting officials to temporarily disconnect the system while additional safeguards are put in place.” reports Sylacauga News. “According to the utility, the incident occurred on Monday, July 27 and involved a programmable logic controller, a type of industrial device used to help manage utility operations. Officials said the attack was part of a broader effort that also targeted several other public utilities.”
The pattern across all confirmed states is consistent: attacks targeted operational technology and industrial control systems, some facilities shut down systems as a precaution, disruptions were limited, and drinking water remained safe in every case. The FBI confirmed at least seven states had been targeted as of July 30. Wisconsin, Pennsylvania, and Washington have issued warnings to water utilities without confirming attacks. New York has not said whether its utilities were hit but announced more than $9 million in grants to strengthen water sector cybersecurity.
The practical lesson from every confirmed case so far is the same one CISA has been repeating since its July 30 alert: get PLCs and industrial control systems off direct internet exposure, because the attackers are scanning for exactly that exposure and finding it.
A quarter million commercial vehicles in India and sensitive data on tens of thousands of drivers were vulnerable to attacks because of flaws in widely used fleet management software maintained by a VE Commercial Vehicles, a joint venture between the Volvo Group and Eicher Motors, a security researcher has revealed.
And it seems like this is a campaign that has targeted at least seven states. And, because this is where the US is right now, Trump doesn’t believe it’s Iran and that Minnesota…I guess…hacked itself.
“I think I blame it on Minnesota because they’re grossly incompetent,” Trump said. “I would blame it on Minnesota and the governor, the corrupt governor of Minnesota. They like to say, ‘Oh, it’s Iran.’ Iran should be so lucky. Iran’s got bigger problems than worrying about Minnesota.”
No word on whether he believes the other six states have hacked themselves as well.
Once the attacker has breached the corporate network, subsequent stages of the attack often involve leveraging standard domain infrastructure protocols: using Kerberos, running DNS queries, accessing internal services, opening network shares, and other common networking actions. Because this activity is virtually indistinguishable from legitimate network traffic, it is extremely difficult to detect it with traditional network attack detection tools.
Kerberoasting and DNS tunneling have long ceased to be exotic techniques. They are becoming standard methods in modern attacks because they allow attackers to execute critical compromise stages while remaining undetected by traditional security tools. A clear example of this trend is seen in latest campaigns, employing both Kerberoasting and DNS tunneling.
Traditional network security tools perform well when the attack features a distinct and identifiable indicator: a characteristic query string, a known malicious traffic pattern, or the source code of an already discovered exploit. While this approach to threat detection remains effective, it cannot always be applied to discovering network attacks that blend seamlessly with legitimate traffic inside a corporate network.
Instead of searching for explicit indicators of attack, Network Anomaly Detection (NAD) analyzes all traffic for suspicious artifacts that deviate from the host’s typical network activity. Within Kaspersky’s solution portfolio, this technology is implemented specifically in the Kaspersky Anti Targeted Attack (KATA) platform.
The system analyzes network traffic data (DNS, DCE/RPC, Kerberos and other packets) and extracts key parameters used to identify anomalous behavior. This approach enables searching for attacks on domain controllers, signs of traffic tunneling and exfiltration, C2 communications, and other scenarios that may point to compromise of network infrastructure.
However, Network Anomaly Detection is not built on a single, universal set of indicators. Each attack scenario employs tailored detection models that account for the specifics of the corresponding network protocol, typical host behavior, and characteristic deviations from that baseline. This article examines two practical examples – detecting Kerberoasting and DNS tunneling – to demonstrate how these principles are implemented in KATA’s NAD rules and why this approach proves more effective than traditional signature-based analysis.
Kerberoasting attack detection by KATA
Why standard tools have a hard time detecting Kerberoasting
The Kerberoasting attack leverages the standard operational logic of the Kerberos protocol. The attacker identifies service accounts configured with a Service Principal Name (SPN), requests a Ticket-Granting Service (TGS) ticket for them, and attempts to crack the password offline using a dictionary attack against the retrieved ticket. If the password is weak or hasn’t been changed in a long time, the adversary can bruteforce it to get it in cleartext. Subsequently, these compromised credentials can be leveraged for both vertical and horizontal movement across the network.
The essence of a Kerberoasting attack is that an adversary possessing a compromised low-privileged account and a valid Ticket-Granting Ticket (TGT) for that account can request TGS tickets with weakened encryption for service accounts with SPNs. Crucially, it doesn’t matter whether the compromised account actually holds access permissions for those services. Having obtained these tickets, the attacker can then take them offline and bruteforce the service account’s password by trying to decrypt the corresponding ticket locally, without generating any network activity. As the encryption key is based on the password hash, the adversary can guess the password upon finding the correct key.
The attacker’s objective is to find a service account that has a simple password. Most likely, this will be an account created manually by the administrators of the infrastructure or a service. This is precisely why attackers are not interested in system service accounts with SPNs (such as CIFS/fileserver.company.local); these are generated automatically and feature highly complex passwords that are impossible to bruteforce.
We should note that the TGS ticket requests made by attackers are identical to standard, legitimate requests. Every domain naturally exhibits a high volume of Kerberos traffic. Therein lies the primary challenge of detecting Kerberoasting: legitimate service ticket requests (TGS-REQ) are indistinguishable from those issued by attackers. Consequently, the primary detection method relies on correlating indirect indicators rather than signature matching. Key indicators include an anomalous request source (atypical host or user account), a surge in requested SPNs within a short time window, attempts to obtain service tickets for sensitive or privileged service accounts, and off-hour timing or unusual request volume when benchmarked against the historical profile of both the user and the host.
Most of these indicators can be detected using NAD technology, which helps analysts cut through high volumes of Kerberos traffic to establish a concrete hypothesis: who initiated the Kerberoasting attack, which service accounts are at risk, and why this activity deviates from the baseline.
In the context of this attack, the network anomaly stems from a single host – likely using a single user account (cname) – receiving TGS tickets ("msg_type": "KRB_TGS_REP") for numerous unique services with SPNs (sname) within a short timeframe. These service accounts are non-system accounts.
Example of a TGS-REQ – TGS-REP event pair from network session attributes
To detect this anomaly, the NAD rule titled “Signs of a Kerberoasting attack” implements the following logic:
From Kerberos network sessions during the search depth period, select only those with a successful Kerberos TGS-REP response, subject to the following conditions:
The IP address that initiated the session must not be excluded in the excl_sip variable.
The requesting client name (cname) must not be included in the excluded users list (excl_users variable).
The SPN (sname) must not be excluded within the rule. System SPNs are omitted from detection logic because they exist across most corporate environments and hold no interest for adversaries in this attack vector; including them in the total count of unique SPNs could lead to predefined threshold being exceeded, triggering false positives.
Extract the cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.
Group the sessions by the source IP address and client account name (cname), while aggregating sessions with unique SPNs.
Generate an alert if a single IP address using a single client account receives TGS-REP responses for N unique SPN names within the specified search depth window, where N equals or exceeds the threshold variable count_spns.
Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).
We should note that this type of logic cannot be implemented using IDS signatures. Consider creating a Suricata rule designed to detect Kerberos TGS-REP packets. To minimize false positives, we’ll exclude system SPNs (which carry highly complex passwords) and apply a threshold for the number of responses a single client can receive. However, such a rule cannot evaluate the uniqueness of the requested SPNs; it can only track packet counts. As a result, this signature would produce a high volume of false positives because any domain naturally generates large amounts of identical legitimate TGS-REP messages.
Furthermore, adding exclusions and tuning thresholds to fit your specific infrastructure environments is significantly more practical when managed through user variables in the interface rather than directly modifying the underlying structure of the IDS rule itself.
Creating a Network Anomaly Detection rule
Network Anomaly Detection (NAD) rules are written as SQL queries executed against KATA’s ClickHouse database. Below, we demonstrate how to add and deploy a rule.
To begin working with NAD rules, navigate to the “Custom rules” section of the interface and select “Intrusion detection”. Under the “Network Anomaly Detection” tab, you can create a new rule.
The Network Anomaly Detection page UI
When adding a new rule, an analyst can select an appropriate rule template from the prebuilt set supplied with product updates. They can also manually modify the rule added from the template (converting it to a custom rule while keeping the original template intact) or author a rule from scratch using the provided guide.
Upon selecting a template, the analyst can review the rule description and either adjust or leave the default values for the following settings:
Search depth (the lookback window over which the SQL query will run)
Schedule (the execution frequency for running the query against the specified search depth)
Event regeneration period (the timeframe during which identical alerts will be aggregated into a single record rather than displayed as distinct events)
UI for creating a new NAD rule
To ensure the rule functions correctly, we recommend navigating to the “SQL-specific query” tab before deployment to review the variables used within the rule – a description for each variable is available by hovering over the question mark icon.
The variables are lists of IP addresses, dates, strings or numeric values that define the network infrastructure – such as domain controllers, DNS servers, time ranges, critical segments, and other entities. This allows you to tailor each rule to different network environments and incorporate specific infrastructure characteristics without modifying the underlying logic.
In our example, using variables allows you to adjust the “Signs of a Kerberoasting attack” rule as follows without altering the underlying SQL query:
Exclude the source IP address of the TGS-REQ requests from the scope of detection logic (you can specify a single address, a subnet mask, or a dictionary containing addresses and subnets) as well as the requesting client account (accepts a single value or a dictionary with multiple values).
Adjust the threshold value required to trigger an alert based on the number of unique SPNs in the TGS-REQ messages.
Query contents and variables used in the new rule
On this same page, you can test if the rule is functional prior to saving it.
Rule execution test results
When this rule triggers, an NDR:NAD alert is generated. In the alert card, the analyst can review basic information: IP addresses, ports, and participating network endpoints.
Alert card for the NAD rule
From there, the analyst can navigate to the associated event, which provides a detailed breakdown of the anomaly alongside links to the affected hosts.
NAD rule triggering event
If needed, the analyst can view and export the network sessions associated with the alert. These sessions can be accessed directly from the alert or within the event card via the “Show related” drop-down list.
Network sessions that triggered the rule
Within an individual session, the analyst can inspect standard details including interacting parties, data volume sent and received, and other fields and metrics. On the “Attributes” tab, the analyst can review the specific events recorded within that session.
Network session attributes
Detecting DNS tunneling in KATA
How DNS tunnels work
DNS tunneling is a technique used to transmit data or control malware through firewalls by encoding information within DNS protocol requests and responses. Instead of performing standard name resolution, an infected host transmits data encoded within subdomain strings and receives response data via DNS records. This covert channel can be leveraged for C2 communication, bypassing network restrictions, or data exfiltration.
One method of implementing DNS tunneling involves utilizing TXT records. In this scenario, the client issues DNS TXT record queries for domain names where the right-hand portion of the domain name (the higher-level domains) remains static, while the left-hand portion (the lowest-level subdomain) carries encoded or encrypted data sent from the client to the server. Under this structure, a sample domain name might look like ZFcABQAIBA[.]testlab[.]local, where testlab[.]local serves as the static right-hand portion and ZFcABQAIBA represents the variable left-hand string containing the data transmitted by the client.
In response to these queries, the server delivers commands or messages inside the data field of the TXT response. Because the right-hand portion of the domain name remains static, all client queries are consistently routed to the same C2 server, even if the intermediate DNS resolvers targeted by the client change.
DNS query (left) and corresponding response (right) during DNS tunneling via TXT records
It is rather challenging to identify this malicious activity within DNS traffic without generating false positives. DNS traffic is permitted across almost all corporate networks, long domain names occur routinely in both internal and external environments, and TXT records are frequently leveraged for legitimate operational purposes.
Suspicion is established through a combination of indicators: a high volume of long, seemingly random subdomains associated with a single top-level domain, high request frequency, an unusually large number of unique names, non-standard record types, and significant data transfer volumes within a single DNS session.
By analyzing DNS traffic for threat detection, we identified three primary fields of interest:
Requested DNS name
DNS record type
TXT data field within the response
As shown in the image above, all of these fields are present in the DNS response. In a real-world scenario, a tunnel of this nature will transmit a volume of data that is abnormally large compared to standard DNS traffic.
Data exchange within a DNS tunnel
Thus, in the context of DNS tunneling, a network anomaly occurs when 1) a single query source host sends data embedded in the variable left-hand portion of domain names (rrname) while 2) maintaining a static right-hand portion (rrname) and 3) receives DNS server responses containing TXT records (rtype) with varying data (rdata), while 4) the total volume of data transmitted in the left-hand portion of the requested domain name together with the TXT data response (rdata + rrname) exceeds a predefined threshold.
Request and response events from DNS session attributes
When detecting DNS tunneling, the following nuances must be considered:
A single tunnel will not be constrained to a single DNS session; data may be transmitted across multiple sessions with the DNS server, or each individual request may occur within a separate session.
A client DNS query can contain more than one requested domain name.
A DNS response can contain multiple TXT records, as well as a large volume of various non-TXT record types.
Traffic between DNS servers must be excluded, as it duplicates client requests and can trigger false positives.
Although the factors outlined above (an abnormally large or frequently changing left-hand subdomain alongside a static right-hand domain, or an unusually long string in a TXT record) serve as key indicators of DNS tunneling, they can also occur within legitimate network traffic.
These challenges create a high likelihood of false positives when detecting DNS tunneling, particularly when using IDS-based tools. Writing an accurate IDS rule for this type of activity is practically impossible. With rare exceptions, DNS tunneling tools possess static markers that can be leveraged for signature-based detection. However, in the absence of such markers, signature methods fail to deliver high detection accuracy without generating an overwhelming number of false positives. In these cases, a comprehensive approach combining multiple correlated indicators is essential to improve overall detection quality.
DNS tunneling detection logic
To add a rule for detecting this anomaly, you can use the prebuilt “DNS data tunneling via TXT records” template in the new rule creation interface. The “SQL-specific query” tab will display the list of variables used:
user_DNS_servers: a list of internal DNS server addresses within the infrastructure, required for the rule to function correctly and minimize potential false positives
excl_sip: IP addresses to be excluded from the scope of the rule (you can specify a single address, a subnet mask, or a list containing both addresses and subnets)
traffic_size: the threshold value for the total volume of data (in bytes) transmitted through the tunnel
Variables used in the “DNS data tunneling via TXT records” rule
The detection logic for this network anomaly is structured as follows:
From network sessions using the DNS protocol within the timeframe defined by the rule’s search depth, select only those sessions containing at least one TXT response.
Additionally:
The IP address that initiated the session must not be excluded in the excl_sip variable.
The source IP address that initiated the session must not belong to the internal DNS servers listed in the user_DNS_servers variable.
The DNS names requested by the client must not be excluded within the rule.
Split qualifying DNS sessions into individual log lines, each corresponding to an individual request or response. Retain only DNS responses containing TXT data.
Extract DNS names and their associated TXT data from these DNS responses. Retain only unique values.
Group all resulting records by the session’s source IP address, aggregating all unique DNS names and TXT data blocks.
Generate an alert if the combined size (in bytes) of the unique DNS names and TXT response data for a single IP address within the search depth window exceeds the specified threshold (the traffic_size parameter).
Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).
“DNS data tunneling via TXT records” rule triggering event
The primary value of NAD technology in this scenario lies in noise reduction – by minimizing false positives – and faster investigation times. A DNS tunnel rarely presents itself as a single, blatantly malicious request. Instead, it leaves behind a behavioral footprint: repetition, length, domain structure, unusual record types, numerous subdomains branching off an unchanging root domain, and anomalous host behavior. KATA consolidates these indicators into a single alert, presenting the analyst with an actionable attack hypothesis rather than a set of fragmented DNS events.
Prebuilt rules for detecting network anomalies in KATA
KATA users should note that Network Anomaly Detection (NAD) rules are not enabled by default. Rules must be added manually using the procedure described in the preceding sections. This design ensures that analysts can fine-tune rules to fit specific network infrastructures using variables.
Analysts have three ways of creating new rules:
Adding a rule from a prebuilt template and adjusting custom variables. In this case, the rule is classified as a system rule.
Adding a rule from a prebuilt template and modifying its underlying SQL query (which requires enabling the “Unlock all template values” option) to create a custom rule based on the template. When modified this way, the rule transitions from a system rule to a custom rule.
Authoring a custom rule from scratch, which requires a basic understanding of ClickHouse SQL queries and familiarity with the product documentation.
As of this publication, the product ships with 59 prebuilt NAD rule templates (with additional templates delivered via product updates). KATA supports running up to 200 active rules simultaneously.
Prebuilt rules are divided into six categories:
Large Data Transfers: tracking abnormally large network sessions across various protocols during regular hours, at night, or over weekends.
Suspicious Connections: detecting suspicious connections that may indicate hazardous activity, shadow IT, evasion of attack detection mechanisms, and other threats.
Connections to Suspicious Resources: detects actions that violate security policies, potential data exfiltration beyond the perimeter, and unauthorized internet access originating from secured network segments.
C2 Communication: identifies network sessions characteristic of a potential C2 communication channel or tunnel.
The table below lists the rule templates for detecting network anomalies in KATA:
Rule category
Rule name
Protocols used
Large Data Transfers
Data tunneling in DNS traffic
DNS
ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic (6 rules)
ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule)
ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic at nighttime (6 rules)
ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule)
ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic on non-working days (6 rules)
ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule)
Suspicious Connections
Queries to unknown DNS servers
DNS
Use of unauthorized routes
TCP, UDP
Use of suspicious ports for connections to external addresses
TCP, UDP
Use of non-typical protocols for connections
TCP, UDP, HTTP, HTTPS, DNS, SMTP
Inconsistencies with firewall configuration
TCP, UDP
Use of unauthorized ports for RDP or SSH sessions (2 rules)
RDP or SSH (depends on selected rule)
Interactions with external IP addresses over the RDP or SSH protocol (2 rules)
RDP or SSH (depends on selected rule)
Suspicious RDP sessions with domain controllers
RDP
Connection to an unknown server via Kaspersky Security Center ports
TCP, UDP
Domain Attacks
Signs of a DCSync attack
DCE/RPC
Signs of a DCShadow attack
DCE/RPC
Signs of DHCP spoofing
DHCP
DNS queries to Canarytoken domains
DNS
Signs of a Kerberoasting attack
Kerberos
Signs of an AS-REP Roasting attack
Kerberos
Signs of a brute-force password attack on SSH
SSH
Signs of SOAPHound usage
LDAP
Large-volume Active Directory object data collection via LDAP queries
LDAP
Reconnaissance Activity
Getting information about a task in the Task Scheduler
DCE/RPC
Getting a list of Kerberos users
Kerberos
LDAP queries to rights delegation attribute
LDAP
LDAP queries to attribute for getting administrator passwords
LDAP
Signs of an internal horizontal port scan
TCP, UDP
Signs of an internal vertical port scan
TCP, UDP
DNS zone data replication requests sent from sources other than DNS servers
DNS
Successfully completed requests for DNS zone data replication sent from sources other than DNS servers
DNS
LDAP query targeting a critical attribute of insecure credentials
LDAP
Enumeration of domain accounts via LDAP queries
LDAP
Exceeding the threshold for requested critical attributes in LDAP queries
LDAP
LDAP search queries containing a high number of critical attributes
LDAP
Connections to Suspicious Resources
Queries to unauthorized domain names
DNS
Transmission of large data volumes to cloud storages
TCP, UDP, DNS
Connections to cloud storages or file transfer services
TCP, DNS
Connections to public repositories
TCP, DNS
Connections to resources of programs for traffic tunneling
TCP, DNS
С2 Communication
Possible queries to DGA domains
DNS
DNS data tunneling via TXT records
DNS
Numerous blocked connections to external addresses
TCP, UDP
Conclusion
The examples of Kerberoasting and DNS tunneling clearly demonstrate why modern security defenses cannot rely solely on looking for known signatures and indicators of compromise. Both attack techniques abuse protocols that operate inside corporate networks every day. At the individual event level, they may look like legitimate activity, yet in behavioral context, they stand out as clear indicators of compromise.
NAD directly addresses this gap. Instead of relying purely on signature matches across Kerberos or DNS traffic, it highlights deviations from established baselines: who initiated the activity, how frequently it recurred, which services or domains were targeted, and why that matters for a specific infrastructure.
As a result, analysts gain a clear, actionable starting point for investigation. This capability is especially valuable for spotting the signs of APT group activity, which runs stealthily and is designed to blend in with legitimate operations. The importance of this capability will only grow: as attack techniques evolve, detecting suspicious activity at its earliest stages – before it escalates into critical service compromise or a data breach – becomes increasingly vital.
Researchers found that seven of nine tested Hugging Face image-editing tools produced sexualized alterations, highlighting gaps in model oversight, provenance, and enterprise vendor controls.
Two beta releases of joyfill npm Packages have been found distributing a malware implant capable of delivering the DEV#POPPER remote access trojan (RAT) . The compromised Node.js packages use an import-time loader that retrieves encrypted payloads through blockchain transactions instead of traditional command-and-control infrastructure.The affected releases are @joyfill/layouts@0.1.2-2773.beta.0 and @joyfill/components@4.0.0-rc24-2773-beta.4. Joyfill develops software development kits for embedding forms, documents, and PDFs into web and mobile applications. While both packages collectively receive around 16,000 weekly npm downloads, researchers noted that the figure overlaps because @joyfill/components depends on @joyfill/layouts, and it does not represent installations of the compromised beta versions.
Joyfill npm Packages Deliver DEV#POPPER RAT Malware
Unlike conventional npm attacks that rely on lifecycle scripts, the malicious code executes when the Node.js module is imported. This means the implant activates during package loading, making npm install --ignore-scripts ineffective once the affected module is used.Socket's analysis identified code patterns matching the PolinRider loader family and linked the final payload to the DEV#POPPER malware family. Researchers emphasized that these findings are based on technical similarities and published research rather than attributing the compromise to a specific threat actor.According to the report, the compromised joyfill npm Packages are capable of arbitrary code execution across development environments, CI runners, test systems, server-side rendering environments, and production builds. The recovered 77 KB Node.js RAT can collect host information, establish a Socket.IO remote-control channel, execute JavaScript or shell commands, upload files, access clipboard data, and modify developer-related files to maintain persistence.
Investigators found that both malicious releases were published on 28 July 2026 using Node.js 18.20.0 and npm 10.5.0, with the shared prerelease build marker 2773. Source maps indicate the malicious code was present during the build process, although the report states this does not determine whether attackers compromised a developer workstation, source repository, CI pipeline or publishing credentials.The malware uses a multi-stage delivery process, retrieving encrypted payloads through Tron, Aptos and BNB Smart Chain transactions. Researchers warned that this blockchain-based approach enables attackers to update payloads without publishing new npm releases. Additional payloads downloaded by the malware included a detached Node.js bootstrap and a Python credential stealer believed, with medium confidence, to be a variant of OmniStealer.
Recommendations for Developers and Security Teams
The report also noted significant similarities to an incident analysed by eSentire earlier in 2026, in which DEV#POPPER was deployed via a weaponised GitHub repository. However, researchers believe the current campaign most likely resulted from a maintainer compromise rather than a malicious project clone.Security teams are advised to remove both affected joyfill npm Packages, replace them with verified versions @joyfill/layouts@0.1.1 and @joyfill/components@4.0.0-rc24, isolate any systems that imported the malicious releases, and rotate credentials from unaffected machines. The researchers also recommend monitoring Node.js environments for unusual blockchain RPC traffic and reviewing systems for persistence mechanisms that may remain even after the packages are removed.
Phishing played a part in more than half of all incident response engagements undertaken by Talos, Cisco's threat research organization, during the second quarter of 2026, with healthcare organizations and manufacturing firms among the top targets.
In this episode of the podcast, host Paul Roberts interviews Nishawn Smagh of the firm GreyNoise Intelligence about the findings of their State of the Edge report, an analysis of GreyNoise data on risks stemming from compromised edge devices such as broadband routers, VPN gateways, smart home devices and more. Shawn and Paul talk about how attackers are turning edge devices into their favorite entry point, and strategies for organizations to counter the growing risk of compromised edge devices.
Entrar
Image Source: https://rewardsforjustice.net/[/caption]
Yaryab is also accused of directing Shahid Hemmat and Shahid Shushtari, two groups linked to cyberattacks against U.S. organizations. The sectors allegedly targeted include defense, news, shipping, travel, energy, financial services and telecommunications.
The six Iranian officials named in the advisory are linked to Iran's Islamic Revolutionary Guard Corps and its Cyber-Electronic Command.
