Security, et al

This article was first published in EventTracker’s EventSource Newsletter: http://www.eventtracker.com/newsletters/how-to-use-process-tracking-events-in-the-windows-security-log/

I think one of the most underutilized features of Windows Auditing and the Security Log are Process Tracking events.

In Windows 2003/XP you get these events by simply enabling the Process Tracking audit policy.  In Windows 7/2008+ you need to enable the Audit Process Creation and, optionally, the Audit Process Termination subcategories which you’ll find under Advanced Audit Policy Configuration in group policy objects.

These events are incredibly valuable because they give a comprehensive audit trail of every time any executable on the system is started as a process.  You can even determine how long the process ran by linking the process creation event to the process termination event using the Process ID found in both events.  Examples of both events are shown below.

Trying to determine what a user did after logging on to Windows can be difficult to piece together.  These events are valuable on workstations because they are often the most granular trail of activity left by end-users.  You can tell for instance that Bob opened Outlook, a few minutes later opened Word, opened Excel and then closed Word. 

As you can see the process start event tells you the name of the program and when it started.  It also tells you who ran the program and the ID of their logon session with which you can correlate backwards to the logon event and thus further determine what kind of logon session in which the program was run and where the user (if remote) was on the network using the IP address and/or workstation name provided in the logon event.

Process start events also document the process that started them using Creator Process ID which can be correlated backwards to the process start event for the parent process.  This can be invaluable when you are trying to figure out how a suspect process was started.  If the Creator Process ID points to Explorer.exe, after tracking down the process start event, then it’s likely that the user simply started the process from the start menu. 

These same events, when logged on servers, also provide a degree of auditing over privileged users but be aware that many Windows administrative functions will all show up as process starts for mmc.exe since all Microsoft Management Console apps run within mmc.exe.

But beyond privileged and end-user monitoring, process tracking events help you track possible change control issues and to trap advanced persistent threats.  When new software is executed for the first time on a given system it’s important to know that, since it implies a significant change to the system or it could alert you to a new unauthorized and even malicious program running for the first time.

The key to this seeing this kind of activity is to compare the executable name in a recent event 592/4688 to executable names in a whitelist - and thereby recognizing new executables. 

Of course this method isn’t full proof because someone could replace an existing executable (on your whitelist) with a new program but with the same name and path as the old.  Such a change would “fly under the radar” with process tracking.  But my experience with unauthorized changes that bypass change control and APTs indicates that while certainly possible, the methods described here-in will catch their share of offenders and attackers.

Of course to do this kind of correlation you need to enable process tracking on applicable systems (all systems if possible, including workstations) and then you need a SIEM solution that can compare the executable name in the current event to a “whitelist” of executables.

How you build that whitelist is important because it determines if your criteria for a new executable is unique to “that” system, or if it is based on a “golden” system, or your entire environment.  Of course the more unique your whitelist is to each system or type of system the better.  You can build the whitelist by either scanning for all the EXE files on a given system or by analyzing the 592/4688 events over some period of time.  I prefer the latter because there are many EXE files on Windows computers that are never actually executed and I’d like to know the first time any new EXE is run – whether it came with Windows and installed applications out of the box or whether it is a new EXE recently dropped onto the system.  On the other hand if you only want to detect when EXEs run which were not present on system at the time the whitelist was created, then a list built from simply running “dir *.exe /s” will suffice.

If you opt to analyze a period of system activity make sure that the period is long enough cover the full usage profile and business process profile for that system – usually a month will do it. Take some time to experiment with Process Tracking events and I think you’ll find that they are valuable for knowing what running on your system and who’s running it.

This article was first published at Lumension’s Optimal Security blog: http://blog.lumension.com/6588/9-mistakes-apt-victims-make/

A couple years ago, Bruce Schneier said that against an APT attacker, “the absolute level of your security is what's important. It doesn't matter how secure you are compared to your peers; all that matters is whether you're secure enough to keep him out.” Those words have proven true over and over again. APT attackers don’t move on to the next target as soon as they see your security is a little above average.

