• Allow organisations to forward and store specific events of different values and frequency events into separate buckets for basic viewing and/or future import into a SIEM
• Provide rudimentary viewing buckets for quick glance at low volume but high value long term events
• Enable the capability to collect security audit events in DEV/TEST style environments that for whatever reason are not monitored by a SIEM.
• Reduce the attack surface of high value assets by eliminating the requirement for yet another C2 agent with local system privileges.
• Enable highly network isolated environments that can't connect to on-premises SIEM's or a cloud security monitoring solution keeping the native format to allow manual future analysis through manual imports and analysis.

1. Create the custom views .xml files and place them in %programdata%
2. Creates the manifest file and provides instructions to use the Windows SDK to compile and load the .dll
3. Prepares the Event Channels b to receive events and subsequently archive the existing .evtx once it hits 1GB
4. Import the WEC subscription configurations ready to be enabled (manual intervention required to enable by default)

[caption id="attachment_525" align="aligncenter" width="1024"] Enabled WEC Subscriptions with 1 DC connected[/caption]

• Your Domain Controllers in this scenario need to have the appropriate Advanced Audit Subcategories enabled.
• You don't have to enable every subscription at once. Enable a single subscription or just a category eg.. the Object Management category to understand how it works.
• The logs folder will have NTFS compression enabled. This reduces .evtx size by roughly half
• Once an individual .evtx log file hits 1GB, it will be archived by the Event Log service and a new one created.
• ZIP Compressing the .evtx file will result in an rough 60-70MB file.
• If your having issues, check the "Windows Event-Forwarder" plugin on the DC to confirm it has connect the WEC server and succesfully received subscriptions.
• A script to manage the compression of the archived (non-active) .evtx files is nearly completed.
• All .PS1 and the pre-canned .DLL file is AuthentiCode signed. Your machines will (should) not trust my signing certificate by default but should validate they have not been tampered with.

• A domain members version (preview custom view in release 1.3) which covers the events from Jessica's MSAU 2015 Ignite session Monitoring what matters – Windows Event Forwarding for everyone (even if you already have a SIEM.)
• A pre-canned .DLL for AD Certificate Services (AD-CS) to collate Issued, Pending, Revoked certificate and service operations.
• Custom views for the WEC server to allow further quick discovery eg... Show RC4, AES128 and AES256 Kerberos AS requests

• Domain Controller (Windows Server 2000)
• Domain Controller Authentication (Windows Server 2003)
• Kerberos Authentication (Windows Server 2008 and above)

Certificate Authority - Certificate Template Prep

