Threat Monitoring — Keyword-Based Alerting
Recurring keyword surveillance over everything the platform collects: Telegram, WhatsApp, forums, social networks, .onion sites, paste sites, code repositories, IOC feeds, credential databases and infostealer logs. A monitor describes what matters; collection runs on its own schedule, and whatever matches becomes an alert waiting for triage.
Overview
Every monitor has a name unique within the organization, a category (twelve options, from threat detection to executive protection), an owning team (SOC, CSIRT, Threat Intelligence, DevSecOps, Compliance, Risk, Fraud, Data Protection), a priority and a status.
Frequency ranges from 1 minute to 30 days. The execution timeout goes up to 2 hours, and the number of retries on failure is configurable up to ten. Execution is orchestrated by Airflow: a manual run queues the DAG, and the history keeps every run with its duration, outcome and trend.
Terms are encrypted at rest. Keywords, term lists, search commands and the monitor’s own description are stored in encrypted fields. What an organization watches is itself sensitive information: it reveals which assets, executives and brands are at risk.
How the Query Is Built
Terms become mandatory phrase clauses across four fields of the alert — title, description, raw data and source. On top of the terms come the operators:
- AND adds further mandatory terms;
- OR forms a group in which at least one term must appear;
- NOT excludes any document containing any of the listed terms.
After the query there is a second filtering pass over what came back. It treats a standalone term with word boundaries and a multi-word expression as a substring — which is what stops bin from matching inside binary while still allowing “credit card” to match as a phrase. Both stages exist because exclusion at query time alone cannot handle negation over nested fields.
Triage, Not a Firehose
An alert is born pending. The analyst marks it valid or dismissed, and that decision is recorded with author, date, assigned severity and a false-positive flag. The three queues can be worked separately, with filters by title, severity, matched keyword, stealer family and the presence of card data.
Meanwhile, a layer of regular expressions tags the alert across ten categories — credentials, fraud, data leakage, brand abuse, phishing, dark web, malware, executives, infrastructure and social networks. The tag steers the queue; it decides nothing.
A monitor also accepts a declarative triage configuration: scope, monitored entities, keyword tiers by criticality, negative keywords, validation and auto-discard patterns, known benign sources, a deduplication window in hours and a scoring threshold. It is the way to say “ignore mentions in an academic context” without rewriting the query.
Capabilities
- 112 collection sources mapped to dedicated indices
- Optional AI summary per alert, using a closed schema of threat types — plus a filter to see only alerts with or without a summary
- Cross-referencing against the leak archive (combolists) and against infostealer packages, including a filter by stealer family
- Alerts can be promoted into an incident or a report, one at a time or in bulk
- Alert export to XLSX
- Soft delete with author and date, configuration versioning and a history of eight change types
- An organization asset dictionary with 41 categories across ten groups, which feeds the monitor’s terms
Use Cases
- Follow mentions of the brand and of executives on forums and closed channels
- Detect corporate credentials inside infostealer packages, with the family identified
- Watch a specific actor’s campaign by combining positive and negative terms
- Feed the SOC queue with alerts that arrive already categorized and prioritized
What the Module Does Not Do
- The alert channels are e-mail, Slack and webhook. There is no native delivery to Microsoft Teams or Discord — use the webhook for those.
- The AI summary does not decide whether an alert is valid. Validation belongs to the analyst, and it is the analyst’s decision that goes on the record.
- Automatic categorization is lexical, driven by text patterns. It is not a trained classifier and has no published accuracy rate.
- There is no automatic retroactive reprocessing of history when a new term is added to a monitor.
Integrations
- Slack, e-mail and custom webhooks
- Airflow (run orchestration) and OpenSearch (the collection archive)
- OODA Leaks, OODA Incident, OODA Reports and the platform’s REST API
SLA & Guarantees
Frequency from 1 minute to 30 days · terms encrypted at rest · every alert validation is signed