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 Microsoft Sentinel 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

Table

The entire GreyNoise data is stored in this one table:

Implementation Steps

Step 1: Baseline Network Validation

Identify your organization's firewall logs in Sentinel and filter for traffic that was permitted from the outside.

Note: The query below is an example of CommonSecurityLog, which is the standard table for CEF-based firewall logs.

CommonSecurityLog
| where DeviceAction in~ ("allow", "allowed", "permit", "accept")
| where CommunicationDirection == 0
| where isnotempty(SourceIP)
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, CommunicationDirection

Step 2: Apply GreyNoise Threat Intelligence Join and Detection Filters

Join the source IP addresses against the GreyNoise ThreatIntelIndicators table and apply classification filters.

Filter criteria:

We filter based on two specific criteria:

• classification="malicious"

OR

• classification="suspicious"

Impact: Flags IPs actively validated by GreyNoise as part of a malicious campaign, botnet, or exploit engine. Including unknown surfaces, suspicious IPs that GreyNoise has observed but not yet fully classified.

// Create a variable storing GreyNoise threat IPs that are malicious or suspicious
let GreyNoiseThreatIPs = ThreatIntelIndicators
   | extend d = parse_json(Data)
// Filter to only include records where the 'name' field contains "GreyNoise"
   | where tostring(d.name) has "GreyNoise"
   | extend ThreatType = tostring(d.indicator_types[0])
// Keep only records classified as "malicious" or "suspicious"
   | where ThreatType in ("malicious", "suspicious")
   | where isnotempty(ObservableValue)
   | project ObservableValue, ThreatType;
// Start querying the CommonSecurityLog table for network security events
CommonSecurityLog
// Filter to only include traffic that was allowed/permitted by the firewall
   | where DeviceAction in~ ("allow", "allowed", "permit", "accept")
// Filter to only inbound traffic (CommunicationDirection == 0 means inbound)
   | where CommunicationDirection == 0
   | where isnotempty(SourceIP)
// Perform an inner join: keep only inbound traffic where SourceIP matches GreyNoise threat IPs
   | join kind=inner GreyNoiseThreatIPs on $left.SourceIP == $right.ObservableValue
   | summarize
    Count       = count()
    by SourceIP
// Filter to only keep source IPs with 10 or more inbound connections
   | where Count >= 10
// Sort the results by Count in descending order (most active threats first)
   | sort by Count desc

Step 3: Automate as a Sentinel Analytics Rule

Once the query is verified end-to-end, save it as a recurring Sentinel Analytics Rule for continuous automated monitoring:

• Navigate to Microsoft Sentinel Workspace → Analytics → Create → Scheduled query rule.

• Title: UC2 - Inbound Threat Detection (GreyNoise Enriched)

• Description: 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.

• Severity: Select desired severity

• MITRE ATT&CK: Select tactics, techniques, and sub-techniques.

  • Tactics: Reconnaissance
  • Technique: T1595 - Active Scanning
  • Sub-Technique: T1595.001 - Scanning IP Blocks

• Click on the Next: Set rule logic option.

• Rule query: provide the query created in step-3

• Entity Mapping:

1. Map relevant fields from your query results to Sentinel entities (for example, map SourceIP to the IP entity type). This allows Sentinel to enrich alerts with context and helps in investigation and correlation within incidents.

• Alert details:

1. Provide a meaningful alert name in the Alert Name Format text box.
2. Enter the description in the Alert Description Format text box. You can also dynamically customize these using query fields (e.g., include IP addresses or usernames) so each alert provides better context during investigation.

• Query scheduling

1. Set how frequently the rule runs in the Run query every text box.
2. Enter the amount of historical data it analyzes in the Lookup data text box. The lookback period should be at least as long as the run interval to avoid missing events.

• Alert threshold

1. Define when an alert should be generated based on query results in the Generate alerts when number of query results option. (e.g., trigger an alert when results are greater than a defined number). This helps control noise and adjust detection sensitivity.
2. Decide how alerts are generated from query results:
   1. Group all events into a single alert: Creates one alert summarizing all matching events.
   2. Trigger an alert for each event: Generates a separate alert for each event for granular visibility.
3. You can enable suppression to stop the rule from running after an alert is triggered.

• Click on the Next: Incident settings option.

• Incident Settings

1. Configure the rule to automatically create incidents from generated alerts. This ensures alerts are grouped into incidents for SOC investigation workflows.

• Automation rules

1. Attach automation rules or playbooks (Logic Apps) to trigger actions such as blocking IPs, sending notifications, or enriching alerts. You can define conditions, triggers, and execution order for these automated responses.

• Click on the Save option.

Note: You can adjust the Schedule and Lookup durations as needed.

Understanding the Output

The KQL query joins every inbound source IP against the GreyNoise ThreatIntelIndicators table, then applies progressive filters as follows:

• Targets allowed only inbound traffic; blocked connections are excluded, as perimeter controls already handled them.
• Joins all source IPs against GreyNoise malicious and suspicious indicators via an inner join on the ThreatIntelIndicators table.
• Keeps only IPs classified as malicious or suspicious.
• Retains only IPs that cross the volume threshold of >= 10, eliminating low-frequency opportunistic noise.
• Sorts by count descending - most active threat IPs surface first.

Result: Out of a high volume of raw inbound allowed events, only confirmed threat IPs that cross the classification-specific threshold survive all filters, giving the analyst a single, pre-validated list of perimeter gaps that require immediate remediation.

Results and Impact

Before vs After GreyNoise

Benefits for the SOC Team

• Eliminates alert fatigue - Raw allowed inbound events are reduced to a confirmed list of threat IPs - analysts focus only on what matters.
• Immediate prioritization - volume threshold and sort order ensure the most aggressive threat IP surfaces first, no manual triage needed.
• Confirmed threat context - GreyNoise classification removes ambiguity, giving analysts confidence before escalating.
• Pivot-ready output - Clean SourceIP and Count fields give analysts a direct starting point for expanding investigations across EDR, authentication, and proxy logs.
• Consistent coverage - Query runs across all configured log sources in the workspace, ensuring no blind spots across firewall and WAF telemetry.

Conclusion

GreyNoise not only adds intelligence to your alerts but also eliminates those that are not worthy of investigation in the first place. By incorporating a single ThreatIntelIndicators join within your existing Sentinel inbound traffic query, your SOC team goes from looking at raw, noisy inbound events without context to seeing a clean, prioritized list where every remaining result is genuinely worth their time.

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