Detect Outbound Connections to Threat Infrastructure

Overview

Internal corporate assets should not initiate outbound connections to internet infrastructure known to be hostile. When they do, it signals something far more serious than a misconfigured firewall rule - it means a device inside your network is actively reaching out to the threat actor, not the other way around.

This pattern bypasses traditional perimeter defenses and is often a strong indicator of compromise - active C2 beaconing, data exfiltration, or botnet participation.

The GreyNoise Solution

By correlating internal egress and outbound logs with GreyNoise malicious IP indicators within Google SecOps, this use case isolates high-fidelity anomalies. It surfaces internal hosts communicating with known command-and-control (C2) servers, active exploitation infrastructure, or botnet staging grounds.

The result is a high-fidelity, low-noise detection surface - not a list of suspicious IPs to manually research, but a confirmed list of internal assets that have made successful outbound connections to infrastructure GreyNoise has already validated as malicious.

The Core Signal: Any successful outbound connection from an internal host to GreyNoise-classified malicious infrastructure warrants immediate investigation of that internal host for indicators of compromise.

Prerequisites

Ensure your environment meets these prerequisites before beginning the setup:

Tools and Access

Implementation Steps

To achieve the use case, follow the steps below:

Step 1: Connectivity Verification of the GreyNoise Data Ingestion Script

Before building detection rules, confirm that the GCP Cloud Function is deployed and actively ingesting indicators into Google SecOps. Navigate to Investigation > SIEM Search and run the following UDM filter to confirm ingested data is present:

graph.metadata.event_metadata.base_labels.log_types = "GREYNOISE"

Expected Result: You should see GreyNoise IP entities appearing in the Results panel. If no results are returned, check the Cloud Function logs in GCP Cloud Logging for any errors before proceeding.

Step 2: Verify if Network Connection Logs exist in the instance

Confirm that your network connection logs are present in Google SecOps SIEM. In the SIEM Search (UDM Search), filter for network connection events:

metadata.event_type = "NETWORK_CONNECTION"

Expected Result: You should see the network connection events populated in the results panel before proceeding. Validate that the result set includes records with a populated principal.ip field. This IP field serves as the join key for GreyNoise correlation.

Step 3: Create Detection Rule

Create a YARA-L detection rule in Google SecOps that correlates outbound network connection events with GreyNoise malicious IP indicators. It detects internal hosts making repeated allowed outbound connections to IPs marked by GreyNoise as malicious.

Detection Rule:

// Use case 4: Detect Outbound Connections to Threat Infrastructure
// Rule declaration: defines a YARA-L rule
rule greynoise_intelligence_outbound_connection_to_malicious_infrastructure {
  // Metadata section: non-functional fields used for documentation and triage
  meta:
    // Identifies who wrote or owns this rule
    author                  = "GreyNoise Intelligence"
    // Human-readable name for display
    rule_name               = "GreyNoise Outbound Connection to Malicious Infrastructure"
    // Explains what the rule is designed to detect
    description             = "Detects internal hosts making repeated allowed outbound connections to IPs marked by GreyNoise as malicious."
    // Indicates the risk level if this rule fires
    severity                = "High"
    // Indicates the response urgency level for this alert
    priority                = "High"
    // Tags for this rule
    tags                    = "threat intelligence"
  // Events section: defines the UDM field filters that must be satisfied
  events:
    // Network Connection Events
    // Filter to only network connection events
    $network.metadata.event_type = "NETWORK_CONNECTION"
    // Include only connections that were permitted by security controls
    $network.security_result.action = "ALLOW" or $network.security_result.action = "ALLOW_WITH_MODIFICATION"
    // Restrict to outbound traffic only - internal host initiating contact with an external destination
    $network.network.direction = "OUTBOUND"
    // Bind the internal source IP to a variable for use in the match aggregation
    $network.principal.ip = $source_ip
    // Bind the destination IP to the correlation variable used to join against GreyNoise data
    $network.target.ip = $correlation_ip
    // Exclude private and reserved IP ranges to ensure only public routable destinations are evaluated
    // Exclude RFC1918 Class A private range
    NOT net.ip_in_range_cidr($correlation_ip, "10.0.0.0/8")
    // Exclude RFC1918 Class B private range
    NOT net.ip_in_range_cidr($correlation_ip, "172.16.0.0/12")
    // Exclude RFC1918 Class C private range
    NOT net.ip_in_range_cidr($correlation_ip, "192.168.0.0/16")
    // Exclude loopback addresses
    NOT net.ip_in_range_cidr($correlation_ip, "127.0.0.0/8")
    // Exclude link-local addresses
    NOT net.ip_in_range_cidr($correlation_ip, "169.254.0.0/16")
    // Exclude IPv6 loopback address
    NOT net.ip_in_range_cidr($correlation_ip, "::1/128")
    // Exclude events where the correlated destination IP is empty or null
    $correlation_ip != ""
    // Join logic: Check if the Destination IP exists in the GreyNoise dataset
    // Filter the GreyNoise enrichment records by their log type label
    $greynoise.graph.metadata.event_metadata.base_labels.log_types = "GREYNOISE"
    // Ensure the enrichment record comes from the GreyNoise Intelligence product
    $greynoise.graph.metadata.product_name = "GreyNoise Intelligence"
    // Confirm the GreyNoise entity being evaluated is an IP address type
    $greynoise.graph.metadata.entity_type = "IP_ADDRESS"
    // Include only IPs that GreyNoise has classified as actively malicious
    $greynoise.graph.metadata.threat.threat_verdict = "MALICIOUS"
    // Join the GreyNoise entity IP to the same correlation variable used in network events
    $greynoise.graph.entity.ip = $correlation_ip
  // Match section: groups correlated events
  match:
    // Aggregate per internal source IP over a 15 minute window
    $source_ip over 15m
  // Outcome section: computes derived fields attached to the generated alert
  outcome:
    // Count total distinct outbound connections from this internal host in the window
    $connection_count           = count_distinct($network.metadata.id)
    // Malicious destination context
    // Collect all unique destination IPs confirmed as malicious by GreyNoise
    $malicious_destinations     = array_distinct($network.target.ip)
    // Collect all unique destination ports contacted by the internal host
    $destination_ports          = array_distinct($network.target.port)
    // Collect all unique destination hostnames associated with the malicious IPs
    $destination_hostnames      = array_distinct($network.target.hostname)
    // Internal host context for triage
    // Collect all unique hostnames of the internal host initiating the outbound connections
    $source_hostname            = array_distinct($network.principal.hostname)
    // Protocol context
    // Collect all unique network-layer protocols observed across the outbound connections
    $network_protocol           = array_distinct($network.network.ip_protocol)
    // Collect all unique application-layer protocols observed across the outbound connections
    $application_protocol       = array_distinct($network.network.application_protocol)
  // Condition section: final boolean logic that must be satisfied to generate an alert
  condition:
    // At least one matching network connection event exists
    // and a GreyNoise record exists for the destination IP
    // and at least 3 distinct outbound connections were observed within the window
    $network and $greynoise and #network >= 3
}