1. On your Enterprise Issuing CA, open "certsrv.msc" and right-click the "Certificate Templates" folder and select "Manage". This will show you all the templates present in the Active Directory forest.
2. Scroll down until your find "Kerberos Authentication". Right-click it and select "Duplicate"
3. If you are on 2012/2012R2, you will be presented with the compatibility screen. Unless you know what you’re doing with version 3/4 templates, simply select "Windows Server 2008 R2" and "Windows 7/Windows Server 2008 R2" for both of the options and select OK on the confirmation prompts.
4. On the "General" tab, give your new template the name "Kerberos Authentication (Offline Request)". In production environments, prefixing the name with a few letters can help group your active templates together in the UI, recommended but optional.
5. Now, to make it an Offline Template, simply head over the "Subject Name" tab and select the top radio box "Supply in the Request". Click OK on the security warning prompt. Please read an understand this prompt. In our scenario, only DCs have the ability to request this certificate, but with other certificate templates, the ticking of this box should be done only if restricted and trusted users can request the template. [caption id="attachment_455" align="aligncenter" width="300"] Use Subject in Auto Enrollment Renewals[/caption]
6. Also on the "Subject Name" tab, tick the "Use subject information from existing certificate for autoenrollment renewal requests". This tick box is critical to the “magic sauce” that allows the CA Policy engine to reuse the existing certificate subject name values instead of being provided as brand new ones in the CSR. (This is an offline request, the names can't be built from Active Directory)
7. Next, open the "Security" tab and remove the “Enroll” security right from "Domain Controllers","Enterprise Domain Controllers" and "Enterprise Read-only Domain Controllers”.
8. Add new ACE’s for each of the special DC’s (or possibly a security group with them in) that are to receive the custom certificates and ensure they have the “Read" and "Enroll” security right only. Check that no other entries include Enroll or Autoenroll except administrative user groups. Make sure you enable "Computer Objects" in the select objects prompt.
9. Optional. For advanced players, head over to the "Superseded Templates" tab and add the "Domain Controller", "Domain Controller Authentication" and "Kerberos Authentication" templates to the list. This will "archive" any certificates from those templates when this new one is enrolled. Note. Archived = hidden, not deleted.
10. Close the new template to save it.
11. Now that our new template for the "special" DC's is ready to go, open the original “Kerberos Authentication” template and the security tab. Add the Deny “Enroll” and "Auto Enroll" right to the special DC’s you are giving custom certificates to. This will stop them from getting the standard Kerberos Authentication certificates during the auto enrolment process.
12. As per normal, we need to actually issue the template. Right-Click "Certificate Templates" again and select "New" and "Certificate Template to Issue"
13. From the list, select your newly minted "Kerberos Authentication (Offline Request)" template and click OK.
14. Optional - If both the original "Online" and our new "Offline Kerberos Authentication" templates are present in the issuance list, remove the older "Domain Controller" and "Domain Controller Authentication" templates. Simply right-click them and select "Delete". This doesn't remove template itself from Active Directory, just their issuance from this particular CA. If you have multiple CAs, it's a good idea to remove their issuance form them as well. Should you issue the "Kerberos Authentication" templates from multiple CAs? You can, but not really required.

Domain Controller - GPO Prep

 Domain Controller - Initial Enrollment

1.  On one of our special Domain Controllers, Open "certlm.msc". If it's a 2008 R2 DC, you will need to open "mmc.exe" and add the "Certificates" snap-in targeting the local computer.
2. Right-Click the "Personal" store and select "Request New Certificate". Click "Next" twice until the screen with available templates appears. Select the check box next to our "Kerberos Authentication (Offline Request)" Template and then click the hyperlink "More Information is required ...." below the name.
3. Leave the "Subject Name" blank, but add the following to the alternative name section. The first 3 are the names that are added automatically with the built-int template. The last one is our new custom name. They are all of the type "DNS"FQDN of the AD Domain Controller FQDN of the AD Domain NetBIOS name of the AD Domain Your new custom secure LDAP DNS name [caption id="attachment_435" align="aligncenter" width="300"] Subject Alternative Names[/caption]  
4. Click "OK" once you have finished adding the names and then "Enroll" to send the CSR to the Enterprise Issuing CA for issuance.
5. When complete, expand the Personal -> Certificates folder and check out your shiny new cert. Double-click the certificate to open it and confirm the names present in the Subject Alternate Name extension. If there are multiple certificates, you can scroll the console window to the right to see the template names.
6.  Repeat the process on the other special DCs you wish to create a custom secure LDAP certificate for.

Domain Controller - Verifying renewal will work

1. Open “certsrv.msc” on your Enterprise Issuing CA and right-click the “Certificate Template” folder and select "Manage" to open the Certificate Templates Console.
2. Open the security tab of our "Kerberos Authentication (Offline Request)" template and simply add the “Auto-Enroll” security right/flag to the existing ACEs for our special DCs. This will allow the auto enrollment client on our special DCs to now consider this template as part of its automatic renewal process and also monitor the template version for update requests. Close the certificate template properties to save it.
3. Right-click our "Kerberos Authentication (Offline Request)" template and select "Reenroll All Certificate Holders". If you have a keen eye, you will notice the version will change from something like 100.2 to 101.0. The minor version (the second number) will increase every time you make a change to the certificate template. Increasing the minor version won't affect already issued certificates. Increasing the major however instructs clients with the second auto enrolment client check box enabled to renew this certificate at their next update cycle. We want to trigger this to ensure everything works a treat.
4. Back on your DC, feel free to wait around until this occurs or you can run "certutil -pulse". If you really love your GUI, in the certificates console, right-click "Certificates - Local Computer" at the top of the left-hand tree and select "All Tasks" -> "Automatically Enroll and Retrieve Certificates"
5. It may take a few minutes, but once it's completed (all going well), you should be able to analyse the "Certificate Template" field in your "Kerberos Authentication (Offline Request)" certificate and see the major version field matches the increased version of your certificate template. If the version hasn't increased, confirm your GPO and certificate template settings. See below on how to view your older archived certificates (including any superseded ones)
6. Once again, validate all your subject names are correct and expected. The next section can make things a little easier. [caption id="attachment_445" align="aligncenter" width="1024"] Old and New Template Versions[/caption]

 LDAP/S (TCP 636) Validation

Some Pre-emptive Q&A's

cd Cert:\LocalMachine\My
ls -force
$Cert = Get-Item <ThumbprintOfNewCert>
$Cert.Archived = $True
$Cert = Get-Item <ThumbprintOfOldCert>
$Cert.Archived = $False

 Wrapping Up

How does it happen?

1. You need to have PASSWD_NOTREQD enabled on your userAccountControl attribute and
2. Have a password not set at creation time OR have privileged user exercise the "Reset-Password" security right and simply press enter on the password change prompt to grant the account a blank password.

So I have "X" amount of accounts in my report, can you tell me how many have blank passwords?

Cleanup Aisle 3

# Report on Affected Accounts
$StatusLog = @()
Get-ADUser -Filter 'useraccountcontrol -band 32' -Properties "passwordnotrequired","useraccountcontrol","msDS-LastSuccessfulInteractiveLogonTime","lastLogonTimestamp" | Select-Object -Property DistinguishedName,Enabled,PasswordNotRequired,"msDS-LastSuccessfulInteractiveLogonTime","lastLogonTimestamp" | Out-GridView -Wait
# Attempt to remediate and log output
$Response = Read-Host "`nDo you want to attempt to remove PASSWD_NOTREQD from the listed accounts?"
If($Response.ToLower() -eq "y"){
 ForEach ($Account in (Get-ADUser -Filter 'useraccountcontrol -band 32')){
 $Status = "" | Select Status,Account 
 $Status.Account = $Account 
 Get-ADUser $Account | Set-ADUser -PasswordNotRequired $False -ErrorAction SilentlyContinue
 If($?){
 Write-Host "Succesfully removed PASSWD_NOTREQD from $Account" -ForeGroundColor Green
 $Status.Status = "Success"
 }
 Else{
 Write-Host "Failed to remove PASSWD_NOTREQD from $Account" -ForeGroundColor Red
 $Status.Status = "Failure"
 }
 $StatusLog += $Status
 }
}
Write-Host $StatusLog.Count "accounts processed. Refer to FIX_PASSWD_NOTREQD.csv for full details"
$StatusLog | Export-CSV -NoTypeInformation FIX_PASSWD_NOTREQD.csv

Final Words

• If you don't have it already laying around, grab a copy of the Windows SDK for your OS. Why? We need to compile a .dll. I'm not a programmer and I don't understand what resource and link files are, but thankfully you don't really need to.
• Right-click to download the template "manifest" file from this blog post and rename it to .man from .txt.
• A machine to configure all of this on. I used a throw away virtual machine with Windows Server 2012 R2 and the Windows 8.1 SDK from above to perform these steps.

Create our Custom Event DLL and Manifest

1. Go ahead and install your Windows SDK to your machine. I only applied the core SDK itself to the default install location.
2. Now open the Manifest Generator which you will find at "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\ecmangen.exe"
3. Open the starter template manifest file from above. The screen should look something like this
4. The channels you see here are really the goal. Any channels you create here are will show up in Event Viewer and also be available for selection in our event collector subscriptions.
5. Modify the Name and Symbols to your hearts content. You can add a maximum of 8 channels per provider.
6. If you want, feel free to also change the "WEC" at the root of the events section to something else.
7. Save the .man file to somewhere on your drive. For the next few steps, I used the path "C:\ECMan" on my machine
8. Now execute the following commands to build our .dll

   cd\ECMan
   "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\mc.exe" C:\ECMan\CustomEventChannels.man
   "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\mc.exe" -css CustomEventChannels.DummyEvent C:\ECMan\CustomEventChannels.man
   "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\rc.exe" C:\ECMan\CustomEventChannels.rc
   "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /win32res:C:\ECMan\CustomEventChannels.res /unsafe /target:library /out:C:\ECMan\CustomEventChannels.dll C:\ECMan\CustomEventChannels.cs

9. The output of the folder post processing  should now look like the following
10. Take a copy of the highlighted .man and .dll files and place them in your "C:\Windows\System32" folder on your Windows Event Collector server.
11. We don't need this machine any more (unless you want to create more)

Load It Up

1. Open an elevated command prompt, and execute the following

   wevtutil im c:\Windows\system32\CustomEventChannels.man

2.  If everything goes well, there should be zero console feedback. Now open Event Viewer (re-launch if it's already open) and you should now have your new custom folders ready to select in your WEC subscriptions (the pic below was taken after the subscription was configured and the log receiving events)
3. The last thing before we start using them in anger, is to actually give the logs some configuration. The following commands will do the job easily for us. Below is an example for moving the WEC-Domain-Controllers custom log to E:\Logs and configuration a maximum size of 1GB. You can also right-click the log and configure the standard properties that way too.

   wevtutil sl WEC-Domain-Controllers /lfn:E:\Logs\WEC-Domain-Controllers.evtx
   wevtutil sl WEC-Domain-Controllers /ms:1073741824

4. The last piece of the puzzle is simply telling our event subscriptions to dump the events there instead of our old friend Forwarded Events.

Short Version

What does the cmdlet actually do?

First Steps

Checking a single CDP

CDP - The URL path to the CRL file to be checked. ServerIP - The IP to use directly. If omitted, a DNS lookup is performed. WarningHours - Use to define or override the warning period

Import-Module .\CRLFreshCheck.psm1 -Function Get-CRLFreshness
Get-CRLFreshness -CDP "http://crl.microsoft.com/pki/mscorp/crl/msitwww2.crl"

A Real World Example

CASubjectCN,CDP,ServerIP,WarningHours
Baltimore CyberTrust Root,http://cdp1.public-trust.com/CRL/Omniroot2025.crl,,0
Baltimore CyberTrust Root,http://cdp1.public-trust.com/CRL/Omniroot2025.crl,117.18.237.191,120
Microsoft IT SSL SHA1,http://crl.microsoft.com/pki/mscorp/crl/msitwww1.crl,,0
Microsoft IT SSL SHA1,http://crl.microsoft.com/pki/mscorp/crl/msitwww1.crl,23.205.115.152,0
Microsoft IT SSL SHA1,http://crl.microsoft.com/pki/mscorp/crl/msitwww1.crl,23.205.115.144,0
Microsoft IT SSL SHA1,http://mscrl.microsoft.com/pki/mscorp/crl/msitwww1.crl,,0
Microsoft IT SSL SHA1,http://mscrl.microsoft.com/pki/mscorp/crl/msitwww1.crl,68.232.45.201,0
Microsoft IT SSL SHA2,http://crl.microsoft.com/pki/mscorp/crl/msitwww2.crl,,0
Microsoft IT SSL SHA2,http://crl.microsoft.com/pki/mscorp/crl/msitwww2.crl,23.205.115.152,0
Microsoft IT SSL SHA2,http://crl.microsoft.com/pki/mscorp/crl/msitwww2.crl,23.205.115.144,0
Microsoft IT SSL SHA2,http://mscrl.microsoft.com/pki/mscorp/crl/msitwww2.crl,,0
Microsoft IT SSL SHA2,http://mscrl.microsoft.com/pki/mscorp/crl/msitwww2.crl,68.232.45.201,0

Import-Module .\CRLFreshCheck.psm1 -Function Get-CRLFreshness
Get-CRLFreshness -Batch -InputFIle .\MSIT.csv

Wrapping Up

• Password Never Expires (DONT_EXPIRE_PASSWD)
• User Cannot Change Password (PASSWD_CANT_CHANGE)
• Account is Disabled (ACCOUNTDISABLE)

• Password Not Required (PASSWD_NOTREQD)
• Account is Sensitive and Cannot be Delegated (NOT_DELEGATED)
• Account is Trusted For Kerberos Delegation (TRUSTED_FOR_DELEGATION)
• Account is Trusted for Kerberos Delegation with Protocol Transition (TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION)

Query UserAccountControl Script

.\Query-UserAccountControl.ps1 -Server "dc1.contoso.com"
Note: Some files will always be empty as their flags are not used. Account Lockout is such an example.

A Simple Check

 OK, how badly am I affected?

# Enable Simple LDAP Bind Logging 
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

# Disable Simple LDAP Bind Logging.
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 0

Note: You may need replace the double quotes after copy+paste.

Custom Event View

1. Open Event Viewer.
2. Right-click "Custom Views" then select "Import Custom View".
3. Provide a path to the downloaded .xml file. Feel free to rename it/change the description and location as you see fit.
4. If you are doing this on a management server (and you should be) you will get an error about the service channel being missing. Once you bind to the appropriate Domain Controller, it will show the appropriate events.

Insecure LDAP Binds Query Script

.\Query-InsecureLDAPBinds.ps1 -ComputerName dc1.contoso.com -Hours 24

"IPAddress","Port","User","BindType"
"10.0.0.3","60901","CONTOSO\Administrator","Simple"
"[::1]","65445","CONTOSO\Administrator","Simple"

Fixing Your Applications

Conclusion