How Defenders Can Make Attack Chains Slower and Noisier

Attackers do not need every step of an intrusion to be reliable. They need enough of the environment to behave predictably that one action leads to the next. That may mean finding an administrative account, abusing a permitted remote-management tool, persuading an employee to bypass normal verification, or retrieving command-and-control information from a service that appears legitimate.

A defensive strategy built around frustrating those assumptions can make an operation slower, less dependable, and more visible. In a report for Cybersecurity Awareness Month, Cisco Talos researchers describe a collection of practical measures that apply across the attack lifecycle. The central idea is not that one control will stop every intrusion. Rather, organizations should remove easy options, introduce uncertainty, and identify the dependencies that connect one stage of an operation to another.

The recommendations cover deception, behavioral detection, governance of legitimate administrative tools, social-engineering resistance, controls for AI agents, and disruption of infrastructure dependencies. Some examples are based on Talos observations; others are the researchers’ defensive assessments and recommendations. They should therefore be adapted to the organization’s architecture, business processes, and risk tolerance.

Make the environment less predictable

According to Cisco Talos, many adversaries favor techniques that work across a broad range of organizations. That creates a defensive opportunity: an environment with carefully selected differences can make common attack paths less reliable.

Examples include restricting which accounts may sign in to critical servers, alerting when unauthorized users attempt to connect, and monitoring changes to those restrictions. Sensitive systems can use separate credentials or authentication methods, while protected enclaves can add monitoring around critical infrastructure. Talos also recommends alerting on changes to administrative accounts and groups.

These measures do not make an organization impenetrable. Their value is that they reduce the number of assumptions an intruder can safely make. A stolen account may not be authorized for a critical server. A newly added administrator may generate an alert. A connection that would normally blend into routine activity becomes anomalous because the environment has defined more precise boundaries.

Use deception as an early-warning layer

Deception can expose reconnaissance and initial-access activity before an adversary reaches genuine users or systems. Talos describes the use of honeypot email accounts, fictional employee profiles, false servers, decoy shares, user accounts, and network space.

One proposed approach is to create monitored email accounts associated with expired domains or addresses that have previously been exposed, as well as fictional profiles whose addresses are placed where unwanted senders may discover them. Because these accounts have no legitimate users, messages sent to them can be treated with a higher degree of suspicion. They may provide intelligence about lures, campaigns, or infrastructure before similar activity reaches employees.

Decoy systems and shares serve a related purpose. An attacker cannot be certain that a discovered resource is genuine or useful, while defenders gain an opportunity to detect access or interaction. Talos also discusses tarpits, including experiments intended to slow automated systems with large amounts of incoherent content. The report does not present this as a universal control; organizations should assess whether such mechanisms are safe, lawful, and operationally appropriate in their environment.

For administrators, the practical requirement is ownership. Every decoy should have a defined purpose, a monitored access path, and an escalation process. A honeypot that produces alerts nobody reviews is not meaningful deception. Alert context should include the account or resource touched, the source system, the time, and the activity that triggered the alert.

Detect objectives rather than favorite tools

Tool-specific detections are often fragile. An adversary seeking credential material can replace one utility with another, use a different syntax, or apply obfuscation. Cisco Talos recommends designing detections around the underlying behavior and objective instead.

The report uses credential access as an example. A detection narrowly focused on a named utility may miss activity performed through another implementation. A more durable analytic looks for the attempt to access protected credential material, then considers the process, user, host, timing, and surrounding activity.

Talos recommends that detection engineers first identify the adversary techniques with the greatest potential impact in their environment. They should then map the different procedures that could accomplish those objectives, determine which behaviors remain consistent when tools or implementations change, and account for encoding, transformation, and obfuscation.

This approach depends on reliable telemetry and an understanding of normal activity. Useful data may come from endpoint, identity, authentication, application, network, and cloud logs, depending on the behavior being monitored. The goal is not to alert on every unusual event. It is to create high-value detections for actions that an attacker cannot easily avoid if they continue pursuing the objective.

MITRE ATT&CK can provide a taxonomy for organizing this work, but the supplied Talos research does not assign specific ATT&CK technique IDs to the examples in the report. Teams should avoid treating a taxonomy as a substitute for local validation. Detection logic must reflect how systems are actually administered and what legitimate software does in that environment.

Govern legitimate remote-management software

Remote monitoring and management tools illustrate the challenge of dual-use software. Organizations depend on RMM products for administration and support, while ransomware operators can use similar capabilities for persistence, remote interaction, or privilege-related activity.

Cisco Talos states that Warlock ransomware has used Zoho Unattended Agent. The report presents the product as an example of a legitimate tool that can provide a remote technician with elevated permissions even when the signed-in user is not an administrator. Talos does not claim that the product itself is malicious; the security significance depends on whether its use is authorized and consistent with the organization’s operating model.

A defensible program begins with an inventory of approved RMM products, owners, installation locations, and expected users. Application allowlisting can permit authorized products while blocking or generating high-confidence alerts for unapproved tools. Talos names AnyDesk, ScreenConnect, and Atera as examples of tools that may warrant this treatment when they are not approved. Possible enforcement points include Windows Defender Application Control, AppLocker, and endpoint detection and response platforms.