In this age, when you have to do everything right to protect your network, it pays to look at what other people do wrong and learn from their mistakes. Based on public and unpublished APT incidents, I’ve gathered a list of 9 different things that show up repeatedly:

1.       Allowing open attack surfaces without securing configurations

A system’s attack surface comprises the started services, enabled features and installed software.  Stopping all unneeded services, disabling each and every feature that isn’t needed and removing all non-essential software is how you reduce your attack surface. 

This includes all those elements that might seem innocuous and have no known risks.  Time and again innocent little features have proven to harbor nasty vulnerabilities that the bad guys find and leverage.  Case in point is Internet Explorer’s automatic proxy server detection which is enabled by default.  A recent weaponized malware exploited this feature to fool computers trying to download Windows security updates.

While group policy is part of the solution you need configuration management and centralized remediation capabilities so that you can obtain ongoing assurance that all systems on the network are secure and presenting the smallest possible target to the enemy. 

2.       Permitting unlocked ports and unfettered device usage

Allowing USB drives and other removable storage devices to connect to your PCs is reckless.  USA Today details how an infected USB drive idled a power plant for 3 weeks.  This Slashdot article tells how one study found 2/3 of lost USB drives carry malware.  Think you can’t be singled out and targeted USB drives?  Think again.  The bad guys go to tradeshows of target industries and pass them out as swag.  They drop them in Starbucks near target businesses. 

Windows features native removable storage restrictions that can be implemented in group policy but if you need enterprise management and compliance features like reporting and better control over different classes of devices look to your endpoint security vendor.

3.       Failing to use centralized vulnerability remediation

There are too many tweaks and security fixes that can’t be made via group policy including de-registering unsafe DLLs, setting the kill bit, configuring BitLocker, power shell security and changing the local administrator password to name just a few.  You need a way to run commands, remediation scripts and other fixes  on all your PCs automatically and be able to track the success of such remediation steps.  Startup and logon scripts in group policy don’t provide this crucial reporting capability so you need to look at your system management capabilities or end point security technologies.

4.       Allowing untrusted software to execute

This is the single most effective way to stop APTs.  You might be able to use Windows 7 AppLocker  or you may need a modern enterprise application whitelisting solution but either way, stop unknown, unauthorized software from executing on your systems.  Enough said. 

5.       Failing to follow existing security policies/procedures and use at-hand technology consistently

Not eating your own dog food is a painful reason to fall victim to an APT but it happens.  All it takes is one neglected computer or one person who fails to follow policy.  Case in point: Adobe allowed a critical code-signing server to function while noncompliant with their corporate security standards.  It lead to malware being signed to look like valid Adobe software and resulted in a huge security incident affecting Adobe customers.

6.       Permitting open policies for privileged user authority

The RSA SecureID incident involved lateral movement between systems and users resulting in privilege escalation.  This typically means that a privileged user was logged on interactively on a system where they also read email, browse the web or open document files.  Best practices and privileged user technologies exist to keep admin level credentials sacrosanct; APTs show their value.

7.       Not engaging in consistent end-user security awareness

RSA SecurID incident occurred when 3 users were sent an infected spreadsheet, it went into their Junk email, and a single user opened it.  One corporation sent a spear-phishing email to its users as part of a security awareness program.  It took 3 campaigns before they got the open rate below 20%.  Lesson: security awareness needs to be more than a poster in the break room.  Make your program constant and trackable so that you can verify that you are changing behavior.

8.       Failing to leverage logging and to set up traps

Most organizations do not monitor process start events to discover new EXEs.  Nor do most organizations deploy decoy folders with bait files on production systems and audit access to these files.  Both are effective ways to detect malicious outsiders.

9.        Permitting Malware beaconing and exfiltration

In most cases, malware must be installed and permitted to run for an APT to be persistent. When activated, most APT-ware must beacon back to command and control servers.  At some point data is exfiltrated.  It is challenging, but there are techniques for recognizing outbound traffic that could be malware.  Here’s a couple examples: Look for strange packet patterns inconsistent with normal web browsing like more data going up than down.  Look for mysterious domain names like ibiz.3387.org. 

