Archive for June, 2019


Need 2012 R2 Domain functional level on the forest to use authentication silos/policies

Their are part of the configuration partition (so, at the forest level), replicated on all domain controllers



There’s Something About Service Accounts



The exact command being run is: psexec.exe \\admin-pc -accepteula cmd /c (cd c:\temp ^& mimikatz.exe “privilege::debug” “sekurlsa::tickets /export” “exit”) (see the ATA playbook above) ↩︎

Full article:



At its most basic, SMB is a protocol to allow devices to perform a number of functions on each other over a (usually local) network. SMB has been around for so long and maintains so much backwards compatibility that it contains an almost absurd amount of vestigial functionality, but its modern core use is simpler than it seems. For the most part, today SMB is used to map network drives, send data to printers, read and write remote files, perform remote administration, and access services on remote machines.

SMB runs directly over TCP (port 445) or over NetBIOS (usually port 139, rarely port 137 or 138). To begin an SMB session, the two participants agree on a dialect, authentication is performed, and the initiator connects to a ‘tree.’ For most intents and purposes, the tree can be thought of as a network share.[1] The PCAP below, shown in Wireshark, demonstrates a simple session setup and tree connect. In this case, the machine is connecting to the “c$” share (equivalent to the C:\ drive) on the machine, which is called “admin-pc


When you connect to remote Server Message Block (SMB) services shares by using \\192.x.y.z\share name, Kerberos is not used, and the Internet Protocol (IP) SMB file share access does not use Kerberos. A network trace shows the following Kerberos error in the KRB_ERROR: Server not found in Kerberos database


By default, Microsoft Windows Server 2003 and Microsoft Windows 2000 try to use Kerberos as the security provider. When a client uses Kerberos to authenticate itself to a server, the client requests a session ticket for the Service Principal Name (SPN). IP addresses are not names, so Kerberos is not used. After this occurs, the server goes through the list of the other supported security providers.


This behavior is by design.
IP addresses typically change, and it is not workable to add these addresses as SPNs. An SPN can be one of the following:

•The DNS name for the domain.
•The DNS name of a host.
•The distinguished name of a service connection point object.

Change coming in July 2019



KB 4490425:



To help determine if any applications or accounts are using the unsafe delegation, use the following resources:

  • PowerShell
    • A quick command can be run against a trust from PowerShell that will determine if the flag is set on an inbound trust. Run this command from the forest that has the inbound trust:
      Get-ADTrust -Filter {Direction -eq "Inbound"} | ft Name,TGTDelegation

      The value returned from the above command is counterintuitive and is backwards from what you might expect:

      • FALSE – A return of false means that the delegation is enabled and is in the unsafe state.
      • TRUE – A return of true indicates that the delegation is disabled and is in the safe state.
    • A script has been created that can scan forests that have incoming trusts that allow TGT delegation.
    • Refer to this support article for the PowerShell code:
      KB4490425 – Updates to TGT delegation across incoming trusts in Windows Server
    • Copy and Paste the code from the support article into a file named Get-RiskyServiceAccountsByTrust.ps1
    • There are two options switches that the script can be executed with:
      • -Collect will output any principals that have unconstrained delegation.
        Get-RiskyServiceAccountByTrust.ps1 -Collect
      • -Collect -Scanall will output security principals that have unconstrained delegation and search across trusts that do not allow TGT delegation
        Get-RiskyServiceAccountByTrust.ps1 -Collect -ScanAll

      Example of Output:

  • Event Viewer/Event Logs


There are three kinds of Kerberos delegation in Active Directory:

  • Unconstrained
    When a Domain Administrator configures a service’s account to be trusted for unconstrained delegation, that service has the ability to impersonate any user account to any other service. This is the most insecure delegation option, because a service could impersonate any user to any other service it likes. For a regular user account, not so bad, but for a Domain Admin or an Enterprise Admin, a rogue service could request information from the domain or change user account or group permissions in the name of the privileged account. For this reason, unconstrained Kerberos delegation is a high security risk.
  • Constrained
    First introduced with Windows Server 2003, constrained delegation allows an administrator to limit the services to which an impersonated account can connect to. Constrained delegation is difficult to configure and requires unique SPN’s to be registered as well as Domain Admin rights to implement. Constrained delegation cannot cross domain or forest boundaries.
  • Resource-based Constrained
    First introduced with Windows Server 2012, Resource-based constrained delegation improved on the constrained delegation introduced with Windows Server 2003. It eliminated the need for SPNs by switching to security descriptors. This removed the need for Domain Admin rights to implement and allowed server administrators of backend services to control which service principals can request Kerberos tickets for another user. Resource based allows delegation across domain and forest boundaries.