Controls should be paired with an exception process. MSPs and internal IT teams may legitimately require remote access, and indiscriminate blocking can disrupt support operations. The objective is to ensure that every remote-management deployment is attributable, authorized, monitored, and removable. An unexpected installation, service creation, execution by an unusual account, or connection from an unmanaged host should receive particular scrutiny.

Reduce the success of urgency-based social engineering

Technical controls cannot remove every social-engineering risk. Cisco Talos emphasizes that attackers frequently manufacture urgency so recipients act before verifying a request.

Organizations can reduce this pressure by defining verification paths for realistic emergencies. Employees should know which channels are trusted for executive requests, financial changes, account recovery, or urgent welfare-related messages. A request should not be validated using the phone number, link, or reply address supplied by the suspicious message itself.

This is a process design issue as much as an awareness issue. Payment changes, gift-card requests, password resets, and access approvals should have independent confirmation requirements. Tabletop exercises can test whether employees know how to pause an urgent request without being penalized for delay. The objective is to make verification routine rather than exceptional.

Give AI agents an identity and an off switch

Talos argues that each AI-agent session should be identifiable, restricted, and interruptible. The report references a separate Anthropic report describing four incidents in evaluation environments where agents had inadvertently been given internet access. The organizations were not named, and the activity was not described as conventional malicious operations. Talos presents the incidents as evidence of what can happen when agents move beyond their intended boundaries.

The recommended controls include unique identities and short-lived credentials for each agent run, routing traffic through an independent gateway, and blocking access to cloud metadata, Kubernetes interfaces, and other sensitive systems unless the agent genuinely requires it.

Security teams should investigate unexpected writes to package registries, datasets, wikis, paste sites, or file-sharing services; unusual repository creation or dataset commits; unexpected API operations; calls to Kubernetes, VPN, or DNS-over-HTTPS services; rapid destination changes; short-lived egress identities; and unusual traffic bursts. The report also highlights credential discovery followed by activity across cloud accounts or source-control platforms as a concerning sequence.

These are monitoring priorities, not proof of malicious behavior. Some may be legitimate for particular workloads. Agent traffic should therefore carry enough identity and session context to support rapid attribution, review, and interruption.

Break dependencies between attack stages

An operation can continue after a payload reaches an endpoint only if the next required dependency remains available. Finding and blocking that dependency may interrupt the chain even when the initial compromise is not immediately removed.

Cisco Talos describes two attack chains involving the Amatera information stealer. In one, a page on the legitimate Telegra[.]ph publishing service concealed the location of the command-and-control server. This is a dead-drop resolver pattern: malware retrieves infrastructure information from a public service rather than carrying the destination directly. Blocking the specific page can break the handoff, leaving the malware unable to determine where to communicate for collection instructions or additional payloads.

In another chain, Talos says that the C2 domain for the secondary payload ZigCryptoStealer was stored in the metadata of a BNB Smart Chain contract, a technique commonly known as EtherHiding. Blocking one contract does not prevent an adversary from deploying another, but it can disrupt the existing operation and force infrastructure changes.

Defenders can use DNS filtering, secure web gateways, proxies, or firewalls to block known malicious domains and URLs when reliable intelligence is available. Blockchain-related controls are more difficult because they require visibility into remote procedure call traffic and a way to distinguish specific contracts. Organizations without a legitimate need for public blockchain or RPC access may choose broader restrictions; those that need the technology should consider approved-service allowlists and monitoring for known contracts.

What organizations should do now

• Define which accounts, groups, tools, and network paths are authorized for critical systems, then alert on deviations.
• Deploy carefully managed decoy accounts, shares, or services where the organization can monitor and investigate access.
• Prioritize behavioral detections for high-impact objectives instead of relying only on named tools or static indicators.
• Inventory all RMM software, remove unauthorized installations, and require attributable ownership for approved deployments.
• Document independent verification procedures for urgent financial, administrative, and executive requests.
• Assign every AI-agent session a distinct identity, short-lived credentials, restricted egress, and a reliable interruption mechanism.
• Map critical attack-chain dependencies, including public services and infrastructure-resolution mechanisms, and prepare enforcement options.
• Measure whether controls increase detection lead time, generate actionable alerts, or force repeated changes in observed attacker behavior.

Conclusion

The defensive principle in Cisco Talos’s research is straightforward: make essential adversary actions harder, riskier, or less reliable. Deception creates uncertainty, behavioral detection limits tool substitution, governance reduces abuse of legitimate software, verification slows social engineering, and identity-based controls constrain AI agents. Dependency analysis can then expose the point where one stage of an operation relies on another.

None of these measures guarantees prevention. Their combined value is operational: they reduce attacker choices and create more opportunities for defenders to see, investigate, and interrupt an intrusion before it reaches its final objective.

Sources

Cisco Talos: “The Fine Art of Frustrating the Adversary”