Create & Enable Detection Rule

1. From Google SecOps SIEM, navigate to Detection > Rules & Detections.

   

2. Go to the Rules Editor Tab, click on the + button.

3. Copy and paste the Detection Rule provided above in the editor.

   

4. Click on SAVE NEW RULE.

5. To generate detections, Enable Detecting, and to generate alerts, Enable Alerting.
   

6. Click the Rules Dashboard tab to see all rules.

7. Search or browse for the rule you want to activate. Click on the 3 dots in the top right corner for the specific rule and toggle Live Rule as enabled to activate the Detection Rule.

   

See Google SecOps: Detection Rules for more information.

Step 4: Trigger Retrohunt and View Alerts

Once the rule is live and alerting is enabled, it will immediately begin triggering alerts for matching events. To run the rule for a specific time range, we need to run YARA-L retrohunt by following these steps:

Steps to run YARA-L Retrohunt:

1. From Google SecOps SIEM, navigate to Detection > Rules & Detections.

2. Click the Rules Dashboard tab to see all rules.

3. Search or browse for the rule. Click the 3 dots in the top-right corner for the specific rule's row.

4. Click on the YARA-L Retrohunt.

   

   Note: You can change the Run Frequency as needed.

5. Select Time range.

   

6. Click on Run.

Wait approximately five minutes to verify if alerts have been generated. Even without running a YARA-L retrohunt, the rule will automatically trigger alerts for new incoming events as long as it is live and alerting is enabled.

Follow these steps to view alerts in Google SecOps:

Steps to view alerts

1. From Google SecOps SIEM, navigate to Detection > Rules & Detections.

2. Click the Rules Dashboard tab to see all rules.

3. Search or browse for the rule. Click the 3 dots in the top-right corner for the specific rule's row.

4. Click on the View Rule Detections.

   

5. The list of Alerts will be visible in the Detections section, with the Detection Type column set to Alert.

   

6. To view the outcome variables of Alert, click on the Alert row, then on the Alert viewer tab, and click on Variables.

   

Understanding the Output

The YARA-L rule correlates outbound network connection events against GreyNoise malicious IP indicators and applies the following logic:

• Targets only allowed outbound connections - blocked traffic is excluded as perimeter controls already handled it; what remains is traffic that successfully left the network.
• Cross-references every destination IP against GreyNoise entity records, retaining only IPs carrying a MALICIOUS verdict - eliminating benign internet traffic instantly.
• Enforces a minimum threshold of 3 outbound connections from the same internal source IP within a 15-minute window - filtering out single-event coincidences and surfacing only persistent, repeated outreach to threat infrastructure.
• Enriches each alert with internal host context, destination IPs, ports, hostnames, and protocol details - giving analysts an immediate picture of what was communicated, where, and how.

Result: Out of 88 outbound events, only 14 IPs were left for investigation. Out of many outbound connection events, a confirmed list of internal IPs is making repeated contact with known malicious infrastructure. Each alert represents an internal host that has actively and successfully reached out to C2, exploitation, or botnet infrastructure — warranting immediate investigation for indicators of compromise.

Results and Impact

Before vs After GreyNoise

Benefits for the SOC Team

1. Flips the perspective - instead of watching what comes in, this use case watches what your internal hosts are reaching out to, catching compromised hosts that may have already bypassed perimeter controls.

2. Immediate compromise indicator - an internal host connecting to confirmed malicious IPs is one of the strongest signals of active infection or C2 activity.

3. Multi-destination visibility - ThreatDestinations exposes all malicious IPs contacted by the same internal host in a single row, revealing the full scope of outbound threat communication at a glance.

4. Reduces noise significantly - hundreds of raw outbound events reduced to a small number of internal hosts worth investigating, with connection count and threat destinations pre-compiled.

5. Pivot-ready - SourceIP identifies the exact internal host to isolate, and ThreatDestinations provides the malicious destinations to block at the perimeter.

Conclusion

Outbound connections to malicious infrastructure are one of the clearest post-compromise signals available - but only if you have the intelligence to recognize the destination. Standard egress monitoring cannot make that determination from raw logs alone.

GreyNoise not only adds intelligence to your alerts but also eliminates those that are not worthy of investigation in the first place. By correlating outbound events with GreyNoise Indicators, your SOC team goes from looking at hundreds of raw outbound events without context to a small number of internal hosts making confirmed connections to malicious infrastructure - the clearest possible signal of an active compromise.