Using SOCbuddy

SOCbuddy is an AI co-pilot for security operations. You paste, upload, or push security telemetry into it and it returns a structured triage verdict: severity, confidence, a one-line summary, extracted indicators, mapped MITRE ATT&CK techniques, recommended actions, and false-positive checks.

The four surfaces

• Chat — the main workspace. Free-form investigations, evidence attachments, quick actions, and playbooks.
• Alert Inbox (/ingest) — the SIEM ingestion endpoint plus a manual tester for sample payloads.
• Reports — export any triage as JSON or PDF, or hand someone a share link.
• Settings — your IOC reputation API keys and cross-device sync.

Your first investigation, in under two minutes:

1. 1Open a New investigation from the sidebar (the app creates one automatically on first load).
2. 2Paste raw alert text, a log excerpt, or an email header block straight into the prompt box and send it.
3. 3Read the response top-down: Severity and Confidence first, then Summary, Indicators, MITRE TTPs, Recommended Actions, and False-Positive Checks.
4. 4Expand any tool card in the reply to see what SOCbuddy looked up (CVE details, IOC reputation) and where the verdict came from.
5. 5Add your own reputation keys in Settings when you want authoritative verdicts rather than best-effort ones.

Threads

• New investigation starts a fresh thread. Threads are listed newest-first in the sidebar and auto-titled from your first message.
• Hover a thread to rename or delete it.
• Threads live in this browser's local storage — they are not on a server, they do not follow you to another machine unless you turn on sync, and clearing site data deletes them permanently.

Quick actions

Playbooks cover Ransomware, Phishing, Data Exfiltration, and Account Compromise. Each one loads a structured prompt into the composer — edit it to add your environment specifics before sending, and the output gets far more useful.

Attaching evidence

• Supported: .json .log .txt .csv .tsv .eml .xml .yml .yaml .md .conf .ini, plus any plain-text or JSON MIME type.
• Up to 5 files per message. Each file is read up to 1 MB; anything longer is truncated and clearly marked in the message.
• Attached files appear as chips above the composer — click the × on a chip to drop it before sending.
• Binaries, PCAPs, archives, and memory images are not supported. Export the relevant text view first (for example tshark -r capture.pcap -T fields ...).

Reading the output

Built-in tools

• lookup_cve — pulls live CVE data from the NVD (CVSS score and vector, description, references) whenever a CVE-YYYY-NNNNN appears.
• lookup_ioc — checks every extracted IP, domain, URL, and hash against the reputation feeds you have enabled.

Tool calls render inline as collapsed cards inside the assistant reply. Open one to see the exact query and the raw feed response — always do this before you act on a verdict.

The Alert Inbox at /ingest is where you wire your SIEM into SOCbuddy and where you test payloads by hand.

Manual testing

1. 1Open the Alert Inbox. On mobile, use the menu button or the "Inbox" shortcut in the top bar.
2. 2Press Load sample to drop a realistic alert into the payload box, or paste your own JSON.
3. 3Press Triage now and wait for the structured report to render below.
4. 4If the report fails to load, use Try sample again — it clears the error, resets the checklist, and re-runs the triage.

Endpoint

POST  /api/public/ingest
OPTIONS /api/public/ingest   (CORS preflight, 204)

Authorization: Bearer <SOCBUDDY_INGEST_SECRET>
Content-Type:  application/json

Optional per-request reputation keys:
  X-VirusTotal-Key: <key>
  X-AbuseIPDB-Key:  <key>
  X-GreyNoise-Key:  <key>

CORS is open (Access-Control-Allow-Origin: *) so browser-based and server-side callers both work. The bearer token is compared in constant time.

Request schema

Sample payload

{
  "source": "splunk",
  "alertId": "SPL-2291",
  "severity": "high",
  "timestamp": "2026-08-10T02:14:55Z",
  "title": "Suspicious PowerShell encoded command",
  "description": "Encoded PowerShell spawned by winword.exe on a finance workstation.",
  "host": "FIN-WKS-014",
  "user": "j.rivera",
  "src_ip": "10.12.4.87",
  "dst_ip": "185.234.219.12",
  "indicators": ["185.234.219.12", "CVE-2024-21412"],
  "raw": "powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4A..."
}

Sample request

curl -X POST https://aisocbuddy.lovable.app/api/public/ingest \
  -H "Authorization: Bearer $SOCBUDDY_INGEST_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "splunk",
    "alertId": "SPL-2291",
    "severity": "high",
    "title": "Suspicious PowerShell encoded command",
    "host": "FIN-WKS-014",
    "src_ip": "10.12.4.87",
    "dst_ip": "185.234.219.12",
    "raw": "powershell.exe -nop -w hidden -enc SQBFAFgA..."
  }'

Pass your own reputation keys per request when the caller is a server you control:

curl -X POST https://aisocbuddy.lovable.app/api/public/ingest \
  -H "Authorization: Bearer $SOCBUDDY_INGEST_SECRET" \
  -H "X-VirusTotal-Key: $VT_KEY" \
  -H "X-AbuseIPDB-Key: $ABUSEIPDB_KEY" \
  -H "X-GreyNoise-Key: $GREYNOISE_KEY" \
  -H "Content-Type: application/json" \
  -d @alert.json

Response

{
  "alertId": "SPL-2291",
  "severity": "High",              // SOCbuddy verdict, not the source severity
  "confidence": "Medium",
  "summary": "Encoded PowerShell spawned by Word on a finance host, beaconing to a known-bad IP.",
  "indicators": ["185.234.219.12", "FIN-WKS-014", "j.rivera"],
  "mitre_ttps": ["T1059.001", "T1566.001"],
  "recommended_actions": ["Isolate FIN-WKS-014", "Pull the parent Word document", "..."],
  "false_positive_checks": ["Confirm no admin script deployment ran at 02:14Z", "..."],
  "report_markdown": "**Summary**\n...",   // full analyst-readable report
  "ioc_data": [                             // reputation feed results, one per IOC
    { "ioc": "185.234.219.12", "type": "ip", "verdict": "malicious", "confidence": "high", "sources": ["URLhaus"] }
  ]
}

Errors

Wiring your SIEM

# Splunk alert action -> Webhook
# Settings > Alert > Trigger Actions > Webhook
# Splunk cannot set custom headers, so front it with a tiny relay:

#!/usr/bin/env bash
# /opt/socbuddy/relay.sh  (Splunk custom alert script)
payload=$(cat)
curl -sS -X POST "$SOCBUDDY_URL/api/public/ingest" \
  -H "Authorization: Bearer $SOCBUDDY_INGEST_SECRET" \
  -H "Content-Type: application/json" \
  -d "{\"source\":\"splunk\",\"title\":\"$SPLUNK_ALERT_NAME\",\"raw\":$payload}"

# Kibana > Stack Management > Connectors > Webhook
Method:  POST
URL:     https://aisocbuddy.lovable.app/api/public/ingest
Headers:
  Content-Type: application/json
  Authorization: Bearer <SOCBUDDY_INGEST_SECRET>

Body (rule action, Mustache):
{
  "source": "elastic",
  "alertId": "{{alert.id}}",
  "severity": "{{context.rule.severity}}",
  "title": "{{context.rule.name}}",
  "description": "{{context.rule.description}}",
  "host": "{{context.alerts.0.host.name}}",
  "src_ip": "{{context.alerts.0.source.ip}}",
  "dst_ip": "{{context.alerts.0.destination.ip}}",
  "raw": "{{context.alerts.0._source}}"
}

# Generic poster: read alerts from a queue file, triage each one
*/5 * * * * /usr/local/bin/socbuddy-post.sh

