Some of you may already have heard of Sigma
, a generic approach for signatures used in SIEM
systems. Its main purpose is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.
Today I would like to describe another use case that helps us build the best possible signatures for any application.
In typical security monitoring projects, people integrate different log sources and threats/use cases they want to monitor in these logs. The selection of the log sources is determined by importance, availability and operational requirements. The central question is:
“What do I want to detect?”
There are several white papers and guides for the most common log sources like the Windows Eventlog. What you have to do is to read the documents, extract the interesting detection methods and define searches, panels and dashboards in your SIEM system. One of the main purposes of Sigma is to relieve you from this time consuming process. These public descriptions of detection methods are already part of Sigma or will be integrated by one of the contributors.
But today I’d like to point out a different use case that is less obvious but very useful.
The Best Possible Monitoring
Security analysts try to define useful searches and statistical analyses on the log data from all different log sources. They typically follow the public guides and create many different “failed logon” rules for all kinds of operating systems and applications.
But what happens when start integrating log sources and types that are not covered by public guidelines?
There are different approaches to this problem:
- Cover failed authentication attempts
- Monitor any failure event (with a base-lining)
- Use statistic deviations (many new events of a certain type)
- Look through the log data and select interesting messages
- Talk to the application owners / administrators (often rather disappointing)
- Talk with the application developers (in case of inhouse development)
All of these methods are valid and can help you setup useful searches on the available data. However, in order to create the best possible signatures we have to consider the following:
- The most interesting and relevant fault conditions do not happen under normal conditions and therefore do not appear in everyday log data (the log data we have to select interesting events from)
- Developers know the rarest or most relevant error conditions and the corresponding error IDs and messages
- All possible error messages of that application appear in its source code
Imagine that we can extract the most interesting messages that the application is able to generate and define rules for these conditions. Imagine that this process is an easy task that any developer is able to perform.
Well, we have at our fingertips all the tools that are needed.
An Example: vsftpd
Let’s make this approach clearer. Under optimal conditions we ask the developers to extract the most relevant or abnormal error messages that the applications produces under conditions that indicate a manipulation or attack. Alternatively, we can do it ourselves and cross-check the results with the available log data to avoid false positives.
I checked the source code of the FTP server ‘vsftpd’ for error messages that indicate rare error conditions and fatal failures.
The resulting Sigma rule looks like this:
title: Suspicious VSFTPD error messages
description: Detects suspicious VSFTPD error messages that indicate a fatal or suspicious error that could be caused by exploiting attempts
author: Florian Roth
- 'Connection refused: too many sessions for this address.'
- 'Connection refused: tcp_wrappers denial.'
- 'Bad HTTP verb.'
- 'port and pasv both active'
- 'pasv and port both active'
- 'Transfer done (but failed to open directory).'
- 'Could not set file modification time.'
- 'bug: pid active in ptrace_sandbox_free'
- 'PTRACE_SETOPTIONS failure'
- 'weird status:'
- "couldn't handle sandbox event"
- 'syscall * out of bounds'
- 'syscall not permitted:'
- 'syscall validate failed:'
- 'Input line too long.'
- 'poor buffer accounting in str_netfd_alloc'
After some testing we can now share the rule with the world in order to build a large signature database for the all different types of applications and services.
We could also try to convince developers to provide Sigma rules with their applications to help organisations establish the best possible monitoring of their software. I was thinking about an error message extractor that would parse a software project and extract error message strings that contain certain keywords like “failure”, “fatal”, “permission denied”, “refused” and others to facilitate this process for the rule writer.
If you want to support the project, create a pull request or send me your rules as gists or via pastebin to @cyb3ops. You could also become a contributor by providing a new backend for the rule converter “Sigmac” or become a member of our Slack team for threat hunters (references required).