Why GreyNoise Isn’t an AI Company—But Why Every Security Team Needs Both Now + Video

Listen to this Post

Featured Image

Introduction

In a recent LinkedIn reflection, Andrew Morris, Founder of GreyNoise Intelligence, recounted a pivotal moment when a prospect stopped his technical pitch with a simple challenge: “Stop telling me how it works. Tell me what problem you’re solving.” This cuts to the heart of a critical debate in modern cybersecurity—the distinction between being an “AI company” versus a security company that leverages AI. As software vulnerabilities accelerate from discovery to weaponization, defenders face compressed timelines where the difference between a 12-hour and week-long breach could mean SEC filings and millions in enterprise value. The question isn’t whether your vendor sells AI—it’s whether they solve the real problem of internet-scale threat detection with or without it.

Learning Objectives

  • Understand the distinction between AI-native security companies and security companies leveraging AI as a tool
  • Learn practical automation techniques for vulnerability detection and response using open-source tools
  • Master the integration of threat intelligence feeds into SIEM and SOAR platforms for accelerated incident response

You Should Know

  1. The Vulnerability Acceleration Problem: Why Automation Isn’t Optional

Andrew Morris highlights a terrifying reality: “Software vulnerabilities will continue to be discovered, weaponized, and hurled at hosts on the internet. The frequency is exaggerated, and the time between each step is compressed.” In 2024, the average time from CVE publication to active exploitation dropped to under 24 hours for critical vulnerabilities. This means manual patching cycles are dead.

Step‑by‑step guide: Automating vulnerability discovery with Nmap and NSE scripts

First, let’s understand your exposure. Run this Linux command to identify all internet-facing services:

sudo nmap -sS -sV -p- -T4 -iL targets.txt -oA initial_scan

For Windows environments, use the PowerShell equivalent with Test-NetConnection in a loop:

$targets = Get-Content .\targets.txt
foreach ($target in $targets) {
Test-NetConnection -ComputerName $target -Port 443 -InformationLevel Detailed
}

Now, to detect recently weaponized vulnerabilities, integrate the GreyNoise API (or similar threat intel) into your scanning. Here’s a Python script that checks if scanning IPs are malicious:

import requests
import json

api_key = "YOUR_GREYNOISE_API_KEY"
headers = {"key": api_key, "Accept": "application/json"}

def check_ip(ip):
response = requests.get(f"https://api.greynoise.io/v3/community/{ip}", headers=headers)
if response.status_code == 200:
data = response.json()
if data.get('classification') == 'malicious':
print(f"ALERT: {ip} is malicious - {data.get('name', 'Unknown')}")
return True
return False

Read scan results and check each source IP
with open('initial_scan.gnmap', 'r') as f:
for line in f:
if '/open/' in line:
parts = line.split()
ip = parts[bash]
check_ip(ip)

This script automates the first step of Morris’s argument: distinguishing between background internet noise and targeted threats. The key takeaway? You can’t manually triage millions of events—automation must handle the grunt work.

2. Building Automated Detection and Response Pipelines

Morris emphasizes that “defenders need to invest as much as possible into automation that drives detection and response.” This means moving beyond simple alerts to automated containment.

Step‑by‑step guide: Creating a SOAR-like workflow with open-source tools

We’ll use TheHive (incident response) and Cortex (analysis) with Shuffle (workflow automation) on Ubuntu 22.04:

First, install Docker and Docker Compose:

sudo apt update && sudo apt install -y docker.io docker-compose
sudo systemctl enable docker && sudo systemctl start docker

Create a docker-compose.yml for TheHive and Cortex:

version: '3'
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
environment:
- discovery.type=single-node
- "ES_JAVA_OPTS=-Xms1g -Xmx1g"
volumes:
- ./elasticsearch/data:/usr/share/elasticsearch/data

cortex:
image: thehiveproject/cortex:latest
depends_on:
- elasticsearch
ports:
- "9001:9001"
volumes:
- ./cortex/data:/opt/cortex/data

thehive:
image: thehiveproject/thehive:latest
depends_on:
- elasticsearch
- cortex
ports:
- "9000:9000"
volumes:
- ./thehive/data:/opt/thehive/data

Run `docker-compose up -d` to start. Now configure Cortex analyzers—add GreyNoise analyzer to automatically enrich observables:

docker exec -it cortex bash
cd /opt/cortex/analyzers
git clone https://github.com/TheHive-Project/Cortex-Analyzers.git
cd Cortex-Analyzlers/analyzers/GreyNoise
pip3 install -r requirements.txt

Back in the Cortex web UI (https://your-server:9001), add the GreyNoise analyzer with your API key. Now when TheHive receives an alert, it can automatically query GreyNoise to determine if the IP is part of internet-wide scanning or targeted.

This infrastructure mirrors what Morris describes: analysts augmented by agents making “bazillions of API calls to look stuff up.” The difference between a compromised network and a contained incident often comes down to whether your automation stack can make these decisions in real-time.

  1. The AI Agent Revolution: MCP and Threat Intelligence Integration

Morris notes that “analysts will increasingly be augmented by agents that do much of the investigative work, and will likely make bazillions of API calls to look stuff up. Cooking every IP scanning the internet into an LLM feels very silly. That’s why things like MCP exist.”

MCP (Model Context Protocol) is emerging as a standard for LLMs to access external tools and data sources. Here’s how to build a simple AI agent that queries threat intelligence before making decisions:

Step‑by‑step guide: Building a threat intelligence MCP server

Create a Python-based MCP server that exposes GreyNoise data to any LLM:

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import requests
import uvicorn

app = FastAPI(title="Threat Intel MCP Server")

class IPRequest(BaseModel):
ip_address: str

class IPResponse(BaseModel):
ip: str
classification: str
last_seen: str
tags: list
is_malicious: bool

@app.post("/analyze_ip", response_model=IPResponse)
async def analyze_ip(request: IPRequest):
api_key = "YOUR_GREYNOISE_API_KEY"
headers = {"key": api_key, "Accept": "application/json"}

try:
response = requests.get(
f"https://api.greynoise.io/v3/community/{request.ip_address}",
headers=headers
)
if response.status_code == 200:
data = response.json()
return IPResponse(
ip=request.ip_address,
classification=data.get('classification', 'unknown'),
last_seen=data.get('last_seen', ''),
tags=data.get('tags', []),
is_malicious=(data.get('classification') == 'malicious')
)
else:
raise HTTPException(status_code=404, detail="IP not found")
except Exception as e:
raise HTTPException(status_code=500, detail=str(e))

if <strong>name</strong> == "<strong>main</strong>":
uvicorn.run(app, host="0.0.0.0", port=8000)

Now any AI agent can query this endpoint. For example, using LangChain:

from langchain.agents import initialize_agent, Tool
from langchain.llms import OpenAI
import requests

def threat_intel_tool(ip):
response = requests.post(
"http://localhost:8000/analyze_ip",
json={"ip_address": ip}
)
return response.json()

tools = [
Tool(
name="Threat Intelligence",
func=threat_intel_tool,
description="Checks if an IP is malicious using GreyNoise"
)
]

llm = OpenAI(temperature=0)
agent = initialize_agent(tools, llm, agent="zero-shot-react-description")

result = agent.run("Analyze IP 8.8.8.8 and tell me if it's malicious")
print(result)

This architecture prevents the “silly” approach of training LLMs on raw IP data. Instead, the AI queries real-time threat intelligence when needed, exactly as Morris advocates.

  1. Ground Truth Data: PCAP Analysis and Payload Inspection

Morris emphasizes that “any data you can get to tie different attack campaigns together (especially ground truth data like PCAPs and payloads) is useful for defenders, whether a human or AI analyst ties it together.”

Step‑by‑step guide: Automating PCAP analysis with Zeek and RITA

First, install Zeek (formerly Bro) on a Ubuntu sensor:

sudo apt update && sudo apt install -y zeek
sudo zeekctl deploy

Zeek will generate logs in /usr/local/zeek/logs/current/. Now install RITA (Real Intelligence Threat Analytics) to detect beaconing and C2 traffic:

wget https://github.com/activecm/rita/releases/download/v3.0.6/rita-3.0.6_amd64.deb
sudo dpkg -i rita-3.0.6_amd64.deb
sudo apt install -f

Configure RITA to import Zeek logs:

sudo vi /etc/rita/config.yaml
 Set LogDirectory to /usr/local/zeek/logs/current/

Now create a script to automatically analyze PCAPs for suspicious patterns:

!/bin/bash
 auto_analyze.sh

PCAP_DIR="/opt/pcap_captures"
cd $PCAP_DIR

for pcap in .pcap; do
 Convert pcap to Zeek logs
zeek -r "$pcap" local

Import into RITA
rita import --rolling /usr/local/zeek/logs/current/ "analysis_${pcap%.pcap}"

Generate HTML report
rita html-report "analysis_${pcap%.pcap}" "/var/www/html/reports/${pcap%.pcap}"

Check for beacons
rita show-beacons "analysis_${pcap%.pcap}" --csv > "/tmp/beacons_${pcap%.pcap}.csv"

Move processed file
mv "$pcap" processed/
done

This automated pipeline captures the ground truth data Morris discusses. When combined with AI analysis, you can identify not just that an attack happened, but how it connects to other campaigns.

5. Real‑Time Feeds and AI Decision Making

Morris’s final point: “AI that does cyber stuff (attack or defense) will always be better equipped to make decisions if it has access to a real time feed of what’s going on on the internet.”

Step‑by‑step guide: Integrating real-time threat feeds into SIEM

For Windows environments using Splunk Free, create a script to ingest GreyNoise data:

 GreyNoise_Ingest.ps1
$apiKey = "YOUR_API_KEY"
$outputFile = "C:\Program Files\Splunk\etc\apps\search\lookups\greynoise_feed.csv"

Get recent malicious IPs (last 24 hours)
$uri = "https://api.greynoise.io/v3/experimental/gnql?query=last_seen:24h%20AND%20classification:malicious"
$headers = @{
"key" = $apiKey
"Accept" = "application/json"
}

$response = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get

Format for Splunk lookup
$csvData = $response.data | Select-Object @{Name="ip"; Expression={$<em>.ip}},
@{Name="classification"; Expression={$</em>.classification}},
@{Name="last_seen"; Expression={$<em>.last_seen}},
@{Name="tags"; Expression={($</em>.tags -join ";")}}

$csvData | Export-Csv -Path $outputFile -NoTypeInformation

Schedule this script to run hourly via Task Scheduler

For Linux with Elastic Stack, use Logstash:

 /etc/logstash/conf.d/greynoise.conf
input {
http_poller {
urls => {
greynoise => "https://api.greynoise.io/v3/experimental/gnql?query=classification:malicious&size=1000"
}
request_timeout => 60
schedule => { cron => "/15    " }
headers => {
"Accept" => "application/json"
"key" => "YOUR_API_KEY"
}
codec => "json"
}
}

filter {
split { field => "data" }
mutate {
add_field => { "[@metadata][bash]" => "%{+YYYY.MM.dd}" }
}
}

output {
elasticsearch {
hosts => ["localhost:9200"]
index => "greynoise-feed-%{[@metadata][bash]}"
}
}

Now your SIEM has real-time context. When an alert fires, you can automatically query: “Is this source IP in the GreyNoise feed? Is it opportunistic scanning or targeted?”

6. Differentiating Run‑of‑the‑Mill vs. Targeted Attacks

Morris concludes with a critical distinction: “the difference between your network being compromised by a run-of-the-mill crypto miner and a targeted attacker is meaningful.” Your automated response should differ dramatically.

Step‑by‑step guide: Building automated response playbooks

Using Shuffle (open-source SOAR), create a workflow:

1. Trigger: New high-severity alert from your EDR

2. Enrichment: Query GreyNoise for the external IP

3. Decision Tree:

  • If IP is mass-scanning (tags: “shodan”, “censys”, “internet background noise”) → Low priority, auto-block for 24 hours, create low-ticket
  • If IP is unknown but has suspicious behavior → Medium priority, isolate host, notify analyst
  • If IP is known APT infrastructure → Critical priority, isolate entire subnet, call IR team, file 8-K if public company

Here’s the Python logic for the decision:

def triage_incident(alert_data, threat_intel):
ip = alert_data['source_ip']
intel = threat_intel.get(ip, {})

Check if it's background noise
if intel.get('classification') == 'benign' and 'scanner' in intel.get('tags', []):
return {
'priority': 'low',
'action': 'block_24h',
'message': f'IP {ip} is known scanner - auto-blocked'
}

Check if it's targeted
if intel.get('classification') == 'malicious':
if any(tag in ['apt', 'targeted', 'ransomware'] for tag in intel.get('tags', [])):
return {
'priority': 'critical',
'action': 'isolate_all',
'message': f'TARGETED ATTACK from {ip} - escalate immediately'
}

Default to medium
return {
'priority': 'medium',
'action': 'isolate_host',
'message': f'Suspicious activity from {ip} - investigate'
}

This automated triage saves precious hours. The difference between responding to a crypto miner (re-image, close ticket) versus an APT (call IR, preserve evidence, legal notification) could determine whether your company faces regulatory action.

What Undercode Say

Key Takeaway 1: AI is a tool, not an identity. The most effective security companies—and internal security teams—are those that solve problems with the best available tools, whether that’s AI, signature-based detection, or human analysis. Don’t get distracted by whether a vendor calls themselves an “AI company”; focus on whether they solve your specific problem.

Key Takeaway 2: Automation must be context-aware. The accelerating vulnerability lifecycle demands automated response, but not all automation is equal. The systems that succeed will be those that can distinguish between background internet noise and genuine targeted threats, applying appropriate response severity based on real-time threat intelligence. This requires integration between your detection stack and external data sources like GreyNoise.

The cybersecurity landscape has fundamentally shifted. With vulnerability-to-exploitation timelines compressed to hours, manual analysis is no longer viable. Yet throwing AI at every alert without context is equally dangerous. The winning strategy combines automation with ground truth data—PCAPs, payloads, and real-time threat feeds—to make intelligent decisions at machine speed. Organizations that master this balance will survive the post-AI era; those that don’t will find themselves explaining to regulators why a crypto miner and a nation-state breach received the same response.

Prediction

Within 24 months, we’ll see the emergence of “Autonomous Security Operations Centers”—AI-driven systems that handle 90% of alert triage without human intervention. These systems will rely on MCP-style integrations with threat intelligence providers, making real-time decisions about containment, eradication, and recovery. Security analysts will shift from alert fatigue to high-level threat hunting and strategic response, but only in organizations that invest today in the data pipelines and automation frameworks that make machine decision-making possible. The vendors that survive will be those that provide not just AI, but the ground truth data that makes AI intelligent.

▶️ Related Video (82% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Andrew – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky