Posts tagged: 'malware'

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/malware/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

 
 

Professional Malware

There is an adage in physical security that criminals will go for the lowest hanging fruit — if a car parked on the street has a security system (denoted by a blinking light), it will be fine when next to a model without one. So the cost-effective strategy is to stay just ahead of the weakest competition. Ten years ago, this held true in information security, when the field was still a large unknown for many organizations, and criminals didn’t need to work particularly hard to compromise an unprotected one. But organizations slowly began catching up to best security practices with an expansion of security devices throughout networks: moving beyond just anti virus to add full endpoint monitoring with virtualized malware sandboxes; beyond a single firewall to intrusion detection systems; and beyond disparate monitoring of multiple devices to centralized security information and event management.

But in this rapidly evolving environment, the attackers didn’t just give up — they became more professional. As a result, malware tools have reached commercial-grade quality. In particular, modularity, first introduced several years ago, now allows variants to be customized to the victim.

The Zeus Trojan, now one of the older pieces of malware (developed nearly 10 years ago), became one of the earliest to be customized in this way after its source code was released in 2010. At first, Zeus was primarily used to target financial institutions. But as they ramped up security, attackers moved to pilfering vulnerable business payrolls. Most recently, malware authors have gone after large retailers payment systems, stealing credit card information.

The introduction of malware loaders, with the ability to covertly pull down any program that the attacker chooses, allowed malware authors to share their best features, giving criminals had the ability to greatly accelerate their progress. Smoke Loader, now a few years old, is a prime example. While investigating a machine that was exfiltrating passwords a couple years ago, I noticed the traffic pattern matched another piece of malware, Carberp. Further analysis showed that the password grabbing function was placed into Smoke Loader. Just as exploit kits customized their payload depending on their victim’s vulnerabilities, botnet operators could customize their control over their bots.

Smoke Loader Interface

The latest assessment of BlackEnergy shows that it now includes modules for nearly any feature an attacker would want — the ability to target different operating systems (including routers), launch DoS attacks, read BIOS details from the motherboard, and decrypt or destroy data. More importantly, these tools are being used by attackers with significant infrastructure and skill to target organizations like NATO and government agencies. And most alarmingly, some BlackEnergy modules target critical infrastructure such as energy and water sectors.

Information security divisions will be facing increased complexity and professionalism in attacks. Simply buying and deploying a security device is not going to protect an organization — to do so requires utilizing the defense’s one major asset — homefield advantage. By understanding their own network, an security operations team can use Cyber Discovery techniques to find the unusual activity that criminals will inevitably generate. This requires significant effort, but defenders must evolve along with their adversaries.

Tags: ,

none | SecuritySIEM

 
 

Malware Analysis — Betabot variant

{Collaboration by: Michael Logoyda, Greg Foss, Matt Willems, and Mark Vankempen}

A phishing email received by LogRhythm Labs, originating from a fake facebook email address (no-reply@facebook-mail.com), encourages the recipient to click on the link to download a ‘private photo archive’.

phish-email

Figure 1 : Phishing email

Following the link navigates the default browser to hxxp://sv-poesel.de/get_photo.php, initiating a download of ‘private_photo_archive.zip’ (md5 => 3a1c8aa265732bb21e3a105c4f50ee33). Decompressing the file presents an executable ‘private_photo_archive.exe’ (md5 => c35f18a4e4bd4c15f15e8c66f8293cce).

Figure 2 : private_photo_archive.zp properties

The file is packed, and attempting to run the sample through a debugger or inside a sandbox will cause the program to halt execution and exit. PE Explorer was used to further examine and unpack the file and view its contents, which uncovered the following malicious actions:

  • Evaluates the OS license to determine if the host is an unlicensed VM and thus a potential sandbox environment.
  • Also checks file access across the OS for sandbox evidence
  • Hijacks the currently installed AntiVirus software and runs as a mirror process in memory
  • Attempts to gather stored account credentials from popular FTP clients
  • Attempts to steal the Microsoft License, if valid
  • Communicates using popular User Agent Strings to avoid network-layer detection
  • Erases itself and resides in memory either injected into or masquerading as a legitimate process following execution.

When launched, the executable disappears without any visible effect — in actuality, the malware hijacks another legitimate process if available or spawns the WerFault.exe process. Interestingly, if the host is running AntiVirus software that does not detect the threat, the malware hijacks and hides behind the AV process. This was observed when running the malware using Avast AntiVirus (which has since been updated and now accurately detects the malware).

Figure 3 : Hijacking and hiding behind Avast

The malware makes several registry changes before disabling and then corrupting the Windows Firewall configuration — any attempts to re-enable the firewall result in error messages.

Figure 4 : Trying to enable the firewall resulting in an error

Next a scheduled task is set…

Figure 5 : Scheduled tasks

…that proactively disables Windows Defender — evident when comparing the scheduled tasks before and after the malware was launched.

Figure 6 : Removing Windows Defender from scheduled tasks

The user’s home directory contents are also corrupted, but it’s not clear why this occurs.

Figure 7 : Corrupted home folder error

The process in its entirety running on a host with no AntiVirus installed can be viewed easily using ProcDOT:

Betabot Malware Activity

click to enlarge

Figure 8 : Malware propagation

ProcDOT also shows outbound communication initiated when the malware is run on a host running AntiVirus:

Figure 9 : Outbound HTTP communication

