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.

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


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


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


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


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


A user account was created.


Security ID:                              WIN2008TESTSERVERAdministrator

Account Name:                       Administrator

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x1d944

New Account:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER


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


A member was added to a security-enabled local group.


Security ID:                              WIN2008TESTSERVERAdministrator

Account Name:                       Administrator

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x1d944


Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       -


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


An account was successfully logged on.


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


Special privileges assigned to new logon.


Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x4f1f1

Privileges:                               SeSecurityPrivilege








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