Discuss an engagement
Menu

Adversary Simulation

Supply Chain Attack Assumed Breach

Start from a compromised developer account and find out what an attacker could reach. A controlled assumed breach exercise modelling a backdoored software dependency.

Discuss an engagement
Objective
Reach from a compromised developer
Maturity
Developer tooling and a cloud estate
Approach
Simulated malicious dependency
Result
Evidence of attainable access

Software dependencies have become a direct route to developer accounts, and developers usually hold more privileged access than a typical end user. A backdoored open-source package is a functional version of legitimate software with harmful logic embedded, installed as part of routine local development.

Once a compromised package enters a development environment it can persist undetected while work continues as normal, and in many cases the compromise stays invisible until significant damage has been done.

This engagement does not attempt to simulate the initial compromise. It assumes that access has already happened, because in practice it happens without warning, and asks what a threat actor could realistically achieve from the developer's device and whether existing controls would detect or contain them.

Further reading: what follows a compromised dependency, and the dependency compromise exposure worksheet for mapping your own exposure.

Why this route matters

Compromise typically occurs when a developer installs a package from a public repository without scrutinising the underlying logic. The open nature of these ecosystems, and the perceived trustworthiness of publicly readable source code, gives a threat actor a quiet foothold inside the organisation.

Privileged by default

Developer accounts commonly reach source control, pipelines and cloud consoles that ordinary user accounts never touch.

Quiet persistence

A compromised dependency keeps working as intended, so nothing about day-to-day development looks wrong.

An actively used route

Campaigns attributed to financially motivated groups have deliberately targeted widely used packages in standard development workflows.

Unclear blast radius

Most organisations cannot say with confidence what a single compromised developer laptop would expose.

Is a supply chain assumed breach the right fit?

It suits organisations whose developers pull from public package repositories and whose developer accounts reach systems that matter.

A supply chain assumed breach fits when

  • Developers install packages from public repositories as part of normal work
  • Developer accounts reach source control, CI/CD or a cloud environment
  • Endpoint and identity controls are deployed and you want them tested, not assumed
  • You want evidence of attainable access rather than a list of theoretical risks

How the engagement runs

Five stages, from agreeing the account to modelling to pursuing the objectives it can reach.

  1. 01

    Agree the account to model

    • Your organisation designates a developer account and a system representative of a real profile, with standard controls enabled
    • The choice directly shapes the attack paths explored, so it is made deliberately rather than by convenience
    • Candidates include the most common developer role, a junior developer, a contractor or remote developer, or a role siloed to one team
    • Permissions are best cloned from an existing user so the exercise reflects access a real attacker would obtain
  2. 02

    Deploy the simulated dependency

    • SilentGrid develops Python and Node.js packages tailored to the environment
    • Each carries an embedded command-and-control payload that runs when the module is imported by a local program
    • This models the behaviour of a backdoored dependency delivering an implant, without touching any public package registry
  3. 03

    Establish the foothold

    • The engagement begins with all security controls fully enforced, including EDR, ITDR, and firewall and network monitoring
    • Detections and blocks at this stage are recorded as positive observations, because they are a result in their own right
    • Concessions are then introduced so assessment can continue past the initial foothold
  4. 04

    Assess what the account reaches

    • Cloud environments across platforms such as AWS, Azure and GCP
    • CI/CD platforms such as Jenkins, Octopus Deploy or Azure Pipelines
    • Source code repositories such as GitHub, GitLab or Bitbucket
    • Knowledge repositories such as Jira, Confluence and SharePoint
    • Identity platforms such as Microsoft Entra ID and Okta, and on-premises Active Directory
  5. 05

    Pursue the agreed objectives

    • Map the services and resources the compromised account can reach, and identify viable paths for lateral movement and privilege escalation
    • Prioritise paths leading to core business systems, sensitive data or other targets that demonstrate tangible impact
    • Activities may include evading endpoint and network controls, obtaining domain credentials, escalating to privileged accounts, moving between network segments, and staging or simulating exfiltration of sensitive data

Controls and concessions

Running the engagement against every control is valuable in itself, but where those controls block the simulated implant, assessment of the wider environment stops at the first host. Concessions keep the exercise moving without discarding that first result.

Enforced at the start

Controls run fully enforced until they detect or block the implant, and whatever they catch is written up as a positive observation.

Applied narrowly

Concessions may place EDR in monitoring-only mode on the foothold host, or allow-list command-and-control infrastructure.

Limited to the foothold

Concessions are not expected to apply to other hosts reached during the engagement, only the host used for initial access.

Detection, not stealth

Operators remain undetected where viable, but effort is not spent on evasion at the cost of reaching the agreed objectives.

