Security, et al

Randy's Blog on Infosec and Other Stuff

Auditing File Shares with the Windows Security Log

Thu, 02 Jan 2014 15:22:25 GMT

This article was first published in EventTracker’s EventSource Newsletter:http://www.eventtracker.com/newsletters/auditing-file-shares-windows-security-log/#open

Over the years, security admins have repeatedly ask me how to audit file shares in Windows.  Until Windows Server 2008, there were no specific events for file shares.  About the best we could do was enable auditing of the registry key where shares are defined.  But in Windows Server 2008 and later there are 2 new subcategories for share related events:

  • File Share

  • Detailed File Share

File Share Events

The good news is that this subcategory allows you to track the creation, modification and deletion of shared folders (see table below).  You have a different event ID for each of those 3 operations.  The events indicate who made the change in the Subject fields and provides the name of the share users see when browsing the network and the patch to the file system folder made available by the share.  See the example of event ID 5142 below.

A network share object was added.

Subject:
  Security ID:  W8R2\wsmith
  Account Name:  wsmith
  Account Domain:  W8R2
  Logon ID:  0x475b7

Share Information:
  Share Name: 
\\*\AcmeAccounting
  Share Path:  C:\AcmeAccounting

The bad news is the subcategory also produces event ID 5140 each and every time a user connects to a share.  The data logged, which includes who accessed it and their client IP address, is nice but the event is logged much too frequently.  Since Windows doesn’t keep network logon sessions active if no files are held open you will tend to see this event a lot if you enable “File Share” audit subcategory.  There is no way to configure Windows to produce just the share change events and not this access event as well.  Of course that’s the point of a log management solution like EventTracker which can be configured to filter out the noise. 

5140

A network share object was accessed

5142

A network share object was added.

5143

A network share object was modified

5144

A network share object was deleted.

 

Detailed File Share Events

Event ID 5140, as discussed above, is intended to document each connection to a network share and as such it does not log the names of the files accessed through that share connection.  The “Detailed File Share” audit subcategory provides this lower level of information with just one event ID – 5145 which is shown below.

A network share object was checked to see whether client can be granted desired access.

Subject:
  Security ID:  SYSTEM
  Account Name:  WIN-KOSWZXC03L0$
  Account Domain:  W8R2
  Logon ID:  0x86d584

Network Information:
  Object Type:  File
  Source Address:  fe80::507a:5bf7:2a72:c046
  Source Port:  55490

Share Information:
  Share Name: 
\\*\SYSVOL
  Share Path:  \??\C:\Windows\SYSVOL\sysvol
  Relative Target Name: w8r2.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\Machine\Microsoft\Windows NT\Audit\audit.csv

Access Request Information:
  Access Mask:  0x120089
  Accesses:  READ_CONTROL
     SYNCHRONIZE
     ReadData (or ListDirectory)
     ReadEA
     ReadAttributes

Access Check Results:
  READ_CONTROL: Granted by Ownership
     SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;WD)
     ReadData (or ListDirectory): Granted by D:(A;;0x1200a9;;;WD)
     ReadEA: Granted by D:(A;;0x1200a9;;;WD)
     ReadAttributes: Granted by D:(A;;0x1200a9;;;WD)

This event tells identifies the user (Subject fields), the user’s IP address (Network Information), the share itself and the actual file accessed via the share (Share Information) and then provides the permissions requested and the results of the access request.  As you can see this event actually logs the access attempt and therefore you will see failure versions of the event as well as success events. 

But be careful about enabling this audit subcategory because you will get an event for each and every file accessed through network shares – every time the application opens the file.  That can be much more frequent than you’d imagine for some applications like Microsoft Office.  Conversely, remember that this category won’t catch access attempts on the same files if a locally executing application accesses the file via the local patch (e.g. c:\docs\file.txt) instead of via a patch. 

Instead you might want to consider enabling auditing on individual folders containing critical files and using the File System subcategory.  This method allows you to be much more selective about who, which files and what types of access are audited.

For most organizations I suggest enabling the File Share subcategory if it’s important to you to know when new folders are shared.  But you will probably want to filter out all those occurrences of 5140.  Then if you have file level audit needs, turn on the File Access subcategory, identify the exact folders containing the relevant files and then enable auditing on those folders for the specific operations (e.g. Read, Write, Delete) necessary to meet your audit requirements.  Don’t enable the Detailed File Share audit subcategory unless you really want events for every access to every file via network shares.

email this digg reddit dzone
comments (0)references (0)

Related:
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Auditing File Shares with the Windows Security Log
Virtualization Security: What Are the Real World Risks?
Following a User’s Logon Tracks throughout the Windows Domain

Pay Attention to System Security Access Events

Tue, 19 Nov 2013 13:15:50 GMT

There are 5 different ways you can logon in Windows.  We call them logon types.  The Windows Security Log lists the logon type in event ID 4624 whenever you logon.  Logon type is what allows you to determine if the user logged on at the actual console, via remote desktop, via a network share or if the logon is connected to a service or scheduled task starting up.  The logon types are:

Type

Description

Allow right

Deny right

2

Interactive (logon at keyboard and screen of system)

SeInteractiveLogonRight

Allow logon locally

SeDenyInteractiveLogonRight

Deny logon locally

3

Network (i.e. connection to shared folder on this computer from elsewhere on network)

SeNetworkLogonRight

Access this computer from the network

SeDenyNetworkLogonRight

Deny access to this computer from the network

4

Batch (i.e. scheduled task)

SeBatchLogonRight

Log on as a batch job

SeDenyBatchLogonRight

Deny logon as a batch job

5

Service (Service startup)

SeServiceLogonRight

Log on as a service

SeDenyServiceLogonRight

Deny logon as a service

10

RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance)

SeRemoteInteractiveLogonRight

Allow logon through Terminal Services

SeDenyRemoteInteractiveLogonRight

Deny logon through Terminal Services

 There are a few other logon types recorded by event ID 4624 for special cases like unlocking a locked session but these aren’t real logon session types. 

Knowing the session type in logon events is great but you can also control users’ ability to logon in each of these 5 ways.  A user account’s ability to logon is governed by 5 user rights found in group policy under Computer Configuration/Windows Settings/Security Setting/User Right Assignments.  There is an allow and deny right for each logon type. In order to logon in a given way you must have the corresponding allow right.  But the deny right for that same logon type takes precedence.  For instance, in order to logon at the local keyboard and screen of a computer you must have the "Allow logon locally" right.  But if the "Deny logon locally" right is also assigned to you or any group you belong to, you won’t be able to logon.  The table below lists each logon type and it’s corresponding allow and deny rights.

Logon rights are very powerful.  They are your first level of control – determining whether a user can access a given system at all.  After logging in of course their abilities are limited by object level permissions.  Since logon rights are so powerful it’s important to know if they are suddenly granted or revoked and you can do this with Windows Security Log events 4717 and 4718 which are logged whenever a given right is granted or revoked respectively.  To get these events you need to enable the Audit Authentication Policy Change audit subcategory.

Events 4717 and 4718 identify the logon right involved in the "Access Granted"/"Access Removed" field using a system name for the right as shown in corresponding column in the table above.  The events also specify the user or group who was granted or revoked from having the right in the "Account Modified" field.

Here’s an example of event ID 4717 where we granted the "Access this computer from the network" to the local Users group. 

System security access was granted to an account.
Subject:
   Security ID:  SYSTEM
    Account Name:  WIN-R9H529RIO4Y$
    Account Domain:  WORKGROUP
    Logon ID:  0x3e7

Account Modified:
   Account Name:  BUILTIN\Users

Access Granted:
   Access Right:  SeNetworkLogonRight

There’s just one problem.  The events do not tell you who (which administrator) granted or revoked the right.  The reason is that user rights are controlled via group policy objects.  Administrators do not directly assign or revoke user rights on individual systems; even if you modify the Local Security Settings of a computer you are really just editing the local group policy object.  When Windows detects a change in group policy it applies the changes to the local configuration and that’s when 4717 and 4718 are logged.  At that point the user making the change directly is just the local operating system itself and that’s why you see SYSTEM listed as the Subject in the event above.

So how can you figure out who a granted or removed the right?  You need to be tracking group policy object changes is a topic I’ll cover in the future.

email this digg reddit dzone
comments (0)references (0)

Related:
Virtualization Security: What Are the Real World Risks?
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Automating Review and Response to Security Events
Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls

Using Dynamic Audit Policy to Detect Unauthorized File Access

Tue, 15 Oct 2013 13:43:49 GMT

This article was first published in EventTracker’s EventSource Newsletter: http://www.eventtracker.com/newsletters/using-dynamic-audit-policy-to-detect-unauthorized-file-access/

One thing I always wished you could do in Windows auditing was mandate that access to an object be audited if the user was NOT a member of a specified group.  Why?  Well sometimes you have data that you know a given group of people will be accessing and for that activity you have no need of an audit trail. 

Let’s just say you know that members of the Engineering group will be accessing your Transmogrifier project folder and you do NOT need an audit trail for when they do.  But this is very sensitive data and you DO need to know if anyone else looks at Transmogrifier. 

In the old days there was no way to configure Windows audit policy with that kind of negative Boolean or exclusive criteria.  With Windows 2008/7 and before you could only enable auditing based on if someone was in a group not the opposite.

Windows Server 2012 gives you a new way to control audit policy on files.  You can create a dynamic policies based on attributes of the file and user.  (By the way, you get the same new dynamic capabilities for permissions, too). 

Here’s a screen shot of audit policy for a file in Windows 7.

Now compare that to Windows Server 2012.

The same audit policy is defined but look at the “Add a condition” section.  This allows you to add further criteria that must be met before the audit policy takes effect.  Each time you click “Add a condition” Windows adds another criteria row where you can add Boolean expressions related to the User, the Resource (file) being accessed or the Device (computer) where the file is accessed.  In the screen shot below I’ve added a policy which accomplishes what we described at the beginning of the article.

 

So we start out by saying that Everyone is audited when they successfully read data in this file.  But then we limit that to users who do not belong to the Engineering group.  Pretty cool, but we are only scratching the surface.  You can add more conditions and you can join them by Boolean operators OR and AND.  You can even group expressions the way you would with parenthesis in programming code.  The example below shows all of these features so that the audit policy is effective if the user is either a member of certain group or department is Accounting and the file has been classified as relevant to GLBA or HIPAA compliance.

You’ll also notice that you can base auditing and access decision on much more that the user’s identity and group membership.  In the example above we are also referencing the department specified on the Organization tab of the user’s account in Active Directory.  But with dynamic access control we can choose any other attribute on AD user accounts by going to Dynamic Access Control in the Active Directory Administrative Center and selecting Claim Types as shown here.

You can create claim types for about any attribute of computer and user objects.  After creating a new claim type for a given attribute, it’s available in access control lists and audit policies of files and folders throughout the domain. 

But dynamic access control and audit policy doesn’t stop with sophisticated Boolean logic and leveraging user and computer attributes from AD.  You can now classify resources (folders and files) according to any number of properties you’d like.  Below is a list of the default Resource Properties that come out of the box.

Before you can begin using a given Resource Property in a dynamic access control list or audit policy you need to enable it and then add it to a Resource Property List which is shown here.

After that you are almost ready to define dynamic permissions and audit policies.  The last setup step is to identity file servers where you want to use classify files and folders with Resource Properties.  On those file servers you need to add the File Server Resource Manager subrole.  After that when you open the properties of a file or folder you’ll find a new tab called Classification.

Above you’ll notice that I’ve classified this folder as being related to the Transmogrifier project.  Be aware that you can define dynamic access control and audit policies without referencing Resource Properties or adding the File Server Resource Manager subrole; you’ll just be limited to Claim Types and the enhanced Boolean logic already discussed.

The only change to the file system access events Windows sends to the Security Log is the addition of a new Resource Attributes to event ID 4663 which I’ve highlighted below.

This field is potentially useful in SIEM solutions because it embeds in the audit trail a record of how the file was classified when it was accessed.  This would allow us to classify important folders all over our network as “ACME-CONFIDENTIAL” and then include that string in alerts and correlation rules in a SIEM like EventTracker to alert or escalate on events where the information being accessed has been classified as such.

The other big change to auditing and access control in Windows Server 2012 is Central Access Policies which allows you to define a single access control list or audit policy in AD and apply it to any set of computers.  That policy is now evaluated in addition to the local security descriptor on each object. 

