GreyNoise
Guides
Start typing to search…

Event Feeds

Getting Started with Feeds

Overview

The Feeds feature allows GreyNoise customers with an Advanced and Elite platform license access to near-real-time visibility into attacker activity across the internet. With Feeds, you can subscribe to curated event streams that notify you when something important happens, such as an IP being reclassified or a CVE showing new exploitation activity.

Feeds are available directly in the GreyNoise Visualizer.

Who Can Access Feeds

  • Available to: Advanced and Elite platform customers with appropriate data modules
    • IP-based and Tag-based Feeds require any Internet Scanner Intelligence Module (i.e., Triage, Investigate, or Hunt)
    • CVE-based and Vendor-based Feeds require an Investigate or higher level Internet Scanner Intelligence Module (i.e., Investigate or Hunt)
  • Available in: GreyNoise Visualizer

How to Get Started

Access the Feeds Menu

  • Log in to the GreyNoise Visualizer.
  • In the account menu drop-down, click on Feeds.

Create a new Feed

  • Click the “Create Feed” button

  • In the feed creation menu:

    • Give the feed a name to help describe the functionality.
    • Select the Event Type for this Feed.
    • Use the "From" selections to determine the state change that will trigger a feed event to be sent.
    • Optional: Select or enter any additional configuration options to filter the event list, such as IP ranges or CVE numbers.
    • Enter the URL to the destination Webhook to receive the feed events.
    • Optional: Configure necessary header information to be included when events are sent to the webhook.
    • Optional: Use the Send Test Event functionality to test the connection to your destination system.
    • Click “Save” when done.
  • Once successfully set up, events will appear near-real time, usually within 5 minutes of detection.

Next Steps

  • Explore the Feed Reference to understand available feeds.
  • Check out Use Cases to see how to operationalize Feeds in your workflows.

Feed Reference

Current Feed Event Types

The following provides an overview of the available event types.

IP Classification Changes

  • What it means: GreyNoise updates an IP’s classification (e.g., Unknown → Malicious).
  • Why it matters: Helps you reprioritize alerts or block newly confirmed threats.
  • Example event:
{
  "ip": "47.239.198.223",
  "event_type": "IP Classification Change",
  "old_state": {
    "classification": "unknown"
  },
  "new_state": {
    "classification": "malicious"
  },
  "timestamp": "2025-04-30T08:10:00Z"
}

CVE Status Changes

  • What it means: GreyNoise changes how it reports a CVE (e.g., Observed → Active Exploitation).
  • Why it matters: Lets you know when in-the-wild exploitation of a CVE begins or stops.
  • Example event:
{
  "event_type": "cve-status-change",
  "cve": "CVE-2024-58136",
  "old_state": {
    "activity_seen": false,
    "benign_ip_count_10d": 0,
    "benign_ip_count_1d": 0,
    "benign_ip_count_30d": 0,
    "threat_ip_count_10d": 0,
    "threat_ip_count_1d": 0,
    "threat_ip_count_30d": 0
  },
  "new_state": {
    "activity_seen": true,
    "benign_ip_count_10d": 0,
    "benign_ip_count_1d": 0,
    "benign_ip_count_30d": 0,
    "threat_ip_count_10d": 1,
    "threat_ip_count_1d": 1,
    "threat_ip_count_30d": 1
  },
  "timestamp": "2025-09-29T13:20:23.022353819Z",
  "metadata": {}
}

CVE Activity Spike

  • What it means: Receive real-time events when a user-defined surge of activity on a CVE occurs.
  • Why it matters: Not all CVE exploitation attempts are equally important. A single scanner or researcher probing the internet can create unnecessary noise, leading to alert fatigue. The CVE Activity Spike feed reduces this noise by alerting only when exploitation reaches a user-defined threshold, so you decide what level of activity represents a meaningful surge worth your attention.
  • Example event:
{
  "event_type": "cve-activity-spike",
  "cve": "CVE-2020-15505",
  "old_state": {
    "activity_seen": true,
    "benign_ip_count_10d": 0,
    "benign_ip_count_1d": 0,
    "benign_ip_count_30d": 0,
    "threat_ip_count_10d": 25,
    "threat_ip_count_1d": 6,
    "threat_ip_count_30d": 47
  },
  "new_state": {
    "activity_seen": true,
    "benign_ip_count_10d": 0,
    "benign_ip_count_1d": 0,
    "benign_ip_count_30d": 0,
    "threat_ip_count_10d": 29,
    "threat_ip_count_1d": 10,
    "threat_ip_count_30d": 51
  },
  "timestamp": "2025-09-29T17:30:27.161824826Z",
  "metadata": {}
}