Each of these measures is a single layer of defense and you need them all.  Because it only takes one: one user, one PC, one setting or vulnerability that lets the bad guy get a foothold.  It comes down to defense-in-depth, doing everything right and not allowing untrusted code to execute.

It’s been a huge project to record, edit, embellish and enhance but we are finally done.  My 3-day Security Log Secrets course on the Windows Security Log is now available in my unique On-Demand, Interactive format.  We call it “on-demand” because you can take the course anytime.  We call it “interactive” to emphasize this is no passive, couch-potato DVD viewing experience.  My On-Demand Interactive courses provide highly interactive training designed to closely duplicate the live, instructor-led learning experience.

Security Log Secrets On-Demand Interactive (SLS-OI) is like in-person training you can take anytime, anywhere:

·         Get the same CPE credit

·         Get the same courseware

·         Watch me teach the same material

·         Perform the same hands-on exercises

·         If you get stuck, watch me perform the exercise

·         Stay engaged with frequent flash quizzes

·         Got a question? Ask me via the Q&A forum

Security Log Secrets is fun and fascinating and you can get the full details of the Security Log Secrets course here, and my On Demand Interactive training platform here, but what I want to focus the rest of this email on is how I’m going to help as many of you as possible get this training. Which of the following fits your circumstance?

1.       For my most loyal webinar attendees, those of you that have attended 50 or more live webinars, you get SLS-OI free, and that’s true going forward from this point.  You can get a transcript of your attendance any time.  Congrats to: Christopher, “J”, Paul, Peter, Hugo, Steve , Jeff and others!  Here’s what to do:  Email a copy of your transcript to Bridget at info@ultimateWindowsSecurity.com and enroll using “Purchase Order” as the method.  We will take care of the rest.  The same goes for the rest of you when you reach 50 live attended webinars. 

2.       For anyone who has purchased my Security Log Resource Kit in the past, we’re giving you 50% off!  Email your coupon code request to Bridget at info@ultimateWindowsSecurity.com and be sure to include the email address used when you purchased the kit so that we can verify.  We’ll respond with a coupon code. 

3.       Are you out of work in this tough economy?  I realize you need to keep your skills current but don’t have an employer to assist with the expense.  Send Bridget at info@ultimateWindowsSecurity.com some kind of documentation (redacted of course) that verifies your status.  If you do that and if you were already on this email list prior to today we will find a way to make it work. 

4.       Can’t get your boss to pay for the course but have 2 or more colleagues who’d like the course too?  Send us an email with how many are in your group and we’ll arrange a group discount.  10% off for everyone for each person in your group up to 50%.  Again, email info@ultimateWindowsSecurity.com and Bridget will take care of you.

5.       Feeling left out?  Feel the love instead.  Take 25% off SLS-OI, if purchased in February 2013 with coupon code LOVE.

You get the idea I’m passionate about the security log? I really want as many people as possible to have professional-grade competence in this area. It’s good for business, it’s good for the industry, and it’s good for us geeks.

Any don’t let my discounts suggest SLS-OI is expensive.  It’s actually about half the cost of other premium, on demand infosec training (which by the way doesn’t include a hands-on lab like mine).  But we have to keep the lights on at the UltimateWindowsSecurity.com datacenter so thanks, thanks and thanks again for your support!

These discounts are only good through the end of February so don’t delay.

See you out there keeping the bad guys at bay,

Randy

P.S. Interested in SLS-OI as a long term training resource for everyone in your department?  Email pbrander@logbinder.com with department size and Phil can provide a quote.

Windows audit policy has evolved for 20 years and many people at Microsoft have come on gone.  The result is what one Microsoftie describes as “good”. See: http://blogs.technet.com/b/askds/archive/2011/03/11/getting-the-effective-audit-policy-in-windows-7-and-2008-r2.aspx

If you aren’t careful you can easily end up thinking your systems are auditing the right security events when in fact they are not.  In this article I show you how to avoid these problems.