While Microsoft and press are concentrating on the access control aspect of these new dynamic and central security features, I think the greatest immediate value may come from the audit policy side that we’ve just explored.  If you’d like to learn more about dynamic and central access control and audit policy check out the deep dive session I did with A.N. Ananth of EventTracker: File Access Auditing in Windows Server 2012. 

 

email this digg reddit dzone
comments (0)references (0)

Related:
Using Dynamic Audit Policy to Detect Unauthorized File Access
Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls
Virtualization Security: What Are the Real World Risks?
The Art of Detecting Malicious Activity with Logs

New Technical Brief by Randy Franklin Smith

Mon, 14 Oct 2013 15:43:28 GMT

I have a new technical brief titled "Who, What, When, Where and Why: Tracking the 5 W's of Change in Active Directory, SharePoint, SQL Server, Exchange and VMware".

Your organization relies on you to prevent and detect tampering, unauthorized access or human error to your key enterprise technologies, including: Active Directory, SharePoint, SQL Server, Exchange and VMware.

In this brief, Windows security expert Randy Franklin Smith explores the 5 W's of auditing critical changes to your core technologies by discussing:

  • The types of activities that you can audit
  • How to enable auditing and where to find audit data
  • The hidden gaps, caveats and weaknesses of built-in auditing tools
  • How ChangeAuditor from Dell Software fills the gaps in auditing

You’ll come away with a better understanding of the limitations and capabilities of native auditing tools and why a third-party solution might be the best approach to protect your systems, data and your company’s productivity and bottom line.

Click here to read more.

email this digg reddit dzone
comments (0)references (0)

Related:
Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls
Auditing File Shares with the Windows Security Log
New Technical Brief by Randy Franklin Smith
Audit Myth Busters: SharePoint, SQL Server, Exchange

Following a User’s Logon Tracks throughout the Windows Domain

Tue, 17 Sep 2013 10:27:19 GMT

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.

email this digg reddit dzone
comments (0)references (0)

Related:
Virtualization Security: What Are the Real World Risks?
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Automating Review and Response to Security Events

Come to my session at HP Protect: Setting Traps for Malicious Outsiders and APTs on Your Network

Thu, 22 Aug 2013 13:28:35 GMT

 Are you registered for HP Protect 2013?  Can you come?  I hope to see you there
  • 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!
 

email this digg reddit dzone
comments (0)references (0)

Related:
Automating Review and Response to Security Events
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Virtualization Security: What Are the Real World Risks?
New Features in LogRhythm 4.0 Deserve a Place on Your Short List

Anatomy of Reflective Memory Attacks

Tue, 18 Jun 2013 14:22:44 GMT

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”.

 

email this digg reddit dzone
comments (0)references (0)

Related:
Anatomy of Reflective Memory Attacks
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
How to Use Process Tracking Events in the Windows Security Log
The Growing Threat of Friendly Fire from Vendors

Whitepaper: APT Confidential: 14 Lessons Learned from Real Attacks

Wed, 12 Jun 2013 11:55:24 GMT

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. 

email this digg reddit dzone
comments (0)references (0)

Related:
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Virtualization Security: What Are the Real World Risks?
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Automating Review and Response to Security Events

How to Use Process Tracking Events in the Windows Security Log

Mon, 13 May 2013 12:18:05 GMT

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.

Process Start

WinXP/2003

592

A new process has been created.

Subject:

Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1fd23

Process Information:

New Process ID: 0xed0
New Process Name: C:\Windows\System32\notepad.exe
Token Elevation Type: TokenElevationTypeDefault (1)
Creator Process ID: 0x8c0

Win7/2008

4688

Process End

WinXP/2003

593

A process has exited.

Subject:

Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1fd23

Process Information:

Process ID: 0xed0
Process Name: C:\Windows\System32\notepad.exe
Exit Status: 0x0

Win7/2008

4689

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.

email this digg reddit dzone
comments (0)references (0)

Related:
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Virtualization Security: What Are the Real World Risks?
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Automating Review and Response to Security Events

9 Mistakes APT Victims Make

Mon, 13 May 2013 12:06:56 GMT

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.

email this digg reddit dzone
comments (0)references (0)

Related:
9 Mistakes APT Victims Make
How to Use Process Tracking Events in the Windows Security Log
Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls
Auditing File Shares with the Windows Security Log

previous | next

powered by Bloget™