Vendor CVE Spike

  • What it means: Receive real-time events when a user-defined surge of activity on a vendor occurs.

  • Why it matters:

    Individual CVEs and tags are constantly added, updated, and deprecated as new research emerges, creating overhead and blind spots if teams have to manage tracking manually.

    The Vendor Activity Spike feed reduces this complexity by alerting only when activity across a vendor meaningfully increases. As vulnerabilities and tags associated with a vendor change over time, the feed automatically stays up to date, so you can focus on when attacker interest spikes, without worrying about which specific CVEs to track.

    When you search for a vendor name (e.g., "Palo Alto"), the feed uses wildcard matching to find all tags containing that term, then resolves those tags to their associated CVEs. The feed then monitors activity for those CVEs. If you want to monitor tag activity directly without CVE resolution, use Tag Spike instead.

  • Use cases:

    • Vendor-wide vulnerability monitoring: Monitor all CVE exploitation activity across a vendor's products without manually tracking individual CVEs as they're published or updated.
    • Patch prioritization: Prioritize patching cycles based on vendor-level exploitation trends. A spike in activity for your firewall vendor signals it's time to accelerate remediation.
    • Proactive threat hunting: Use vendor spikes as an early warning signal to investigate whether associated CVEs have been attempted against your environment.

  • Syntax:

    • Vendor names are not case sensitive. For example, palo alto or Cisco will both work.

  • Example event:

{
"vendor": "Acme",
"event_type": "Vendor CVE Spike",
"old_state": {
"benign_ip_count_1d": 40,
"threat_ip_count_1d": 40
},
"new_state": {
"benign_ip_count_1d": 90,
"threat_ip_count_1d": 90
},
"timestamp": "2025-04-30T08:10:00Z"
}

Tag Spike

Tag Spike feeds monitor for sudden increases in activity associated with specific GreyNoise tags. When you configure a Tag Spike feed, GreyNoise monitors significant changes in IP counts for tags that match your filter criteria over a rolling 2-hour window.

  • What it means: Receive real-time events when a user-defined surge of activity on a GreyNoise tag occurs.

  • Why it matters: Tag Spike lets you monitor activity for specific threats, botnets, or scanning behaviors directly by tag name. When you search for a tag, vendor, or product name (e.g., "Palo Alto"), the feed uses wildcard matching to find all tags containing that term and monitors their activity directly. Unlike Vendor CVE Spike, which resolves matching tags to their associated CVEs, Tag Spike tracks the tags themselves.

  • Use cases:

    • Monitoring emerging exploit activity for specific products or vendors before CVEs are assigned
    • Tracking botnets, scanners, or malware families by tag name
    • Getting early warning when threat actors ramp up scanning for specific technologies

  • Syntax:

    • Tag names are not case sensitive. For example, Mirai or cisco will both work.

  • Example event:

{
"tag": "botnet",
"event_type": "Tag Spike",
"old_state": {
"benign_ip_count_1d": 60,
"threat_ip_count_1d": 40
},
"new_state": {
"benign_ip_count_1d": 120,
"threat_ip_count_1d": 80
},
"timestamp": "2025-04-30T08:10:00Z"
}

Planned Future Topics

  • New IPs observed for a tag
  • New IPs added to RIOT
  • New tag creation
  • Sensor-based session events

If there are any feed topics you would like to create, please reach out to [email protected].

Use Cases for Feeds

Automated IP Blocking

  • SOAR Workflows: Trigger automated playbooks when IPs shift to malicious.
  • Firewall/WAF Rules: Dynamically update blocklists to minimize attacker dwell time.

Automated Vulnerability Response

  • SOAR Workflows: Prioritize patching vulnerabilities that are actively exploited.
  • Ticket Creation: Open tickets automatically when active CVE exploitation is detected.

Example Scenarios

  • A CVE shifts from “no activity” → “active exploitation”; a ticket is generated for the Vulnerability Management team.
  • An IP moves from Unknown → Malicious; the IP is added to your firewall blocklist.

Updated 15 days ago