GreyNoise shows how internet noise obscures targeted attack signals

At a glance

What this is: GreyNoise maps how internet background noise can be filtered to expose targeted reconnaissance, malicious allow traffic, suspicious authentication, and outbound compromise signals.

Why it matters: This matters because IAM, VPN, firewall, WAF, EDR, and SIEM teams need correlation that distinguishes routine scanning from events that indicate identity abuse or active compromise.

Context

Internet-facing security controls generate enormous telemetry, but most of it is not equally meaningful. Perimeter scanning, brute-force authentication, and opportunistic exploitation attempts create a background layer that hides the smaller set of events that actually indicate targeting, compromise, or identity abuse.

The governance gap is not visibility alone. SOC and identity teams often have logs, but lack the external context needed to separate mass internet behaviour from activity that is more likely to matter to a specific environment. That becomes especially important when the signals touch authentication systems, where grey-area traffic can become a direct identity risk.

Key questions

Q: How should SOC teams separate noisy perimeter scans from targeted attack traffic?

A: Correlate firewall, WAF, VPN, and identity-provider logs with external source-behaviour data, then suppress known mass scanners and prioritise the remaining events by source-IP volume and reputation. The goal is not to eliminate alerts but to increase the odds that what remains reflects targeted reconnaissance, hostile authentication, or outbound compromise worth analyst attention.

Q: Why do allowed inbound sessions from malicious hosts matter to security teams?

A: Because an allow rule is not proof of trust. If a session originates from a host already observed scanning or exploiting the internet, the event may indicate that hostile infrastructure reached your perimeter and should trigger rule review, session investigation, and a check for follow-on identity or application abuse.

Q: What are the signs that authentication traffic is more than random background noise?

A: Repeated login attempts or a successful authentication from a host already associated with scanning, botnets, or proxy infrastructure are strong indicators that the event deserves attention. Those signals suggest the identity layer may be under active targeting rather than experiencing generic internet noise.

Q: What should teams do when internal systems connect to malicious infrastructure?

A: Treat the event as a possible compromise signal, then inspect the source host for indicators of compromise, suspicious persistence, or command-and-control behaviour. Outbound matches to malicious destinations can reflect exfiltration, beaconing, or botnet participation and should be investigated before normal business traffic masks the pattern.

Technical breakdown

How GreyNoise-style source reputation changes perimeter triage

GreyNoise-style telemetry classifies source IPs by observed behaviour across the internet, which gives SOC teams an external reputation layer for inbound and outbound events. Instead of treating every firewall, WAF, VPN, or IdP log line equally, analysts can suppress broad scanners and elevate IPs that have not been seen in opportunistic activity or that are already associated with malicious behaviour. The value is not in replacing native telemetry. It is in adding behaviour context that helps separate background noise from likely targeting, allowing detection logic to focus on events with higher decision value.

Practical implication: Use source-IP behaviour as a filter before analysts spend time on raw perimeter alerts.

Why allowed traffic needs correlation, not just allowlisting

An allowed connection is not the same as a trusted connection. Firewall and WAF rules can pass traffic that originates from hosts with a documented malicious history, and without external correlation those sessions look normal in internal logs. The technical problem is that allowlists and permit rules operate at the policy layer, while hostile infrastructure can still sit behind those policy decisions. Correlating allow events with threat-intelligence context exposes the mismatch between what was permitted and what should have been scrutinised. That is particularly useful for cloud, remote access, and partner ingress paths where trust often outlives validation.

Practical implication: Re-evaluate permit rules when allowed sessions originate from hosts already associated with scanning or exploitation.

Authentication from flagged hosts and outbound beaconing as identity signals

Authentication logs and egress logs often carry the earliest signs that an external host is not just noisy but operationally relevant. When a VPN or identity provider sees login attempts from a flagged IP, the event may represent probing of identity infrastructure rather than random credential stuffing. Likewise, outbound connections to malicious infrastructure can indicate command-and-control, exfiltration, or botnet participation. These are different stages of compromise, but both depend on correlating internal events with outside behaviour. That correlation is what turns ordinary log noise into a signal that can drive response.

Practical implication: Prioritise authentication and egress matches from known-malicious hosts because they can indicate identity abuse or active compromise.

Threat narrative

Attacker objective: The attacker wants to gain or retain access while staying hidden inside high-volume internet noise, then use that access for compromise or outbound control.

