Flag Authentication Attempts from Compromised Hosts

Overview

Every organization's identity provider and VPN gateway receives thousands of authentication attempts daily - the vast majority of which are automated credential stuffing, brute-force, and password spray attacks. Standard detection logic treats all of these uniformly: a failed login generates a low-priority alert, and a successful login is trusted and passed through.

This approach has a critical blind spot.

Some of these attempts originate from IPs that GreyNoise has confirmed are actively conducting mass scanning operations, running botnet infrastructure, or operating known command-and-control (C2) servers. When one of those IPs successfully authenticates to your environment, it is not a routine login event - it is an immediate indicator of compromise, regardless of whether the credentials were technically valid.

The GreyNoise Solution

By integrating GreyNoise threat intelligence into authentication logs within Elasticsearch, this use case correlates both successful and failed authentication events against GreyNoise's global threat intelligence dataset, surfacing two high-value security signals.

A successful authentication from a GreyNoise malicious or suspicious IP should be treated as a high-severity incident requiring immediate investigation, as it may indicate compromised credentials or unauthorized access from known malicious infrastructure.

A failed authentication from the same class of IPs should be treated as a medium-severity event for investigation and monitoring, as it may indicate targeted credential stuffing, brute-force, or password spraying activity against the organization.

Prerequisites

Ensure your environment meets these prerequisites before beginning the setup:

Tools and Access

Authentication Telemetry

1. Access to authentication-related telemetry logs, such as Identity Providers (IdP), VPN gateways, Active Directory authentication logs, SSO platforms, cloud authentication services, or remote access systems.
2. Authentication Event Type: Field indicating the event is authentication-related.
3. Source IP: The external initiating IP address associated with the authentication attempt.
4. Authentication Result: Field indicating whether the authentication attempt succeeded or failed.

Implementation Steps

To achieve this use case, two separate Elastic Security detection rules will be created — one to detect successful authentication attempts originating from GreyNoise malicious or suspicious IPs, and another to detect failed authentication attempts from the same class of IPs. 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 Authentication/User Login Logs exist in the instance

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

event.category: "authentication"

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

Step 3: Create a Detection Rule for Successful Authentication Attempts

Create an Elastic Security detection rule in Elasticsearch that correlates successful authentication events with GreyNoise threat intelligence indicators. The rule should detect successful authentication attempts 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 authentication events while excluding GreyNoise integration logs. It identifies successful authentication attempts that are eligible for GreyNoise threat intelligence correlation.

      Shell

      NOT event.module : "ti_greynoise" and event.category : "authentication" 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

      UC3 - Successful auth from Compromised Hosts (GreyNoise)

   2. Description: e.g

      Detects authentication attempts from IPs GreyNoise has classified as malicious or unknown. Successful logins from malicious IPs are treated as active compromise indicators.

   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), Authentication, Threat Intelligence, and Identity Security.

   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.

Step 4: Create a Detection Rule for Failed Authentication Attempts

Create an Elastic Security detection rule in Elasticsearch that correlates failed authentication events with GreyNoise threat intelligence indicators. The rule should detect failed authentication attempts originating from IPs classified by GreyNoise as malicious or suspicious.

Steps to create a detection rule:

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

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

10. 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 failed authentication events while excluding GreyNoise integration logs. It identifies failed authentication attempts that are eligible for GreyNoise threat intelligence correlation.

       Shell

       NOT event.module : "ti_greynoise" and event.category : "authentication" and event.outcome : "failure"

    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.

       

11. In the About Rule section:

    1. Name: e.g

       UC3 - Failed auth from Compromised Hosts (GreyNoise)

    2. Description: e.g

       Detects failed authentication attempts originating from IPs classified by GreyNoise as malicious or suspicious.

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

    4. Default risk score: 75

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

    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.

       

12. 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.

       

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

14. 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 rules correlate authentication events against GreyNoise threat intelligence and apply the following logic:

• Evaluates both successful and failed authentication attempts against GreyNoise malicious or suspicious classifications.
• Filters out routine authentication noise and surfaces only high-confidence authentication activity associated with known malicious infrastructure.
• Prioritizes authentication events based on the outcome of the login attempt and GreyNoise classification.

Every alert generated by these rules carries a severity level and risk score. The table below defines what each severity level means to the analyst:

Result: Out of 113 raw authentication events, only 3 events were left for investigation. Hundreds of raw authentication events are reduced to a small set of high-priority alerts.

Benefits for the SOC Team

Conclusion

Without GreyNoise, authentication attempts originating from malicious infrastructure may appear identical to routine login activity and pass through traditional monitoring unnoticed. With GreyNoise threat intelligence integrated into Elasticsearch detection logic, successful and failed authentication attempts from GreyNoise malicious or suspicious IPs are immediately surfaced as high-priority security alerts with enriched threat context for analyst investigation.

This enables SOC teams to move away from investigating large volumes of undifferentiated authentication noise and instead focus on a prioritized, intelligence-driven set of authentication threats. The result is faster detection, earlier response, improved analyst efficiency, and reduced exposure to credential-based attacks such as brute-force attempts, password spraying, and compromised credential abuse.