For more information on Kerberos delegation, refer to this documentation:

Kerberos Constrained Delegation Overview


SecOps experience news ! Unified on MCAS, Azure ATP and Azure AD identity protection:

Microsoft has three identity-centric security products offering detection capabilities across on-premise and in the cloud:

  • Azure Advanced Threat Protection (Azure ATP) identifies on-premises attacks
  • Azure Active Directory Identity Protection (Azure AD Identity Protection) detects and proactively prevents user and sign-in risks to identities in the cloud
  • Microsoft Cloud App Security (MCAS) identifies attacks within a cloud session, covering not only Microsoft products but also third-party applications

Azure ATP:


Latest on premise ATA version: ATA v1.9 :

ATA forum:



Technet resource:

Suspicious activity guide:

ATA simulation playbook:


ATA powershell module:

(copied under \\\microsoft\microsoft ATA\)

News from pentesters:


What’s new in ATA version 1.8

New & updated detections

  • NEW! Abnormal modification of sensitive groups – As part of the privilege escalation phase, attackers modify groups with high privileges to gain access to sensitive resources. ATA now detects when there’s an abnormal change in an elevated group.
  • NEW! Suspicious authentication failures (Behavioral brute force) – Attackers attempt to brute force credentials to compromise accounts. ATA now raises an alert when an abnormal failed authentication behavior is detected.
  • NEW! Remote execution attempt – WMI exec – Attackers can attempt to control your network by running code remotely on your domain controller. ATA added detection for remote execution leveraging WMI methods to run code remotely.Reconnaissance using directory services queries– In ATA 1.8, a learning algorithm was added to this detection allowing ATA to detect reconnaissance attempts against a single sensitive entity and improve the results for generic reconnaissance.
  • Kerberos Golden Ticket activity ATA 1.8 includes an additional technique to detect golden ticket attacks, detecting time anomalies for Kerberos tickets.
  • Enhancements to some detections, to remove known false positives:
    • Privilege escalation detection (forged PAC)
    • Encryption downgrade activity (Skeleton Key)
    • Unusual protocol implementation
    • Broken trust


  • NEW! More actions can be made to suspicious activities during the triage process.
    • Exclude some entities from raising future suspicious activities. Prevent ATA from alerting when it detects benign true positives (i.e. an admin running remote code or using nslookup) or known false positives (don’t open a Pass-The-Ticket alert on a specific IP).
    • Suppress a reoccurring suspicious activity from alerting.
    • Delete suspicious activities from the timeline.
  • A more efficient triage – The suspicious activities time line has gone through a major process of re-design. In 1.8, a lot more suspicious activities will be visible at the same time, and will contain better information for triage and investigation purposes.


  • NEW! Summary report. An option to see all the summarized data from ATA, including suspicious activities, health issues and more. It’s possible to define a reoccurring report.
  • NEW! Modification to sensitive groups report to see all the changes made in sensitive groups during a certain period.


  • Lightweight Gateways can now read events locally, without configuring event forwarding
  • Feature flags were added for all detection, periodic tasks and monitoring alerts
  • Accessibility ramp up – ATA now stands with Microsoft in providing an accessible product, for everyone.
  • E-mail configuration for monitoring alerts and for suspicious activities are separated


  • NEW! Single sign on for ATA management.
    • Gateway and Lightweight gateway silent installation scripts will use the logged on user’s context, without the need to provide credentials.
  • Local System privileges removed from Gateway process
    • You can now use virtual accounts (available on stand-alone GWs only), managed service accounts and group managed service accounts to run the ATA Gateway process.
  • Auditing logs for ATA Center and Gateways were added and all actions are now logged in the event viewer.Added support for KSP Certificates


Version: 1.7

Reference articles:

ATA on Technet:

ATA events:

ATA deployment demo:


Additional resources:

Powershell windows forensics:

Powershell windows forensics:

Powershell windows forensics: