Custom Module Examples

This page introduces four custom Module examples. They show how external logs or raw alerts become ASP Cases, Alerts, and Artifacts.

For testing, use Mock Data or raw alert samples under backend/custom/data/modules/. In production, the source is usually real SIEM / EDR / mail-system logs. This page does not focus on how logs are generated; it focuses on how alert rules, alert ingestion, and Module scripts connect.

Common flow

All examples follow the same idea:

log / raw alert
  -> SPL / ES|QL / alert rule
  -> alert ingestion writes Redis Stream
  -> custom Module consumes Stream
  -> creates Case / Alert / Artifact

• Log source: use Mock Data in testing; use real SIEM / EDR / mail-system logs in production.
• Alert ingestion: Splunk Webhook, Kibana Webhook, or ELK Index Action.
• Module validation: use Refresh / Validate in Custom Console to confirm the Module is loaded and inspect Stream status.
• Output: check generated Cases in Case, then open Case detail to review Alert and Artifact.

1. EDR Vssadmin Delete Shadows

Item	Value
Module	backend/custom/modules/edr_vssadmin_delete_shadows.py
Stream	EDR-01-HOST-Vssadmin-Delete-Shadows
Scenario	Detects vssadmin.exe delete shadows, a common recovery-inhibition behavior used by ransomware.

Alert query example

FROM siem-host-events
  | WHERE process.name == "vssadmin.exe"
  | WHERE risk_score >= 80
  | WHERE process.command_line LIKE "*delete*shadows*"
  | SORT @timestamp DESC

Alert ingestion

Write matched events to Redis Stream through Kibana Webhook or ELK Index Action. The Stream name must match the Module STREAM_NAME:

EDR-01-HOST-Vssadmin-Delete-Shadows

What the Module does

This Module extracts:

• Host name and host IP.
• User name.
• Process name, parent process, and command line.
• File path and file hash.

It then generates a correlation UID and calls create_alert_with_context() to create or associate Case, Alert, and Artifact. The generated Case represents an investigatable ransomware precursor behavior, not a single log line.

2. AWS IAM Privilege Escalation via AttachUserPolicy

Item	Value
Module	backend/custom/modules/aws_iam_privilege_escalation_attach_user_policy.py
Stream	Cloud-01-AWS-IAM-Privilege-Escalation-via-AttachUserPolicy
Scenario	Detects high-risk IAM AttachUserPolicy operations that may lead to privilege escalation.

Alert query example

FROM siem-aws-cloudtrail
  | WHERE event.action == "AttachUserPolicy"
  | WHERE event.risk_score > 80
  | WHERE event.outcome == "success"
  | WHERE
      requestParameters.policyArn IN
        (
          "arn:aws:iam::aws:policy/AdministratorAccess",
          "arn:aws:iam::aws:policy/IAMFullAccess"
        )
  | SORT @timestamp DESC

Alert ingestion

Write matched CloudTrail events to Redis Stream through Kibana Webhook or ELK Index Action. The Stream name must match the Module STREAM_NAME:

Cloud-01-AWS-IAM-Privilege-Escalation-via-AttachUserPolicy

What the Module does

This Module extracts:

• AWS account and region.
• Actor user, ARN, principal ID, and access key ID.
• Target user.
• Attached IAM policy ARN.
• Source IP and user agent.

It then creates a Case / Alert based on outcome, risk score, and policy type, and splits users, account, policy, source IP, and related values into Artifacts for investigation and enrichment.

3. User Reported Phishing Mail

Item	Value
Module	backend/custom/modules/mail_user_report_phishing.py
Stream	Mail-01-User-Report-Phishing-Mail
Scenario	Processes user-reported suspicious mail and creates a mail-security investigation Case.

Input source

This example is not generated by the SIEM Mock log generator. For testing, use:

backend/custom/data/modules/mail_user_report_phishing/raw_alert_*.json

In production, the source can be a mail gateway, user-reporting system, SOAR, or mail alert from SIEM.

Alert ingestion

Send mail raw alerts to Redis Stream through Splunk Webhook, Kibana Webhook, or any other Stream-writing integration. The Stream name must match the Module STREAM_NAME:

Mail-01-User-Report-Phishing-Mail

What the Module does

This Module extracts:

• Sender, recipient, and reporter.
• Subject and Message ID.
• URLs and domains.
• Attachment filenames and hashes.

It then creates a phishing-related Case / Alert and splits email addresses, URLs, domains, attachments, and hashes into Artifacts. This example shows that non-SIEM logs can also enter Modules through a unified raw alert shape.

4. NDR Brute Force: Failed Logins Followed By Success

Item	Value
Alert name / Stream	NDR-01-Brute-Force-Multiple-Failed-Logins-Followed-By-Success
Log source	Authentication logs from siem-network-traffic. Use Mock Data for testing, and real network or authentication logs in production.
Scenario	The same source.ip / user.name has multiple failed logins followed by a successful login, indicating possible successful brute force.

Alert query example

index=siem-network-traffic event.category=authentication (event.action=login_failed OR
  event.action=login_success)
  | search
      [search index=siem-network-traffic event.category=authentication event.action=login_failed
       | stats count AS failed_count BY source.ip, user.name
       | where failed_count >= 5
       | join source.ip, user.name
           [search index=siem-network-traffic event.category=authentication event.action=login_success
            | stats count AS success_count BY source.ip, user.name]
       | fields source.ip, user.name]

Splunk Action / Alert ingestion

Save the SPL as a Splunk Alert and configure a Splunk Webhook Action:

• Select For each result as the trigger so each result is sent separately.
• Set Webhook URL to ASP: https://<asp-host>/api/webhook/splunk/.
• Set Alert name to:

NDR-01-Brute-Force-Multiple-Failed-Logins-Followed-By-Success

Splunk Webhook uses search_name as the Redis Stream name and writes result as the raw alert. Therefore, the generated Module should use the same value as STREAM_NAME.

Generate the Module with Module Creator

This example does not currently have a built-in Module script. Use the Module Creator Skill from the ClaudeCode plugin to generate one from the SPL output fields.

Recommended input for Module generation:

• Module name: NDR Brute Force Multiple Failed Logins Followed By Success
• STREAM_NAME: NDR-01-Brute-Force-Multiple-Failed-Logins-Followed-By-Success
• Key fields: source.ip, user.name, event.action, event.outcome, failed_count, success_count
• Expected Case: a suspected successful brute-force login.
• Expected Artifacts: source IP, user name, authentication action, related host or session fields.

After generation, place the script in:

custom/modules/

Then run Refresh / Validate in Custom Console → Modules, confirm the Module loads successfully, and check whether the Redis Stream with the same name has messages written by Splunk Webhook.

Run and validate

1. Place Module files in custom/modules/.
2. Run Refresh / Validate in Custom Console.
3. Confirm the Module list contains the expected STREAM_NAME.
4. Start the Module Worker:

python manage.py run_agentic_module_worker

5. Write raw alerts through alert ingestion or a test script.
6. Check generated results in Case.

Related documentation

• Mock Data
• Alert Ingestion
• Module Development
• Custom Console
• Custom Playbook Examples