Harden-Runner POC Detections

Harden-Runner is a purpose-built network filtering and runtime security monitoring platform for CI/CD runners. To learn more about Harden-Runner functionality, see here.

This repository contains the workflow file POC-detections-gh-hosted.yml that contains several different jobs to trigger all Harden-Runner detections. It also contains several other workflows for testing Lockdown Mode (ARC deployments only). A summary of the detections are below:

Detections	Description
Secrets in Build Logs	Detects secrets (API keys, tokens, etc.) that were accidentally leakd in build logs
Secrets in Artifacts	Detects secrets found in generated artifacts
Outbound Calls Blocked	Blocks outbound network requests to prevent security risks
Anomalous Outbound Network Calls	Detects anomalous or unexpected external network requests [Requires Baseline]
Suspicious Outbound Network Calls	Detects potentially malicious network requests during workflow execution
Source Code Overwritten	Detect files modified during workflows to detect unauthorized changes
HTTPS Outbound Network Calls	Monitors API calls that contain data-exfiltration signals (ie; POST, PUT, or PATCH going outside of organization)
Action Uses Imposter Commit	Monitors for actions using tags that are pointed to maliscious commits (pointed to a fork or outside repo)
Reverse Shell	Monitors for reverse shell activity. Reverse shells allow attackers to run commands, exfiltrate data, and move laterally
Privileged Container	Monitors for privileged containers, which can let attackers escape to the host, access data, and move laterally
Runner Worker Memory Read	Monitors for attempts to read runner.worker memory, which attacks like TJ-Actions use to extract secrets

Prerequisites

• Ensure you have installed the StepSecurity GitHub App and have access to your StepSecurity dashboard
• Fork/clone this repository or simply copy the workflow file POC-detections-gh-hosted.yml into your own organization for testing

Environment information

• The main workflow (POC-detections-gh-hosted.yml) runs on GitHub-hosted runners, and it already includes the harden-runner action. No additional installation or configuration is required. For Self-Hosted scenario, please reach out to StepSecurity.
• This workflow uses workflow_dispatch trigger, meaning the workflows can be triggered manually from the Actions tab by selecting the workflow and clicking Run workflow
• Most detections do not require a baseline to be established and will be triggered upon running the POC Detections workflow one time
• This workflow contains several different jobs, each intentionally triggering certain detections. Take a look at the workflow to get familiarized
• To detect anomalous network calls, a baseline is required to be established. For testing purposes, it is recommended to reduce the minimum number of runs from the default (100) to 1
  • This can be done under your dashboard: Admin Console → Settings → Anomaly Detection - set this as '1' and Save Changes

Triggering detections not requiring a baseline

You can instantly test majority of these detections via the POC-detections-gh-hosted.yml workflow. The following detections will trigger as soon as you run the POC-detections-gh-hosted.yml workflow one time:

• HTTPS Monitoring for Anomalous Network Calls (Network Event)
• Outbound Calls Blocked (Network Event)
• Reverse Shell (Process Event)
• Privileged Container (Process Event)
• Runner Worker Memory Read (Process Event)
• Imposter Commit (Process Event)
• Secrets in Build Logs (Control)

Viewing detections not requiring a baseline

Navigate to your StepSecurity dashboard. Under Harden-Runner → Workflow Runs select the workflow run which you ran in the step above and select Insights

For Network Event Detections, select the Network Events tab. Browse through the jobs to see which ones triggered detections. This workflow will trigger an anomalous network call via HTTPS Monitoring for the pytorch-simulation job.

• Click on API Calls to view details
• Click on the Process ID (PID) to pinpoint the exact process triggering this network call

For Process Event Detections, select the Process Events tab. Browse through the jobs to see which ones triggered detections. The poc-detections workflow triggers several process events for the following jobs: reverse-shell, priviledged-container, and imposter-commit. The screenshot below shows an example for the reverse shell detection.

• Runner.worker memory read process detections will automatically get blocked as part of lockdown mode, without any configuration, as they are high-fidelity indicators of secret exfiltration. The tj-actions-simulation.yml workflow is provided separately - running this workflow will result in the job being terminated.

