Detecting Allowed Inbound Traffic from Known Malicious Hosts

Overview

Modern enterprise networks are subjected to thousands of automated scans, exploitation attempts, and brute-force attacks daily. While edge security controls - Firewalls, WAFs, Proxies - block the vast majority of this traffic, perimeter gaps can occur due to misconfigured rules, outdated ACLs, or overly permissive policies such as Any-Any rules.

When these gaps happen, unauthorized traffic is allowed into the network. If left unmonitored, security teams have no way of knowing if a connection was established by a harmless scanner or a known malware command-and-control (C2) node.

The GreyNoise Solution

GreyNoise threat indicators integrated into Google SecOps cross-reference real-time inbound logs - specifically traffic marked as allowed - against GreyNoise's malicious and suspicious IP classifications. It isolates events in which known malicious actors have successfully bypassed perimeter defenses, giving security teams a clear, audited list of edge leaks to patch.

Prerequisites

Ensure your environment meets these prerequisites before beginning the setup:

Tools and Access

Network Inbound Telemetry

1. Access to network perimeter telemetry logs, such as Firewalls, WAFs, Load Balancers, or Routers.
2. Source IP: The external initiating IP address.
3. Action Taken: Field indicating traffic was allowed, permitted, or accepted.
4. Directionality: Field or context indicating the traffic was inbound or outside-to-inside.

Implementation Steps

To achieve the use case, follow the steps below:

Step 1: Connectivity Verification of the GreyNoise Data Ingestion Script

Before building any detection logic, 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 Firewall Logs exist in the instance

Confirm that your firewall 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 firewall/network events populated in the results panel before proceeding. Validate that the result set includes records with src.ip or principal.ip populated fields. These IP fields serve as the join key for GreyNoise correlation.

Step 3: Create Detection Rule

Create a YARA-L detection rule in Google SecOps that correlates inbound network events with GreyNoise IP indicators. Detects allowed inbound firewall connections from IPs classified by GreyNoise as malicious or suspicious, where the same source IP has made 10 or more connections.

Detection Rule:

// Use case 2: Detecting Allowed Inbound Traffic from Known Malicious Hosts
// Rule declaration: defines a YARA-L rule
rule greynoise_intelligence_allowed_inbound_malicious_or_suspicious {
  // 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 Intelligence Allowed Inbound Malicious or Suspicious"
    // Explains what the rule is designed to detect
    description     = "Detects allowed inbound firewall connections from IPs classified by GreyNoise as malicious or suspicious, where the same source IP has made 10 or more such connections within a 1-hour window."
    // 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            = "cloud security, threat intelligence"
  // Events section: defines the UDM field filters that must be satisfied
  events:
    // Filter for network traffic that was successfully allowed through the perimeter
    // Filter to only network connection events
    $network.metadata.event_type = "NETWORK_CONNECTION"
    // Include connections that were explicitly allowed or allowed with modification by the firewall
    $network.security_result.action = "ALLOW" or $network.security_result.action = "ALLOW_WITH_MODIFICATION"
    // Filter to only inbound traffic entering the environment
    $network.network.direction = "INBOUND"
    // Bind either src.ip or principal.ip to the correlation variable
    (
        $network.src.ip = $correlation_ip or
        $network.principal.ip = $correlation_ip
    )
    // Exclude events where the correlated IP is empty or null
    $correlation_ip != ""
    // Join with GreyNoise intelligence data
    // 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"
    // Match only IPs that GreyNoise has classified as actively malicious or suspicious
    (
        $greynoise.graph.metadata.threat.threat_verdict = "MALICIOUS"
        or
        $greynoise.graph.metadata.threat.threat_verdict = "SUSPICIOUS"
    )
    // 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 into a window
  match:
    // Aggregate all events sharing the same $correlation_ip within a 15 minutes window
    $correlation_ip over 15m
  // Outcome section: computes derived fields attached to the generated alert
  outcome:
    // Total allowed inbound connection count for this source IP
    // Count distinct network event IDs to avoid double-counting duplicate log entries
    $connection_count = count_distinct($network.metadata.id)
    // Destination context
    // Collect all unique target IPs that were targeted by this source
    $target_ip              = array_distinct($network.target.ip)
    // Collect all unique hostnames that were targeted by this source
    $target_hostname        = array_distinct($network.target.hostname)
    // Collect all unique target ports contacted by this source
    $target_port            = array_distinct($network.target.port)
    // Principal context
    // Collect all unique principal IPs associated with this traffic
    $principal_ip           = array_distinct($network.principal.ip)
    // Collect all unique principal hostnames associated with this traffic
    $principal_hostname     = array_distinct($network.principal.hostname)
    // Source context
    // Collect all unique source hostnames for the attacking IP
    $source_hostname        = array_distinct($network.src.hostname)
    // Collect all unique ASNs associated with the source IP for infrastructure attribution
    $source_asn             = array_distinct($network.src.ip_geo_artifact.network.asn)
    // Collect all unique countries associated with the source IP for geographic context
    $source_country         = array_distinct($network.src.ip_geo_artifact.location.country_or_region)
  // Condition section: final boolean logic that should match
  condition:
    // at least one matching network event exists,
    // a GreyNoise record with MALICIOUS or SUSPICIOUS verdict exists for the IP,
    // and 10 or more network events were seen in the 15 minutes window
    $network and $greynoise and #network >= 10
}

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 detection rule correlates allowed inbound network traffic with GreyNoise threat intelligence, then progressively filters activity to surface only high-confidence malicious or suspicious source IPs:

• Targets only inbound traffic that was allowed through perimeter controls.
• Correlates source IPs against GreyNoise intelligence using src.ip or principal.ip.
• Retains only IPs classified by GreyNoise as MALICIOUS or SUSPICIOUS.
• Keeps only IPs generating 10 or more allowed inbound connections, filtering low-frequency noise.
• Outcome context including:
  • Total connection volume
  • Target IPs, hostnames, and ports contacted internally
  • Principal and source host context
  • ASN and geographic origin of the source IP
• Surfaces the most active and highest-confidence threat IPs first for analyst investigation and perimeter validation.

Result: Out of 42 raw inbound allowed events, only 3 events with 10 hits survived all filters. What remains is a highly focused set of external IPs classified by GreyNoise as malicious or suspicious that successfully established repeated inbound connections into the environment. These events indicate potential perimeter control gaps, misconfigured firewall policies, or active exploitation attempts requiring immediate analyst review and remediation.

Results and Impact

Before vs After GreyNoise

Benefits for the SOC Team

1. Eliminates alert fatigue — 42 raw events reduced to a single confirmed threat IP, analysts focus only on what matters.
2. Immediate prioritization — volume threshold and sort order ensure the most aggressive threat IP surfaces first, no manual triage needed.
3. Confirmed threat context — GreyNoise classification removes ambiguity, giving analysts confidence before escalating.
4. Pivot-ready output — clean source IP, target IP fields give analysts a direct starting point to expand investigation across EDR, auth, and proxy logs.
5. Consistent coverage — query runs across all configured indexes, ensuring no blind spots across FW/WAF log sources.

Conclusion

GreyNoise integration with Google SecOps not only enriches detections with actionable threat intelligence but also significantly reduces alert noise by filtering out known internet-wide scanning activity. By incorporating GreyNoise intelligence directly into YARA-L detection logic, SOC analysts move from reviewing large volumes of noisy inbound events to investigating a smaller, prioritized set of high-confidence threats. The result is improved analyst efficiency, faster triage, and greater visibility into activity that may represent genuine targeted attacks against the environment.

The core value of this use case is to reduce the noise between SOC analysts and the threats that actually matter.