Introduction

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.

To detect this anomaly, the NAD rule titled “Signs of a Kerberoasting attack” implements the following logic:

1. 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.
2. Extract the cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.
3. Group the sessions by the source IP address and client account name (cname), while aggregating sessions with unique SPNs.
4. 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.
5. 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.

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)

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.

On this same page, you can test if the rule is functional prior to saving it.

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.

From there, the analyst can navigate to the associated event, which provides a detailed breakdown of the anomaly alongside links to the affected hosts.

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.

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.

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.

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.

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.

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

The detection logic for this network anomaly is structured as follows:

1. 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.
2. Split qualifying DNS sessions into individual log lines, each corresponding to an individual request or response. Retain only DNS responses containing TXT data.
3. Extract DNS names and their associated TXT data from these DNS responses. Retain only unique values.
4. Group all resulting records by the session’s source IP address, aggregating all unique DNS names and TXT data blocks.
5. 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).
6. 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).

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:

1. Adding a rule from a prebuilt template and adjusting custom variables. In this case, the rule is classified as a system rule.
2. 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.
3. 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.
• Domain Attacks: detecting classic attacks targeting domain network infrastructures using offensive tooling.
• Reconnaissance Activity: identifying suspicious activity within domain protocol sessions (Kerberos, DCE/RPC, LDAP, DNS) resembling domain reconnaissance.
• 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.

UPD 03.07.2026: added a package of rules and recommendations that help detect the described malicious activity for companies using our Kaspersky SIEM system.

Introduction

To access compromised systems, threat actors frequently abuse legitimate remote monitoring tools. At first glance, these utilities rarely raise red flags: they are signed with valid digital certificates, often allowlisted under corporate IT policies, and fully supported by OS vendors. However, they grant attackers the ability to harvest data from target devices, drop malware, and move laterally across the network.

During a recent investigation engagement, the Kaspersky Managed Detection and Response (MDR) team discovered the ScreenConnect remote access tool being leveraged to deploy and execute an AsyncRAT payload.

A deep dive into this single incident unraveled a massive campaign distributing malicious installer archives hosted on spoofed websites. These installers masquerade as popular software like OBS Studio, DNS Jumper, DS4Windows, Bandicam, and others. In total, we uncovered more than 90 domain names localized across 10 languages. The malicious archives bundle a legitimate, signed Microsoft install.exe binary alongside a rogue install.res.1033.dll library. It is loaded onto the device via DLL sideloading and deploys the ScreenConnect service, which awaits further instructions from the threat actors.

As a result, what initially appeared to be an isolated ScreenConnect incident served as the starting point for a full investigation into the threat actor’s C2 infrastructure. Every spoofed site we uncovered followed the exact same playbook: dropping a hidden ScreenConnect remote administration service under the guise of a legitimate software installer. This allowed the attackers to maintain control over compromised endpoints, with victims ranging from individual users to organizations.

We continue to break down complex, multi-stage incidents like this in our ongoing The SOC Files series. In this post, we take a deep dive into the technical execution of the ScreenConnect attack and analyze the broader infrastructure under the threat actor’s control.

Initial incident investigation

The investigation was triggered by an alert from Kaspersky MDR, which flagged the creation and execution of suspicious PowerShell and VBS scripts spawned by a ScreenConnect process.

About ScreenConnect

ScreenConnect is a legitimate remote management utility. Kaspersky solutions detect it as not-a-virus:HEUR:RemoteAdmin.MSIL.ConnectWise.gen.

ScreenConnect was running as an Access-type service — enabling direct remote connectivity — with the server explicitly passed via the command line:

Once running, ScreenConnect created and executed a PowerShell script named Fj5NmEsp9EuKrun.ps1:

Below is an excerpt from the contents of the script:

This script configures Microsoft Defender exclusions for the following objects:

• All disks in the system: C:\, D:\, and others
• All root directories on the C:\ drive, as well as the C:\Users\Public directory
• RegAsm.exe process

Additionally, the script disables User Account Control (UAC) prompts by setting the ConsentPromptBehaviorAdmin registry parameter to 0.

Following this setup, the ScreenConnect service goes on to create a VBScript file:

The installer_method3_stream.vbs script creates five files in the C:\Users\Public directory (msgbox.txt, secret_bytes.txt, 1.vb, cap.ps1, and script.vbs) and immediately triggers their execution by launching script.vbs.

This script terminates all active powershell.exe processes to cover its tracks and executes cap.ps1 in a hidden window.

cap.ps1 reads the contents of the secret_bytes.txt file, extracts sequences matching the [SXX- pattern, and converts XX from hexadecimal representation to a byte. It then uses a 0xA7 XOR key to decrypt each byte and inverts the bit order. The resulting byte array yields a fully formed PE binary, which is then reflectively loaded into the CLR.

Within the loaded assembly, the ConsoleApp1.Module1 type contains a static method named Run. The script uses reflection (Reflection.BindingFlags) to resolve a reference to this method and invoke it.

The Run method executes a process hollowing technique (T1055.012), spawning a new RegAsm.exe process with the CREATE_SUSPENDED flag. The deobfuscated and decrypted PE image from secret_bytes.txt is then copied into its address space. As a result, the RegAsm.exe process no longer executes its original code, instead serving as a container for the injected .NET module — which, in this case, is the AsyncRAT remote access Trojan.

To establish persistence, the malware schedules a task named MasterPackager.Updater:

"schtasks" /Create /TN "MasterPackager.Updater" /TR "wscript.exe "C:\Users\Public\script.vbs" " /SC MINUTE /MO 2 /F

This task triggers every two minutes, ensuring that script.vbs — and consequently the entire loader chain — executes even after a system reboot.

Once the entire infection chain successfully executes, the RegAsm.exe process establishes a connection to the C2 domain mora1987[.]work[.]gd.

How ScreenConnect entered the system

A retrospective analysis of the incident allowed us to pinpoint the source of the ScreenConnect installation: a user-downloaded archive named obs-studio-windows-x64.zip.

The archive was downloaded from hxxps://www.studioobs[.]com/, a typosquatted domain mimicking the official site for OBS Studio, a popular open-source screen recording app. This site is present in search engine results; in this specific incident, the user landed on the malicious domain directly from a search query, a vector we analyze in more detail below.

Clicking the download button for the supposedly legitimate software triggers a request to the following URL, from which the archive is fetched:

hxxps://fileget.loseyourip[.]com/obs-studio-windows-full/gVOMs5VZ9BtlcaM

The archive contains a legitimate, Microsoft-signed executable named install.exe (87603EA025623B19954E460ADD532048), renamed to masquerade as the OBS Studio installer, along with a malicious library named install.res.1033.dll. Additionally, the archive includes an Assets folder containing both a copy of the actual software being impersonated and the ScreenConnect utility.

The complete file structure of the archive is organized as follows:

When OBS-Studio-Installer.exe is executed, it loads install.res.1033.dll via DLL sideloading. This library contains the instructions required to install both ScreenConnect and OBS Studio. The deployment relies on native Windows utilities (msiexec.exe), but the attackers renamed the standard MSI packages to look like DLL files:

• Assets\x86\Data\vcredist_x64.dll: ScreenConnect installer
• Assets\x86\Data\vcredist_x86.dll: OBS Studio installer

The contents of the vcredist_x64.dll MSI package are shown below:

The Windows Installer is launched to install ScreenConnect silently in the background without requiring a system reboot:

msiexec.exe /i "C:\Temp\OBS-Studio-Windows-x64\Assets\x86\vcredist_x64.dll" /qn /norestart

Once the installation wraps up, a new service named Microsoft Update Service is created. The command line for this service explicitly defines the connection server as r[.]servermanagemen[.]xyz.

Meanwhile, the MSI package for the actual OBS Studio software runs using a standard graphical user interface.

Expanding the investigation

The attackers’ reliance on the legitimate install.exe binary provided a crucial pivot point for our broader investigation. We discovered that this specific file was being deployed in the wild under a variety of suspicious aliases, including:

• ds4windows.exe
• crosshairx_installer.exe
• obs-studio-installer.exe
• dns jumper.exe
• glary utilities pro.exe
• processhacker-2.39-setup.exe

These file names indicate that the threat actor was disguising their ScreenConnect archives as popular utilities beyond OBS Studio. Among the fakes, we identified counterfeit installers for DS4Windows, DNS Jumper, Glary Utilities, and Process Hacker. Crucially, when we search for these utilities on major search engines, these fraudulent sites frequently appear at the very top of the organic search results. This indicates that the threat actor is actively leveraging SEO techniques to boost traffic to their landing pages.

Spoofed software portals appearing in search engine results

For example, here is how the fraudulent download portal for DNS Jumper looks:

On this page, the download button directs users to the following address:

hxxps://direct-download.giize[.]com/dns-jumper/iopbsr4hymbo7nfa1q7j

Just like the OBS Studio variant, this drops an archive onto the victim’s device with an identical structure: a renamed legitimate install.exe file, a sideloaded library, and an Assets directory containing the promised software packaged alongside ScreenConnect.

Other fraudulent websites that appear in search engine results when querying the corresponding software are designed in a similar fashion.

Spoofed websites used to distribute ScreenConnect

Notably, the vast majority of the fraudulent sites we uncovered are localized into English, Russian, and Chinese. In several instances, the pages were also translated into German, French, Spanish, Arabic, and other languages. This multi-language support underscores the global footprint of the campaign, targeting a broad user base across multiple regions.

Fake domain infrastructure

To distribute ScreenConnect disguised as freeware, the threat actor spun up an extensive network of domain names mapped across three IP addresses. We have categorized these into two distinct infrastructure clusters.

Cluster 1: 162.216.241[.]242 and 198.23.185[.]81

```
162.216.241[.]242
Country: United States
Org name: Dynu Systems Incorporated
```

The connection graph below illustrates the campaign websites tied to IP address 162.216.241[.]242, which hosts the previously mentioned www[.]studioobs[.]com domain.

Looking into the registration dates for the domains on this IP, we found that the threat actor initially attempted to disguise their sites as various gaming portals:

Subsequently, starting in January 2026, they shifted strategy and began registering fake domains designed to mimic popular freeware:

In this specific branch of the ScreenConnect campaign, the malicious archives are hosted on fileget.loseyourip[.]com. Notably, the download resource is hosted on a completely separate provider:

```
198.23.185[.]81
Country: United States
Org name: NOHAVPS LLC
```

Our analysis of this second IP address revealed that it also hosts additional resources tied to the campaign, including fake gaming sites and supplementary download links:

Cluster 2: 2.59.134[.]97

```
2.59.134[.]97
Country: Germany
Org name: dataforest GmbH
```

Below is an infrastructure graph showing this IP address and its hosted domains. Notably, unlike the previous case, this address also hosts direct-download.giize[.]com, a resource used to store distributed malicious archives.

In this branch of the campaign, the threat actor skipped game-themed lures entirely, focusing exclusively on creating fraudulent freeware sites that bundled ScreenConnect with the requested application. The domains hosted on IP address 2.59.134[.]97 were registered between October 2025 and March 2026.

The chart below shows the volume of fraudulent websites created month by month:

Breakdown of ScreenConnect delivery sites by theme, August 2025 through March 2026 (download)

C2 infrastructure analysis

In total, we identified dozens of different archives distributed across this campaign. All of them share a uniform file structure, containing the malicious install.res.1033.dll library and the ScreenConnect MSI package located at Assets\x86\vcredist_x64.dll.

In some instances, the ScreenConnect installation package also bundles a CAB archive.

This archive contains a system.config XML file, which defines the connection address for the ScreenConnect C2 server:

By analyzing these ScreenConnect installations, we uncovered additional C2 addresses, which are mapped out in the following graph:

The next graph illustrates the AsyncRAT command-and-control infrastructure:

Based on the registration dates of the C2 domains, we can determine that the campaign was launched in October 2025 and paused at the end of March. However, at the time of publication, many of the landing pages remain accessible via search engine results.

Takeaways

Investigating a single case of AsyncRAT delivered via ScreenConnect allowed us to uncover a massive, multi-domain, multi-language infrastructure designed to distribute a hidden installer for this software and further advance the attack. The threat actor disguises ScreenConnect as popular utilities and distributes it through fraudulent websites that mimic official product pages. The attackers leverage search engine optimization techniques to push these sites to the top of search results in engines like Google and Bing.

This attack chain targets both everyday consumers downloading free software from the internet and corporate networks, where remote access tools are frequently allowlisted and granted elevated privileges.

The potential objective of the campaign is to steal credentials en masse and gain unauthorized access to systems for subsequent resale on dark web marketplaces.

To mitigate the risks associated with this threat, we recommend implementing the following security measures:

• Enforce strict software installation controls: application allowlisting and blocking MSI package execution from untrusted sources
• Continuously monitor for the creation of new remote administration services and scheduler tasks
• Filter outbound traffic to unknown domains and IP addresses
• Regularly train users on safe downloading practices
• Verify the authenticity of all software sources

For enterprise users, credential monitoring is a critical mitigation strategy against the risks detailed in this article, as a leaked account or compromised system access frequently serves as a vector for subsequent attacks on the organization.  Kaspersky Digital Footprint Intelligence provides continuous data monitoring across open and dark web sources, enabling security teams to respond proactively to potential threats.

Detection by Kaspersky solutions

Kaspersky Managed Detection and Response detects the malicious activity described in this post using the following indicators of attack:

1. ScreenConnect service creation with suspicious parameters
   

   logsource:                      
       product: windows         
       category: security
   detection:
       selection_access:
           EventID: 4697
           Service File Name|contains:
               - 'e=Access'
               - 'ClientService.exe'
       selection_support:
           EventID: 4697
           Service File Name|contains:
               - 'e=Support'
               - 'ClientService.exe'
       condition: selection_access or selection_support

2. Anomalous child processes being spawned by the ScreenConnect service
   

   logsource:
       product: windows
       category: process_creation
   detection:
       selection:
           ParentImage|endswith:
               - '\\ScreenConnect.ClientService.exe'
               - '\\ScreenConnect.WindowsClient.exe'
               - '\\ScreenConnect.WindowsBackstageShell.exe'
               - '\\ScreenConnect.WindowsFileManager.exe'
           Image|endswith:
               - '\\powershell.exe'
               - '\\cmd.exe'
               - '\\net.exe'
               - '\\schtasks.exe'
               - '\\sc.exe'
               - '\\msiexec.exe'
               - '\\mshta.exe'
               - '\\rundll32.exe'
       condition: selection

Additionally, Kaspersky products detect the malware covered in this post under the following verdicts:

• Trojan.Win64.DLLhijack.*
• Trojan.VBS.Agent.*
• Trojan.PowerShell.Agent.bav
• Trojan.JS.SAgent.sb

Endpoint malicious activity can be monitored using Kaspersky EDR Expert. Specifically, security teams should look for the execution of commands and scripts containing suspicious patterns, such as XOR operations used for command and data obfuscation by malware operating on the host. This activity is flagged by the suspicious_assembly_loading_into_powershell_via_reflection_amsi and xored_powershell_command_amsi rules.

Additionally, persistence mechanisms involving the creation, modification, or utilization of scheduled tasks via the schtasks.exe utility are caught by the scheduled_task_create_from_public_directory_via_schtasks rule.

Malicious code injection into the RegAsm.exe process — leveraged by attackers to masquerade execution behind a trusted system component — is detected via the code_injection_to_unusual_process rule.

To visualize the stages of the attack, security teams can utilize Kaspersky Cloud Sandbox on the Threat Intelligence portal. For instance, this tool allows defenders to map out the entire deployment and payload execution chain originating from the initial VBS dropper.

Furthermore, the Kaspersky Threat Intelligence portal supports searching and graphing the connections between malicious domains and files involved in this campaign, as demonstrated in our adversary infrastructure analysis section.

Finally, the Similarity engine within Kaspersky Threat Analysis profiles file contents to hunt down samples resembling the original threat, helping organizations identify new or previously undetected malicious objects.

To protect companies using our Kaspersky SIEM system, there are rules available in the product repository to help detect this type of malicious activity.

• Adding exclusions to Windows Defender scans via the registry is detected by rule R241_Modification of Windows Defender exclusions through the registry. Adding exclusions via PowerShell (Add-MpPreference -ExclusionPath|ExclusionProcess) is detected by rule R076_04_Windows Defender settings disabled or changed via PowerShell.
• Bypassing the UAC mechanism by modifying the ConsentPromptBehaviorAdmin registry key is detected by rule R242_UAC disabled through the Windows registry.
• Running VBS scripts from a public directory triggers rule R290_07_Running VBScript files from shared folders.
• Creating a scheduled task that runs an executable file from a public directory triggers rule R099_01_Scheduled task started from a public folder.

For the rules to function correctly, it is necessary to configure event 4657 (Security) audit for the following registry keys:

• HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths
• HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Procesess
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin

Additionally, when developing your own detection rules or conducting threat hunting for suspicious ScreenConnect behavior, we recommend monitoring the following events:

• Creation of the ScreenConnect service with suspicious parameters
  

  DeviceEventClassID = '4697' 
  AND FileName LIKE '%ClientService.exe%' 
  AND (FileName LIKE '%e=Access%' OR FileName LIKE '%e=Support%')

• Launch of atypical child processes from the ScreenConnect service
  

  DeviceEventClassID = '4688'
  AND match(SourceProcessName, '.*\\\\ScreenConnect\\.(ClientService|WindowsClient|WindowsBackstageShell|WindowsFileManager)\\.exe')
  AND match(DestinationProcessName, '.*\\\\(powershell|cmd|net|schtasks|sc|msiexec|mshta|rundll32)\\.exe')

Indicators of compromise

Loaders

B32810973132D11AFD61CCEE222BBB79
5B7E1FE55BD7B5EA54BD4ED1677E5A26
9A9CCD8B0E5D05F4EE77667B024844DB
0EEE9BAD07E22415439E854657FA1366
8F4E8B680D3E8D3F5AC39BD72882F713

Malicious library: install.res.1033.dll

5F96C04E3AFAE97017B201BE112284D2
73BEAD922109A61E5F9F85771A7812C5
EDFF4F58722C93D7C09ED71899416396
83601C3D4ED28E8D2BE1B99BEB8EC18C
695E794631EF130583368770E7B81E98
83601C3D4ED28E8D2BE1B99BEB8EC18C
1E6A5C7B620D487D0CFC6874C3B77C90
54025CE2A9405039899FE99A1D77E0BB
BD05FCF80E493CF9AA71EC510319469D
999A63730C9634481D1D76955A2E76A8
479BD3BB617B39CD4A46D0768A2592D4
776DFD3DF9C04BB9FCDD6C1880C3761A
8E4C57358A66EB14D31ABB614DDC68DE
A40D3AEB0DAE5B00BDB3A517F3135BBB
A85A5BFDCB7C65AB93043B8CF9E20065
01325880EFFFEC546F59490089A3B415

AsyncRAT C2

mora1987[.]work[.]gd

Fake websites addresses

ds4windows[.]io
direct-download[.]giize[.]com
tmodloader[.]org
tmodloader[.]app
ds4windows[.]net
losslessscaling[.]app
processhacker[.]dev
steamtools[.]pro
dnsjumper[.]app
free-download[.]camdvr[.]org
defendercontrol[.]org
dns-jumper[.]com
cpuz[.]app
processhacker[.]org
processhacker[.]app
steamtools[.]cc
cpuz[.]pro
wallpaper-engine[.]app
processhacker[.]net
antimicrox[.]net
defendercontrol[.]app
tmodloader[.]pro
dnsjumper[.]io
bandicam[.]app
mgba[.]app
dnsjumper[.]pro
ferdium[.]app
ds4windows[.]pro
lossless-scaling[.]online
defender-control[.]com
gom-player[.]app
defendercontrol[.]pro
lossless-scaling[.]download
antimicrox[.]pro
mgba[.]pro
lossless-scaling[.]app
losslessscaling[.]pro
mgba[.]dev
tmodloader[.]download
tmod-loader[.]com
defendercontrol[.]download
ferdium[.]pro
deadreset[.]com
gom-player[.]net
crosshairx[.]pro
libreoffice[.]pro
studioobs[.]com
studio-obs[.]net
crosshairxv2[.]com
km-player[.]com
corel-draw[.]net
glary-utilities[.]com
download-full-version[.]ooguy[.]com
crosshair-x[.]com
kms-tools[.]com
studio-obs[.]com
crosshairx[.]net
clair-obscur-33[.]com
vlc-player[.]net
arksurvival-ascended[.]com
elden-ringnightreign[.]com
ready-ornot[.]com
arma-reforger[.]com
crusader-kings[.]com
crosshairx2[.]com
mediaplayerclassic[.]net
bandizip[.]pro
obs-studio[.]site
ovr-advanced-settings[.]com
studio-obs[.]pro
vlc-media[.]com
clair-obscur-33[.]town
ovr-toolkit[.]com
crusader-kings[.]church
bandizip[.]net
apexlegends[.]org
obs-studio[.]pro
vlc-media[.]net
crosshairx[.]site
monster-hunterwilds[.]com
km-player[.]pro
mediaplayerclassic[.]pro
kms-tools[.]net
fernbus-simulator[.]com
studioobs[.]pro
bandicam[.]cc
crystaldiskmark[.]cc
crystaldiskmark[.]io
crystaldiskmark[.]dev
crystaldiskmark[.]app
crystaldiskmark[.]pro
bandicam[.]io

Fake domain infrastructure

fileget.loseyourip[.]com
file-download-crosshairx.giize[.]com
all-toll-free.loseyourip[.]com
mpc-update.giize[.]com
all-toll-free.publicvm[.]com
198.23.185[.]81
direct-download.giize[.]com

ScreenConnect C2

servermanagemen[.]xyz
185.254.97[.]249
r.manage-server[.]xyz
45.145.41[.]205
winservec[.]net
manageserver[.]xyz
cloudsynn[.]com
pingserv[.]pro
ehostservers[.]xyz
serverdnsplan[.]net
pingpanl[.]pro
managedevice[.]xyz
edgeserv[.]ru

As organizations rush to adopt AI, they are discovering that traditional, siloed security tools cannot keep pace. The data is too vast, the infrastructure is too interconnected, and runtime environments are too dynamic. Security leaders are confronting a hard reality: AI cannot be secured with point solutions — it is just too broad.

To scale AI with confidence, enterprises must move beyond check-the-box controls and adopt a holistic, machine-speed defense that secures the entire AI lifecycle. This means protecting the data that fuels and is accessed by models, the cloud infrastructure that runs them, and the workloads and AI systems operating at runtime as a single, unified, and immutable system.

As AI capabilities accelerate, a critical question is emerging in the market: Does AI reduce the need for cybersecurity, or fundamentally increase it?

The answer is clear. With current infrastructure architectures, AI is not a replacement for security. It is a multiplier for risk. Models ingest massive volumes of data and agents can sprawl uncontrollably. It depends on complex cloud infrastructure and operates continuously at machine speed. Each stage of the AI lifecycle introduces new attack paths and new failure modes.

Today, SentinelOne is announcing the expansion of its AI Security platform with new Data Security Posture Management (DSPM) capabilities, model red teaming, validation and guardrails (by Prompt Security), MCP Security (by Prompt Security), AI-SPM, AI Workload Protection, and AI end user protection. This milestone advances our broader vision, delivering a unified platform that secures AI end to end, from data accessed, all through runtime execution and model input and output. This is complete security, visibility, and governance over Al usage throughout its entire lifecycle.

The Foundation: Securing AI at the Data Layer

AI security starts with data, not because data is abundant, but because mistakes made at this stage are irreversible. AI models also don’t just process the data they ingest, they memorize it. If sensitive PII, credentials, or proprietary information enter a training pipeline, that data can become baked into a model’s weights, creating a permanent security liability that is nearly impossible to remediate later.

This risk is amplified by scale. Industry projections estimate that the global datasphere, the unstructured data stored in cloud object stores and increasingly fed into AI pipelines, will reach 10.5 zettabytes by 2028. This data is not just storage. It is the fuel that trains, fine-tunes, and powers AI systems. This is why data security is the first mile of AI security.

With the introduction of these new DSPM capabilities, SentinelOne enables organizations to establish a “safe-to-train” gate before data ever reaches an AI pipeline. These capabilities provide deep visibility into cloud-native databases and object stores, allowing teams to discover unmanaged or forgotten data sources, classify sensitive information with policy-driven precision, and prevent high-risk data from being used in training or inference workflows.

Singularity Cloud Security’s integrated DSPM discovers cloud object stores and databases and classifies sensitive data that could find its way into AI training pipelines. 

However, visibility alone is not enough. AI pipelines ingest data at massive scale, making them an attractive vehicle for malware delivery and pipeline poisoning. In addition to identifying and redacting sensitive data, SentinelOne actively scans cloud storage at machine speed to prevent malicious content from ever reaching AI models or applications. By securing data at ingestion all before training begins, organizations eliminate entire classes of AI risk that cannot be fixed downstream. This is the foundation for trusted AI adoption.

The Infrastructure Layer: Securing the Systems That Run AI

Securing AI data is necessary, but it is not sufficient. Data does not exist in isolation. Rather, it lives on cloud infrastructure and in AI environments where infrastructure becomes a critical failure point.

AI workloads introduce a uniquely high-risk combination of high-value data, high-privilege access, and high-performance compute. AI factories, training clusters, managed AI services, and inference endpoints often require broad permissions and continuous access to cloud object stores. Without strong infrastructure controls, attackers can pivot from exposed data into model logic, model weights, or downstream applications. This is where cloud infrastructure security becomes inseparable from AI security.

Traditional Cloud Security Posture Management (CSPM) provides essential hygiene across the cloud estate by identifying misconfigurations, excessive permissions, and policy drift. In AI environments, however, security teams also need visibility and control that is specific to how models are built, deployed, and accessed.

AI-Security Posture Management (AI-SPM) extends infrastructure security directly into the AI layer. By treating AI systems as first-class assets, AI-SPM provides a unified inventory of training jobs, development notebooks, managed AI services, and inference endpoints across the environment.

 

Together, CSPM and AI-SPM allow security teams to understand how data, infrastructure, and AI systems are connected. They can trace attack paths from misconfigured storage to over-privileged training containers, detect unmanaged AI assets, and prevent adversaries from moving laterally from the cloud foundation into model logic. This infrastructure layer is what connects secure data to secure runtime and it is essential for protecting AI at scale.

The Runtime Layer: Protecting AI In Production

AI security cannot stop when a model finishes training. The moment AI systems move into production, they begin interacting with real users, real data, and real business processes, making runtime protection a critical part of the AI security lifecycle.

At runtime, AI workloads operate continuously and at machine speed. Models and agents execute inside cloud workloads that must be protected against exploitation, unauthorized access, and lateral movement. Any compromise at this stage can immediately impact business operations, data integrity, and customer trust.

This is where runtime workload protection becomes essential. Cloud Workload Protection Platforms (CWPP) provide real-time visibility and enforcement across the compute environments running AI models, ensuring that workloads are monitored, hardened, and protected without degrading the performance required for high-velocity inference.

By extending protection into runtime, security teams ensure that AI systems remain secure not only during development and deployment, but throughout their operational life. This completes the AI security lifecycle from data ingestion, through infrastructure, to production execution.

Prompt Security and AI Red-Teaming: Continuously Validating Trust

Securing AI at runtime goes beyond protecting the workloads that execute models. It also requires validating how models behave when they are used (and misused) in the real world.

Prompts are the primary interface to AI systems and they represent a powerful new attack surface. Malicious or malformed prompts can be used to bypass controls, extract sensitive information, manipulate model behavior, or trigger unintended actions in downstream systems. These risks cannot be addressed solely through static controls or one-time reviews. This is where prompt security and AI red-teaming become essential.

By continuously testing AI systems with adversarial prompts and simulated attacks, organizations can identify behavioral weaknesses before they are exploited in production. AI red-teaming helps validate that models behave as intended under real-world conditions, exposing prompt-level vulnerabilities, unsafe outputs, and policy bypasses that would otherwise go undetected.

When combined with runtime protection, this approach ensures that AI systems are not only secure in how they are built and deployed, but also resilient in how they respond — even as models evolve, prompts change, and new attack techniques emerge.

This continuous validation loop is critical for maintaining trust in production AI systems and closing the final gap in the AI security lifecycle.

A Unified Fabric for AI Security

The transition to AI is ultimately a trust shift. Organizations will only move AI from experimentation to production if they can trust the data that trains models, the infrastructure that runs them, and the systems that govern how AI operates at runtime. Securing AI therefore cannot be fragmented. It requires a unified platform that treats data, infrastructure, and runtime as a single, connected system with shared context and continuous visibility across the entire AI lifecycle.

By integrating data security, cloud infrastructure posture management, AI-specific posture management, and runtime workload protection, SentinelOne delivers end-to-end AI security from data ingestion through runtime execution. This approach does more than reduce risk. It enables velocity. When security is built into the foundation, organizations can deploy AI faster, meet evolving regulatory requirements more easily, and innovate with confidence.

Secure the data.

Secure the infrastructure.

Secure the runtime.

This is how AI moves from risk to real-world impact. Contact us or book a demo to see how SentinelOne secures AI end to end — from data ingestion to runtime execution.

With cloud infrastructure and, more recently, artificial intelligence (AI) systems becoming prime targets for attackers, security leaders are laser-focused on defending these high-profile areas. They’re right to do so, too, as cyber criminals turn to new and emerging technologies to launch and scale ever more sophisticated attacks.

However, this heightened attention to emerging threats makes it easy to overlook traditional attack vectors, such as human-driven social engineering and vulnerabilities in physical security.

As adversaries exploit an ever-wider range of potential entry points — both new and old — security leaders must strike a balance to ensure that they’re capable of addressing all risks effectively.

Cyber crime is still a human problem

Despite overwhelming hype, technology is not a panacea. It can’t replace human expertise in every domain, and AI alone can’t match the innately human qualities of intuition and creative thinking. Adversaries know this too, which is why the smarter — and much more dangerous — ones use a blend of human- and technology-powered tactics.

While major technical vulnerabilities tend to make the headlines, the reality is that the weakest link is almost always the human element. Almost all attacks involve a social engineering element, and despite the buzz around generative AI and deepfakes helping scale such attacks, it’s human-to-human interaction where the greatest risks lie.

Synthetic content is now all around us, and people are getting better at telling it apart. Whether we get to the point when that’s no longer the case is a topic for another discussion. But for now, the most dangerous and effective social engineering attacks still depend primarily on human conversations, whether by phone, email or even in person. After all, a seasoned attacker can build trust and forge sham relationships in a way that no AI nor deepfake can match.

Cyber espionage remains a serious threat

Take state-sponsored cyber espionage, for example. Highly trained social engineers are a far cry from the typical rabble of independent cyber crime rackets operating off the dark web, who tend to rely more on scale than targeting specific enterprises and individuals. These attackers may target data systems, but when it comes to their own arsenals, their talents in manipulation and deception are by far their greatest weapons.

Technology still has a long way to go before it can come close to matching the age-old tactics of spycraft.

When facing an attacker who can pose effectively as an internal employee or any other trusted individual, someone relying solely on technology to mitigate the threat stands little chance of protecting themselves. That isn’t a technology failure. It’s a process failure, hence why the human element must always be a key factor in any cybersecurity strategy.

Of course, that’s not to say technology doesn’t have a vital role to play in bolstering your cyber defenses. It most certainly does, not least, because more and more routine threats are being automated or are carried out en-masse by attackers who are less skilled or experienced. The value of technology — especially AI-powered cybersecurity automation — exists primarily in its ability to free up time for security leaders to focus on the threats that technology alone can’t solve.

Explore cybersecurity services

It’s not all about the cloud, either

The majority of business data is now stored in the cloud, and the percentage continues to rise. Many businesses, especially smaller organizations and startups, exclusively use the cloud for data storage and other IT operations. The rise of AI, given how computationally demanding it is, is further accelerating cloud adoption.

Nonetheless, cloud computing isn’t the best option in all situations. On-premises remains the preferred choice for high-performance workloads that require extremely low latencies. In some cases, on-premises computing is also the cheaper option, and that’s unlikely to change in the near future.

Even though more companies are migrating to the cloud, that doesn’t mean they don’t keep sensitive data on-site. For instance, edge computing, which brings data processing closer to where it’s needed, has become a critical enabler in certain use cases. Examples include smart energy grids, remote monitoring of industrial assets and autonomous vehicles. These include cases where you can’t always rely on internet connectivity.

The smarter and better-funded adversaries aren’t just targeting cloud-hosted infrastructure. They’re also setting their sights on local servers and cyber-physical systems, such as industrial control systems and hardware supply chains. The fact that there’s often minimal collaboration between logistics, production and cybersecurity departments makes these risks all the more serious.

Ransomware remains one of the biggest threats targeting on-premises systems despite the small reduction in attacks over the last year. While cloud systems aren’t inherently immune from ransomware attacks, the vast majority target bare-metal hypervisors and local servers. In one recent case, the Akira ransomware group reverted to its earlier double extortion tactics, experimenting with different code frameworks to target systems running ESXi and Linux.

Botnets are another growing concern as the number of IoT devices continues to soar. Used to launch distributed denial of service (DDoS) attacks spanning thousands of devices, these botnets primarily target unsecured IoT devices, like those that monitor and operate industrial machines and critical infrastructure. One recent report discovered that DDoS attacks against critical infrastructure have increased by 55% in the last four years. These attacks don’t directly involve the exfiltration of sensitive data, but given how they can cause widespread disruption, adversaries may rely on them to draw attention away from more serious threats.

Why physical security is still relevant

As security leaders focus on locking down their cloud-hosted assets, they cannot afford to lose sight of the risks facing their physical infrastructure. Sometimes, the easiest way into the cloud is from within.

Even thin clients and dumb terminals — both widely used in high-security environments like healthcare and finance — can potentially give attackers a foothold in wider systems, including cloud infrastructure and remote data centers. Edward Snowden proved that while working at the National Security Agency when he exfiltrated 20,000 government documents stored on the servers in NSA’s headquarters 5,000 miles away. He did so without using any advanced technology. While that happened way back in 2013, and the NSA has long since updated its physical security protocols, the risk is just as relevant today as it was then.

While most thin clients are now protected by multiple layers of security, including encryption and multifactor authentication, these solutions alone can’t fully protect against physical compromise. If an attacker gains access to a terminal — perhaps by way of social engineering — they may be able to compromise it using unauthorized peripherals or by directly manipulating the device’s firmware. This could give them access to the wider network, potentially allowing for the injection of customized malware that goes undetected by regular security scans.

IoT devices are another leading reason behind the expansion of attack surfaces. They often lack adequate security, also giving attackers a potential entry point into the broader computing infrastructures they’re connected to. The fact that these connected technologies are being rolled out en masse in areas like smart cities, critical infrastructure and transportation networks, greatly magnifies such vulnerabilities.

Ultimately, if an attacker is able to get past your physical safeguards, then these connected systems present far easier pathways to an organization’s so-called “crown jewels” than trying to break through multi-layered cloud defenses.

Cloud data is not always the true target

In other cases, data hosted in the cloud might not be the attacker’s end goal. Many companies, such as those subject to stringent data residency regulations or that require high performance for real-time applications, still store their data on on-premises servers.

Some of these systems are air-gapped, meaning they’re entirely disconnected from any other networks, including the Internet itself. While more secure than any cloud-hosted server, at least in theory, their security can’t be taken for granted. For instance, anyone with physical access to the servers may be able to compromise them, either maliciously or accidentally.

Physical security, such as CCTV and biometric security checkpoints, is as important as ever in such cases. But it’s not just about protecting against intentional physical tampering. Indirect attacks orchestrated by highly skilled social engineers can also dupe unsuspecting employees into taking a desired action — such as lending them a biometric security access card.

These are not the sort of adversaries that usually work by email or use AI to scale their attacks – they’re far likelier to deceive someone in person, a tactic as old as humanity itself. In fact, the attacker could be anyone, such as a disgruntled former employee, a hacker operating in the interests of a rival company or even a rogue state.

Bridging the gap between digital and human security

Technology alone can’t protect an organization from the myriad threats out there, and neither can humans keep up with ever-expanding system logs and security information feeds if they’re relying solely on manual processes.

The reality is that you need both, starting with people and using technology to broaden their capabilities. A layered security strategy should typically start with locking down physical access to any data-bearing system or system that is connected to another.

The next layer of defense is the human one. This revolves heavily around security awareness training. But the reality is that many programs are ineffective, either because they lack practical application, are overly reliant on generic content or focus too much on technical factors that are beyond the target audience’s understanding.

Phishing simulations are often similarly limited in their scope, focusing on common lures like trending news topics, a sense of urgency or even outright threats. However, more sophisticated attackers tend to use subtler ways to elicit a response. This could be something as simple as sending messages about a routine policy update regarding company dress code or remote work guidelines. These topics might seem trivial, but they can pique interest, especially when they concern changes to daily routines and work-life balance. Attackers could then use this to dupe unsuspecting victims into divulging sensitive information via a sham survey.

Like any other security measure, physical systems and awareness training will only ever be effective if they’re tested regularly. That’s where physical red teaming comes in. Whereas red teaming in the context of IT focuses on technical measures like penetration testing, physical red teaming is all about having teams try to gain entry to restricted areas and systems. To do so, they might use a blend of simulated social engineering attacks and technology to hack into physical security systems. By attempting to bypass physical security barriers or impersonate staff, red teams can reveal gaps that might otherwise go unnoticed. That’s what makes them a valuable part of any comprehensive information security program.

The post AI and cloud vulnerabilities aren’t the only threats facing CISOs today appeared first on Security Intelligence.

The threat of cyberattacks against critical infrastructure in the United States has evolved beyond data theft and espionage. Intruders are already entrenched in the nation’s most vital systems, waiting to unleash attacks. For instance, CISA has raised alarms about Volt Typhoon, a state-sponsored hacking group that has infiltrated critical infrastructure networks. Their goal? To establish a foothold and prepare for potentially crippling attacks that could disrupt essential services across the nation.

Volt Typhoon embodies a threat far beyond everyday cyber crime. It indicates the dangerous reality of cyber pre-positioning — a tactic that allows cyber actors to infiltrate systems, maintain persistence and potentially launch massively destructive operations. With lifeline sectors such as communications, energy, transportation and water and wastewater systems under threat, the question is no longer if attackers are embedded within U.S. infrastructure but how deeply they have rooted themselves. And the implications directly impact national security.

Nation-state pre-positioning goes beyond espionage

Employed by nation-state actors, pre-positioning goes beyond mere intelligence gathering. By silently lurking within critical infrastructure networks, actors gain the capability to wreak havoc at a moment’s notice. These intrusions, particularly in sectors like water systems and energy grids, serve little espionage value, per Anne Neuberger, the Deputy National Security Adviser for Cyber and Emerging Technologies. This indicates that the infiltrations are likely precursors to far more disruptive objectives.

Volt Typhoon’s methodical approach has allowed them to infiltrate U.S. systems for extended periods — up to five years in some cases — without detection. They’ve targeted the infrastructure that millions of Americans depend on daily. In a time of heightened geopolitical tension, a well-timed cyberattack could grind vital systems to a halt, leaving the nation vulnerable to cascading failures across multiple sectors. The fallout could be unprecedented, impacting national security, the economy and everyday life.

Volt Typhoon’s tactical mastery

Volt Typhoon is no ordinary hacking group. This state-sponsored entity has displayed a level of sophistication that challenges even the most robust cybersecurity defenses. Through its living-off-the-land (LOTL) tactics, the group exploits legitimate network administration tools, blending seamlessly with normal traffic and making detection extremely difficult. Their use of known vulnerabilities in public-facing devices such as routers and VPNs allows them to gain access, while compromised administrator credentials give them the power to burrow deeper into networks and assess operational technology (OT) systems.

The group’s calculated patience is noteworthy. Instead of seeking short-term gains, they carefully study their targets and gain an understanding of the nuances of the systems they infiltrate. In one case, Volt Typhoon spent nine months moving laterally through a water utility’s network, gaining access to crucial OT assets, including water treatment plants and electrical substations. These infiltrations are more than a technical breach — they represent a looming threat to physical infrastructure that could manifest in catastrophic failures.

Read CISA cybersecurity advisories

The FOCAL Plan’s strategic response

In the face of these threats, CISA has developed a robust response: the Federal Civilian Executive Branch (FCEB) Operational Cybersecurity Alignment (FOCAL) Plan. This strategic framework aims to shore up federal cybersecurity defenses by driving coordinated action across agencies. The FOCAL Plan outlines how federal agencies can adopt best practices to defend against pre-positioning and other sophisticated cyber threats, promoting a holistic approach from prevention to incident response.

The FOCAL Plan focuses on five critical areas: asset management, vulnerability management, defensible architecture, cyber supply chain risk management and incident detection and response. Each area plays a crucial role in safeguarding federal systems from persistent threats like Volt Typhoon:

1. Asset management: Without knowing what assets exist within an organization, it is impossible to protect them. The FOCAL Plan emphasizes comprehensive, continuous visibility into all IT and OT assets to ensure that any unauthorized access can be detected and mitigated quickly.

2. Vulnerability management: Regular vulnerability scanning and timely patching prevent hackers from exploiting known weaknesses, shutting down one of their primary entry points.

3. Defensible architecture: Organizations must build resilience into systems, assuming that attacks will happen. This includes implementing zero trust principles to restrict lateral movement within networks and limit the damage attackers can do, even if they gain access.

4. Supply chain risk management: This addresses the growing reliance on third-party vendors. With many cyberattacks exploiting vulnerabilities in third-party systems, the FOCAL Plan emphasizes the need for agencies to closely monitor their supply chains and ensure that their vendors adhere to strict cybersecurity protocols.

5. Incident detection and response: This is the FOCAL Plan’s approach to real-time cyber defense. CISA urges agencies to deploy advanced tools like endpoint detection and response (EDR) systems, which can identify and respond to threats before they cause significant damage. The ability to share threat intelligence and coordinate responses across federal agencies is essential for ensuring that the government can act swiftly in the event of an attack.

Mitigation urgency and action

The threat landscape outlined by Volt Typhoon’s actions calls for an urgent response — not just from federal agencies but from every organization that operates critical infrastructure. The key to stopping attackers from exploiting pre-positioned access is to adopt a mentality of constant vigilance and proactive threat hunting. It’s not enough to react to attacks after they happen. Organizations must actively hunt for threats, continually monitor their systems and act quickly to patch vulnerabilities before they can be exploited.

CISA’s FOCAL Plan provides a framework, but it is up to individual organizations to implement these measures at every level. Regular security audits, comprehensive asset management and adherence to the latest cybersecurity best practices are non-negotiable. Organizations must be prepared for the reality of an attack, ensuring that they have backup systems in place. It’s vital to practice incident response through tabletop exercises and maintain open communication channels with CISA and other federal agencies.

The harsh reality is that many organizations may already have pre-positioned attackers within their networks. The objective now is to limit the damage they can do and to ensure that attackers cannot trigger even more widespread disruption.

The clock is ticking

The presence of cyber actors like Volt Typhoon in U.S. critical infrastructure is not hypothetical — it’s happening now, and the consequences of inaction could be devastating. The ability of these attackers to remain hidden within networks for years, studying their targets and preparing for destructive actions, underscores the importance of robust, proactive cybersecurity measures.

The FOCAL Plan is a step in the right direction, but the fight against pre-positioned cyber actors is far from over. It will require a sustained, coordinated effort between federal agencies, private organizations and international allies to ensure that U.S. critical infrastructure is protected and remains resilient.

Explore cybersecurity services

The post Are attackers already embedded in U.S. critical infrastructure networks? appeared first on Security Intelligence.

A recent CISA red team assessment of a United States critical infrastructure organization revealed systemic vulnerabilities in modern cybersecurity. Among the most pressing issues was a heavy reliance on endpoint detection and response (EDR) solutions, paired with a lack of network-level protections.

These findings underscore a familiar challenge: Why do organizations place so much trust in EDR alone, and what must change to address its shortcomings?

EDR’s double-edged sword

A cornerstone of cyber resilience strategy, EDR solutions are prized for their ability to monitor endpoints for malicious activity. But as the CISA report demonstrated, this reliance can become a liability when paired with inadequate network defenses. Here’s why:

1. Tunnel vision on endpoints: EDR excels at identifying threats on individual devices but struggles with network-wide attacks. This leaves gaps when hackers exploit lateral movement or unusual data transfers — activities that often require network-level visibility to detect.
2. Playing catch-up with threats: Traditional EDR tools depend on recognizing known indicators of compromise (IOCs). Advanced attackers can easily sidestep these tools by using novel techniques or blending in with legitimate activity.
3. Blind spots in legacy systems: Legacy environments often go unnoticed by EDR, giving attackers free rein. In the CISA case, these systems allowed the red team to persist for months undetected.
4. Overwhelmed defenders: Even when EDR generates alerts, security teams can become desensitized by a flood of notifications. As seen in the CISA assessment, critical warnings can slip through the cracks simply because defenders are too stretched to respond.

Common EDR pain points

The challenges highlighted in the CISA report mirror broader issues organizations face with EDR:

• Detection without context: EDR tools often spot anomalies on endpoints but fail to connect the dots across the broader network. This lack of context can leave organizations blind to coordinated attacks.
• Weak network integration: Without network-layer defenses, EDR struggles to identify malicious activities like unusual traffic patterns or data exfiltration, key tactics in advanced breaches.
• Fragmented systems: Many organizations operate a patchwork of security tools, leaving critical gaps in coverage and making it harder to correlate data across endpoints, networks and cloud environments.

Explore threat detection and response services

The next evolution of EDR

Recognizing these shortcomings, cybersecurity is rapidly evolving beyond traditional EDR. Here’s how:

1. Extended detection and response (XDR): XDR takes EDR to the next level by integrating endpoint, network and cloud data into a single platform. This broader scope allows organizations to see the full attack picture and respond more effectively.
2. AI-driven insights: Cutting-edge EDR solutions now harness machine learning to detect subtle behavioral anomalies. By identifying deviations from normal activity, these tools catch threats even when no IOCs exist.
3. Zero trust security: Zero trust architectures take endpoint defense a step further by ensuring no device or user is trusted by default. This integration of endpoint, identity and network security reduces dependence on EDR alone.
4. Network visibility: Modern EDR tools are incorporating network traffic analysis to close the gaps identified in the CISA report. Monitoring traffic for anomalies, such as unusual data flows or external connections, bolsters defenses.
5. Cloud-native solutions: As businesses embrace hybrid and cloud environments, EDR is evolving to provide seamless coverage across on-premises and cloud systems, addressing vulnerabilities in these critical areas.

Why do gaps persist?

Even with these advancements, many organizations struggle to fully address EDR’s limitations:

• Resource strains: Small security teams often lack the bandwidth or expertise to implement and manage advanced solutions like XDR.
• Budget constraints: Upgrading to integrated platforms or modernizing legacy systems can be costly.
• Legacy challenges: Outdated environments remain vulnerable, acting as weak points that attackers can exploit.
• Leadership missteps: As the CISA report pointed out, organizations sometimes deprioritize known vulnerabilities, leaving critical gaps unaddressed.

Building a more resilient future

The CISA red team findings are a wake-up call: Endpoint protection alone is no longer enough. To outsmart today’s sophisticated adversaries, organizations must adopt a layered defense strategy that integrates endpoint, network and cloud security. Solutions like XDR, zero trust principles and advanced behavioral analysis offer a path forward — but they require strategic investments and cultural shifts.

The post Insights from CISA’s red team findings and the evolution of EDR appeared first on Security Intelligence.

On September 25, CISA issued a stark reminder that critical infrastructure remains a primary target for cyberattacks. Vulnerable systems in industrial sectors, including water utilities, continue to be exploited due to poor cyber hygiene practices. Using unsophisticated methods like brute-force attacks and leveraging default passwords, threat actors have repeatedly managed to compromise operational technology (OT) and industrial control systems (ICS).

Attacks on the industrial sector have been particularly costly. The 2024 IBM Cost of a Data Breach report found the average total cost of a data breach in the industrial sector was $5.56 million — an 18% increase for the industry compared to 2023. This represents the highest data breach cost increase of all industries surveyed in the report, rising by an average of $830,000 per breach over last year.

Ongoing vulnerabilities pose a serious threat to public safety and national security, especially as water systems and other critical infrastructure providers remain underprepared in the current threat landscape. Let’s take a closer look at the current state of critical infrastructure security, highlighting recent incidents, efforts to address vulnerabilities and the need for further collaboration between the government and private sectors.

Arkansas City Water Treatment Facility attacked

The cybersecurity incident at the Arkansas City Water Treatment Facility on September 22 exemplifies the growing risks. While city officials emphasized that the water supply remained safe and no disruption to service occurred, the breach still forced the facility to switch to manual operations. The incident is currently under investigation, with local authorities and cybersecurity experts collaborating to resolve the issue and prevent further attacks. But the Arkansas City breach is not an isolated incident; it mirrors a larger trend of attacks on water systems.

CISA has issued multiple warnings regarding the susceptibility of water and wastewater systems to cyber threats. Intruders often exploit outdated and unsecured OT and ICS environments, where systems are exposed to the internet or still using default credentials. This means cyber criminals can gain access using relatively simple techniques, which raises concerns about the overall preparedness of critical infrastructure operators.

CISA warnings and hacktivist activity

CISA’s September alert is not the first indication of the heightened threat to water and other critical infrastructure providers. Earlier in 2024, the agency warned that Russia-affiliated hacktivists were actively targeting ICS and OT environments in U.S. critical infrastructure facilities. Water systems, dams and sectors, such as energy and food, were particularly vulnerable to these attacks.

The situation worsened with the rise of the Cyber Army of Russia Reborn, a hacktivist group tied to Advanced Persistent Threat 44 (APT44), commonly known as Sandworm. The group has been quite busy exploiting weak cybersecurity postures of smaller water systems that lack adequate cyber defense resources.

According to Keith Lunden of Mandiant, “We expect these attacks to continue for the foreseeable future given the lack of dedicated cybersecurity personnel for many small- and mid-sized organizations operating OT.” Unfortunately, hacktivist groups have exploited these gaps with relative ease. And without rapid intervention, these attacks will likely continue.

Read the Threat Intelligence Index

The State and Local Cybersecurity Grant Program (SLCGP)

Amidst the growing cyber threats, the U.S. Department of Homeland Security (DHS) has recognized the need for more support for state and local government cybersecurity. In fiscal year 2024, DHS announced the allocation of $280 million in grant funding for the State and Local Cybersecurity Grant Program (SLCGP). This funding aims to assist state, local, tribal and territorial governments in enhancing their cyber resilience. A special emphasis has been placed on protecting critical infrastructure systems like water utilities, energy grids and emergency services.

These grants will help organizations improve monitoring systems, patch vulnerabilities and implement critical cybersecurity measures such as multi-factor authentication and regular system audits. In states like Michigan, for example, government agencies are already working with local water utilities to provide cybersecurity training and support. The DHS funding could greatly expand these efforts, offering a much-needed boost to the security posture of critical infrastructure providers.

The Cyberspace Solarium Commission

In 2019, the Cyberspace Solarium Commission (CSC) was established by the U.S. Congress to develop a national cyber defense strategy. Currently, approximately 80% of its recommendations have been implemented. However, a final push is needed to address critical gaps, particularly regarding private-sector collaboration and insurance reforms.

One major challenge is identifying the “minimum security burdens” for systemically important entities critical to national security. This would ensure that high-priority infrastructure providers, such as key transportation systems and water utilities, receive the necessary support to prevent catastrophic events.

The CSC also highlighted the need to develop an economic continuity plan for cyber events. This would be nothing less than an incident response and resilience plan to protect the U.S. economy in the face of a major cyberattack. The commission also emphasized the need for better information sharing between government agencies, private industries and international partners to protect critical infrastructure from evolving cyber threats.

During a recent panel discussion, Senator Angus King, co-chair of CSC 2.0, pointed to the difficulties of building trust between the government and private sectors. Private entities own and operate the majority of the nation’s critical infrastructure, but historical tensions make collaboration challenging. King noted that the situation mirrors early tensions that existed between state officials and CISA. Nonetheless, the collaboration between private industry and government is essential to address the growing threat to critical infrastructure.

The state of critical infrastructure cybersecurity

The cybersecurity posture of U.S. critical infrastructure remains a concern. As seen in attacks like the Arkansas City Water Treatment Facility and other incidents targeting internet service providers, threat actors are increasingly focusing on essential services. These attacks are not limited to small municipalities. Larger-scale infrastructure providers, including ISPs and managed service providers, have also been targets.

The FBI recently disclosed that China-linked hackers compromised more than 260,000 network devices, underscoring the scale of the problem. Meanwhile, attacks attributed to the Chinese government have targeted ISPs and managed service providers through vulnerabilities in Versa Networks’ SD-WAN software, demonstrating the growing sophistication of these threats.

While the U.S. government is actively working to improve critical infrastructure cybersecurity, the attacks on water treatment systems and other essential services clearly reveal that more needs to be done. The DHS grant program and the recommendations of the Cyberspace Solarium Commission represent critical steps in this effort, but collaboration between government, private industry and international partners will be key to building a resilient defense against evolving threats.

The safety of critical infrastructure remains a pressing concern. Recent events should serve as a wake-up call for operators, policymakers and the public to take action before a cyberattack occurs that impacts human life and health. Undoubtedly, the threats are real — and any meaningful response requires a concerted effort.

The post Is the water safe? The state of critical infrastructure cybersecurity appeared first on Security Intelligence.

At the end of 2024, we’ve reached a moment in artificial intelligence (AI) development where government involvement can help shape the trajectory of this extremely pervasive technology.

In the most recent example, the Department of Homeland Security (DHS) has released what it calls a “first-of-its-kind” framework designed to ensure the safe and secure deployment of AI across critical infrastructure sectors. The framework could be the catalyst for what could become a comprehensive set of regulatory measures, as it brings into focus the significant role AI will play in securing key infrastructure systems.

As Secretary Alejandro N. Mayorkas put it, “AI offers a once-in-a-generation opportunity to improve the strength and resilience of U.S. critical infrastructure, and we must seize it while minimizing its potential harms. The framework, if widely adopted, will go a long way to better ensure the safety and security of critical services that deliver clean water, consistent power, internet access and more.”

Mayorkas’ statement underscores the urgency of getting it right, as today’s decisions will profoundly shape how AI impacts vital systems in the future.

Key features of the DHS AI framework

The framework lays out clear roles and responsibilities for the parties involved in AI development and deployment for critical infrastructure.

Risk management guidance: DHS suggests an approach that incorporates ongoing risk management, advising stakeholders to continually identify, assess and mitigate potential AI risks. The recommendation includes adopting transparent mechanisms to track AI decisions that could impact essential services.

Ethical standards for developers: The guidelines stress the importance of incorporating ethical considerations into AI design, and make a push for responsible practices that minimize harm and ensure equitable treatment.

Collaboration across sectors: Recognizing the interconnected nature of infrastructure, DHS is promoting collaboration between public and private sectors to share best practices and vulnerabilities effectively. Information sharing is always a great way to minimize the risks brought about by both deliberate attacks and unintended failures.

Incident response preparedness: The framework also outlines how AI developers and operators should prepare for potential incidents; clear protocols must be in place to quickly address issues before they escalate.

Explore AI cybersecurity solutions

What are the responsibilities of AI developers?

One of the most notable aspects of the DHS report is the explicit focus on the responsibilities of AI developers.

The guidelines set a new precedent by outlining clear expectations, especially for those creating AI tools meant to operate in or interact with critical infrastructure.

This focus on developers is particularly important because they are at the forefront of creating technology that directly influences critical systems. The decisions made during the design, development and deployment phases can have significant consequences and impact everything from public safety to national security. By giving developers a structured set of responsibilities, DHS is hoping to create a culture of accountability and foresight in the AI community.

As such, AI developers are encouraged to take the following actions to align with the new guidelines.

Design with risk in mind: Developers are urged to build AI systems that prioritize safety and resilience from the ground up, especially when the technology is intended to interact with critical services like power grids or communication networks. This means integrating fail-safes, conducting stress tests and simulating potential failure scenarios during the design phase.

Adopt explainable AI practices: Transparency is crucial for AI developers. The framework urges the adoption of explainable AI techniques that allow human operators to understand why certain decisions were made. This practice boosts trust while also providing an audit trail that can be useful in identifying the root causes of any issues that arise.

Collaborate for broader impact: Developers should not just work alone but actively engage with a broader community of stakeholders, including policymakers, users and other tech creators. After all, collaboration helps ensure that AI tools are safe, reliable and ready to operate under real-world conditions.

By following these guidelines, developers can help build AI systems that meet technical standards and also align with societal values and safety requirements. The focus on explainable AI, risk-based design and collaboration creates a balanced approach that can maximize the benefits of AI and minimize its potential downsides.

Why does this matter now?

The release of the AI framework is a good reminder that AI technology is not evolving in a vacuum. Today, AI is more pervasive than ever before, but its use in critical infrastructure demands the highest level of care and responsibility. With the focus on developers as important players in minimizing risks, the DHS is creating an environment where AI can thrive without compromising essential public services.

It’s important to note that the responsibility for secure AI extends beyond the developer stage. Tech organizations will play a key role as well. Arvind Krishna, Chairman and CEO of IBM, says, “The DHS Roles and Responsibilities Framework for Artificial Intelligence in Critical Infrastructure is a powerful tool to help guide the responsible deployment of AI across America’s critical infrastructure, and IBM is proud to support its development. We look forward to continuing to work with the Department to promote shared and individual responsibilities in the advancement of trusted AI systems.”

Secretary Mayorkas echoes those sentiments, adding, “The choices organizations and individuals involved in creating AI make today will determine the impact this technology will have in our critical infrastructure tomorrow.”

The secretary’s words capture the essence of why this framework matters: We need to shape the future of AI in a way that protects and enhances the services that are foundational to our society.

The post DHS: Guidance for AI in critical infrastructure appeared first on Security Intelligence.

On August 29, 2024, CISA announced the launch of a new cyber-incident Reporting Portal, part of the new CISA Services Portal.

“The Incident Reporting Portal enables entities and individuals reporting cyber incidents to create unique accounts, save reports and return to submit later, and eliminate the repetitive nature of inputting routine information such as contact information,” says Lauren Boas Hayes, Senior Advisor for Technology & Innovation, at CISA.

Shortly after the announcement, Security Intelligence reported on how the portal was designed and how it differs from other cyber incident reporting structures. We noted that CISA’s biggest advantage was its ability to assist the reporting organization with response and remediation.

“Any organization experiencing a cyberattack or incident should report it — for its own benefit and to help the broader community. CISA and our government partners have unique resources and tools to aid with response and recovery, but we can’t help if we don’t know about an incident,” said CISA Executive Assistant Director for Cybersecurity Jeff Greene in a formal statement covering the portal’s announcement.

Four months later

Since the announcement in August, a lot has happened. There was a presidential election, and a new administration will take charge on January 20. The current CISA director and other political appointees will step down. The agency’s future is uncertain as of this writing, particularly regarding who will oversee it and whether its functions will be divided across different federal departments. Still, it is expected that its work will continue.

Before these changes occur, we wanted to check in with CISA to follow up on the portal’s progress and what the future might look like.

Explore cybersecurity services

Long history of collecting cyber incident reports

CISA was first created in 2018, but federal agencies have collected cyber incident reports for decades.

“The launch of the Incident Reporting Portal is a significant step forward for CISA’s ability to collect operationally relevant data from reporters in a system which is more usable for reporters,” says Hayes. “The vision for the Incident Reporting Portal is for CISA’s Incident Reporting Portal to continue to enhance the functionality of the system to enable entities to share submitted reports with colleagues or clients to facilitate more effective third-party reporting, communicate directly with CISA, and access information and services relevant to the reporter.”

The portal is expected to make compliance with the Cyber Incident Reporting for Critical Infrastructure Act of 2022 easier. This act will “require CISA to coordinate with Federal partners and others on various cyber incident reporting and ransomware-related activities” across the 16 sectors, agencies and industries deemed “vital to the health, economy and security of the community or region.”

Hayes adds that while reporting under the Cyber Incident Reporting for Critical Infrastructure Act of 2022 will not be required until the Final Rule goes into effect, the agency encourages critical infrastructure owners and operators to voluntarily share information on cyber incidents prior to that date to help prevent other organizations from becoming victims of similar incidents.

“Sharing information allows us to work with our full breadth of partners to help prevent attackers from compromising other victims using the same techniques,” says Hayes.  “Sharing information can provide insight into the scale of an adversary’s campaign.”

Why reporting is vital to overall cybersecurity

While reporting cyber incidents to the portal is voluntary at the moment, all organizations are encouraged to share the information. If they feel the need, they can do so anonymously. As cyberattacks and nation-state threats become more sophisticated and increasingly target critical infrastructure industries, sharing this information with CISA allows the agency to help other organizations prepare for emerging threats and implement preventive measures before the damage is done.

“Isolating cyberattacks and preventing them in the future requires the coordination of many groups and organizations,” CISA explained. “By rapidly sharing critical information about attacks and vulnerabilities, the scope and magnitude of cyber events can be greatly decreased.”

And it isn’t just CISA that uses this information. According to the U.S. Government Accountability Office (GAO), 14 federal agencies are responsible for protecting critical infrastructure from cyberattacks, many in unexpected ways. For example, TSA, which handles airport security screening, is also responsible for safeguarding the country’s gasoline pipelines.

“Entities representing critical infrastructure owners and operators told us there are great benefits in getting information about threats from federal agencies,” the GAO reported.

What comes next

Despite a changing presidential administration, CISA is moving forward. It is planning a future designed to keep the critical infrastructure safe from cyber threats, which, in turn, will provide a layer of protection for the nation’s citizens and businesses.

“Sharing information allows us to work with our full breadth of partners so that the attackers can’t use the same techniques on other victims and can provide insight into the scale of an adversary’s campaign,” Jeff Greene was quoted in Federal News Network. “CISA is excited to make available our new portal with improved functionality and features for cyber reporting.”

As for the Incident Reporting Portal’s future, Hayes says, “In the future, we are planning to implement additional features that will take time to develop and incorporate user feedback. Our user experience team is actively working to get feedback on how we can improve the system over time.”

The post CISA’s cyber incident reporting portal: Progress and future plans appeared first on Security Intelligence.