Otto  background

Automox + Splunk SOAR

How to automate endpoint response across security and IT teams

Connect With Us

See for yourself how policy-driven IT Automation saves time and eliminates risk.

Automox is built for fast, scriptable remediation. With the new Splunk SOAR integration, you can extend that speed into automated workflows across both security and IT operations.

The integration started as a way to streamline internal incident response. The Automox Security Team saw an opportunity to bridge Automox’s endpoint management with Splunk’s automation and orchestration framework. Now, you can instantly retrieve detailed endpoint or organization data and take immediate action — whether remediating a threat or tagging a device for reallocation.

Think about any situation where every second counts: a suspected malware infection, a compromised device, or an insider risk alert. With Automox integrated into Splunk SOAR, analysts can immediately pull critical data from affected endpoints. That includes software install history, patch status, IP connections, and user activity. Fast access to this information improves decision-making and reduces the manual effort needed during investigations.

This app is now available to the broader security and IT community. Read on to see how you can use Automox with Splunk SOAR to strengthen incident response, cut manual overhead, and act confidently under pressure.

Why the Automox Security Team built it

Security operations teams face constant pressure to respond quickly. But repetitive manual tasks slow things down — switching tools to identify users behind IPs, gathering forensic data, or confirming whether behavior is suspicious or expected. Each step adds friction. Mistakes or delays during investigations can increase risk.

Internally, the  Automox Security Team uses Splunk SOAR to write playbooks that reduce that friction. That led to a natural question: What if Automox actions could trigger directly from within Splunk SOAR?

Now they can. With this integration, your playbooks can directly call Automox for data or take specific actions. That means fewer context switches and faster, more reliable responses.

Tackling these challenges directly improved Automox’s internal security posture and workflows — and motivated the Automox Security Team to build a solution for the broader community.

Automox + Splunk SOAR: Integration overview

The Automox app for Splunk SOAR connects endpoint management directly into your automated workflows. With it, you can:

Run Automox actions directly from SOAR alerts

  • Execute Automox Worklets™ on demand

  • Isolate endpoints (firewall or disable adapters)

  • Kill processes by PID or name

  • Stop services

  • Disable USB ports

  • Revoke active sessions

Collect evidence from affected devices

  • Retrieve process lists or file change history

  • View currently installed apps and install timestamps

  • Check recent IP connections

  • View historical user logins

Query device and organization-level data

  • Pull patch status and compliance data

  • Identify inactive or out-of-policy devices

This integration gives you direct control and insight into your endpoints from within Splunk SOAR — helping you move faster and act smarter.

Automating real-world workflows

One of the most useful things about this integration is that it isn't limited to just security incidents — you can also use it for day-to-day IT operations such as user off-boarding or keeping tabs on device health.

Auto-remediate Security Alerts with Automox Worklets

Trigger: Splunk alert (malware infection, misconfiguration, etc)

App Actions: get device by hostname, run policy

Purpose: Automate the application of a remediation script to affected endpoints. For example, for certain security alerts, you could run something custom or written by Automox (check out our macOS IR worklet here). The flexibility is endless here.

Diving in some more:

Here is how you might set up a playbook to triage an alert related to an endpoint:

Example flow chart for Splunk integration

With this playbook in mind, let's say you’re an analyst that gets an alert forwarded to Splunk SOAR about some sort of threat on an endpoint. The event coming from Splunk contains the hostname of the affected endpoint.

Message report from Splunk console

Because the playbook is configured to run automatically on these events, you can go to Splunk SOAR and confirm that it triggered using the deviceHostname from the alert. The action widget displays the output, showing the playbook ran successfully.

Log from Splunk console

First, the playbook runs the get device by hostname action using the deviceHostname field from the artifact to retrieve the device ID. That ID is then passed to the run policy action.

In the Automox console, you can verify the action by checking the device’s Activity Log — the script appears there as successfully executed. You can also confirm the output directly on the endpoint, showing that the DFIR script ran as expected.

Automox Activity Log
Event Viewer File Browser

For even greater flexibility, consider configuring the Worklet to upload specific artifacts, like the export mentioned previously, to a cloud storage solution. This would provide security teams with convenient access for analysis.

User off-boarding automation

Trigger: HRMS or IDP user termination log

App Actions: list organization users remove user from account, list devices, update device

Purpose: Automated user deprovisioning while prepping devices for reallocation. For example, as part of your offboarding automation, you could use remove user from account and then update device to apply a tag like “awaiting-wipe,” reducing the risk of orphaned accounts and keeping inventory clean.

Diving in some more:

Let's say you're ingesting logs from your HRMS or your IDP and you have an alert configured to fire when there is an event pertaining to a user being terminated. You could use the Automox app to further automate your offboarding process by removing the user from your Automox console (using something like their email address) and/or even set an action to update the user's device to set a tag like "awaiting-wipe" for example.

Example Splunk flow chart for user off-boarding

The playbook triggers when an artifact — such as a log entry tied to a user termination event — comes into Splunk SOAR. The workflow follows these steps:

  1. Retrieve users: The playbook pulls a list of all users in the organization.

  2. Match and remove: If the email address in the log matches a user in the Automox console, that user is removed. If no match is found, the playbook adds a note indicating the user couldn't be located.

  3. Identify and tag devices: After removing the user, the playbook lists all devices in the organization. If any device's last logged-in user matches the terminated user's email — even in different formats (e.g., HOSTNAME\hsmith and hsmith@automox.com) – the device is tagged with awaiting-wipe. If there’s no match, another note is added to inform the analyst.

There are multiple ways to build a workflow like this. Instead of relying on a log entry, you could design a version that prompts an analyst to input an email address, then uses that input to remove the user.

This structure isn’t one-size-fits-all. For example, if your devices have multiple user accounts, tagging them as awaiting-wipe may not be the right move. You might prefer a different off-boarding approach, such as running a Worklet to clean up the user account from the device. You can tailor the playbook’s complexity to fit your environment.

Unauthorized software detection and cleanup

Trigger: Scheduled or alert-driven scan

App Actions: list devices, get device software, run policy

Purpose: Enforce software policy and remove shadow IT or risky applications. For example, you could build a playbook that uses list devices and get device software to find endpoints running unapproved software, then automatically trigger a run policy action to execute a Worklet that removes it.

Stale endpoint monitor

Trigger: Daily scheduled playbook (or Splunk Search)

App Actions: list devices, update device

Purpose: Identify and track endpoints that may be offline, lost, or need intervention. For example, you could query Automox for devices with a last check-in older than 30 days and tag them for IT review.

Bringing Security and ITOps together

Thanks for making it this far! To wrap things up, here are the key takeaways:

  • Security + IT automation in one
    The Automox SOAR app connects security operations and IT workflows, enabling unified, automated responses across both areas.

  • Faster, more confident responses
    Automating tasks like software audits, user offboarding and policy/Worklet executions = reduced investigation time and faster response times.

  • Ready-to-Use actions
    Built-in capabilities make it easy to create impactful playbooks right out of the box.

Want to see it in action? Check out the app on Splunkbase, or reach out directly in the Automox community. We’d love to see how this integration accelerates incident response — and IT operations — for teams like yours.