Click on Suspicious Processes to see details

For Secret Detections, select the Controls tab. Any secrets in build logs or artifacts will show here. This workflow includes a leaked secret in the build logs for the handle-private-key job.

Click on View Build Log to see details on where this secret was leaked

Triggering detections requiring a baseline

After a baseline is established, Harden Runner can detect any new, anomalous network calls that are outside of the baseline. The baseline is configurable by number of job runs required, or by number of days elapsed. You can find this in your tenant dashboard under Admin Console -> Settings -> Anomaly Detection. While the default is 100, it is recommended to lower this for easier testing purposes.

• Run the workflow based on the number of runs set above to generate a baseline. You can verify the baseline is stable under the Harden-Runner -> Baseline tab
• Run the workflow one more time, this time entering a new domain. (Actions tab -> POC Detections and before running the workflow, enter a new domain, ie https://www.pastebin.com)
• Since this new domain is now outside of the baseline, it will trigger an anomalous network call - to observe the anomalous network call, navigate to the workflow runs insights page under the Network Events tab
• Block Policy - [this section is currently being updated]

Blocking outbound calls

There are two ways Harden Runner can block outbound network calls:

1. Global Block List

StepSecurity maintains a global block list of known malicious domains and IP addresses. During active supply chain incidents (e.g., axios, trivy compromises), IOCs are added to this list and automatically blocked, even if a block policy has not been explicitly set

• The global-block-list job demonstrates this by attempting to call out to a dummy malicious domain (evil.invalid). After running the workflow, you can see the blocked call in the Insights page

2. Block Mode with Domain Allowlist

With Harden Runner, you can define an allowed-endpoints list. This can be done directly in the workflow (GitHub-hosted runners) or centrally via Policy Store (GitHub hosted and self-hosted runners). Any outbound call to a domain NOT on the list is blocked. The unauthorized-outbound-call job demonstrates this - it allows github.com, goreleaser.com, and www.google.com, then attempts a reverse shell connection to ngrok.io, which gets blocked. You can see the blocked call in the Insights page

Lockdown Mode (Kubernetes ARC deployments only)

For self-hosted ARC (Actions Runner Controller) deployments, StepSecurity supports Lockdown Mode - which provides automatic blocking of CI/CD jobs when critical security threats are detected in real-time. Currently the following process detections are supported:

Detection	Description
Reverse-Shell	Blocks reverse shell connection attempts
Priviledged-Container	Blocks containers running with elevated privileges
Runner-Worker-Memory-Read	Blocks unauthorized memory reading attempts

Prerequisites

Before testing Lockdown Mode, you must have the ARC Harden-Runner agent installed in your Kubernetes cluster. To enable access to the ARC installation instructions:

1. Contact StepSecurity to activate ARC installation for your tenant.
2. Once enabled, navigate to: Settings → Harden Runner Installation → ARC
3. Follow the provided steps to deploy the Harden-Runner agent.

Finally, ensure that the Lockdown Mode workflows lock-down-[process event type].yml use the correct runner label

Set up Lockdown Mode policy

To set up a Lockdown Mode Policy:

1. Navigate to the Policy Store tab (Harden Runner → Policy Store) and create a new policy, or edit an existing one
2. Add the lockdown configuration using the following syntax:

lockdown-mode:
 enabled: true
 detections:
   - Privileged-Container
   - Runner-Worker-Memory-Read
   - Reverse-Shell

3. Attach the policy to your desired scope: cluster, organization, repository, or workflow
4. Trigger one of the three available Lockdown test workflows, for example lock-down-reverse-shell.yml via the Actions tab. This will trigger detections for these process events. When a threat is detected, the job will be immediately terminated and you will receive a notification with details about the blocked threat

In the StepSecurity dashboard under Harden-Runner → Workflow Runs, you will see the following Run Terminated messaging for that workflow

The Summary page for that workflow run will show a red lock icon indicating the run was blocked

The Process Events tab will also show indication with a red lock icon that the run was blocked