The original audit policy in Windows NT was 7 audit policies corresponding to 7 categories in the Windows security log.  Along came Windows 2000 with Active Directory and that increased to 9.  You configured those settings in group policy under Computer Configuration\Windows Settings\Security Settings\Local Policy\Audit Policy.

Easy.

Then with Windows 2008, Microsoft and apparently more specifically, Eric Fitzgerald, then security log czar at Microsoft, made a LOT of changes to the security log in a project called Crimson. 

All security log event IDs changed from 3 digits to 4.  Some events were split into multiple new ones, other legacy events were merged into a single new event ID. New categories were added for new security events for the Windows firewall and other features. To handle the new events and to respond to customer pressure to improve the granularity of audit policy, each of the 9 audit categories gained multiple new subcategories.  Microsoft should have just done away with the original 9 but probably didn’t for backward compatibility?  It would have saved untold confusion that exists till this day and the arrangement of the subcategories in to the legacy 9 categories does not make sense.  (e.g. what are IPsec events doing in the Logon/Logoff category?). 

Anyway you could supposedly configure Windows using either the top 9 audit categories or the new subcategories.  But no one would want to do that because the new subcategories for the Windows firewall are scattered through the original 9 categories and are extremely noisy making almost everyone want to disable them.  You can only pick and choose between subcategories if you tell Windows to ignore the legacy 9.  In Windows 2008 there was no way to configure subcategories from group policy; you had to use the auditpol command on each system. 

With Windows 2008 R2 Microsoft added Advanced Audit Policy Configuration to a completely different place in Group Policy and put the “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” under Security Options.

Now, as long as you know to ignore the legacy 9 categories, enabled the “Audit: Force subcategory…” option and configure your Advanced Audit Policy Configuration you can safely use to group policy to centrally configure audit policy across your Win2008+ systems.  By the way you can use the same GPO to manage audit policy on Win2003 and XP systems.  They will ignore the new subcategories and that security option and just look at what you configure on the legacy 9 categories. 

But Microsoft never finished adjusting other areas of Windows policy management to fully support the new subcategories.  This means that policy reporting tools you depend on like Group Policy Results Wizard may very well lie.

Also, unlike most other security settings, local administrators can use auditpol to temporarily override the audit policy you push down from group policy.  You heard me right.  Just open a command prompt and change audit policy with auditpol and you can disable any subcategories you like until the next time group policy refreshes.  (By the way, on laptops disconnected from the domain, this does NOT take affect by running gpupdate or rebooting.  I just tested it from my hotel.  The policy reverts to what it should be only once you re-connect to the domain.)

This is really sad because in order to enforce accountability over admins, we need audit log integrity.  What can you do?  Continue to monitor for 4719 (audit policy change) and 1102 (audit log cleared).  I always like to say, “While admins can cover up their tracks, they can’t cover up the fact they covered up their tracks.”

Where does all of this leave us?  Here are my:

Best Practices/Commandments for Win2008R2/Win7 Audit Policy Configuration:

1. Do not use Local Security Policy 
2. Do not use auditpol /set
3. Use group policy objects in AD to configure audit policy
4. Always enable “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” and, for Win2008R2+ systems, ignore the 9 legacy audit categories.
5. Configure all of the advanced audit policy subcategories even if it is just to explicitly disable them
6. Do not use Local Security Policy, Group Policy Results Wizard, RSOP or gpresults to verify what your true audit policy is
7. Use only “auditpol /get /category:*” to verify what your true audit policy is on a given system
8. Monitor for 4719 where user is not the system itself.  This indicates someone is temporarily overriding your official audit policy defined in AD GPOs.  Terminate them!  Seriously though, it is indicative of something bad.

Hope this helps and I want to thank SolarWinds Log & Event Manager for sponsoring this article.

This article was first published at Lumension’s Optimal Security blog: http://blog.lumension.com/6036/growing-threat-from-friendly-fire-from-vendors/