#!/usr/bin/env bash
set -euo pipefail
for f in /var/spool/alerts/*.json; do
  curl -sS -X POST "$SOCBUDDY_URL/api/public/ingest" \
    -H "Authorization: Bearer $SOCBUDDY_INGEST_SECRET" \
    -H "Content-Type: application/json" \
    --data-binary "@$f" >> /var/log/socbuddy.log && mv "$f" /var/spool/alerts/done/
done

Escalating to a thread

Any triaged alert in the Inbox has an escalate action that opens the full report as a new chat investigation, so you can keep asking follow-up questions with the alert context already loaded.

Feeds that need no key

• URLhaus (abuse.ch) — known malware-distribution URLs, domains, and payload hashes. A hit is strong evidence; a miss means nothing.
• ipapi.co — geolocation, ASN, and hosting-provider context for IPs. Context only, never a verdict.

Optional feeds (your keys)

Add keys in Settings (sidebar) or in the keys panel on the Alert Inbox. The feeds active counter shows how many of the five are live — it starts at 2/5 with URLhaus and ipapi.co.

Reading a verdict

• Each IOC card shows a verdict (malicious / suspicious / benign / unknown), a confidence level, and the sources that produced it.
• With VirusTotal enabled, multi-engine detections carry the verdict; a single engine hit is treated as suspicious, not malicious.
• AbuseIPDB abuse-confidence scores drive IP verdicts — a high score on a residential or hosting IP is a strong signal.
• GreyNoise RIOT identifies benign common infrastructure (CDNs, DNS resolvers, patch servers), which suppresses false positives on IPs that look busy but are harmless.
• Unknown is not clean. A brand-new C2 domain is unknown to every feed on day one.

Download

• JSON — the structured report exactly as the API returns it. Ideal for attaching to a case record or feeding into a SOAR playbook.
• PDF — opens a print-ready view; use your browser's print dialog and choose "Save as PDF". Best for handing to someone outside the SOC.
• Markdown — export a whole chat investigation, including your questions and every tool result, from the thread menu.

Share links

A share link encodes the entire report into the URL itself (base64) and opens it on the public /report page. Nothing is written to a database, there is no expiry, and no account is needed to open it.

What syncs

• Your IOC reputation API keys.
• Your investigation threads and their full message history.
• Saved triage reports.
• Not synced: the ingest secret (that lives on the server) and any file you attached, beyond the text already inside the messages.

Setting it up

1. 1On your main device, open Settings → Sync and press Generate sync code.
2. 2Copy the code and store it in your password manager.
3. 3Press Push to upload the encrypted bundle.
4. 4On the second device, open Settings → Sync, enter the same code, and press Pull.
5. 5Choose Merge to combine both devices' threads, or Replace to overwrite local data with the cloud bundle.

Inviting your team

1. 1Open Settings → Sync and press the Invite link button to copy a link.
2. 2Send the link to a teammate. It opens a Team invite page with the sync code already filled in.
3. 3They press Link this device — their device pulls the shared API keys, investigation threads, and saved reports, merging with anything already stored locally.

The code travels in the link's hash fragment (#code=…), which browsers never send to the server, so the invite link itself never exposes the code to SOCbuddy's backend.

Encryption model

The sync code is your passphrase. Your browser derives an AES-GCM 256 key from it and encrypts the bundle locally; only the ciphertext is uploaded. The server stores an opaque blob keyed by a hash of the code — it never receives the code itself and cannot decrypt anything.

• Advisory, not authoritative. Every severity call, TTP mapping, and recommended action is a model output. Verify against your own telemetry before you isolate a host, disable an account, or close a ticket.
• Mind what you paste. Message content is sent to a hosted model for inference. Do not paste credentials, private keys, PII, PHI, or regulated customer data. Redact before you attach.
• Local retention. Threads, saved reports, and IOC keys live in your browser's local storage and persist until you delete them or clear site data. There is no automatic expiry and no server-side copy unless you push a sync bundle.
• Feed limits are real. Free reputation tiers are small. In a busy inbox, high-volume automated triage will exhaust them — batch alerts or upgrade the feed plan rather than retrying in a loop.
• No environment access. SOCbuddy cannot query your SIEM, EDR, or directory. It only knows what you send it.