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: logrhythm, malware, siem, sql injection
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."