When launched, beaconing is initiated from the infected client over HTTP POSTs to ‘nigazz.com’ . It should be noted that the IP is not preloaded and a DNS request is required. In this case, the IP resolves to Russian IP 62.152.39.53. The POSTs use port 80, URI path ‘/neg/order.php’, and payloads that contain standard url encoding with about 700B of hex data that appears to have obfuscated or encrypted values. The server then responds with about 150B of binary data — probably instructions.

Figure 10 : HTTP POST request

The beacons occur over a periodic interval of 10 minutes, which is clearly visible in LogRhythm Network Monitor.

Figure 11 : Periodic communication

Twelve hours after the initial infection, the beacon changed to ‘niggazz.com’, also hosted on the same Russian IP.

Based on the network traffic and open source research, it’s clear that the infected machine is part of a botnet — silobreaker.com identified the botnet as Betabot on Nov 25, 2013 with the domain being hosted from Ukraine (194.28.173.217). It should be noted that well known Zeus variants were hosted on that same IP within a few days.

Since late November, the server has changed its physical location to Russia, the malware itself continues to evade detection AV detection, and there is little other information available — as of 2014-01-16, only Websense ThreatSeeker identifies the domain as malicious out of all URL Scanners used on VirusTotal. This malware still poses a very good chance of going undetected and poses a credible threat.

Both LogRhythm System Agent and LogRhythm Network Monitor collect evidence of the beaconing and can be used for gathering and connecting evidence of infection. After collecting indicators, the activity can be blocked via IPS or Firewall. Infected machines need to be completely wiped — there is little chance of completely removing the virus otherwise.

Figure 12 : Beaconing evidence in the logs

Tags: , , , , ,

none | Security

 
 

Connecting the Dots

This year I was fortunate enough to be able to attend the Black Hat 2013 conference in Las Vegas. The opening keynote by General Alexander set the mood for what I think will be a common trend throughout the rest of conference this year, connecting the dots.  It was a heckle filled talk that left the General unfazed while he kept restating in different ways how we need to “connect the dots” across different dimensions of information to keep our country safe and failing to do so… essentially, will allow the bad guys to win.

Being able to efficiently and accurately connect the dots is the Holy Grail in all domains of security, including information/network security. From the talks I’ve attended in just one day, it’s obvious that there are a lot of bright people and companies out there in the malware community who are studying, reverse engineering and coming up with ingenious ways to identify malware. It always fascinates me to see how clever malware can be and the various tricks they employ. For instance, fast flux domain switching. This isn’t a new technique but has been widely utilized for a variety of criminal enterprises. Enterprises akin to malware delivery, spamming, phishing schemes, and to other activities leading to even darker criminal intentions. It’s an efficient way to utilize a botnet by having numerous DNS A records associated with a single FQDN. Then the key step is to swap out these IPs every 5 minutes or so without changing the domain name. This technique is only becoming easier to implement as time goes on with competing hosting sites practically giving away domains for just 99 cents.

The good news is that the detection of malware employing the use of fast flux domain switching exists. It has existed for a while. It just requires the collection, storage, and normalization of webserver and DNS logs – not to mention efficient lookup & dot connecting capabilities on that data. You hear this a lot, but I think it bears repeating. The amount of data floating around out there is beyond non-trivial, it’s overwhelming. Being able to leverage advanced intelligence techniques on key meta data fields is the fundamental step in being able to connect the dots required for the identification of advanced malicious threats.

Tags: , , ,

none | GeneralSecurity

 
 

On Its Three Year Anniversary Conficker Still a Top Threat

Recently I was asked to speak about the prevalence of the Conficker worm.  I initially scoffed at the idea, remembering that Conficker was discovered in November 2008, and the vulnerability it used to spread was patched by Microsoft in October of the same year…ancient history in the security world.  However, after just a little research, I found AV vendors are still considering it to be one of the most prevalent pieces of malware out there.

How can this be?  The vulnerability Conficker used to spread was patched 3 years ago!  Every AV vendor I know of has been able to detect and remove the worm since then.  Many have even issued “Conficker Removal Tools” to assist in the event a system gets in a state where standard AV isn’t working properly.  So why is Conficker still a problem?Dave Pack, Manager LogRhythm Labs talks about Conficker

It really comes down to fundamental security practices (or should I say lack of fundamental security practices).  The early variants of Conficker spread by exploiting a vulnerability in the Windows Server Service, then downloading a payload from a remote site.  The worm continues to spread via this method, but also by attempting to execute copies of itself on ADMIN$ shares on computers visible on the network, launching a dictionary attack if the shares are protected.  In addition, copies are saved to removable media devices and spread via AutoRun.

Any organization with a basic patch management program and AV strategy, both very standard things to have in a defense arsenal, should be protected against Conficker.  However, with an ever-expanding mobile workforce, many organizations are losing control over systems connecting to corporate networks, which might be one of the reasons older malware such as Conficker are still prevalent.  Even home users that don’t have corporate resources should be running one of the free AV products, and have Windows Updates enabled to ensure their systems stay patched.

So that covers the “now.”  What about when the next worm that hits, one that utilizes a zero-day vulnerability that by definition isn’t yet patched, and unlikely to be picked up by many AV engines?  This is where SIEM can help.  Instead of worrying about detecting the exploit itself, a SIEM can look for general worm-like behavior.  Worms are noisy.  Once a host is compromised, the worm will continue to try to spread to other hosts on the network, as outlined above.  By utilizing advanced correlation rules against this rather noisy activity, specifically rules that target internal network activity, a SIEM can alarm on worm-like behavior, even if the exploit being used to spread the worm is unknown.

Tags: , , ,

0 Comments | GeneralSecuritySIEM