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 Elastic 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: Verification of the GreyNoise Data Ingestion

To verify successful GreyNoise data ingestion in Elasticsearch, check the logs-ti_greynoise_latest.ip* data stream in Kibana Discover.

Expected Result: You should see documents containing GreyNoise threat intelligence and enrichment data.

Step 2: Verify if network Logs exists in the instance

Confirm that your network logs are present in Elasticsearch. In Kibana Discover, under your relevant data view, run the following KQL query:

event.category: "network"

Expected Result: You should see firewall or network events populated in the results panel before proceeding. Validate that the returned events contain populated source.ip fields, as these IP fields are used for GreyNoise enrichment and correlation. Also, verify that fields such as network.direction, event.module, event.category, event.outcome, and event.type are present in the result set.

Step 3: Create Detection Rule

Create an Elastic Security detection rule in Elasticsearch that correlates inbound network events with GreyNoise threat intelligence indicators. The rule should detect allowed inbound firewall connections originating from IPs classified by GreyNoise as malicious or suspicious

Steps to create a detection rule:

1. Navigate to Security > Rules > Detection Rules and click Create New Rule.

2. Select Indicator Match as the rule type and make the following changes.

3. In the Define Rule section:

   1. Index Pattern: Add the index pattern relevant to the data you want to monitor. For best results, use perimeter or network traffic data, such as firewall, IDS/IPS, VPN, proxy, or network flow logs (for example, logs-panw.*, logs-cisco_asa.*, or logs-suricata.*). Keep the pattern as specific as possible for better performance.

   2. Custom Query: The following KQL query filters successful inbound network connection events while excluding GreyNoise integration logs. It identifies inbound traffic that was allowed through perimeter controls and is eligible for GreyNoise threat intelligence correlation.

      Shell

      NOT event.module : "ti_greynoise" and event.category : "network" and network.direction : "inbound" and event.type : "allowed" and event.outcome : "success"

   3. Indicator index patterns: Use logs-ti_greynoise_latest.ip*.

   4. Indicator index query: The following KQL query filters GreyNoise threat intelligence indicators collected within the last 3 days and retains only IPs classified as malicious or suspicious. These indicators are used to correlate against inbound network traffic events during detection.

      Shell

      @timestamp >= "now-3d/d" and (greynoise.ip.internet_scanner_intelligence.classification : "malicious" or greynoise.ip.internet_scanner_intelligence.classification : "suspicious")

   5. Indicator Mapping:

      1. Field: Map to the field in your Elastic environment containing IPs, e.g., source.ip.
      2. Indicator Index Field: threat.indicator.ip

   6. Required fields (Optional): Add threat.indicator.ip.

   7. Related integrations (Optional): Add GreyNoise.

      

4. In the About Rule section:

   1. Name: e.g

      UC2 - Inbound Threat Detection (GreyNoise Enriched)

   2. Description: e.g

      Detects inbound traffic that was permitted by perimeter controls from IPs classified as malicious or unknown by GreyNoise - indicating a potential perimeter gap or misconfiguration.

   3. Default Severity: e.g., critical.

   4. Default risk score: 100

   5. Tags: Add GreyNoise (used for filter Alerts generated by this rule by rule transforms), Cloud Security and Threat Intelligence.

   6. Max alerts per run: Default is 100; configurable up to 1000.

   7. Indicator prefix override: Set to greynoise.ip to enrich alerts with GreyNoise data.

      

5. In the Schedule Rules section:

   1. Set Runs Every - Defines how frequently the rule runs.

   2. Additional Lookback Time - Specifies how far back to check for matches.

      

6. Under the Rule Actions section, configure automated response actions to execute whenever the detection rule generates an alert. (Optional)

7. Click on Create & enable rule.

Steps to view alerts

1. Once the rule is saved and enabled, alerts will appear in the Security > Alerts section when matches are detected.

   

2. To view the details of the Alert, click on the

   

   icon, then on the Alert viewer tab, and click on Table.

   

Understanding the Output

The Elastic Security detection rule correlates allowed inbound network traffic with GreyNoise threat intelligence and progressively filters events to surface high-confidence malicious or suspicious source IP activity:

• Targets only inbound traffic that was successfully allowed through perimeter controls.
• Correlates source.ip values against GreyNoise intelligence enrichment data.
• Retains only events where greynoise.classification is marked as malicious or suspicious.
• Outcome context including:
  • Target IPs, hostnames, and ports contacted internally
  • Source host context
  • GreyNoise actor, organization, and classification details
  • ASN and geographic origin of the source IP
• Surfaces the highest-confidence threat IPs first for analyst investigation and perimeter validation.

Result: Out of 39 raw inbound allowed events, only 2 events survived all filters. What remains is a highly focused set of external IPs, classified by GreyNoise as malicious or suspicious, that successfully established inbound connections to 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 — 39 raw events reduced to a single confirmed threat IP, analysts focus only on what matters.
2. Immediate prioritization — 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 Elasticsearch not only enriches security detections with actionable threat intelligence but also significantly reduces alert fatigue by filtering out known internet-wide scanning and background noise activity. By incorporating GreyNoise intelligence directly into Elastic Security detection logic, SOC analysts can move from investigating large volumes of noisy inbound connection events to focusing on a smaller, prioritized set of high-confidence malicious or suspicious threats.

The result is improved analyst efficiency, faster investigation and triage, better visibility into potential perimeter security gaps, and increased confidence in identifying activity that may represent genuine targeted attacks against the environment.

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