The Breach and Attack Simulation (BAS) SEG is a Single-Engineer Group within our Incubation Engineering Department.
This page is updated regularly but updates can be tracked in issues here Breach and Attack Simulations updates issue. The parent update issue also includes a list of GitLab Unfiltered videos from this SEG.
Running exploits to confirm vulnerabilities is inherently risky. We must be intentional in how we define what is in scope or out of bounds for assessments.
This scope may include:
Configuring targets is done inside a project's Security Configuration. For example scan targets can currently be configured inside the DAST CI/CD configuration and DAST profiles for defining dynamic or on-demand targets.
Due to the added risk of simulating attacker behavior this scope should not include a production server. The documentation for authenticated DAST scans sets a clear precedent with a warning. An equivalent warning should be included in documentation surrounding any BAS focused scanners.
Breach and Attack Simulation has several areas that can be focused on. The goal for this SEG is to iterate on existing Secure functionality to highlight high-value targets found through reconnaissance through experiments around further features mentioned below.
To attack something one must first know what targets are available.
Some attacker techniques include:
Inside of GitLab CI we're able to leverage the following:
docker image inspect "$IMAGE"under the path
The following tools could come in handy for port scanning or subdomain enumeration phases of reconnaissance:
When a target system/application exposes vulnerabilities on a network an external system may exploit them.
After recon we discover which vulnerabilities we believe to be exploitable. We can then run exploits against vulnerabilities where there's a low risk of causing actual damage (or in a sandbox environment).
Dynamic Analysis functionality has been updated to add active checks as well as callback checks which enable proving exfiltration of data during simulated attacks.
In many cases privileges for the compromised service or user account may not be sufficient for collection or exfiltration of sensitive data. Through a secondary exploit an attacker can escalate to a more privileged account.
Command and Control, a.k.a. as C2, is the process of creating a persistent channel for executing further commands after an initial compromise to maintain control of a compromised system.
Remote code execution vulnerabilities that are exploitable naturally give us the ability to simulate this behavior.
Once an attacker has compromised an asset in a network they gain even further network access via lateral movement from one asset to another.
In main cases attackers are looking for data or sensitive information they can use for further compromise or financial gain. In many cases network access is restricted so obfuscation or unconventional methods must be used to get this data off of the target network.
To confirm exfiltration we could set up listeners on DNS, TCP, HTTP, etc. to confirm we can initiate egress including unique identifiers. One such tool we could leverage is interactsh which is designed for testing out-of-band (OOB) interactions.
Progress of this portion can be monitored in this issue at gitlab-org/gitlab#333751.
In rarer cases an attacker's goal is simply denial of a service through maliciously destroying data or code required for a target system to run applications.
Evidence of code execution or command injection is sufficient for simulated destruction in some ways. Alternative proof of destruction could be a process similar to Secret Detection post-processing and revocation.
We could introduce a feature flag in DAST to enable destructive behaviour when code injection is viable. We must perform domain/subdomain validation before attempting to run destructive behaviour from Runners.
The complexity of public cloud networks means that a user may have ingress and egress points that are not adequately protected. Using AI/ML, this SEG aims to determine what are the most vulnerable parts of a customers network, and suggest remedies to resolve.
This involves multiple entry point testing which can be simlated by building up a graph of all:
The first iteration where can immediately add value is to provide our users with asset discovery/attack surface & inventories.
Utilize JTBD and job statements to:
|When configure run security scans, I want to run curated attack scenarios, so that I don't need to verify each individual vulnerability manually.||Issue||Issue|
|When I have performed a DAST scan, I want to view exploited vulnerabilities, so I can prioritize remediation and mitigation.||Issue||Issue|
|When I have performed a non-DAST scan, I want to view exploited vulnerabilities, so I can prioritize remediation and mitigation.||Issue||Issue|
|When I run my service inside a GitLab CI Service container, I want to simulate attacks, so that I can see which detected vulnerabilities are exploitable.||Issue||Issue|
|When I run my service inside a pre-production environment, I want to simulate attacks against my own Kubernetes environment, so that I can see which detected vulnerabilities are exploitable.||Issue||Issue|
|When I have successfully simulated an attack, I want to call out to a dedicated callback server, so that I can simulate exfiltration of data.||Issue||Issue|
|When I have successfully simulated an attack, I want to detect accessible services on the network, so that I can view lateral movement potential.||Issue||Issue|