Tag Archive: splunk

This post will try to explain some relevant parameters from the ADFS side. I’m not saying the defaults aren’t good, that’s something you’ve got to decide for yourself.


WS-Fed/SAML protocol requirements: All time is UTC. ADFS will ignore system time and will use UTC.

Dates in SAML

A Security Assertion Markup Language(SAML) assertion might contain many attributes that contain dates. For example the following Conditions element of a SAML assertion has two date attributes:
<saml:Conditions NotOnOrAfter=”2013-07-29T23:49:40.051Z” NotBefore=”2013-07-29T23:39:40.051Z”>

Time in SAML elements is expressed in xs:dateTime format (xs is a XML format style). The Z at the end indicates that the Time Zone is Coordinated Universal Time (UTC) or Zulu time format. SAMLCore explicitly references “W3C XML Schema Datatypes specification [Schema2]” which in turn references ISO 8601.

Dates in OpenTokens

An OpenToken contains multiple dates. For example the following OpenToken contains three dates:


The format for OpenTokens also uses ISO 8601 which also uses UTC.
See also: Microsoft KB 884804 – How to convert UTC time to local time

WebSSOLifetime (Default 480 = 8 hours)

This parameter is server-wide. Meaning if you configure it, it’s active for all of the ADFS relying parties. Whenever a user asks a token for a given RP he will have to authenticate to the ADFS service first. Upon communicating with the ADFS service he will receive two tokens: a token which proves who he is (let’s call that the ADFS Token) and a token for the RP (let’s say the RP Token). All in all this seems very much like the TGT and TGS tickets of Kerberos.

Now the WebSSOLifetime timeout determines how long the ADFS token can be used to request new RP Tokens without having to re-authenticate. In other words a user can ask new tokens for this RP, or for other RP’s, and he will not have to prove who he is until the WebSSOLifetime expires the ADFS token.

TokenLifetime (Default 0 (which is 10 hours))

The TokeLifetime is now easy to explain. This parameter is configurable for each RP. Whenever a user receives a RP Token, it will expire at some time. At that time the user will have to go to the ADFS server again an request a new RP token. Depending on whether or not the ADFS Token is still valid or not, he will not have to re-authenticate.

One argument to lower the TokenLifetime could be that you want the claims to be updated faster. With the default whenever some of the Attribute Store info is modified, it might potentially take 10 hours before this change reaches the user in its claims.

NotBefore and NotOnOrAfter, NotBeforeSkew

Setting up federated trusts with third-party vendors to provide users with single sign on (SSO) is very common.  SAML2 is the preferred method for SSO authentication.  One issue with this method is ensuring the SAML tokens have a valid lifespan.  Basically, when does a token become valid and when is it no longer valid.  Built into the SAML specification, there is a <saml:Conditions> element, which contains two attributes; NotBefore and NotOnOrAfter.  The NotBefore attribute contains the date and time value that specifies when the assertion becomes valid.  The NotOnOrAfter attribute contains the date and time value that specifies when the SAML assertion is no longer valid.  Both must be UTC datetimes, without the time zone.  As long as the SAML token is being used between the NotBefore and NotOnOrAfter times the assertion will be valid.

But what happens when the IdP server time and the third-party server times are off by a few seconds, or even a couple of minutes?  Simple, authentication may fail because the third-party server may see the SAML as not yet valid.

Luckily, ADFS 3 (Windows Server 2012 R2) offers a simple solution.  A simple time skew value can be added to the relying party on the ADFS server.  This property is called NotBeforeSkew.  It contains the number of minutes to adjust the NotBefore value by.  Setting the NotBeforeSkew to a value of 5 will result in a NotBefore of -5 minutes.

The following PowerShell command can be used to set the NotBeforeSkew value.

Set-ADFSRelyingPartyTrust -TargetIdentifier "<replying party identifier>" -NotBeforeSkew 5




Download sysmon:

NEW: Sysmon 6.10 is available ! : https://technet.microsoft.com/en-us/sysinternals/sysmon  and how to use it:

NEW: WMI detections: https://rawsec.lu/blog/posts/2017/Sep/19/sysmon-v610-vs-wmi-persistence/

Installation and usage:

List of web resources concerning Sysmon: https://github.com/MHaggis/sysmon-dfir

Sysmon events table: https://rawsec.lu/blog/posts/2017/Sep/19/sysmon-events-table/

