AlphaSOC for Splunk
Overview
The AlphaSOC for Splunk app surfaces AlphaSOC findings directly within Splunk.
Use the built-in dashboards to triage threats, investigate entities, and pivot
to raw OCSF findings — all without leaving Splunk. The app also includes the
alphasoc generating command for running targeted searches over OCSF telemetry
stored in AlphaSOC's data lake.
Installation
Within Splunk Enterprise or Splunk Cloud, click into Apps -> Find more apps
and search for alphasoc to find and install AlphaSOC for Splunk.
The app is also available from Splunkbase here.
Configuration
To connect the AlphaSOC for Splunk app to your Analytics Engine, generate an API key in the AlphaSOC Console and configure it in Splunk. Follow the steps below.
- Navigate to the AlphaSOC Console.
- Go to the Credentials section and click API Keys.
- Click on New API key button and, optionally, provide a description for
the new key.
- Click Create to create the API key.
- Copy the generated API key and keep it in a secure place, as you will need it
to configure the integration with Splunk.
- In the AlphaSOC for Splunk app, go to the Settings tab.
- Click on the Analytics Engine. Paste your AlphaSOC API URL under API
URL and the copied API key into the designated field under API Key.
- Click Save to apply the changes.
- Still in the Settings tab, click on Data Location. Select the Splunk
index containing your AlphaSOC findings from the dropdown (e.g.,
alphasoc_findings).
Investigating Threats
The AlphaSOC for Splunk app provides three views that form an investigation workflow — from high-level threat overview down to raw OCSF findings.
Threat hunter
The Threat Hunter dashboard is the default landing page. It displays a prioritized table of all entities with active detections in your environment.
Each row represents an entity (IP address, hostname, AWS ARN, Kubernetes service account, etc.) and includes:
- Severity — highest severity level assigned to the entity's findings.
- Entity — the identifier of the affected host or account.
- Domain — event domain: Network, System, or Application.
- Top Detection — the name of the highest-priority detection for this entity.
- Last Seen — timestamp of the most recent finding.
- Trend — sparkline showing finding volume over the selected time range.
- Detections — number of distinct detection rules that fired.
- Findings — total count of findings associated with the entity.
Use the filter bar at the top to narrow results by time range, event domain, entity, detection type, and minimum severity. Rows are color-coded by severity — Critical, High, Medium — so the most urgent items stand out at a glance.
MITRE ATT&CK
The MITRE ATT&CK dashboard maps the same findings onto the MITRE ATT&CK Matrix for Enterprise. Columns represent tactics, and each cell lists the techniques AlphaSOC has observed in your environment.
Use this view to assess attacker coverage across the kill chain rather than triaging individual entities.
Findings explorer
From the Threat Hunter table, click on any entity row to open the Findings Explorer. This is the investigation dashboard for a single entity.
Investigation details
The left panel summarizes the entity under investigation:
- Entity identifier — the IP address, hostname, or account (e.g.,
172.25.163.137). - Severity — the highest severity across all findings for this entity.
- Total findings — aggregate count of findings.
- First seen / Last seen — the time window over which activity was observed.
- Event domain — Network, System, or Application.
- Unique entities — count of distinct entities involved.
- Tactics and Techniques — MITRE ATT&CK tactics and techniques mapped to the entity's findings.
Summary cards
Four cards across the top provide at-a-glance counts: Entities, Detections, Findings, and Techniques. Use these to gauge the scope of the investigation — how many detection rules fired, how many total findings were generated, and how many ATT&CK techniques are in play.
Activity timeline
The timeline chart plots finding volume over the selected time range. Use it to identify spikes, sustained activity, or beaconing patterns. The legend indicates the detection type (e.g., "C2 communication attempt indicating infection").
Severity distribution
The donut chart breaks down findings by severity level. A chart dominated by Critical indicates an entity that needs immediate attention.
Observables, detections, entities, and samples
The tabbed section at the bottom provides the detailed breakdown:
- Observables — lists every observable associated with the entity's findings: queried hostnames, destination IPs, destination ports. Each row shows severity, first/last seen timestamps, the observable value, its type (Hostname, IP Address, Port), and the number of findings it appears in.
- Detections — groups findings by detection name.
- Entities — lists all entities involved.
- Samples — shows detailed information about the findings.
Pivoting to raw findings
Each observable row includes an Actions menu (three-dot icon). Click it to open the raw OCSF findings in Splunk Search.
This opens a pre-populated search that retrieves the AlphaSOC OCSF findings matching that observable. Each event in the results includes:
- Event metadata — event code, timestamps, and source identifiers.
- Detection details — detection name, severity score, confidence level, and MITRE ATT&CK mapping.
- Observables — the full set of observables: queried hostnames, resolved IPs, destination endpoints, ports, and protocols.
- Evidence and context — supporting data such as DNS query types, response codes, connection metadata, and threat intelligence enrichment.
Use the Splunk field sidebar to filter, aggregate, or correlate across the dataset. From here you can build additional searches, create alerts, or export the data into your existing workflows.
AlphaSOC Data Lake Search
With the alphasoc command you can search the OCSF telemetry and threat
evidences stored in AlphaSOC's data lake without leaving Splunk Search. Use it
independently from the dashboards above when you need to query raw data by
specific OCSF fields.
alphasoc is a generating command: it must appear at the beginning of your
search pipeline, prefixed with a pipe (|), and its first argument is a
subcommand that selects what to query. The time range comes from the Splunk time
picker.
| alphasoc event [class_name=<class>] [metadata.product.name=<source>] [<filter_expression>]
| alphasoc evidence [evidence_type=<type>] <filter_expression>
| alphasoc activity [evidence_type=<type>] [metadata.product.name=<source>] <filter_expression>
| alphasoc help
alphasoc has four subcommands (the subcommand name is case-insensitive):
event— query raw OCSF event telemetry.evidence— query the threat evidences AlphaSOC flagged.activity— query threat evidences joined with the source identity that produced them.help— open this documentation in your browser.
Query syntax
The filter grammar and value rules below apply to the event, evidence, and
activity subcommands.
Filters are field-value pairs on OCSF field paths; combine them with AND /
OR operators and parentheses.
ANDis implicit: adjacent filters without an operator combine withAND. For example,device.ip=10.0.0.5 dst_endpoint.port=443is equivalent todevice.ip=10.0.0.5 AND dst_endpoint.port=443.ANDhas higher precedence thanOR. Use parentheses to make grouping explicit when mixing both.- Quote values containing spaces or
=.
Options
Each subcommand supports its own set of options, described in its section below. Options can appear before or after filter terms.
To match more than one value, repeat the option and join the terms with OR,
for example class_name=dns_activity OR class_name=network_activity. OR may
only join values of the same option; the command rejects an option OR-ed with
a filter field, such as class_name=dns_activity OR device.ip=10.0.0.5.
When combining an OR group with further filter terms, parenthesize the group:
write (class_name=dns_activity OR class_name=network_activity) device.ip=10.0.0.5, not class_name=dns_activity OR class_name=network_activity device.ip=10.0.0.5.
Streaming and limits
The command streams results: events appear in Splunk as they arrive from the data lake. A server-side limit may cap a large result set, in which case you receive a partial result set. To reduce the result set, use a shorter time range or more specific filters.
event
Returns ingested event telemetry, normalized to OCSF.
| alphasoc event [class_name=<class>] [metadata.product.name=<source>] [<filter_expression>]
With no filter, event returns all events in the selected time range.
Options
class_name— OCSF event classes. Accepts Title Case, snake_case, and dash-separated formats. Examples:"DNS Activity","dns_activity","dns-activity".metadata.product.name— data origins. See AlphaSOC data origins documentation for the complete list.
Supported OCSF classes: DNS Activity, Network Activity, HTTP Activity, API Activity, Process Activity, Authentication, Account Change.
Queryable fields
Field paths follow OCSF v1.5.0.
| OCSF Field | Description | Example |
|---|---|---|
device.ip | Device IP address (IPv4; supports /16, /24, /32 CIDR) | 10.0.0.0/24 |
device.hostname | Device hostname | workstation-01 |
device.uid | Device identifier (e.g., CrowdStrike AID) | 09e8771fc488477d9cddb61b5fd32c6c |
device.mac | Device MAC address | 00:1A:2B:3C:4D:5E |
actor.user.name | User name | alice |
metadata.tenant_uid | Tenant UID that matches AlphaSOC's dataScope | aws:123456789012:us-east-1:vpc-1234567890 |
query.hostname | DNS query fully qualified domain name (FQDN); supports a leading wildcard | *.google.com |
query.type | DNS query type | A |
src_endpoint.ip | Source IP address (IPv4; supports /16, /24, /32 CIDR) | 192.0.2.10 |
dst_endpoint.ip | Destination IP address (IPv4; supports /16, /24, /32 CIDR) | 8.8.8.8 |
dst_endpoint.port | Destination port | 443 |
connection_info.protocol_name | IP protocol | tcp |
http_request.http_method | HTTP client request method | GET |
http_request.user_agent | HTTP client user agent | Mozilla/5.0 (X11; Linux x86_64) |
tls.certificate.fingerprints[0].value | TLS server certificate fingerprint | 0db6495611891de35650a18ad91002845f9cc6bc |
tls.certificate.subject | TLS server certificate subject | CN=example.org |
tls.certificate.issuer | TLS server certificate issuer | CN=GTS CA,O=Google Trust Services,C=US |
Examples
Fetch all events in the selected time range:
| alphasoc event
Filter events by device IP:
| alphasoc event device.ip=10.0.0.5
Combine filters with implicit AND (both forms are equivalent):
| alphasoc event device.ip=10.0.0.5 dst_endpoint.port=443
Filter by event class and device:
| alphasoc event class_name=dns_activity device.ip=10.0.0.5
Match multiple event classes by repeating the option with OR:
| alphasoc event class_name=dns_activity OR class_name=network_activity
Parenthesize the OR group when combining it with other filters:
| alphasoc event (class_name=dns_activity OR class_name=network_activity) device.ip=10.0.0.5
Combine options and filters with boolean logic:
| alphasoc event class_name=dns_activity device.ip=10.0.0.5 AND (query.hostname=example.org OR dst_endpoint.port=443)
Query a specific data origin:
| alphasoc event metadata.product.name=aws-route53 query.hostname=example.org
evidence
Returns the individual indicators AlphaSOC observed and flagged. Each evidence
record is an OCSF event carrying an evidences[] array of those indicators.
| alphasoc evidence [evidence_type=<type>] <filter_expression>
The evidence subcommand requires at least one filter; it cannot run
unfiltered.
Options
evidence_type— restricts which evidence types are searched. Accepted values:dns,ip,http,tls,audit. This changes results: an unfiltered value such as a hostname can match both DNS and HTTP evidences.
Queryable fields
Field paths follow OCSF v1.5.0.
| OCSF Field | Description | Example |
|---|---|---|
query.hostname | DNS query fully qualified domain name (FQDN); supports a leading wildcard | *.google.com |
query.type | DNS query type | A |
src_endpoint.ip | Source IP address (IPv4; supports /16, /24, /32 CIDR) | 192.0.2.10 |
dst_endpoint.ip | Destination IP address (IPv4; supports /16, /24, /32 CIDR) | 8.8.8.8 |
dst_endpoint.port | Destination port | 443 |
connection_info.protocol_name | IP protocol | tcp |
http_request.user_agent | HTTP client user agent | Mozilla/5.0 (X11; Linux x86_64) |
url.url_string | Full URL | https://example.org/path |
tls.certificate.fingerprints[0].value | TLS server certificate fingerprint | 0db6495611891de35650a18ad91002845f9cc6bc |
tls.certificate.subject | TLS server certificate subject | CN=example.org |
tls.certificate.issuer | TLS server certificate issuer | CN=GTS CA,O=Google Trust Services,C=US |
tls.ja3_hash.value | JA3 TLS fingerprint | 0b2a5b08a7c44adaeaa1c0d29493c409 |
tls.ja3s_hash.value | JA3S TLS fingerprint | 254c31292ed05b84addc077fe6cee283 |
process.file.name | Process file name | powershell.exe |
process.file.hashes[].value | Process file hash (MD5 or SHA-256) | d41d8cd98f00b204e9800998ecf8427e |
The url.url_string value must be a full, parseable URL; matching ignores
query strings and fragments.
Examples
Query threat evidences for a hostname:
| alphasoc evidence query.hostname=example.org
Combine filters with implicit AND:
| alphasoc evidence dst_endpoint.ip=8.8.8.8 dst_endpoint.port=443
Restrict the search to DNS evidences:
| alphasoc evidence evidence_type=dns query.hostname=example.org
Filter by JA3 fingerprint:
| alphasoc evidence tls.ja3_hash.value=0b2a5b08a7c44adaeaa1c0d29493c409
Filter by process file hash:
| alphasoc evidence process.file.hashes[].value=d41d8cd98f00b204e9800998ecf8427e
activity
Returns threat evidences joined with the source identity observed for the same
query: which device resolved example.org, and as which user. Each record shares
the evidences[] shape of the evidence subcommand, with the source reported
under device and actor.user.
| alphasoc activity [evidence_type=<type>] [metadata.product.name=<source>] <filter_expression>
The activity subcommand requires at least one filter; it cannot run
unfiltered.
The search still returns records without an observed source (their device and
actor are empty). Filtering on a source field (device.*, actor.user.name,
metadata.tenant_uid, or the metadata.product.name option) restricts results
to records with a source.
Options
evidence_type— same as theevidencesubcommand. Accepted values:dns,ip,http,tls,audit.metadata.product.name— restricts to sources observed by the given data origins. See AlphaSOC data origins documentation for the complete list.
Queryable fields
Source fields identify the device and user behind the evidence:
| OCSF Field | Description | Example |
|---|---|---|
device.ip | Source device IP address (IPv4; supports /16, /24, /32 CIDR) | 10.0.0.0/24 |
device.hostname | Source device hostname | workstation-01 |
device.uid | Source device identifier (e.g., CrowdStrike AID) | 09e8771fc488477d9cddb61b5fd32c6c |
device.mac | Source device MAC address | 00:1A:2B:3C:4D:5E |
actor.user.name | User name | alice |
metadata.tenant_uid | Tenant UID that matches AlphaSOC's dataScope | aws:123456789012:us-east-1:vpc-1234567890 |
You can also use all queryable fields of the evidence subcommand.
src_endpoint.ip remains an evidence field (the audit caller IP); use
device.ip for the source device.
Source fields and evidence fields combine with AND only; the command rejects
an OR across the two groups, such as device.ip=10.0.0.5 OR query.hostname=example.org.
Examples
Find who resolved a hostname:
| alphasoc activity query.hostname=example.org
Restrict the search to a subnet:
| alphasoc activity device.ip=10.0.0.0/24 query.hostname=example.org
DNS evidences observed by a specific data origin:
| alphasoc activity evidence_type=dns metadata.product.name=aws-route53 query.hostname=example.org
help
Returns a link to this documentation without running a query:
| alphasoc help
Learn More
AlphaSOC for Splunk is free to download and install from Splunkbase, as below.