Security, et al

Randy's Blog on Infosec and Other Stuff

NEW Free & Easy to Use Tool, Event Log Forwarder for Windows

Sun, 22 Feb 2015 22:13:47 GMT

Right or wrong, Syslog remains the de facto standard protocol for log forwarding. Every SIEM and log management solution in the world accepts syslog. So frequently you run into the situation of needing to forward Windows events via syslog. But Windows doesn’t support syslog and the “free” forwarders I’ve looked at in the past were just not pretty. Some even written in Java. Ugh. Besides being klunky and hard to configure they weren’t flexible in terms of which event logs they could forward much less which events within those logs.

But SolarWinds has just released a new and completely free Event Log Forwarder for Windows (ELF). ELF takes seconds to download, seconds to install and a minute to configure. Just select the logs you want to forward (below example shows successful and failed logons and process start events from the security log):

and specify the address of your syslog server:

ELF runs as a background service and immediately starts sending events out via syslog as you can see here on my syslog server.

I love how easy it is to filter exactly which events are sent. This allows you to filter out noise events at their source – conserving bandwidth and log management resources all the way down the line.

But what if you have many systems that need to be configured to forward events? I took a look at the folder where ELF was installed and found a LogForwarderSettings.cfg file that is very easy to read. Moreover there’s even a LogForwarder.PDF file in the Docs folder that fully documents this settings file. I don’t see anything installation dependent in this file so it looks to me like you could use the ELF GUI Client to configure one installation and then copy LogForwarderSettings.cfg to all the other systems where you want the same behavior.

You can download SolarWinds Event Log Forwarder here

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


Randy's Review of a Fast, Easy and Affordable SIEM and Log Management

Thu, 29 Jan 2015 17:46:06 GMT

One of the most frequent complaints I hear from you folks is “We need a SIEM but can’t afford the big enterprise solutions.”  And as a tech-heavy small business owner I truly understand the need for software that installs in minutes and doesn’t require a ton of planning, learning, design and professional services before you start getting results.

Well, I’ve installed SolarWinds Log and Event Manager (LEM) in my lab and I can say that it is all of the above and more.  There’s actually no install of software or provisioning of a server because it’s a prebuilt virtual appliance.  When you download and run the LEM install package it simply unpacks the OVA template.  You just open VMWare or Hyper-V, deploy a new VM from template and point it at the file from SolarWinds.  After it boots up for the first time all you have to do is point your web browser at its DHCP assigned address which you can see in VMWare or Hyper-V.  Answer a few configuration questions such as static IP address and you are up and running.  To start pulling events from your servers click on Ops Center and click on the green plus sign.  We’re talking minutes.

LEM has all the features you need and expect from a SIEM.  And it’s flexible; you can monitor server logs with or without agents and you can also accept SNMP traps and Syslog flows from devices and UNIX/Linux systems. 

LEM is affordable, too.  It starts at $4495 and monitors up to 30 servers.  That’s the total price – no server OS or databases to license much less manage.

Since there’s such a need for affordable SIEM and log management and so many of you in my webinar are still trying get by with free utilities I’ve partnered with SolarWinds to raise awareness about LEM.  Please download it and try it out.  Even if you don’t have a virtualization server, you can still run the virtual appliance with a free desktop virtualization program like VM Player.  

LEM is affordable but it’s not “cheap” software.  LEM is actually one of the few SEIMs out there that implements my #1 feature: normalization and categorization.  LEM understands what events actually mean from each of the many, many log sources it supports.  By that I mean that whether the event comes from Linux, Windows, Cisco or anything other source if it’s a logon event (for instance) it gets parse and categorized as such.  This is important because every log source out there logs the same kind of events but in a different format.  None of us have time to learn all the formats and arcana out there about each log source.  LEM’s normalization makes so many things not only possible but also effortless.  For instance “show me all failed logon events for Randy Smith across all my systems and devices regardless of log source and format”.  Voila!

So, please, take a look at LEM.  Download it here.  

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


Seven Steps to Designating Owners of Unstructured Data

Wed, 08 Oct 2014 15:17:27 GMT

Many organizations are seeing surges in the amount of unstructured data in their environments, even as new data breaches come to light every week. As a result, those organizations face increased audit and regulatory pressure regarding loose access controls over unstructured data that might contain sensitive information such as Social Security numbers, credit card data, health care information and proprietary data.

Download this white paper to discover:

  • How unstructured data can lead to increased costs and security vulnerabilities
  • A seven-step process for establishing information owners for unstructured data
  • A solution that helps automate the complex processes of governing and controlling unstructured data

Click here to download the white paper.

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


Comparison: SQL Server Audit vs. SQL Trace Audit for security analysts

Tue, 07 Oct 2014 18:19:23 GMT

I just wrote a new whitepaper about SQL auditing. 

Security analysts must have meaningful, relevant audit data from the mission critical applications such as SQL Server. Database admins must have no disruptions nor degradation to the performance of the mission critical instances of SQL Server. Beginning with SQL Server 2008,versions of Microsoft SQL Server offer a new, superior SQL audit capability custom-built to meet demands.... continue reading over at click here.

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


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:

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.

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

Share Information:
  Share Name: 
  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. 


A network share object was accessed


A network share object was added.


A network share object was modified


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.

  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: 
  Share Path:  \??\C:\Windows\SYSVOL\sysvol
  Relative Target Name:\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\Machine\Microsoft\Windows NT\Audit\audit.csv

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

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)


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:



Allow right

Deny right


Interactive (logon at keyboard and screen of system)


Allow logon locally


Deny logon locally


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


Access this computer from the network


Deny access to this computer from the network


Batch (i.e. scheduled task)


Log on as a batch job


Deny logon as a batch job


Service (Service startup)


Log on as a service


Deny logon as a service


RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance)


Allow logon through Terminal Services


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


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:

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)


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)


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:

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)


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)


previous | next

powered by Bloget™


Recent Blogs