Hijacking Playing with MIT Kerberos Authentication Tickets

I often end up reading about kerberos authentication especially MIT open source  version and Heimdal Kerberos authentication. Just an interesting protocol to read to understand bit more on  how MIT Kerberos Distribution Center (KDC) inner functionality works.

The objective with this article is to play with MIT KDC and some of the tricks i would use during authorized penetration testing and red team engagements to circumvent technical security controls and avoid blue team to recon, compromise and move laterally.

We all familiar with Windows Active Directory Key Distribution Center and widely deployed in large network enterprise – MIT Kerberos authentication provides similar authentication functionality used in Linux environments especially adding a Linux servers/services hassle free and works well with MIT KDC version.

Environment Lab Setup:

cryptolab.local # Primary Key Distribution Center installed on Raspberry Pi

private.cryptolab.local # Kerberbroised SSH service accepts Kerberos tickets as opposed to PAM Password based authentication

nebu.cryptolab.local  # SSH client uses kerberos keys to authenticate the SSH service.

  • What would happen if someone gets hold MIT version kerberos ticket granting ticket cache ?
  • Can the stolen ticket be destroyed and will the attacker be able to reuse kerberos ticket in different user session?


The short answer to above questions – An attacker can steal valid tickets and use session for days even if the legitimate user destroys the ticket.  This is obviously subject to kdc configuration on the server side.

But but before we divine into MIT kerberos authentication a brief description would be a good starting point for those less familiar with Kerberos protocol.

The Kerberos protocol is designed to provide reliable authentication over open and insecure networks where communications between the hosts belonging to it may be intercepted.  No kerberos is not authorization protocol. One should be aware kerberos does not provide any guarantees if a system begin used are vulnerable/compromised.

In nutshell kerberos provides the following and more:
  • End user’s password must never travel over the network
  • User password never to be stored in any form on the client machine
  • User password should never be stored in unencrypted form even in the authentication server database.
  • User asked to enter password once per work session and access transparently access to all the authorized kerberorised services e.g. ssh a.k.a SSO ( Single Sign On)
#Install MIT kerberos 
apt-get install krb5-admin-server krb5-kdc 

Specify Realm in my lab i decided to name my realm CRYPTOLAB.LOCAL

1-krbconfigFigure 1 key distribution service kdc set to kdc.cryptolab.local and admin server to kdc.cryptolab.local on the same server.


Initial setup  on KDC server to setup realm master database similar to NTDS.dit in windows environment ( By default krb5_newrealm selects default realm CRYPTOLAB.LOCAL and master key is required to decrypt user TGT tickets.

2-krb5-newrealm-databasecretedFigure 2 master database is created.

kadmin  is kerberos database administration management

3-createkdc-principlesFigure 3 addprinc kdcadmin created a new  remote and local admin in window world this account known as domain administrator (DA)

addprinc pexsr as authenticated standard user

4-pexsr-user-createdFigure 4 pexsr standard authenticated user.

MIT Kerberos authentication supports kerberoised services allowing end users to authenticate ssh services using KDC instead of  traditional password authentication or public key authentication.

addprinc -randkey specifies that the encryption key should be chosen at random instead of being derived from a password.

5-create-randkey-sshFigure 5 kadmin.local we create network service for ssh server  private.cryptolab.local.

Service princiaples are needed for the following reasons:

  • To allow services to verify that service tickets were issued by ginuine Key Distribution Center
  • To allow end clients to verify that they are communicating with correct intended service.

Kadmin.local to create  a keytab for the ssh service. a keytab  is a file used to store encryption keys for the service principals – Keytab is used for obtaining a ticket granting ticket (TGT) so having an encryption key can be equated to having a password.

5-create-ssh-key-serviceFigure 6 ktadd used to create a private.keytab.


8Figure 7 secure copy from KDC to ssh server /etc/krb5.keytab.

Kdestroy – destroy Kerberos tickets utility to destroy users active kerberors tickets by overwritting and deleting the credential cache that contains them.

Even though we destroyed the TGT ticket  from the target system –  the ticket still valid on the system we copied the ticket over.  Its seems kdestroy utility on local and would not communicate to KDC to invalidate the ticket. An attacker with copy of ticket can have a valid session for at least 10 hours default  MIT kerberos ticket expire.


Figure 8 Kdestroy utility to remove the TGT ticket from local machine.

Kinit to obtain kerberos ticket granting ticket for user pexsr

kinitFigure 9 obtained  initial TGT ticket for user pexsr

Wireshark traffic capture from target machine KRB5 AS-REQ & AS-REP


Figure 10 Key Distribution Center options shows Ticket Granting Ticket with Renewable flag set allows  TGT ticket to be renewed before expire time  subject to KDC configurations.


Imagine now an attacker have access to user pexsr workstation – it would be very simple to steal, transfer existing kerberos session to attackers control to maintain valid session.

8-krb-ticket-copiedFigure 11 /tm/krb5cc_1000 valid kerberos session issued by KDC for user pexsr copied to attacking machine.

Kdestroy – destroy Kerberos tickets utility to destroy users active kerberors tickets by overwriting and deleting the credential cache that contains them.

Even though we destroyed the TGT ticket  from the target system –  the ticket still valid on the system we copied the ticket over.  Its seems kdestroy utility on local and would not communicate to KDC to invalidate the ticket. An attacker with copy of ticket can have a valid session for at least 10 hours default  MIT kerberos ticket expire.


Figure 12 Now that we copied kerberos  key to our attacking machine /tmp folder  we can ssh to  kerberoised ssh  service and login to different servers/services using the stolen kerberos ticket.


Figure 13  successful ssh connection from attacker system.

Klist on the target SSH service shows the copy of stolen key /tmp/krb5cc_1000 still valid and the host/private.cryptolab.local SSH kerberosized ssh services authenticated with the stolen key as opposed to traditional Password authentication.


kerberos-ticket-still-validFigure 14  Klist  valid ticket granting ticket and ticket granting service for user pexsr with stolen kerberos ticket.


  • Kerberos ticket can be copied to attacker machine for reuse and lateral movement
  • Kdestory is local ticket overwrite only no validation on the KDC server side and the ticket remains valid for 10 hours and it might be possible to renew it.
  • Set Strong complex master key database password
  • Enable auditing against kerberos authentication services





Playing with Microsoft Unconstrained Delegation Permissions

Why you should remove the use of Kerberos Unconstrained Delegation?

In simple term unconstrained delegation allows a service ability to impersonate your account to a service. For example you have in-house custom web application running on IIS windows web server and the application pool is configured with unconstrained delegation and the server has native windows authentication enabled and a domain admin browse  the in-house application from his/her domain connected workstation. You might think so what’s wrong with browsing an application with unconstrained delegation enabled?  Well…  Your domain admin TGT ticket granting ticket is copied to IIS web server LSSAS memory, which means any one with the local admin can extract valid ticket granting ticket and resubmit the domain admin ticket… Worse case scenario ? The attacker could get Kerberos Ticket Granting Ticket (KRBTGT) hash from domain controller and use the hash to create golden/silver ticket, access, pivot, persist in the network.

Sean Metacalf brilliant description with unconstrained delegation ( How compromise a of a single Server Can Compromise the Domain) Link  here.

Link by Harmj0y  for better weaponize of constrained delegation abuse.

fileshare.cryptolab.local  properties delegation enabled.

Attack Scenario:

Assume you compromised a file server with unconstrained delegation enabled on a file server with smb shared service allowing user to access share remotely.

fileshare.cryptolab.local  ( Server with unconstrained delegated)

primary.cryptolab.local    ( primary domain controller)

secondary.cryptolab.local (secondary domain controller)

windows10.cryptolab.local ( windows 10 to access smbservice share with domain administrator credentials)

Server 2012 R2 server SMB share service.

SMB Share

Figure 2 Configuring SMB share on the fileshare.cryptolab.local.


c:\smbservice folder shared on the fileshare server.


Figure 3  smbservice file shared.


File share  server configured with unconstrained delegation to any service (Kerberos only)


Figure 4 File share server properties set to trust this computer for delegation to any service ( This is of course very bad)

Accessing shared file from windows 10 enterprise with  DA Domain Admin Privilege.



Figure 5 TGS Ticket Granting Service TGT ticket is copied to local Security Authority Subsystem Service ( DA TGT ticket is waiting for an attacker extract and create new valid session)

Klist on the fileshare.cryptolab.local shows my current logged in as servicedeskuser which is local administrator only ( no domain admin)


Figure 6: Klist shows valid kerberos session key ( Not a domain admin yet)

servicedeskuser has local admin access – Mimikatz to extract all the existing kerberos tickets ( privilege::debug > sekurlsa::export tickets)

Client Name:  Administrator  Ticket Granting Ticket valid kerberos session copied to LSSAS to impersonate access SMB services as opposed to Ticket Granting Service (TGS) Unconstrained delegation expected behavior.


Figure 7: Domain Admin kerberos session in the file share server.

Pass The Ticket (PPT) using extracted administrator (DA)


Figure 8: Kerberos ticket is re-injected into memory ( Valid Domain Admin Session)

Klist command to validate the ticket successfully injected.


Figure 9 Cached Ticket with domain admin privilege.

Listing  C:\\ directory on the domain controller using valid TGT ticket.


Figure 10 authentication to the domain controller with the TGT ticket.

Why stop here when you have 8 hours valid domain admin kerberos session?

Extracting KTBTGT ticket? my previous OWASP Red Team talk, steps by steps to extract kerberos master key  to create golden/silver tickets. (Link to OWASP PowerPoint)

Armed with domain admin KRBTGT Hash we go ahead and create golden tickets to gain access to domain controller or file share server and fully patched windows 10 enterprise.


Figure 11 created golden ticket with user fakeadmin  ( fakeadmin.ccache) kerberos ticket.

Shell on the primary domain controller using fakadmin user ( Golden ticket)


Figure 12 wimexec with -k flag and -no-pass set to use fakeadmin.ccache ticket as opposed to password based authentication.


  • Avoid using delegation all together if works in your environment
  • Use constrained delegation
  • Set service account with complex strong password
  • Audit users/services with delegation enabled.






Kerberos Attack Surface

There are different ways of attacking active directory and the attack surface/vectors change all the time. I do like to use built-in tools and my own Linux box to interact with the windows infrastructure environment for few good reasons:

  • Not every environment use NTLM authentication
  • Hacker/Security tools fails to work in Kerberos only environment
  • Stealth – Kerberos less monitored protocol
  • Kerberos is less understood protocol
  • Majority of SIEM services fails to identify
  • Kerberos is difficult to monitor and identify anomalies
  • My ridiculous ego,unconscious aspect of the personality is happier with kerberos
  • Gained initial foothold e.g phishing, web app exploit, client side attack etc.
  • Gained physical access and connected to target network Wired/WiFi.
  • You have no credentials to begin but you are connected to target network.
Reconnaissance Phase:

Domain Name Server (DNS) to look up for particular Active Directory Resource using  dig linux command line utility

dig  -t SRV _ldap._tcp.pri-dc-01.cryotoambient.com ( LDAP  AD server discovery)

dig -t  SRV  _gc._tcp.pri-dc-01.cryotoambient.com   ( Global Catalog  LDAP recon for entire active directory forest)

dig -t _kerberos._tcp.pri-dc-01.cryotoambient.com  ( Identify Key distribution center KDC)

dig -t  SRV  _kpasswd.tcp._tcp.pri-dc-01.cryotoambient.com  ( Kerberos Password changer server)

Example dig command to identify kerberos (KDC Servers)


Figure 1 dig Linux utility to identify  KDC (Kerberos Key Distribution Center)


Similarly we can conduct reconnaissance using NSLOOKUP utility


Figure 2 identifying KDC using nslookup command line utility

LDAP –  We can identify domain controller  and request few details with no authentication:

  •  Functionality level  e.g.  Is the target server 2003,2008/2012 domain controller
  • Identify KDC Kerberos Distribution Center
  • Limited objectclass information e.g. Domain metadata

unauthenticated ldap query


Figure 3  ldapsearch to list juicy useful metadata

Domain functionality level is 4 indicating the target server is Windows 2008 R2

functionality-levelFigure 4 unauthenticated ldap query to identify target server functionality level.


Figure 5  -Ref Microsoft MSDN

You can also use Netbios to identify  hosts in a network  (NBT) still in use for legacy system. I leave this to the reader for unsupervised reading investigate how an attacker abuse NBT (nbtscan & responder)

Imagine that we obtained an unprivileged AD user with no remote desktop/no special privilege with most basic active directory rights e.g. simple basic active directory authentication.

NTLM SessionErro (NTLM Not Supported)


Figure 6 standard penetration tools fails to work with valid credentials

CME  Fails to with correct credentials. (Sky is falling – Target infrastructure is Kerberos only)


Figure 7 CME and other pen test tools fails due to NTLM authentication is disabled

Under the hood at the packet level we see the see NTLMSSP_Auth Plinux user request failed due to the NTLM is not supported.


Figure 8 Attempt to establish NTLM session fails no session created.

Quick look at the Active Security Policy shows the  NTLM Authentication in this domain set to deny all ( Do not apply this to your production environment it will break legacy system communicating with the active directory server )


Figure 9  Deny all to NTLM authentication. Very difficult to implement/apply deny all, due to the legacy products and still list of major network devices doesn’t support Kerberos authentication.

Sky is falling none of our standard security tools no longer work? So maybe the target system is SECURE?  Not so easy…  Kerberos (Hound of Hades)  Multi-Headed dog that guards the gates of the windows environment ( Dead from leaving )

Ok lets utilize MIT Kerberos V5 to operate in secure kerberos environment:

  • Configure /etc/krb5.conf and specify  default_realm to your AD
  • Set the relams at the bottom of configuration file to Active directory FQDN


Figure 10 we setup/configure kerberos KRB5 client and set the relam to our target domain controller to communicate target windows environment via Kerberos authentication.

We must make changes  to /etc/resolv.conf and point our attacking Linux machine to active directory domain name server (DNS) in our case the active directory runs  as DNS  and the IP is


Figure 11 pointed our attacking Linux machine to the active directory

KRB5 configuration is complete we can now authenticate to Active Directory account.


Figure 12 kinit ambientuser user with valid password to create TGT Ticket Granting Ticket. The ticket issued by KRBTGT kerberos master key. Klist shows valid Principal.

smbclient with kerberos to authenticate the target victim server

8Figure 13 kerberos authentication used to connect the target server

rpcclient with  -k flag initiated to connect the target victim server


Figure 14 authenticated to the target server with TGT ticket

Shell? gaining shell via kerberos using wmiexec


Figure 15 limited shell with kerberos authentication on target victim machine

psexec with kerberos authentication against target server


Figure 16 psexec to authenticate target victim server

Golden ticket:
  • Domain Sid
  • Target Domain
  • Impersonated user


Figure 17 forged kerberos ticket user notadministraor to authenticate as domain admin target domain controller server.

Set export KRB5CCNAME variable to the forged kerberos notadministrator.cacche ticket


Figure 18 set KRB5CCNAME to our impersonated notadministrator.ccache

  • Least privilege principle
  • Remove the use of NTLM authentication as much as possible and rely on Kerberos
  • Enable kerberos auditing
  • Monitor Kerberos authentication TGT & TGS tickets



Playing with Kerberos, Kerberoasting, Kinit, Ticket Granting Ticket (TGT)

There has been a number of technical blog posts, demonstrations  about Kerberoasting/SPNs and how widely abused attack vector against windows enterprise network infrastructure (AD) i will try to minimize background info on SPNs and kerberoating as much as possible and provide links at the end to all that i know about.

My focus on this post is to demonstrate how to perform all your attack on a Linux OS as opposed to windows based operating system, the advantages with this approach is your attacking system do not require to be domain joined, all you need is basic (AD) username and password to perform a successful attack.

Attack advantages:

  • Linux OS as attacking machine
  • No windows domain join hassle and permissions etc
  • Can use majority of red team and penetration tools
  • Stealth avoid detection

GetUserSPNs.py specify DC IP address and the user authenticate with.

Figure 1  List Services Accounts IIS_003 and IIS_002 assigned to servers.


GetUserSPNs.py   -request parameter and the DC IP address to request Kerb TGT service tickets.


Figure 2  -request parameter to capture kerberos ticket granting ticket on IIS_002, IIS_003 in hashcat format.

Hashcat password cracking tool to crack the TGT response on the IIS_002 and IIS_003 service accounts.   (Hashcat -m  130100  tgtkerberosticket.txt  dictionaryword.txt)


Figure 3  IIS_002 TGT Response ticket password successfully cracked.

Now that we know the domain controller FQDN we send 2 pings to the host.


Figure 4  sec-pr1-01 DC Netbios name identified.

In order to reduce and avoid detection (Red team)  in the target network we can utilize the use of Heimdal implementation of Kerberos 5 client to receive valid TGT session ticket and use Kerberos post exploitation as opposed password equivalent NTLM hash. The idea is to blend in to the target network and reduce the risk of been identified by security operation team (SOC) and security conscious system administrators.

Steps to configure Heimdal clients on Linux OS:

Vi /etc/krb5.conf 

  • default_relam set that  to a target domain controller CRYPTOAMBIENT.COM
  •  realms set that to a target KDC to Fully qualified domain controller e.g. my target domain controller is set to sec-pri-01.crytoambeint.com and the admin_server and default_domain to FQDN target server.


Figure 5 Heimdal Krb5 client configuration

We also must add the following entries in to the /etc/resolv.conf and point our nameserver to the domain controller. Almost 99% of time DNS is the root cause of kerberos authentications problems/issue. “My own personal experience”


Figure 6 resolve configuration file added with the target domain entries.

Kinit obtains and caches an initial ticket-granting ticket for ambientuser and klist is used to list the valid ticket issued by domain controller KRBTGT. Armed with valid TGT ticket we can tools from our Linux attacking machine and interact with accessible hosts within the domain controller forest.


Figure 7 TGT Ticket Granting Ticket for valid ambientuser received.

smbclient with –kerberos flag to use ambinetuser ticket to authenticate a hosts IPC$.


Figure 8 smbclient to use kerberos ticket as opposed to traditional clear text/NTLM authentication hash.

rpcclient  -k flag is to use kerberos to authenticate windows host joined cryoptoambient.com domain forest.


Figure 9 rpclient can be used to enumerate SID,RID Password policy etc.

wmiexec with -k flag and –nopass used to gain remote shell against the domain joined host using kerberos ticket – user must be part of local admin or domain admin group to be able spawn a cmd.exe process. WMI is still widely used/abused and difficult challenge for good guys to identify slow planned WMI attack.


Figure 10 wmiexec to gain remote administrative level shell on the target host.

psexec i will not and never will use it in real engagement but just for demonstration  i thought it’s a good idea to show different attack tool(s) that supports kerberos to interact with target domain joined hosts.


Figure 11 psexe to gain code execution with the SYSTEM privilege the disadvantages with psexec creates a service executable, writes to a share and finally execute/start the service.

Moral of the story:  Kerberos is the way to go in a locked down enterprise network to avoid detection and operate without the use of NTLM hash in windows environment.


  • Use Group managed security groups for service accounts
  • Use 28 or more password character for service accounts
  • Make sure service accounts are not delegated rights to domain admin or any other groups in fact.
  • Monitor and enable kerberos auditing
  • Investigate incidents do not just assume


What is SPNs




Hemidal Kerberos


Windows Service Privilege Escalation

Now you have gained initial foot hold on the network and you almost certain the end user is low privilege user. Yes, you need to elevate the privilege to local administrator or maybe to system level or if you in luck domain admin.

So what we talk about here you may ask? Privilege escalation; a privilege escalation happens when a low level user requires access to a user or a service to increase privilege on compromised workstation/server etc.

Hacker thoughts and Post exploitation Assumptions:

  • Initial intrusion could start from anywhere, a phishing attack, a guest account a local authenticated user?
  • Living of the land, build in windows tools such as windows binary and PowerShell to come rescue?
  • Windows Services & Third party applications leverage and exploit it to our advantage and escalate low user to admin and or system.
  • Exploiting Weak Folder Permissions and mount and redirect  folder.
  • Classic dll hijacking and gain elevated privilege.

Steps to exploit weak services and binary implants

Assume we compromised an end user windows 10 fully patched workstation and the compromised user is as expected low level user (Authenticated user) no special permissions or rights.

There are different and easy ways to elevate privilige from low level user to all the way to  domain admins in less security conscious environment e.g The GPP Vulnerability  extracting cpassword filed in SYSVOL Groups.xml file etc

Here, we will be looking at different attack vector often overlooked  (Windows and third party services) often windows/third party service binary run under the System or high integrity level, any vulnerability in a service could result in privilege escalation.

Windows Services is  vast subject link for your further unsupervised read  here

Naturally, i go for quick powershell one liner to list all the potential vulnerable services in C:\ drive.  Get-WMIobject win32_service to look for services running outside of c:\windows folder   and the -eq “auto” is to check if the services out started, finally we check the  if the services running under the localsystem privilege account and we output the path is located.



Figure 1 we identified  c:\Users\lowuser\Desktop\AwesomeService\Secure.exe  path sits on user desktop with localsystem intergity level.

Icacls Microsoft  native binary to list  security descriptors on folders and files –  (F) indicates lowuser has full control over the Secure.exe binary. Obvious fail but this does happen all the time.

Service_1Figure 2    Lowuser has full control of the folder

Security descriptor definition language (SDDL) in windows world used to define access and protect objects for example, folders, shares, active directory objects, windows event logs etc.   SC sdshow lists access list against AwesomeService a.k.a to identify which user groups have access and make etc

service_03Figure 3 AwesomeService a.k.a Secure.exe SDDL

Brilliant description with SDDL breakdown here:

You might have notices you from SDDL output Authenticated User is not part of the SDDL,we can add our lowuser account to specific access.




Figure 4 Interactive user but not Authenticated User e.g. lowuser account

In order to add lowuser account to the list of SDDL we need the user Security Descriptor, we can identify user SID in the following locations:



Figure 5 low user sid

Whoami /all is also another way to list user SID


Figure 6  whoami /all cmd.exe

SC sdset to set the Authenticated User Read Property and Write Property


Figure 6 SetServiceObjectSecurity successfully set.


Figure 7 authenticated user is set and part of sddl.

Privilge escalation steps:

  • Lowuser has full control of the t C:\Users\lowuser\Desktop\AwesomeService\ folder
  • We can modify ,change, delete, replace
  • Build empire executable and replace the Secure.exe with our own call back agent
  • Reboot the service
  • Elevate Privillige from lowuser to SYSTEM integrity level


Compiled Empire agent executable and named it Secure.exe and copied to our Target Service location ( Replaced the legitimate Secure.exe service with our own executable)


Figure 8 compiled Empire callback and named it Exactly the same as Secure.exe


As expected we got shell from the victim machine with SYSTEM privilege successfully elevated from lowuser to SYSTEM user.


Figure 9 Secure Process Shell with integrity level SYSTEM.


Final couple of words,  log log log everything from your end user workstations, ensure third party services not running under HIGH/SYSTEM integrity.

I hope this has been informative

LSA Secrets, Service Account Password Extraction, NT/SYSTEM Privilege Account, gMSAs

In this article we talk about one of the most common vulnerability exist in modern  enterprise windows network infrastructure. We demonstrate how an attacker elevate privilege from administrator account to NT/ SYSTEM Authority privilege which is highest privilege in local windows system. The idea is to use NT authority system privilege to interact with LSA secrets and extract passwords from services account. Often these services accounts misconfigured in modern windows enterprise, which likely enable low privilege user to gain higher privileges.

Technical assumptions:

  • Attacker has an elevated privilege (Local Admin)
  • Attacker identified a service account AwesomeService.exe installed locally and runs under the local administrator privilege


Regedit Registry editor permission with SAM hive file requires NT/Authority SYSTEM Privilege, we  can not access the SAM File hive with windows local administrative permission.


Figure 1 SAM Hive set to full control permission


We Launch registry editor under the local administrative privilege – we are not able to read/write and modify SAM files.


Figure 2 Regedit under the windows administrator privilege account.


We elevate the local administrator privilege to NT/Authority SYSTEM privilege using the SysInternals PsExec Mark Russinovich copy of the PsExec Here   with the -i interactive, -s run remote process in the system account and -d  dot wait for process to terminate.


Figure 3 PsExec elevated privilege from local admin to NT/Authority SYSTEM


NT Authority\SYSTEM has access to SAM hive files


Figure 4 Corroborates the SAM hive access via SYSTEM privilege


We not really interested in SAM/SYSTEM contents – We are after LSA Secrets and Service Account password extraction, however we need to create and compile a windows 10 compatible service and install it locally on our windows 10.


Figure 5 –  We created AwesomeService.exe with DisplayName “Windows Update” using SC Service Control to install and set the run time to auto start.


Display Name set as Windows Update


Figure 6 AwesomeService.exe runs as service under the local administrator privilege.


AwesomeService current value is in binary mode


Figure 7  AwesomeService in binary value


lsasecret.exe /service AwesomeService command to dump clear text password from the registry.


Figure 8   extracted openSSHd and AwesomeService accounts from registry.

Link to github lsasecre.exe the original source code from “Timothy D.Morgan”



There are couple of solutions to mitigate against this particular vulnerability – the easiest and Microsoft recommended approach is the use of native windows feature,  Managed Service Account (MSA) and Group Managed Service Account (gMSA) .

Switch to your Server 2012 domain controller generate KDS root key for use with managed MSA and Group Managed Service Accounts (gMSA)   New-KdsRootKey Powershell cmdlet to initialize the key. The reason that we need to generate this once because this will be used in generating passwords for the Group Managed Service Accounts.

Add-KdsRootKey –EffectiveImmediately

Run this under the windows administrator Powershell console; The  -EffectiveImmeditely takes 10 hours from the time of creation to allow all domain controllers to replicate before allowing the creation of a gMSA. The idea behind 10 hours delay is a safety measure to prevent password generation from occurring before all domain controller are capable of responding to gMSA requests.

Perhaps yo may want to run this over the weekend over the night in production environment?


Service Account Creation

It’s straightforward to create gMSAs (Group Managed Service Account) Switch to the server you want to add service account, you need active directory Powershell module part of the RSAT for this to work.

New-ADServiceAccount -Name svc_Secure -DNSHostName cryptoambient.local -PrincipalsAllowedToRetriveManagedPassword  WIN-12-AV$

Command Breakdown :

-Name    service name of your choice

-DNSHostName   –  FQDN for our domain controller that holds KDS root key in my case ambientcrypto.local

PrincipalsAllowedToRetriveManagedPassword     –  This parameter allows you to specify the server(s) that you are going to be running particular (gMSA) on.


That’s it, simple and extremely reliable to manage service accounts. Good luck 🙂






Windows Task Scheduler Privilege Escalation ALPC exploit

Quick Description:

Hacker goes by name SandboxEscaper decide to upload 0day exploit in the windows 10 32-64 bit & Server 2016 x64 task scheduler, SchRpcSetSecurity API contains a privilege escalation vulnerability which can allow authenticated low privilege user to overwrite content of certain files protected by ACLs in filesystem. This is big, a local user authenticated can elevate their privilege to NT Authority /SYSTEM, which is highest privilege in windows operating system.

Maybe this new trend to release 0days ?

Hey I link to the code here,hopefully SanboxEscaper doesn’t mind me doing that.

Exploit prerequisite:

-Windows 10 32/64 or server 2016 system
-Exploit code link here
-CFF PE resource editor link here
-Your own malicious dll e.g msfvenom or empire powershell post exploitation framework etc

Process explore tool to see existing/new running process.Cmd.exe then launched notepad.exe to create a new process id PID  so that we can use PID to call hijack DDL as system privilege.


Figure 1  notepad process associated with PID 1356 run under the cmd.exe.

Windows CFF explore  to edit ALPC_Tasksched-LPE.dll  then  RCData 101, Click right to Replace Resource Raw  then poc.dll which we used empire C2 for dll generation . CFF

Figure 2 CFF explore edit the ALPC_Tasksched-LPE.dll and replaced the existing dll with our empire C2 for reverse during execution.


InjectDll.exe 3508 notepad PID and our modified ALP-TaskSched-LPE.PoC.dll


Figure 3  we execute InjectDll.exe with modified empire dll

Local copy of empire agent call back “whoami” command shows session runs under the NT Authority\SYTEM


Figure 4  Agent runs under the NT AUTHORITY\SYSTEM privilege context


Quick Video session here to demonstrate steps taken to corroborate the  ALPC privilege escalation  https://youtu.be/t50v8zGIwWE


Wait for Microsoft to release security patch next few weeks…





Playing and Hacking Active Directory Certificate Authority

Brief Active Directory Certificate Authority

Microsoft Active Directory Certificate Services provide a platform for generating and issuing and managing PKI Public Key Infrastructure certificates. In short AD CS provides certificates for securing HTTP traffic and also supports other authentication mechanism such as computer, user or device accounts on a network.
No point for me to describe what the certificate authority is used for as Microsoft has covered this here in details  here and here.

The objective with this brief technical article is to demonstrate common mis-configuration with the certificate generation and issuing keys to domain joined end users. The idea is to show an attacker can enumerate certificate authority using built-in windows MMC managed certificate Snap-in in windows 10 and export private keys to our attacking machine for offline PKCS12 PFX password recovery.
You probably ask why do you want to extract private key and recover the password? Well that depends on the type o certificate but generally speaking certificate used for encrypting traffic or perhaps use machine authentication to a domain controller or can be used as internal code signing certificate.
In my personal opinion I think CA Certificate Authority is significant attack vector and often overlooked by system administrators and security professionals, for years’ bad actors utilized and abused certificate authority to circumvent external/internal technical controls and security operations, often these attacks go undetected by third part and built-in signature based anti-virus products.

So let’s assume breach scenario here and an attacker managed to gain foothold on your end user windows 10 workstation and we also assume the workstation is domain joined, and there is a single tier domain joined active directory certificate authority installed on server that issues automated client machine/user certificates to the workstations once  joined the domain controller (AutoEnrollment Group Policy Configured)

LAB Setup and Break down:

Cryotoambient.com SEC-PRI-DC-1 (Primary Lab Domain Controller)

SEC-PRI-DC-02 (Secondary Domain Controller – Certificate Authority installed

Windows10 Domain Joined with active directory low privilege user ambient10

Let’s assume the attacker is on post exploitation phase and enumerating the workstation for vulnerabilities weakness to elevate higher privilege access from zero to hero domain administrator privilege. There are different methodology and techniques to elevate privilege from windows environment, unpatched vulnerabilities, powershell, vulnerable services, pass the hash,  credential theft and the list goes on.

Let’s focus on how an attacker abuse exportable certificates and reuse the certificate for other malicious use cases.

Certificate authority  we replicated an exiting template and named it User_V2.


Figure 1  Notice Private Key is to be exported ticked.


Enabled Certificate Templates we created.


Figure 2 Published User/Workstation authentication template.


Group Policy change to enable automatic enrollment.

comes just after 2 with commens

Figure 3  PKI Group Policy created to allow AutoEnrollement to end user workstations.

Joined our target windows10 to the domain controller.

comes before 2

Figure 4 DESKTOP-BOB1 Windows 10 Joined to the domain controller and waiting for the certificate to be pushed to the user workstation upon first login.


Issued Certificates to workstations.


Figure 5 User/Machine certificate issued to newly joined window10 with the user ambient10 as low privileged user.


Next we check newly joined Windows 10 MMC console under the Personal  Certificate we see ambient10 user been issued a certificate.


Figure 6 We use export wizard to export the private key in PKCS12 PFX format.


Certificate Export Wizard.


Figure 7 we select the export private key from abmient10 user personal certificate


ExportPrivateKey certificate saved on the ambient10 user desktop.


Figure 8  private key saved on to the ambient user workstation desktop


Next we move the file to the c:\cert folder on the target workstation for quick certificate transfer to our attacking machine.


Figure 9 from our lab kali machine we use mount -t cifs to mount the remote folder to our /mnt folder on our attacking machine with the user ambient10 credential.


Now that we have copy of the private key in pfx format we github crackpkcs12 source code here and compile it on our kali machine.  Crackpkcs12 -b  certificatefile.pfx or pkc12 format.


Figure 10  Successful Brute force attack and recovered the Password “123”


When was the last time did you review/audit your internal Certificate Authority published certificates ? Do you know if the keys are exportable?




MS10-010 vulnerability patched by Microsoft affecting from windows 7 to a windows server 2016 (Eternalromance/synergy published by shadow brokers the exploits are very unstable if tried against the windows 2012, 2016 server causing 100% of the target machine BSOD

This is not a comprehensive article but we will demonstrate how we can leverage and make necessary changes to the Sleepys code and make minimal code change in order to obtain a privileged windows meterepreter reverse on the target system

Virtual Environment & prerequisites

Kali Ubuntu Machine  IP address

Python v.2.7

Ps1Encode   – Used to generate PowerShell metasploit types revershell


Windows Server 2012 R2 target IP ( Not patched with MS17_010 )

Ok so without further ado let’s compromise windows 2012R2 server

The exploit has been published by sleepya https://www.exploit-db.com/exploits/42315/  the exploit is working properly without doing any modification if we execute the exploit against the windows 2012r2 server it will create a file  in C:\pawned.txt  on the target disk .

But you might already think hm but that doesn’t give me meterpreter shell on the target box , that’s very much true but we make couple of modification to get the desired shell

We now enabled guest account on our windows server R2 windows machine


Figure 1  we set the authentication to “guest”  with minimal privilege


The exploit code requires two parameters  the actual Target IP address windows server 2012R2 in our case and the PIPE name  – windows named pipe is not in the scope of this article. SMB protocol supports three different types of shares  File share which is a directory tree, Print: print share  which is access to print shares on the server,   PIPE inter communication between the process that uses FIFO model essentially first in first out  a.k.a  named pipes .

What other pipe types you can potentially exploits on a windows server box ?

  • Netlogon, samr, lsarpc,spoolss,browser

Ok it’s very straightforward to identify which named pipe are available on a target server – I wrote a python scrip which compares the UID to identify if the named pipe exist is so then just check access if allowed or denied

Script identify named pipes on the target windows server 2012 R2


Figure 2 allows identify named pipe Browser, Spools, Netlogon, LSARPC, SAMR

If we decide to execute the exploit it will create c:\\namlook.txt on the target .


Figure 3  executed code without reverse shell created c:\namlook.txt

Code snippet creates namlook.txt on the target server

1Figure 4 CreateFile function adds pwned.txt on the target server but no reverse shell code.

Executing code with our SCT reverse shell code ( SCT File Extension ) Windows script component

This is an affective approach to evade security controls using the SCT extension with embedded powershell reverse shell code. We wil l use PS1encode  that allows us to generate encoded metasploit codes in different/several format

Exploit Modification/Reverse shell

Executing code with our SCT reverse shell code ( SCT File Extension ) Windows script component. This is an affective approach to evade security controls using the SCT extension with embedded powershell reverse shell code. We wil l use PS1encode  that allows us to generate encoded metasploit codes in different/several format

We can download the ps1encode here  from github   https://github.com/CroweCybersecurity/ps1encode

SCT Reverse Shell code

3Figure 5 reverse shell code windows/meterepreter/reverse_tcp

Armed with .SCT reverse shell file we simply move the to our python web server on kali machine  /var/www/html  or any machine that can be reach from the target server. The idea is that when we execute the exploit against the target server to use regsvr32 (Microsoft Register Server) command line utility for registering and  DLLs in the windows registry

Reverse shell code


Figure 6  – We modified code to execute our malicious revershell code .SCT  on our target machine

Meterpreter session

We now configrured the metasplot’s exploit/multi/handler to receive reverse shell


Figure 7 handler configured with windows/meterpreter/reverse_tcp

After executing modified MS17_010 exploit get clean meterpreter reverse shell


Figure 8 sysinfo with  NT/Authority priv ….


Go and patch please … https://technet.microsoft.com/en-us/library/security/ms17-010.aspx