Skip to main content

SIEM Tools

The SIEM tool module provides four tools for log search, event correlation, IOC extraction, and MITRE ATT&CK mapping. Located in aurorasoc/tools/siem/.

Tool Inventory​

SearchLogs​

Queries SIEM data sources for log events matching criteria.

class SearchLogs(AuroraTool):
    name = "search_logs"
    description = "Search SIEM logs across all data sources"
    
    input_schema = {
        "properties": {
            "query": {"type": "string", "description": "Search query"},
            "time_range": {"type": "string", "default": "15m"},
            "source": {"type": "string", "enum": ["wazuh", "suricata", "zeek", "velociraptor"]},
            "max_results": {"type": "integer", "default": 100}
        },
        "required": ["query"]
    }
    
    async def _execute(self, query, time_range="15m", source=None, max_results=100):
        # Query SIEM backend
        events = await siem_client.search(query, time_range, source, max_results)
        return {
            "events": events,
            "count": len(events),
            "query": query,
            "time_range": time_range
        }

Used by: Security Analyst, Threat Hunter, Forensic Analyst

Operator Workflow Extensions​

The SIEM workspace now exposes two operator-facing workflow primitives on top of raw search:

Saved Hunts​

Saved hunts persist a search query plus the active source, severity, and host filters.

  • GET /api/v1/siem/hunts returns the currently stored hunts.
  • POST /api/v1/siem/hunts stores a new hunt from dashboard state.
  • PATCH /api/v1/siem/hunts/{hunt_id} updates description, tags, or sharing metadata.
  • POST /api/v1/siem/hunts/{hunt_id}/run reruns the hunt and returns the latest result set plus updated hit counters.

Saved hunts are designed for repeatable operator workflows such as recurring brute-force review, PowerShell execution hunting, and exfiltration sweeps.

Hunt Persistence And Sharing Model​

Hunts are now backed by the siem_hunts table instead of in-memory state.

  • sharing_mode supports private, team, and roles.
  • shared_with_roles stores the explicit AuroraSOC roles allowed to view or run a hunt when the mode is roles.
  • created_by and is_owner enforce owner-only mutation while still allowing shared read access.
  • last_run_at and last_match_count provide operator-facing telemetry for recurring hunts.

This means saved hunts are durable, auditable, and available across sessions in real mode.

Detection Engineering APIs​

AuroraSOC now exposes a dedicated detection-engineering slice alongside the SIEM search APIs.

  • GET /api/v1/detections/rules
  • POST /api/v1/detections/rules
  • PATCH /api/v1/detections/rules/{rule_id}
  • POST /api/v1/detections/rules/{rule_id}/run
  • GET /api/v1/detections/rules/{rule_id}/runs
  • GET /api/v1/detections/metrics
  • GET|POST /api/v1/detections/rules/{rule_id}/suppressions
  • GET|POST /api/v1/detections/rules/{rule_id}/feedback

Each rule captures:

  • a reusable query and pivot set (query, source, match_severity, host)
  • alert rendering templates
  • output severity and optional auto_create_case
  • optional scheduler metadata (schedule_enabled, schedule_interval_minutes, next_run_at)
  • tags, MITRE techniques, and team-sharing metadata
  • counters for last matches, true positives, and false positives

Scheduled Rule Execution And Metrics​

The background scheduler now evaluates due detection rules inside the same periodic loop used for recurring hunts.

  • Due rules are selected from persisted scheduler metadata rather than in-memory timers.
  • Each execution writes a DetectionRuleRunModel record that stores trigger mode, status, match counts, suppressed counts, sample log IDs, and any error details.
  • Manual runs and scheduled runs both contribute to the rule's persisted telemetry (last_run_at, last_match_count, last_triggered_at).
  • GET /api/v1/detections/rules/{rule_id}/runs is the operator-facing history surface for recent executions.
  • GET /api/v1/detections/metrics returns aggregate trend data for dashboards, including run volume, scheduled-rule counts, noisy rules, and high-match rules over the last 24 hours.

Suppression And Feedback Loops​

DetectionSuppressionModel stores bounded suppression windows plus JSON criteria such as host, source, or severity pivots.

  • Rule execution checks active suppressions before returning match candidates.
  • SIEM promotion with a rule_id also respects active suppressions and returns 409 when a matching event is intentionally muted.

DetectionFeedbackModel records the analyst verdict after an event has been promoted and investigated.

  • true_positive increments rule confirmation counters.
  • false_positive increments rule noise counters and can update the linked alert status to false_positive.
  • Feedback records optionally point to the promoted alert, linked case, and source SIEM log so tuning remains traceable.

SIEM Log Promotion​

POST /api/v1/siem/logs/{log_id}/promote turns a searched event into a first-class workflow object.

  • The backend extracts basic observables from the log body and raw payload.
  • Promotion creates or deduplicates an alert using the same dedup hash strategy as alert ingestion.
  • When create_case=true, the route also opens a linked case and appends a case timeline entry so the investigation path is preserved.
  • When rule_id is supplied, promotion links the alert/case back to the detection rule that produced the match and participates in suppression and feedback accounting.

This closes the loop between SIEM hunting and the IMS/triage surfaces: operators no longer need to manually recreate findings in the alerts or cases pages.

CorrelateEvents​

Finds relationships between events based on shared indicators.

class CorrelateEvents(AuroraTool):
    name = "correlate_events"
    description = "Correlate security events by shared indicators"
    
    input_schema = {
        "properties": {
            "event_ids": {"type": "array", "items": {"type": "string"}},
            "correlation_fields": {
                "type": "array",
                "items": {"type": "string"},
                "description": "Fields to correlate on (src_ip, dst_ip, user, hash)"
            },
            "time_window": {"type": "string", "default": "15m"}
        },
        "required": ["event_ids"]
    }
    
    async def _execute(self, event_ids, correlation_fields=None, time_window="15m"):
        correlated = await correlator.find_related(
            event_ids, correlation_fields, time_window
        )
        return {
            "correlated_events": correlated,
            "correlation_graph": build_graph(correlated),
            "total_related": len(correlated)
        }

Used by: Security Analyst

ExtractIOC​

Extracts Indicators of Compromise from raw event data using regex patterns and heuristics.

class ExtractIOC(AuroraTool):
    name = "extract_ioc"
    description = "Extract IOCs (IPs, domains, hashes, emails) from text"
    
    input_schema = {
        "properties": {
            "text": {"type": "string", "description": "Raw event data or log text"},
            "ioc_types": {
                "type": "array",
                "items": {"type": "string", "enum": ["ip", "domain", "hash", "email", "url", "cve"]},
                "description": "IOC types to extract (default: all)"
            }
        },
        "required": ["text"]
    }
    
    async def _execute(self, text, ioc_types=None):
        iocs = []
        
        patterns = {
            "ip": r'\b(?:\d{1,3}\.){3}\d{1,3}\b',
            "domain": r'\b(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z]{2,}\b',
            "md5": r'\b[a-fA-F0-9]{32}\b',
            "sha256": r'\b[a-fA-F0-9]{64}\b',
            "email": r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b',
            "url": r'https?://[^\s<>"{}|\\^`\[\]]+',
            "cve": r'CVE-\d{4}-\d{4,7}',
        }
        
        for ioc_type, pattern in patterns.items():
            if ioc_types and ioc_type not in ioc_types:
                continue
            matches = re.findall(pattern, text)
            for match in set(matches):
                iocs.append({"type": ioc_type, "value": match})
        
        return {"iocs": iocs, "count": len(iocs)}

Used by: Security Analyst

MitreMap​

Maps events and findings to MITRE ATT&CK techniques.

class MitreMap(AuroraTool):
    name = "mitre_map"
    description = "Map security findings to MITRE ATT&CK techniques"
    
    input_schema = {
        "properties": {
            "description": {"type": "string", "description": "Description of the observed behavior"},
            "indicators": {
                "type": "array",
                "items": {"type": "string"},
                "description": "Process names, commands, or behavior indicators"
            }
        },
        "required": ["description"]
    }
    
    async def _execute(self, description, indicators=None):
        # LLM-powered technique mapping
        techniques = await mitre_mapper.map(description, indicators)
        return {
            "techniques": [
                {
                    "id": t.id,
                    "name": t.name,
                    "tactic": t.tactic,
                    "url": f"https://attack.mitre.org/techniques/{t.id}",
                    "confidence": t.confidence
                }
                for t in techniques
            ]
        }

Used by: Security Analyst

Tool Flow Example​