Jaa


Leveraging OMS Log Search to Identify Potential Access Violation Activities

In this post, we look at how we can leverage the Security and Audit solution in OMS and using log searches to identify potential access violation security activities based on the audit events theAudit Collection Services (ACS) in OpsMgr collects and reports on.

In ACS, there are 2 SSRS audit reports available out-of-the-box that allow the user to report on security events occurring in their IT environment that are related to Access Violation activities:

  1. The Access Violation: Account Locked Report, and
  2. The Access Violation: Unsuccessful Logon Attempts Report

The Security and Audit solution in OMS Log Analytics however provides a comprehensive view into your organization’s IT security posture with built-in search queries for notable issues that require your attention.
Adding the Security and Audit solution to an OMS workspace will allow Windows security events, Windows application events, and Windows firewall logs to be collected using direct agents or MMA agents that the user enabled.
For further information, refer to Security and Audit solution in Log Analytics by Bill Anderson.
To retrieve and analyze the security events highlighted by these 2 ACS Audit Reports in OMS Log Analytics, the SQL query search conditions used in these reports can be used as the filter expressions in OMS log search queries against records collected by the Security and Audit solution.

Access Violation: Account Locked Report:

The report returns a list of user accounts that were locked out within a given date/time range by searching for security events 4740 and 6279 stored in the ACS database.
Running this report for a specific date/time range via the Reporting workspace in the OpsMgr Operations Console or the Reporting site will produce the following SSRS Report:

image

Here is an example of a 4740 – A user was locked out security event as shown at the Windows Security Auditing technical documentation on TechNet:
For more information about Event 4740, visit https://technet.microsoft.com/en-us/itpro/windows/keep-secure/event-4740

image

The SQL query used in the RDL file of the Account Locked Report is:

SELECT CreationTime AS DateTime, TargetDomain AS Domain, TargetUser AS UserAccountFROM AdtServer.dvAllWHERE (EventId = 539 OR EventId = 644 OR EventId = 4740 OR EventId = 6279) AND (CreationTime >= @StartDate) AND (CreationTime <= @EndDate)

The search condition from this SQL Query can be used as the filter expression of OMS log searches against Security and Audit solution records like the following examples:

  • A search query to return all records of type SecurityEvent with EventID field containing 539 or 644 or 4740 or 6279:

    SecurityEvent
    | where EventID==539 or EventID==644 or EventID==4740 or EventID==6279
    EventID=539 OR EventID=644 OR EventID=4740 OR EventID=6279

  • A query to compare the number of records of type SecurityEvent with EventID field containing 539 or 644 or 4740 or 6279, grouped by EventID in sortable order within a specific time period:

    SecurityEvent
    | where EventID==539 or EventID==644 or EventID==4740 or EventID==6279
    | summarize count() by EventID

     

Access Violation: Unsuccesful Logon Attempts Report:

The report returns a list of logon attempts from user accounts that were unsuccessfulwithin a given date/time range by searching for security event 4625 stored in the ACS database. Large number of unsuccessful logon attempt for the same user or computer may indicate a potential intrusion.
Running this report for a specific date/time range via the Reporting workspace in the OpsMgr Operations Console or the Reporting site will produce the following SSRS Report:

image

Here is an example of a 4625 – An account failed to log on security event as shown at the Windows Security Auditing technical documentation on TechNet:
For more information about Event 4625, visit https://technet.microsoft.com/en-au/itpro/windows/keep-secure/event-4625

image

The RDL file of the Unsuccessful Logon Attempts Report uses a Semantic Query, with the following filter condition used:
Dv Alls with: All of (Start Date on or after (prompted), End Date on or before (prompted), Any of (Event Id from 529 to 537, Event Id = 539, All of (Event Id = 4625, Status = “0xc000006d”)))

The filter condition from this Audit Report can be used as the filter expression of OMS log searches against Security and Audit solution records like the following examples:

  • A search query to return all records of type SecurityEvent with EventID field containing 529-537 or 539 or 4625 and Status field containing 0xc000006d, limiting the result to the TargetAccount, IpAddress, Computer, LogonProcessName, AuthenticationPackageName and LogonTypeName fields:

    SecurityEvent
    | where EventID between (529 .. 537) or EventID==539 or (EventID==4625 and Status=="0xc000006d")
    | project TargetAccount, IpAddress, Computer, LogonProcessName, AuthenticationPackageName, LogonTypeName

    Here is an example of what the records returned would look like when using this log search query:
    image

  • A query to compare the number of records of type SecurityEvent with EventID field containing 529-537 or 539 or 4625 and Status field containing 0xc000006d, grouped by TargetAccount in sortable order within a specific time period:

    SecurityEvent| where EventID between (529 .. 537) or EventID==539 or (EventID==4625 and Status==”0xc000006d”)
    | summarize EventCount=count() by TargetAccount
    | order by EventCount desc

    Here is an example of what the result would look like when using this log search query:

    image 

To view the complete mapping between all Audit Collection Services (ACS) SSRS reports and search queries used in OMS Log Analytics, refer to:
https://blogs.msdn.microsoft.com/wei_out_there_with_system_center/2016/07/25/mapping-acs-reports-to-oms-search-queries/

 

Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.