1. Entry begins with automated scanning and credential abuse that blend into normal perimeter traffic, making hostile activity hard to distinguish from internet background noise.
2. Escalation occurs when allowed traffic or successful authentication comes from hosts GreyNoise has already observed behaving maliciously, which increases the chance of targeted reconnaissance or access.
3. Impact appears when internal systems reach out to malicious infrastructure, which can indicate command-and-control, exfiltration, or botnet participation.

Breaches seen in the wild

• Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Noise suppression is now an identity control problem as much as a SOC problem. Once mass scanning and brute-force activity flood the edge, the real challenge is deciding which authentication and ingress events deserve human review. That makes correlation between perimeter telemetry and source behaviour a governance issue, not just a detection tuning exercise. For practitioners, the control question is whether identity and network teams are sharing enough context to identify risk before access is normalised.

Allowed traffic from malicious infrastructure is a control failure, not a logging problem. If a known hostile IP can still pass a firewall or WAF rule and appear routine downstream, the environment is relying too heavily on permit logic without behavioural validation. That creates a blind spot across edge security and identity systems because allowed sessions are often treated as trusted by default. Practitioners should treat this as a policy-review trigger for inbound control paths, not as a nuisance alerting issue.

Internet-wide reputation data sharpens the boundary between opportunistic noise and targeted activity. The distinction matters because SOCs and IAM teams do not have unlimited analyst capacity, and every low-value alert delays review of the events that could indicate compromise. GreyNoise-style context is most useful when it helps teams ask whether a source has a history of mass abuse, whether an auth event is credible, and whether outbound traffic resembles compromise. The practical conclusion is that detection quality improves when external behaviour becomes part of internal triage.

Identity infrastructure is increasingly exposed through the same noise layer as perimeter infrastructure. VPNs and identity providers are not isolated from the scanning ecosystem, and that means authentication telemetry should be triaged with the same external context as firewall events. The consequence is a narrower trust envelope for remote access and a higher expectation that identity events be validated against host behaviour. Practitioners should expect fewer false positives and faster incident recognition when identity logs inherit this kind of correlation.

Detection logic should move from event counting to source-confidence scoring. The article's core lesson is that security teams gain more by weighting events according to observed source behaviour than by simply adding more alerts. That aligns with a broader shift in cyber governance toward context-aware prioritisation. For readers, the implication is to make correlation quality a measurable outcome in SOC and identity operations.

What this signals

GreyNoise-style context changes SOC and IAM triage from volume management to confidence management. The practical question is no longer how many alerts arrived, but how much external behavioural evidence supports each one. That shifts operational priority toward source reputation, allowed-session validation, and authentication context.

Identity teams should expect perimeter intelligence to influence access decisions more directly. When VPN and IdP activity is correlated with hostile source behaviour, identity review moves closer to detection and response. That is especially relevant where remote access, partner ingress, and service exposure share the same edge.

For practitioners

• Tune perimeter detections around source behaviour Filter firewall and WAF logs to inbound internet traffic, suppress known mass scanners, and rank the remainder by source-IP volume so analysts focus on potentially targeted events.
• Correlate allow events with threat intelligence Review inbound sessions that were permitted through firewall or WAF rules but originated from IPs GreyNoise classifies as malicious or suspicious, then re-evaluate the rules that allowed them.
• Add external context to authentication review Match VPN and identity-provider authentication events against hostile source reputations so successful logins from flagged IPs are triaged immediately and failed attempts are still visible.
• Investigate outbound connections to malicious infrastructure Correlate outbound network and EDR logs with destination reputation, then treat any successful connection to malicious infrastructure as a possible indicator of compromise on the internal host.

Key takeaways

• Perimeter noise becomes a governance problem when high-volume scanning hides the smaller set of events that indicate targeting or compromise.
• GreyNoise-style source behaviour data helps SOCs distinguish mass internet activity from malicious sessions that deserve re-evaluation.
• The most useful detections here are the ones that connect inbound allow events, authentication attempts, and outbound connections to a higher-confidence triage path.

Key terms

• Source Reputation: Source reputation is the behavioural context attached to an IP, host, or identity based on what it has been observed doing across the internet. In practice, it helps analysts decide whether a login, allow event, or outbound connection is likely routine noise or part of a broader hostile pattern.
• Perimeter Telemetry: Perimeter telemetry is the log and event data generated by devices that mediate traffic into and out of an environment, such as firewalls, WAFs, VPNs, and identity providers. It becomes more useful when enriched with external context that reveals whether the source has a suspicious history.
• Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.
• Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.