What you provide

The engagement depends on an account that looks and behaves like a real developer's. Preparing it well is what makes the findings relevant.

A representative account

Username and password, multi-factor authentication, and group and role assignments cloned from a real developer profile.

A name that fits

The account should carry a plausible name rather than one identifying the assigned SilentGrid operators.

A representative system

An end-user laptop with VPN access, or a VDI development environment, connected to the corporate network.

Developer tooling

The account should be able to install the tooling a developer in that environment could install, such as Python and Node.js.

Matching application access

Messaging, knowledge, CI/CD and source control access aligned with the modelled role, across cloud identity and Active Directory where applicable.

Any exclusions

Employees, systems or services that must stay out of scope are agreed with SilentGrid before the engagement begins.

Run it continuously

Model the compromise once, or test all year.

A single engagement shows what one compromised developer account can reach and whether your controls detect it. Where developer access and tooling change often, CAOS (Continuous Adversary Operations Service) runs adversary cycles through the year that include pivots into developer environments and code repositories.

Explore CAOS

Deliverables and reporting

Reporting covers what was reached, how it was reached, and what held. Positive observations are recorded alongside findings.

Executive summary

A high-level, non-technical account of the exercise and what it found.

Technical summary

The objectives, the concessions applied, positive observations and a summary of findings.

Positive observations

Security controls and mechanisms that worked, recorded as results rather than omissions.

Attack narrative

A step-by-step account of the attack from the operator's perspective, in the order it happened.

Recommendations

Practical changes to improve resilience, prioritised against the paths that were actually attainable.

Appendices

Remaining cleanup items, compromised accounts, public IP addresses, file hashes and command-and-control details.

Why SilentGrid

SilentGrid's consultants are hand-picked, and between them they have delivered red team engagements globally over decades, including CBEST for UK financial institutions and CORIE engagements in Australia. Their sector experience covers banking and financial services, insurance, government, critical infrastructure and healthcare.

Consultants find 0-day vulnerabilities in commercial software and speak or teach at security conferences. That research produces the custom tooling used to bypass EDR and network controls, and keeps techniques current with the threat actor being simulated. The methodology follows concepts set out in NIST, OWASP, PTES and OSSTMM.

CREST ANZApproved company

Individual credentials across our team include

  • OSEE
  • OSCE3
  • OSED
  • OSEP
  • OSWE
  • GXPN
  • CRTO
  • CRTE
  • CRTP
  • OSCP
Meet the team

From our research

What we have found doing this.

All research

Common questions

What is a supply chain attack assumed breach?

A supply chain attack assumed breach tests an organisation the way an attacker behind a backdoored software package would: SilentGrid builds a Python or Node.js dependency with an embedded command-and-control payload, runs it on a representative developer's device without touching any public registry, then maps what that account reaches across source control, CI/CD, cloud and identity platforms.

Do you simulate the supply chain compromise itself?

No. The exercise assumes the initial access has already happened, because in practice a backdoored dependency arrives without warning. Testing begins from the developer's device and measures what follows.

What do we need to provide?

A developer account and a representative system with standard controls enabled, provisioned to mirror the roles, privileges and access rights of a real developer. Any employees, systems or services that must be excluded are agreed beforehand.

Which developer account should we choose?

The choice shapes the attack paths explored, so it is worth deliberating. A junior developer may be the more likely target for an inadvertent install; a senior or specialist developer is more security-aware but usually holds access to core systems and source repositories. Both are valid, and they answer different questions.

Do you ask us to turn our security controls off?

The engagement starts with controls fully enforced, and anything they detect or block is recorded as a positive observation. Concessions are then introduced so assessment can continue past the first host. They may include placing EDR in monitoring-only mode on the foothold host or allow-listing command-and-control infrastructure, and are not expected to apply to other hosts.

Will you try to stay undetected?

Operators remain undetected where that is viable, but effort is not spent on evasion at the cost of reaching the agreed objectives within the engagement. Where a security team is monitoring, the activity generated is useful for validating and tuning alerting and detection rules.

How are the objectives decided?

They are agreed during scoping and reflect what would demonstrate real impact in your environment. Access to sensitive data, a primary code repository, a connected cloud environment or a specific business system are all common starting points.

What do we receive at the end?

A report covering an executive summary, a technical summary, positive observations, a step-by-step attack narrative, recommendations, and appendices including cleanup items and indicators from the engagement.

Ready to test what a developer compromise reaches?

Get started with a supply chain assumed breach

Scope the account to model, agree the objectives that would demonstrate real impact, and plan the engagement around your environment.

Discuss an engagement Explore adversary simulation