Security, et al

This article was first published in EventTracker’s EventSource Newsletter: http://www.eventtracker.com/newsletters/following-a-users-logon-tracks-throughout-the-windows-domain/

In this article, I’ll show you the security events that get logged when a user logs on to their workstation with a domain account and proceeds to run local applications and access resources on servers in the domain.  You can see examples of all the events described in this article at the Security Log Encyclopedia.

When a user logs on at a workstation with their domain account the workstation contacts domain controller via Kerberos and requests a ticket granting ticket (TGT).  If the user fails authentication, the domain controllers logs event ID 4771 or an audit failure instance 4768.  The result code in either event specifies the reason for why authentication failed.  Bad passwords and time synchronization problems trigger 4771 and other authentication failures such as account expiration trigger a 4768 failure.  These result codes are based on the Kerberos RFC 1510 and in some cases one Kerberos failure reason corresponds to several possible Windows logon failure reasons.  In these cases the only way to know the exact reason for the failure is to check logon event failure reason on the computer where the user is trying to logon from.

If the user’s credentials authentication checks out OK, the domain controller creates a TGT, sends that ticket back to the workstation and logs event ID 4768.  Event ID shows the user who authenticated and the IP address of the client – the workstation in this case.  Note that there is no logon session identifier though.  This is because the domain controller handles authentication – not logon sessions.   Authentication events are just events in time – sessions have a beginning and an end.  In Windows, each member computer (workstation and servers) handles its own logon sessions. 

When the domain controller fails the authentication request, the local workstation will log 4625 in its local security log noting the user’s domain, logon name and the failure reason.  There is a different failure reason for every possible reason a Windows logon can failure – in contrast with the more general result codes generated by the Kerberos domain controller events described above. 

If authentication succeeds and the domain controller sends back a TGT, the workstation creates a logon session and logs event ID 4624 to the local security log.  This event identifies the user who just logged on, the logon type and the logon ID.  The logon type is a number that specifies whether the logon session is interactive, remote desktop, network based (i.e. incoming connection to shared folder), a batch job (e.g. Scheduled Task) or a service logon triggered by a service logging on.  The logon ID is a hexadecimal number identifying that particular logon session. All subsequent events associated with activity during that logon session will bear the same logon ID making it relatively easy to correlate all the activity of a user while she is logged on.  When the user finally logs off Windows will record a 4634 followed by a 4647.  Event ID 4634 indicates the user initiated the logoff sequence which may get canceled.  Once the logon session fully terminates you get logon 4647.  If the system is shut down all logon session get terminated and since the user didn’t initiate the logoff, no event ID 4634 is logged.

While a user is logged on they typically access one or more servers on the network.  Their workstation automatically re-uses the domain credentials they entered at logon to connect to other servers.  When a server  receives a logon request – such when a user tries to access a shared folder on a file server – the user’s workstation requests a service ticket from the domain controller that authenticates the user to that server.  The domain controller logs 4769 which is useful because it tells you that user X accessed server Y; the computer name of the server accessed is found in the Service Name field of 4769.  When the workstation presents the service ticket to the file server, the server creates a logon session and records event ID 4624 just like the workstation did earlier but this time logon type is 3 (network logon).  However as soon as the user closes all files opened during this network logon session, the server automatically ends the logon session and records 4647.  Therefore network logon sessions typically last for less than a second while a file is saved unless the user’s application keeps a file open on the server for extended periods of time.   This results in the constant stream of logon/logoff events that you typically observe on file servers and means that logon/logoff events on servers with logon type 3 are not very useful.  It is probably better to focus on access events to sensitive files using object access auditing.

You will see additional logon/logoff events on servers and authentication events associated with other types of user activity such as:

• Remote desktop connections
• Service startups
• Scheduled tasks
• Application logons – especially IIS based applications like SharePoint, Outlook Web Access and ActiveSync mobile device clients

These events will generate logon/logoff events on the application servers involved and Kerberos events on domain controllers. 

You may also see NTLM authentication events on domain controllers from clients and applications that use NTLM instead of Kerberos.  NTLM events fall under the Credential Validation subcategory of the Account Logon audit category in Windows.  There is only event ID logged for both successful and failed NTLM authentication events.

As you can see, a user leaves tracks on each system they access and the combined security logs of your domain controllers alone provide a complete list of every time a domain account is used and which workstations and servers were accessed.  Understanding Kerberos and NTLM and how Windows separates the concepts of logon sessions from authentication really helps you interpret these events and grasp why different events are logged on each system.

• at my LOGbinder booth
• and at my breakout session #1488 – “Setting traps for malicious outsiders and APTs on your network”

HP Protect is next month September 16-19 in Washington, D.C.  It’s a great event for infosec professionals tasked with monitoring networks and detecting intrusions. 

Here’s more information on my session:

Think outside the box with well-known security log expert Randy Franklin Smith as he argues that we’ve been going about catching bad guys the wrong way. Trying to detect malicious activity by defining what makes it an anomaly is difficult. So turn the concept on its head and make malicious activity stand out as intentional and not a one-time event. In this session, instead of looking for hints of malicious activity and weeding through false positives, Randy will show you how to set up traps throughout your network and applications that automatically distinguish between normal insider activity and malicious outsiders or APTs – even if the attacker is running under the credentials of a legitimate user. The principles are applicable to any technology, but Randy will specifically demonstrate laying traps in Windows, SQL Server, and SharePoint. You will also learn how to deal with the end-user awareness and admin pushback challenges that may arise when implementing traps

What is HP Protect?

It is HP’s annual security user conference. It began as an ArcSight conference and, after HP acquired ArcSight, evolved into a comprehensive, pan-HP security conference that delivers technical content, product roadmaps, demos, instruction, and services to users of HP, HP ArcSight, HP Atalla, HP Fortify, and HP TippingPoint software.