Mark russinovitch’s RSA conference: https://onedrive.live.com/view.aspx?resid=D026B4699190F1E6!2843&ithint=file%2cpptx&app=PowerPoint&authkey=!AMvCRTKB_V1J5ow

Sysmon config files explained:




View story at Medium.com

Else other install guides:

Sysinternals Sysmon unleashed



Detecting APT with Sysmon:




Sysmon with Splunk:



Sysmon log analyzer/parsing sysmon event log:





WEF: https://docs.microsoft.com/en-us/windows/threat-protection/use-windows-event-forwarding-to-assist-in-instrusion-detection

logparser: http://www.microsoft.com/en-us/download/confirmation.aspx?id=24659

logparser GUI: http://lizard-labs.com/log_parser_lizard.aspx

The NSA released a PDF entitled “Spotting the Adversary with Windows Event Log Monitoring” earlier this year. The good news is it’s probably one of the most detailed documents I’ve seen in a long time. Everything from setting up Event Subscriptions, to a hardened use of Windows Remote Management, including the use of authentication and firewalls, this document tells you how to securely setup an environment where you can natively consolidate and monitor event log based entries. In addition, the NSA goes onto cover a number of areas that should be monitored – complete with event IDs:



Event forwarding guidance: https://github.com/iadgov/Event-Forwarding-Guidance

Malware archeology cheat sheets: http://www.malwarearchaeology.com/cheat-sheets/

Machine-specific issues – which can be indications of malicious activity

  • Application Crashes
  • System or Service Failures
  • Kernel and Device Signing
  • The Windows Firewall

Administrator Activity – specific actions performed that may be suspect

  • Clearing of Event Logs
  • Software and Service Installation
  • Remote Desktop Logon
  • Account Usage

The bad news is you’re still left to sort out a TON of event log detail and interpret whether the entries are a problem or not.

Additionally: Changes to Group Policy only show up in the events as a change to the policy, but lack detail on exactly what was changed within the Group Policy.

To truly have a grasp on whether you have an “adversary” within or not and, if so, what that adversary is doing, you’re going to require a solution that not only collects events, but can correlate them into something intelligent. Your solution should:

  • Consolidate events
  • Focus on the events you are concerned about
  • Provide comprehensive detail about the changes to your systems, security and data

Three software solutions:

  • Netwrix Auditor for AD
  • Dell change auditor for AD
  • IBM QRadar (SIEM)

Splunk (SIEM)  : Splunk Windows Auditing using the NSA guide: https://github.com/anthonygtellez/windows_auditing

MS white-paper best practices to secure AD: http://aka.ms/bpsadtrd

MS Advanced threat analytics (MS ATA): https://www.microsoft.com/en-us/server-cloud/products/advanced-threat-analytics/

Windows Event IDs useful for intrusion detection:

Windows Vista events and above

Category Event ID Description
User Account Changes 4720 Created
4722 Enabled
4723 User changed own password
4724 Privileged User changed this user’s password
4725 Disabled
4726 Deleted
4738 Changed
4740 Locked out
4767 Unlocked
4781 Name change
Domain Controller Authentication Events 4768 TGT was requested
4771 Kerberos pre-auth failed
4772 TGT request failed
Logon Session Events 4624 Successful logon
4647 User initiated logoff
4625 Logon failure
4776 NTLM logon failed
4778 Remote desktop session reconnected
4779 Remote desktop session disconnected
4800 Workstation locked
4801 Workstation unlocked
Domain Group Policy 4739 Domain GPO changed
5136 GPO changed
5137 GPO created
5141 GPO deleted
Security 1102 Event log cleared
Software and Service Installation 6 New Kernel Filter Driver
7045 New Windows Service
1022, 1033 New MSI File Installed
903, 904 New Application Installation
905, 906 Updated Application
907, 908 Removed Application
4688 New Process Created
4697 New Service Installed
4698 New Scheduled Task
External Media Detection 43 New Device Information
400 New Mass Storage Installation
410 New Mass Storage Installation
Group Changes Created Changed Deleted Members
Added Removed
Security Local 4731 4737 4734 4732 4733
Global 4727 4735 4730 4728 4729
Universal 4754 4755 4758 4756 4757
Distribution Local 4744 4745 4748 4746 4747
Global 4749 4750 4753 4751 4752
Universal 4759 4760 4763 4761 4762