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.

Investigation Operational Security Tips

Operational security during an investigation is extremely important and there are a couple tips I’d like to share. While they may seem obvious at times, it’s imperative that they be kept in mind during an emergency or a normal investigation, especially for those organizations without a dedicated incident response team. Cutting corners in order to save time or ignoring some basic rules can compromise and inform unwanted individuals of your investigation.

  1. DNS Requests

A common practice in many investigations is to gather information and observe a suspicious domain, if one is involved. While this preliminary information gathering can be beneficial it can also compromise your investigation. Making DNS requests to an attacker’s server could inform them that research is being conducted, or their activity has been detected. It is extremely rare for an average foe to monitor inbound DNS requests, but it is a reasonable practice for a targeted and much more sophisticated adversary. In theory, such an adversary could monitor their own DNS servers for communication. Once irregular inbound requests are detected an adversary then has a head start to immediately back out, cover their tracks. and change their tactics. 

This mistake is most common with traffic capturing utilities used within a network for automatic name resolution. These tools can automatically give intelligence to the attacker around your monitoring capabilities. Here are two common examples of disabling automatic name resolution:


This setting is disabled by default, but good to double check if loading a PCAP that may contain network traffic for an investigation or research. The setting can be found in Edit > Preferences > Name Resolution.

Figure 1


Use the –n option. As stated in the manual, this setting will disable name resolution.

Figure 2

  1. Communication Timing

This one is more on the theoretical side, and again very dependent on the sophistication and focus of the attacker. If you are examining a file that could be malicious, the odds are this file will want to ‘talk’ outbound to its control server or request further downloads onto the network. There are obvious best practices when it comes to examining and testing malicious binaries, such as offline operations only, but that’s not always possible.

If you need the code to run, or perhaps you identified the URL holding the download file, be careful with your timing. As a small warning, the hosting location you are reaching has an increased possibility to spot the odd behavior. If they were to know all of their victim machines will reach out to them at a specific time, anything outside of that could inform them that you are researching and potentially identified their activities.

  1. Upload and Sharing of Data

For many, the first step to discovering if a file is malicious or not is to upload it to all the free scanning websites. While this process will provide some quick details for an initial analysis, it can also inform its creator that you have found and are researching their efforts. Some of the more popular destinations for these actions would be VirusTotal, Malwr, and the new IBM X-Force Exchange. These are some of my favorites, and also Lenny Zeltser happens to have a great list of options focused on automated malware analysis.

When it comes to using the numerous online scanning and analysis tools, avoid any aspect of sharing the upload during the initial investigation. Instead, simply search for the data names or hash when possible. An attacker can automate the ability to query the various sites for their binary to see if anyone has found and uploaded it. Searching instead of uploading will allow you to check for possible results while also keeping it concealed that you are performing an analysis on it.

Sharing with the industry can be a great thing, but take caution in the timing and amount of information you decide to make public. VirusTotal does not currently provide the option to opt out of sharing data while Malwr along with X-Force Exchange do. Lastly, there is the option for setting up your own analysis environment with something like Cuckoo Sandbox, but that’s for another blog post!

Figure 3


  1. Defense On The Sea Begins On The Shore

We’ve all heard it, do not share anything private or confidential on social media, yet many people still do. An interesting trend I’ve seen recently comes from LinkedIn in particular. It is common among professionals to connect with each other over LinkedIn shortly after meeting. Think about the timing and viewpoint from individuals watching for this activity. They could find it rather helpful when the team of Company-A begins to connect with people from Company-B. For example, if you began connecting with multiple individuals from a particular security vendor, someone from outside could then assume there may be use of that vendor at the organization. Also, LinkedIn is one of the most widely used sources of information for the social engineering competition (SECTF) each year at DEF CON. The solution may be obvious, but avoid connecting with patterns like this, or just turn off the ability to publicize this information within the account settings.

Treat any social media information with the same paranoia. Tweeting your thoughts on how terrible your users are at clicking links in phishing emails, or taking pictures of your office for your friends on Facebook are the first that come to mind as bad practice. This awareness would also be helpful to TV broadcasts as well, such as the recent event at a London rail station.

In conclusion, it all really comes down to the basic policy of “need to know” for all investigations or activity taking place. Individuals or groups targeting you can use the above methods to potentially gain the upper hand on your labors. None of this is a new idea or method to operational security, but in the ever changing world we must continually assess our practices to ensure its integrity.

Tags: , , , , ,

0 Comments | Digital ForensicsSecurity


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

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 (, encourages the recipient to click on the link to download a ‘private photo archive’.


Figure 1 : Phishing email

Following the link navigates the default browser to hxxp://, initiating a download of ‘’ (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 ‘’ . 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 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 ‘’, 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 — identified the botnet as Betabot on Nov 25, 2013 with the domain being hosted from Ukraine ( 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