After we learned that Flame exploited Microsoft’s Auto Update infrastructure, I pointed out that if attackers were able to compromise Microsoft, a leader in patch management, it couldn’t be long before bad guys exploited the update infrastructures of other vendors who are far behind Microsoft – like Adobe…  And that’s exactly what happened a couple weeks ago.

One of Adobe’s internal servers was hacked.  This server performed code signing for several Adobe applications.  Code signing on the Windows platform is called Authenticode.  It’s a way of digitally signing programs so that when you download what you believe to be Acrobat Reader from Adobe you can be sure that it really is Reader and not some piece of malware. 

Once they hacked this code signing server at Adobe, the attackers used it to sign an unknown quantity (at least 3) of malware files which were later used in some apparently limited, targeted attacks.  Adobe decommissioned the server, informed customers, released updated versions of Adobe apps signed by a new certificate and finally revoked the compromised certificate days later. 

It’s important to understand that the risk in this particular case was not any vulnerability inside Adobe products already installed.  The risk was that your computers might trust malicious software they encounter because it had a completely valid signature from a trusted publisher.

Why then was it necessary to update your Adobe apps?  Adobe never really got into details on that.  They were pretty vague, saying something about “negative impact on user experience”.  My research indicates that once Adobe revoked the certificate in question, User Account Control (UAC) and AppLocker among other things would balk when you tried to run or install Adobe apps signed with the old certificate. 

Adobe’s whole handling of the mess left me and a lot of my colleagues with a bad taste in our mouth.  It really felt like their priority was protecting their application’s usability over user security.  They are where Microsoft was years ago when IIS was getting hacked all the time and whenever I used the words “Windows security” in that sequence, people would say “isn’t that an oxymoron”?  Microsoft almost lost the king of the server hill to Linux and Apache but then Bill Gates came out with Trustworthy Computing.  This was a major turnaround for a man and a company who once said users would never pay for quality.  Microsoft developers stood down on development work for weeks of training and then went back to their source code searching for security vulnerabilities.  They implemented new coding standards and completely revamped their patch process.  Patch Tuesday brought order to the chaos of unpredictable patch releases and things got a lot better for the good guys. 

For a while.  Microsoft’s improvements created a vacuum in the ISV world and the bad guys turned their attention there.  Now we have the Acrobat, Flash, Shockwave, Java, iTunes, 3^rd party browser security patching mess we find ourselves in now.  This has been going on for several years without much discernible improvement. 

What’s new is that in an ironic twist of fate the bad guys are exploiting software update infrastructures – the very infrastructures our vendors are trying to protect us with. 

There’s consensus among the people I talk to that we can’t trust software vendors to automatically update our systems.  We can’t trust them to keep their infrastructures secure.  After all, everyone is vulnerable to advanced persistent threats (APTs).  But when companies are hacked it’s usually their own data that gets compromised.  But with ISVs, it’s their users.  Like one of my community members said, if your ISV sneezes you get the pneumonia.

That’s bad enough but I also don’t think we can trust ISVs act 100% in our best interests when handling security incidents that expose us, their users, to risk.

If we can’t trust on those 2 points, there’s 2 ways we can’t trust ISVs.  First, we can’t trust them to automatically update our systems.  We’ve got to disable all of these automatic updates and take centralized control of patch management.  In fact I propose the following 8 Software Patching Commandments:

1. Thou shalt not depend on vendor automatic updaters
2. Thou shalt not allow patch/installation based on code-signing certificates
3. Thou shalt control which patches go down and when
4. Thou shalt be able to deploy patches within hours
5. Thou shalt be able to deploy patches in phases
6. Thou shalt not be blind to patch deployment status
7. Thou shalt patch software from multiple vendors
8. Thou shalt patch applications on all your operating systems

Second, we can’t trust code signatures.  It may be from Microsoft or Adobe, then again it may be a forged signature hiding some really bad malware.  You can’t trust users not to run malware and it’s evolving to fast.  That means we need to take centralized control of what executes on all servers and endpoints.  There’s no substitute for application whitelisting and that technology has really improved.

There’s great technology for both of these centralized control needs and I don’t see any way around the need for it because we can’t trust the classic mechanisms in place.

