Sliver C2 Attack Compromises Windows Domain

Attackers disable EDR and push Sliver C2 across Windows domain in real-world intrusion

A Sliver C2 attack against an unnamed US organisation shows how attackers can turn one compromised Windows system into a platform for domain-wide access. The operators disabled endpoint protection, created accounts, stole credentials and prepared to deploy command-and-control tooling across multiple hosts.

The incident was reported on 8 September 2026. Although the recovered material contained no evidence of ransomware deployment, the activity demonstrated several capabilities that could support data theft, disruption or a later ransomware operation.

What happened in the Sliver C2 attack

The intrusion affected an Active Directory environment belonging to one unidentified organisation in the United States. The organisation’s industry, size and identity were not disclosed, and the available reporting does not establish when the attackers first gained access.

After securing an initial foothold, the operators used a Sliver beacon to maintain command-and-control access. Sliver is a legitimate, open source adversary simulation framework, but attackers can misuse its remote control capabilities to execute commands, transfer files and manage compromised systems.

The activity was staged from an exposed server controlled or accessed by the operators. Files recovered from that infrastructure included scripts tailored to a real Windows domain, rather than generic test material. This indicates that the attackers had already gathered enough information about the victim’s environment to prepare targeted actions.

Endpoint protection was deliberately disabled

A central part of the Sliver C2 attack involved weakening endpoint security. The operators used scripts intended to disable endpoint protection before expanding their access, reducing the likelihood that later tools and commands would be blocked or reported.

The reporting does not identify the endpoint security vendor, product, configuration or version involved. It therefore does not indicate that a vulnerability in one particular security product was exploited. Instead, the incident appears to involve attackers attempting to interfere with defensive controls after obtaining access and sufficient privileges.

This distinction matters because the event is not a conventional product vulnerability disclosure with a patchable CVE. It is an intrusion in which administrative access, scripts and existing Windows capabilities were used to undermine security monitoring.

Attackers created accounts and targeted credentials

The operators also created accounts inside the compromised environment. New accounts can give an intruder an additional route back into a network if the original entry point is discovered, disabled or isolated.

Credential theft formed another part of the operation. Stolen credentials could allow the attackers to impersonate legitimate users, access additional computers and move through the Active Directory domain without relying solely on malware.

The available material does not specify which accounts were compromised, whether domain administrator privileges were obtained, or which credential extraction technique succeeded. It does, however, show that identity access was a deliberate objective alongside endpoint defence evasion.

How Sliver was prepared for wider deployment

The recovered scripts included a planned rollout across 18 hosts. This is one of the clearest signs that the Sliver C2 attack was intended to extend beyond a single compromised machine and establish broader control inside the organisation.

Deploying beacons across multiple endpoints would provide resilience. If defenders isolated one host, the operators could potentially retain access through another affected system. Multiple footholds could also support parallel reconnaissance, credential collection and remote command execution.

The planned deployment does not prove that all 18 hosts were successfully compromised. It shows that the attackers had identified a defined group of systems and prepared automation for distribution across them. The public reporting does not provide a confirmed final count of infected endpoints.

Remote administration supported lateral movement

Remote administration was used alongside account creation and credential theft. In a Windows domain, legitimate administrative mechanisms can allow authorised staff to manage systems centrally, but the same facilities become valuable to an attacker who has acquired valid credentials and suitable privileges.

This approach can make malicious activity resemble routine administration. Rather than exploiting a separate software flaw on every computer, an operator may use trusted accounts, scripts and remote management functions to execute tools across reachable systems.

The main stages visible in the incident were:

  • Establishing an initial foothold in the unnamed organisation.
  • Using an exposed external server to stage operational files.
  • Deploying or preparing a Sliver beacon for command-and-control access.
  • Attempting to disable endpoint protection before further activity.
  • Creating accounts to provide additional access and persistence.
  • Stealing credentials for use elsewhere in the Active Directory environment.
  • Preparing scripts for rollout across 18 identified hosts.
  • Using remote administration to support movement through the domain.

The initial access method remains unknown from the supplied reporting. There is no confirmed indication that phishing, an exposed remote service, stolen credentials or exploitation of a software vulnerability provided the original entry point.

Current exploitation and ransomware status

The evidence relates to one unnamed US organisation and an exposed staging server. No broader victim count, named threat group or widespread campaign has been confirmed in the available report.

There was also no proof that ransomware was deployed in this specific incident. The absence of a confirmed ransomware payload should not be interpreted as proof that the activity was harmless. Disabling security controls, stealing credentials and spreading command-and-control access are serious post-compromise actions in their own right.

It is also important not to attribute every use of Sliver to one criminal group. The framework is available for legitimate security testing and can be adopted by different operators. Attribution requires supporting infrastructure, malware, operational and intelligence evidence that was not disclosed here.

Why the Windows domain intrusion matters

The incident demonstrates that installing endpoint detection and response software does not guarantee visibility if attackers can alter or disable it. Organisations need to know when agents stop reporting, configurations change or protection services are tampered with.

The planned 18-host deployment also highlights the connection between endpoint security and Active Directory. Once valid credentials and remote administrative privileges are available, a compromise can spread using functions that the organisation normally trusts.

Actions organisations should take now

Defensive work should focus directly on the behaviours seen in this Sliver C2 attack. Security teams should verify that endpoint tamper protection is enabled and that alerts are generated when agents are stopped, removed or disconnected.

  • Review recent creation of local and domain accounts, especially accounts granted administrative rights.
  • Investigate unexpected endpoint protection changes, service stoppages and gaps in security telemetry.
  • Search network and endpoint logs for unexplained Sliver-like beaconing or command-and-control connections.
  • Audit remote administration activity and identify unusual execution across multiple domain hosts.
  • Reset exposed credentials and isolate affected systems before reconnecting them to the domain.
  • Check whether privileged accounts can remotely access more endpoints than their roles require.

If suspicious activity is found, organisations should preserve logs and evidence while determining the full scope. Removing a beacon from one computer may be insufficient if accounts were created, credentials were stolen or deployment had already reached other hosts.

Originally reported by cybersecuritynews.com.

Share this bulletin

About the Author

Rob McBride Headshot - CyPro Partner and leading cyber security expert

Rob McBride

Partner

  • CISSP
  • ACA Chartered Accountant
  • MPhil
  • BSc
  • SOC 2
  • ISO 27001

Rob McBride

Rob is a Founding Partner at CyPro and a highly experienced CISO. Beginning his career with a successful tenure at Deloitte, Rob has since amassed a wealth of experience, notably serving as a cyber security advisor to the UK government and spearheading cloud security transformations for several global banks.

At CyPro, Rob leads the managed service business line, working extensively across multiple sectors including telecommunications, technology, higher education, travel, and retail. He is passionate about equipping small and medium-sized businesses (SMBs) with robust cyber security strategies to fuel their growth.

View Profile
Back to Bulletins

Related CyPro Services

  • Managed Detection and Response (MDR)

    Managed Detection and Response (MDR) is an end-to-end managed service designed to help organisations detect, analyse and respond to cyber threats quickly and effectively. It...
    View Service
CyPro Cookie Consent

Hmmm cookies...

Our delicious cookies make your experience smooth and secure.

Privacy PolicyOkay, got it!

We use cookies to enhance your experience, analyse site traffic, and for marketing purposes. For more information on how we handle your personal data, please see our Privacy Policy.

Schedule a Call