Why attend?

Meet Randy Franklin Smith!

Ha! Seriously, why attend?

How about 100 hours of content; 16 hours with HP experts; 2 hours of keynotes; 8 hours of networking. Nearly 150 technical sessions – 100+ hours of content. 8 hours of networking with 1,000+ security professionals. 16+ hours of one-on-one access to HP security experts. 5 post-conference training courses. Earn up to 15 CPE credits to keep your CISSP credentials current. Learn about updates to the entire HP enterprise security portfolio. Explore new technology, emerging trends, and ways of extending your investments with HP and your peers

Any other reasons?

Conference party: Rock out to "Hey, Soul Sister".  Are you a fan of the band Train? Enjoy their Grammy-winning hits at a private concert celebrating HP Protect. Lead singer Pat Monahan, and guitarist Jimmy Stafford—accompanied by a guest drummer—will perform a lineup of Train’s pop-rock music for your entertainment.

What about the content?

                Here’s the full session catalog.

I hope to see you there!
 

This article was first published at Lumension’s Optimal Security blog: http://blog.lumension.com/6684/anatomy-of-reflective-memory-attacks/

Ophiocordyceps unilateralis is a parasitiodal fungus that, beginning with a microscopic spore, infects a certain species of ant using a series of attacks, one building on the other until it controls the ant’s brain for its own bidding.  The fungus can’t just land on the ant, consume it and reproduce.  It needs to get inside the ant – in order to eat it – and it needs the ant to travel far away from the ant’s normal home in tree to an environment more suitable for the fungus’ growth and reproduction.  The whole process requires a chain of attacks, each one very different in method and each allowing the fungus to gain more strength needed for the next stage and ultimately its reproduction.  That progressive chain of attacks, is in a very creepy way, not unlike the bootstrap process of today’s attacks reflective memory attacks. 

Like a piece of malformed content delivered to a PC, the spore uses enzymes to silently penetrate the ant’s shell.  Then as the malformed content (e.g. a PDF, Office document, JPEG) is parsed, a buffer overflow in the content triggers an initial, tiny shell code to execute arbitrary instructions within the victim process.  Many factors limit how large the shell code can be and thus what it can do at this point on the victim PC.  Similarly the young fungus sprouting from the spore is far from taking over the ant’s brain at this point.

The shell code solves this problem by contacting a server somewhere on the Internet that is controlled by the attacker and downloading a larger module of malicious code.  In this way the malware on the victim PC grows in size and capability.  In comparison the newly penetrated spore must consume nearby soft tissues of the ant in order to grow. 

The fungus has to be careful at this point.  It needs to convert tissue of the ant, to grow, so that it can reach the ant’s brain but it can’t kill the ant.  It needs the ant to stay alive for now until it can get the ant to crawl to the fungus’ optimum location for reproduction. 

Likewise the computer attacker has to be careful.  A poorly written buffer overflow/shell code exploit can inadvertently crash the process – in essence killing the “ant”.  But more importantly the currently active shell code is insufficient to take over the entire PC and begin moving to other systems and/or stealing information.  Obviously the shell code needs to download a larger module of malware but if it writes a malicious executable to the local file system and runs it, antivirus or application control running on the PC can easily catch and block the attack from proceeding.

In the case of the fungus, it carefully consumes non-vital parts of the ant until it reaches the brain.  In the cyber world, the attacker has the shell code download the larger malware but refrains from writing it to the file systems.  Instead it loads the code into a chunk of allocated memory.  Then it uses something called reflective programming to link symbolic references in the malware to the actual addresses of standard functions and system APIs.  This is much easier said than done but the result is that the attacker succeeds in activating a very large and highly functional malware on the target system without touching the file system or even starting a new process on the PC.  The malware lives inside the process that originally parsed the little piece of malformed content.  The process itself as well as the operating systems and security applications have no idea that the process is now a zombie under to control of the bad guys.

Back in “meat space”, as the fungus consumes the ant’s non vital soft tissues it grows towards the ant’s brain.  Having reached the head, the fungus secretes chemicals that take control of the aunt’s brain first throwing the ant into convulsions that cause it to fall from the tree where the colony lives.  Next the fungus causes the ant to climb the north side of a suitable plant stem to a certain height and latch onto the vein of a leaf with all the strength of its mandibles. Now the fungus, with no further need of the ant’s continuing life, consumes the ant with abandon.  Branches of the fungus sprout from the ant to more securely anchor it to the leaf and structurally reinforce the ant’s exoskeleton.  Secretions ward off other microbial competitors. As the fungus matures, the ant’s soft tissues are fully consumed and finally, fruiting bodies sprout from the ant’s head and new spores leave to repeat the process.

In the compromised PC, the attacker uses the malware activated through the reflective memory attack to elevate its privileges to control the operating system and become persistent.  At this point the attacker can fully exploit the compromised PC and the victim user’s authority much like the fungus in its final stages of consuming the ant.

Attack methods are always changing but right now the most fascinating – and dangerous – aspect of a cyber-attack like this is the reflective memory attack. It pays for all of us to learn how it works because these attacks are very hard to detect and require a completely new and different technology than file system based AV and application control. 

Want to learn how reflective memory attacks work? Join Randy for “Reflective Memory Attacks Deep Dive: How They Work; Why They’re Hard to Detect”.

Just in case you missed today's webinar you can still get my whitepaper that the webinar was based off of.  Click here to download my whitepaper "APT Confidential: 14 Lessons Learned from Real Attacks". Our webinar and whitepaper sponsor, Bit9, gave me a unique opportunity to interview security analysts at not only Bit9 but also some of their customers.  This whitepaper explains the lessons learned from real attacks. 

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.