Oh, one other point about trust.  Don’t trust vendors when they say the great majority of you are safe because these attacks are very targeted and limited in nature.  That’s fine as long as you aren’t the one being targeted. All of them say this including Microsoft but I’ll quote Adobe: “We have strong reason to believe that this issue does not present a general security risk. The evidence we have seen has been limited to a single isolated discovery of two malicious utilities signed using the certificate and indicates that the certificate was not used to sign widespread malware.”  That is damage control talk. 

If you want more on the Adobe code signing hack and how it demonstrates the need for centralized, multi-vendor patch management and application whitelisting watch my webinar: Code Signing Debacle 2.0: A Hacked Adobe Server and Its Impact on Us All.

This article was first published at Lumension’s Optimal Security blog: http://blog.lumension.com/6036/growing-threat-from-friendly-fire-from-vendors/

This whitepaper by Randy Franklin Smith, provides an overview of the 3 different audit logs in Exchange and discusses their relative merits in terms of security value and how to integrate with your SIEM.

Download it now here.

This is a PowerShell script I developed to use in my own IT audits of Active Directory and for a webinar: 10 Steps to Cleaning Up Active Directory User Accounts and Keeping Them that Way.

It outputs a comma-delimited list of user accounts and their most important properties for IT audit and account management analysis.

Check it out here.

I recently completed a whitepaper for HP ArcSight that details the available logs in Microsoft Exchange and how you can connect those to HP ArcSight.

Even if you are not an ArcSight user you will still want to read this to see which logs are available for auditing in Exchange since our LOGbinder EX application (www.logbinder.com) will be able to get these logs in to any SIEM; not just ArcSight.

Click here to read the whitepaper.

I recently wrote a whitepaper on protecting the unstructured data in your environment.  Unstructured data is a critical security risk and compliance concern for organizations. Your company's emails, documents and spreadsheets contain readily digestible, business-critical information, and your organizatioon is generating more - much more- of those documents every day. How are you protecting that data?

My whitepaper explains what you can do and how to do it.  You can read it here: Randy's White Paper

This code signing hack at Adobe and the available information still leave a lot of unanswered questions.  No one I’ve talked to has been able to get to the bottom of it.  Here’s what have put together.

One of their code-signing servers got hacked and was used to sign some malicious software.  We know of 3 files and their hashes which are listed at http://www.adobe.com/support/security/advisories/apsa12-01.html. 

Were other files signed?  We do not know.

How can I protect against the 3 files we know were signed?  Create Software Restrictions in Group Policy based on the file hashes.

How can I protect against any other files that were signed? Intelligent whitelisting – join me for my webinar tomorrow to learn more.

Can you add the relevant Adobe certificate to your Untrusted Certificates store?  Adobe says doing that won’t stop the malware signed with the certificate but will create a “negative impact on the user experience and execution of valid Adobe software signed with the impacted certificate. Adobe does not recommend using the Untrusted Certificate Store in this situation.” http://forums.adobe.com/message/4741942#4741942. 

What exactly is the “negative impact”?  I assume legit Adobe apps won’t run…

What do I need to do?  Adobe says we need to install updated versions of about 30 applications.  http://helpx.adobe.com/x-productkb/global/certificate-updates.html#main-pars_header_8

What will happen if I don’t update those applications?  What is the risk of not updating? I can find no explanation at all on this.  The FAQ specifically asks this question but I don’t get much from the answer: Adobe is issuing updates for all impacted products to provide customers with software code signed using a new digital certificate. To determine whether an update signed using a new digital certificate is available for your Adobe software installation, please refer to Security certificate updates.

I’m going to cover all the issues in more depth in tomorrow’s webinar and provide short term tactical suggestions and long term strategic recommendations for this new kind of threat that leverages compromised software vendor update infrastructures to deliver and/or trick your computers into running malicious code.

Lumension has agreed to sponsor this webinar and their software update and application whitelisting experts will be joining me.

Please don’t miss this timely real training for free (TM) session.