Who Became Root?

This week you may have noticed the introduction of a new feature – the sudoer field.

This animated screen capture shows an example of how Threat Stack is able to show the actual user of a command executed using sudo. Normally all commands run with sudo will only show the user as root, however Threat Stack ties this to the user using sudo.

When a user escalates their privileges for valid or nefarious purposes, they become the anonymous root user. Until this week Threat Stack users had to correlate multiple events to figure out who root was, leveraging the TTY Timeline and Process Tree views. Was Alice performing maintenance as expected? Who is touching the SSL private certificate and why?

The Alert Pipeline also was not able to tell who root really was or whether someone simply logged in as root. This made it difficult to blacklist or whitelist actions performed by a user regardless of their privileges at the time.

Threat Stack’s platform now inspects audit events where user=”root” as they come into the platform to see whether a login event had previously been observed for that user. This happens in real time as data flows onto the platform. This event field is included in the event details in Search and Alerts pages, and the user field is updated to show both “root” and the original user name (ex., “root (alice)”).

This allows Threat Stack users to perform actions such as:

  • Create an Alert Rule that blacklists any time someone runs a command other than sv as root, but whitelists Bob: event_type = ”start” and type = ”start” and command != “sv” and user = “root” and sudoer! = “bob”
  • Find all of the activity performed by Bob after they ran sudo: sudoer = ”bob”
  • Find all sudo activity across all users: sudoer != null
  • Find all outbound network activity performed with escalated privileges and all login events: event_type = ”login” or (event_type = ”audit” and type = ”connect” and sudoer != null)

In addition, when you are searching for a user in Threat Stack you will now also be searching across the sudoer field. For example, user = “alice” and command = “psql” will now include all PostgreSQL client runs regardless of whether Alice ran the command with sudo.

If you only want to see Alice’s non-sudo activity, then you can still do user = “alice” and sudoer = null

The sudoer field provides a complete picture of the tactical event, giving you all the information necessary to make an informed response decision. This highlights the importance of domain intelligence and context when deploying a detection solution. The above use cases demonstrate critical IDS, incident response, and hunting workflows, which are often impaired by detection tools stopping at only providing dead end search results that don’t tell the whole story.

For more information and a full description of all the features and how to use them, please visit our knowledgebase article. As always, the products team would love to hear any feedback you have.