Investigating Anomalous Outbound Network Calls

Scenario

You received a detection alert for an anomalous outbound network call either via Email/ Slack notification or a failed GitHub Check.

This runbook will help you identify what code or process caused the outbound call.

Getting Started: Locate the Job and Endpoint

• Open the summary page for the detection.

• You can find the details in the "All Detections" section of the Summary page. This section shows:

  • The job in which the anomalous outbound call occurred.

  • The anomalous endpoint (domain or IP address) flagged by StepSecurity.

• Click on "View Job Details"

• This will take you to the Network Events tab, where you can review all the outbound network calls made by that specific job. Use the “Show findings only” toggle to quickly filter and display just the detections, or use the search bar to look up specific events

Step 1: Review Build Logs with Timestamps

• Each outbound call has an associated timestamp.

• Open the build log for the affected run

• Enable timestamps in the UI

• Scroll to the time around the outbound call and observe what was happening in the workflow at that point

Step 2: Search for the Domain or IP in Logs

• Check if the domain name or IP address from the alert appears in the build log.

• Sometimes, build tools or scripts log outbound destinations directly—this can give a direct clue about what triggered the call.

Step 3: Review Outbound API Call Details

• If available, StepSecurity also shows outbound API call details, including the HTTP method (e.g., GET, POST) and the path.

• This provides additional context about what operation was attempted (e.g., a POST /upload vs. a GET /version).

• Compare this against the code or build step at that time to see if it matches expected behavior.

Step 4: Inspect the Process Tree in Insights

• Go to the Network Events page in StepSecurity.

• Click on the PID of the process that made the outbound call.

• Review the Process Events panel to see the exact command executed and click "View Parent Process (PPID)" to trace back to the parent process

• Inspect the parent process (e.g., /usr/bin/bash) to see which script or tool launched the outbound call

Step 5: Investigate Code, Commits, and GitHub Actions

• Check the commit associated with the build to see if the domain or IP is directly referenced in the changes.

• If the outbound call correlates to a workflow step that runs a GitHub Action, identify which action it was.

  • If it’s a third-party action, inspect the action’s code in its repository to confirm whether the outbound call is expected or suspicious.

  • If it’s your own action, check recent changes or dependencies that might have introduced the behavior.

• If not found in the commit or the correlated action:

  • Search within the repository codebase.

  • Expand the search to your organization’s repositories.

  • As a last step, check if the domain is mentioned in public repositories (to detect potential supply chain or dependency issues).

Outcome

By following these steps, you should be able to trace the anomalous outbound network call back to:

• A specific job and workflow step (or GitHub Action),

• A process or script executed during the build,

• Or a piece of code (commit, repo, dependency) that introduced the outbound behavior.