Designing identity systems that keep pace with AI-driven development

Thesis: Identity systems designed for human-paced development are failing in AI-accelerated environments. To secure modern infrastructure, identity must be default-closed, zero-friction, and automation-driven.

The Snap: Why Identity is Breaking

We have entered an era where engineers can "vibe code" production-grade tools in hours using LLMs. But identity systems still assume weeks of setup, manual tickets, and cross-team coordination.

That mismatch is creating a new class of risk: Identity Debt. Identity Debt is the accumulation of unauthenticated or weakly authenticated internal systems created faster than governance can keep up. It is a growing surface area of "naked" infrastructure created because the official path was too slow. Instead of resisting this shift, I designed an identity foundation to match development velocity.

1. Fail-Open Identity is Dead

Most identity frameworks are fundamentally flawed: they assume developers will remember to secure every route with a decorator. In a high-velocity environment, that assumption is a liability.

I built a Default-Closed Wrapping model:

The Philosophy: Security must be enforced at the application boundary, not at the developer’s discretion.

The Implementation: I built a protect_app(app) initialization that wraps the entire application instance, protecting every route automatically.

The Impact: This eliminates an entire class of "forgotten auth" vulnerabilities at the framework level. By requiring developers to explicitly use an @allow_unauthenticated decorator to make a route public, I moved the burden of security from the human to the framework.

2. Friction is the Real Vulnerability

The biggest barrier to secure identity is not complexity - it’s Day 1 Friction. If a developer cannot get a working auth flow locally in under a minute, they will bypass it.

The Insight: I implemented a Universal Sandbox Pattern that auto-bootstraps for local prototyping.

The Outcome: I inverted the default: the fastest path is now the secure one. Developers can reach a functional OIDC handshake locally with zero configuration. By eliminating the need for a ticket just to see a "Hello World" app, I made security the path of least resistance.

3. Solving the Socio-Technical Bottleneck

Most identity systems fail not because of technology, but because of the coordination overhead between Engineering and IT. To fix identity, I had to fix the Provisioning Pipeline.

I created a CLI tool that consumes application metadata and generates a standardized Identity Provisioning Spec. This reduces onboarding from multi-day coordination cycles to a near-instant, self-service process by automating the exact JSON and documentation required for administrative approval.

4. The Urgency of Agentic Identity

This already extends beyond human users. The next failure mode is not human misuse - it’s Autonomous Agents operating with unclear identity boundaries.

Agents won’t just read data; they will take actions across systems, chain commands, and escalate privileges implicitly. Without clear identity boundaries, those actions become untraceable, ungoverned, and impossible to constrain. My framework provides the foundation for Machine-to-Machine (M2M) authentication, ensuring that agentic workflows inherit the same governance and telemetry standards as human ones.

The Architecture: The Identity-Aware Sidecar

Not all systems can be modified, but identity still needs to be enforced. For services where code changes aren't possible (legacy tools, third-party containers), I utilize a sidecar proxy that enforces identity before traffic ever reaches the application.

 [ USER ] ----> [ IDENTITY PROXY ] ----> [ TARGET APP ]
                      |                     (Isolated)
              (OIDC Handshake)
                      |
              [ IDENTITY PROVIDER ]

The Outcome: This ensures that legacy and third-party systems inherit modern identity controls without requiring code changes. This is how identity systems need to evolve: not as a bottleneck to development, but as infrastructure that scales with it.

Appendix:

Deep Dive — Hardening the Identity Boundary

Secretless by Design

A core property of this framework is that it is fully secretless.

Traditional internal systems rely on static API keys or long-lived service account credentials, which become high-value targets once exposed. In practice, these credentials are frequently over-permissioned and difficult to rotate, making them a persistent source of risk.

This model removes that class of problem entirely. All authentication is handled through short-lived, identity-based OIDC flows, eliminating the need for stored secrets at the application layer.

If there are no static credentials, there are no credentials to steal.

While the external interface is optimized for developer velocity, the underlying implementation adheres to strict security constraints required for enterprise Zero Trust environments. For those interested in the technical specifics:

• Cryptographic Verification: Every inbound JWT is validated against the OIDC provider's JWKS (JSON Web Key Set) endpoint. I built a local caching layer with a short TTL for these keys to minimize handshake latency while ensuring we are always using the current rotation.
• Correlation & Observability: I designed the framework to automatically inject a unique X-Identity-Trace-ID into the headers of every proxied request. This enables seamless correlation in the SIEM, mapping a single user’s path across multiple downstream microservices without requiring per-app logging logic.
• Session Lifecycle Management: I use a sliding-window session model combining short-lived OIDC tokens with a secure, HTTP-only session cookie. This ensures that session revocation at the Identity Provider propagates to the application boundary in near real-time.
• Entropy & State Protection: To prevent CSRF and Replay attacks, the library manages the OIDC state and nonce parameters using a cryptographically secure random generator, ensuring every handshake is unique and cryptographically bound to the initial request.

Cache was a medium rated Linux box where enumerating a website found some hard-coded creds and a vhost that contained an Electronic Medical Records application. This EMR app had some SQL injection vulnerabilities that allowed a password hash to be dumped and cracked, gaining access to the EMR app. A PHP reverse shell was uploaded through the EMR app and those hard-coded creds found earlier came in handy to su to the user 'ash'. From there, creds for a user 'luffy' were pulled out of memcached. For root, I found two paths. The intended route was a Docker container escape. I added cache.htb to /etc/hosts and got started.

Enumeration

nmap scan:

Without creds, time to check out the web server:

News:

Author:

Login:

In short order I found some creds hardcoded in a js file:

These creds worked for the login screen but lead nowhere:

I ran gobuster on the site and got nowhere. I was a bit stuck until I looked a bit closer at the website:

I added hms.htb to /etc/hosts, tried opening it up in a browser and was greeted with a login page:

Initial Foothold

The previously found creds did not work here so I enumerated more with gobuster:

admin.php gave me a version number:

Googling around for vulnerabilties found this article which described multiple instances of SQL injection as well as an authentication bypass. The auth bypass was incredibly simple. First navigate to the registration page:

Then just change the URL to something else. In this case I chose the 'find_appt_popup_user.php' file:

Hitting the search button auto-filled some parameters in:

Knowing that there are SQL injection vulnerabilties, I put a 1' for one of the parameters and received an error:

I saved the working request in Burp as 'req.txt' and threw it at sqlmap with sqlmap -r req.txt -D openemr --tables to find some juicy looking tables:

A few sqlmap commands later, I got a password hash:

Cracked the hash:

The creds worked and I was in the EMR app:

There was a file upload function in the app so I uploaded a reverse shell 'rs.php':

I accessed http://hms.htb/sites/default/images/rs.php and caught a shell:

Ash's password worked and I was able to su to him:

User flag:

User Pivot

While enumerating the system, I spied memcached being run on port 11211:

I had never worked with it before so I googled around and found this very helpful article. I connected to it with netcat and ran a test command stats slabs:

A few moments later, I ran get user and got some creds:

The creds worked and I now had a shell as luffy:

Privilege Escalation - Intended Route

My notes are a bit fuzzy here so apologies, but during enumeration, Docker was found to be running on the system. Googling around eventually lead me to this PoC of a Docker escape. The requirements were to have root access in the container, which we do have. I had issues getting a working exploit (which is why my notes suffered here). I tried various reverse shells, msfvenom payloads and none worked - they would all connect back to me as luffy instead of root. What finally did the trick was the following C code:

The compilation:

I changed the PoC code as follows:

This would change /tmp/t3chnocat to be owned by root and also make it a SUID binary. I built the binary and moved/renamed:

Transferred the files via scp:

As expected, we see both files are owned by luffy:

Now let's run the Ubuntu docker image:

In another shell, list the active containers and copy the t3chnocat-suid file over to the container:

Run the file in the container:

Run /bin/sh from the host:

In the container we see that something happened:

Check the /tmp folder and see that the 't3chnocat' binary is now a SUID owned by root:

Run the binary:

Catch a root shell:

Root flag:

Privilege Escalation - Unintended and Super Easy Route

After finding out that Docker was running, a trip to GTFOBins found this. Here I list the images and run the exploit:

BAM, root!

Taking a break

This will be my last writeup for a while as this was the last HTB box I finished before starting a new job. One of these days I'll have more time to play around on HTB again. Until then, keep hacking :D

Admirer was an easy rated Linux machine that had a lot more steps than I expected, given the rating. A robots.txt file hinted at the presence of credentials which were found with forced browsing. One of these creds worked on the FTP service, allowing us to download a backup file of the website. Inside this archive were various PHP files, more credentials and a clue about the directory structure. More forced browsing found an Adminer instance which was exploited to read a local file, this time containing credentials which worked for SSH. Finally, sudo access to a shell script as well as the ability to set an environment variable were used to gain a root shell. I added admirer.htb to my /etc/hosts and started doing recon.

Enumeration

nmap scan:

Let's check the webpage:

Clicking on the 'about':

Initial Foothold

Nmap said there's 1 disallowed entry in robots.txt so let's check it out:

Unfortunately we don't have access:

I ran gobuster on the root directory and came up with nothing. Gobuster on the admin-dir came up with something:

Ultimately, this didn't seem to help much other than letting us know someone is a fan of The Big Bang Theory:

I scratched my head for a bit before thinking about how robots.txt mentioned contacts and creds, so I tried cred.txt and struck gold with credentials.txt:

The ftp creds worked:

There were a couple of juicy looking files so I grabbed them:

Sql.dump was not helpful but I extracted the gzip file:

This had some interesting content:

There were creds in the index.php file that didn't work anywhere so I took a look inside the utility-scripts folder:

There were more creds which again didn't work anywhere. The admin_tasks.php was accessible on admirer.htb but I didn't have any permissions to do anything fun, so I ran gobuster on the utility-scripts folder:

Adminer.php looked interesting so I checked it out:

Aah, it's nice when the version number is right there eh? A quick search found this article detailing a vulnerability in Adminer. In a nutshell, you need to have the Adminer instance connect to your own MySQL database and load data from a local file on admirer.htb. I spun up a MySQL service on my attacking machine and created a test database:

Then I granted the root user on admirer.htb access to it:

Now I could use the adminer.php file to log onto the SQL service on my attacking machine:

This worked and some shady looking dude in a hoodie said 'I'm in':

I created a table:

Next, I loaded the contents of /var/www/html/index.php on Admirer into a table:

Viewing the table revealed a password:

We finally have a working password and a shell:

User flag:

Privilege Escalation

Waldo has sudo access to set an environment variable and to run a shell script:

Running the script as-is didn't let me do much so I examined the script. Inside, this caught my eye:

It checks if you are root and if you are, it runs /opt/scripts/backup.py. Let's see what's in that script:

It became clear that the idea was probably to change the path for the python library, have it load my malicious library and run my own function named 'make_archive'. First, I checked if netcat was installed and confirmed that it had the '-e' flag available:

Sweet. Next I created my own shutil.py in /tmp/.meow with a 'make_archive' function that would connect back to me with a reverse shell:

The next step was to figure out what environment variable would tell python where to look for libraries. The answer was PYTHONPATH. Now to put it all together:

With a netcat listener, I caught a root shell:

Root flag:

Quick was a hard rated Linux box and man, did it earn that rating. A website was accessed via the QUIC protocol and a password was retrieved. A list of potential usernames was compiled from the 'normal' website and used to spray the password and get past a login page. ESI injection was then performed to execute code and get a shell. A local print service was forwarded to the attacking machine through a SSH tunnel and a discovered MySQL password was used to login to it. A symlink was used to force the print server to connect to the attacking machine and send a higher-privileged user's private SSH key. Finally, a URL encoded password was found and used to su to root. I added quick.htb to /etc/hosts and dug in.

Enumeration

nmap scan:

Let's check port 9001:

The 'portal' link leads to https://portal.quick.htb, so I added it to my /etc/hosts but it didn't work.

'Clients':

'Get started' leads to a login page:

Without any creds, I ran gobuster:

Ticket.php redirectd back to the login page. For once, /server-status was readable and other than what looked to be a SQL query, I didn't see anything interesting:

At a dead end, I scanned UDP ports out of desperation and was confused at the result:

Some googling around and I learned about the QUIC protocol which was pretty interesting. I wasted hours trying to get experimental builds of curl to work - quiche and other libraries refused to play nice. I finally found this client that enabled me to move forward. Now that was working, let's check out the portal site that didn't work over TCP:

I used the http3 client to access pages, save them as HTML files, then opened them up in a browser:

The 'docs' page had links to a couple of PDFs:

So I saved them:

QuickStart.pdf:

Connectivity.pdf contains a password and a quick login page:

Initial Foothold

The .jsp page didn't work but now that I had a password, it was time to come up with some potential usernames and spray that password at the login page. By looking at the names of people who gave testimonials on the website and the client list which included the countries they were from, I compiled a list of potential emails:

I put the password from Connectivity.pdf in pass.txt:

Now, let's look at the login attempt:

Putting everything together resulted in the following hydra command which found creds:

These creds worked and I was presented with a ticketing system:

I created a ticket to see what would happen:

A popup appeared after submitting:

Okay, what happens when I search:

I tried a quote mark:

This lead me down a looong rabbit hole trying various SQL injections. I finally got a nudge to take a closer look at some headers where I spied something called 'Esigate':

I started googling around and found this article about ESI injections. With some experimentation, I was able to get it to reach out to my attacking machine:

On my machine:

Some more googling around and I found potential payloads for RCE with java through XSLT injections. I did notice that I had to keep changing the xsl filenames or they wouldn't download from me. With some experimentation, I got ping to work:

Once I had that going, I experimented more and found that stringing commands together with ; or && didn't seem to work so I had to tackle it in stages. I first created a reverse shell script:

The next xsl downloaded the script to /tmp/t.sh:

Let's make the script executable:

Finally, run the script:

With a netcat listener, I caught a shell as Sam:

User flag:

User Pivot

A MySQL password was in plain text here:

I used it to poke around the database and got some hashes:

I couldn't crack these hashes and put it aside for the time being. Further enumeration showed some ports listening locally:

I checked out /etc/apache2/sites-enabled/000-default.conf and found the relevant section:

Since I needed to forward port 80 to my machine, I created a SSH key pair, added the public key to /home/sam/.ssh/authorized_hosts and used the private key to tunnel:

Next I edited /etc/hosts and pointed printerv2.quick.htb to localhost. With that done, I could finally load up the webpage:

The index.php file makes it clear that I needed to login as srvadm@quick.htb:

Since I couldn't crack the hash, I changed the hash to a known value in MySQL:

Now I could log on as srvadm@quick.htb with Elisa's password:

I tried adding a new printer with my IP:

The printer shows up:

I set up a netcat listener and clicked the printer button to 'test' print:

Now I can add a job:

Now if we look at job.php:

I'm not fluent in PHP at all but from what I could gather, the contents of /var/www/printer/jobs/$date are sent to the printer's network socket after the file is made world readable.

My idea was then to symlink the created file to srvadm's id_rsa file and have it sent to the 'printer' (my netcat listener). You can see from the $file variable that the date starts with the year first so I created a while loop as follows:

I kept spamming the POST request to job.php;

With a netcat listener on 9100 set to keep listening - ncat -nlvp 9100 --keep-open - I eventually got a key:

I saved this key and I was able to SSH in as srvadm:

Privilege Escalation

This one was tricky and took a while for me to find as it was hiding in plain sight. In /home/srvadm/.cache/conf.d/printers.conf there's a section with a DeviceURI:

If you URL decode the section after 'srvadm%40quick.htb:' you get: &ftQ4K3SGde8?

This password lets you su to root:

Root flag:

Magic was a medium rated Linux box that required you to find a hidden upload function then bypass its upload restrictions to execute code and catch a shell as www-data. From here, creds for mysql were stored in plaintext, allowing you to dump the database and get more creds for the user Theseus. Finally a SUID binary did not use quoted paths and this was exploited to gain a root shell. I added magic.htb to /etc/hosts and got started.

Enumeration

nmap scan:

With no creds, let's check out http:

I clicked on the 'login' link:

After trying admin/admin and such, I decided to enumerate more with gobuster:

Initial Foothold

Upload.php looked juicy but it redirected when I tried to access it. I loaded up Burp, set it to intercept and changed the '302' shown below to a '200':

This worked and I was shown an upload interface:

I immediately tried to upload a php reverse shell but was booted back to the login. I checked Burp's history and saw the reason why:

Okay, let's see what a legit upload looks like:

Cat pic uploaded successfully:

I tried various things here - null bytes, double extensions (e.g. shell.php.jpg) and got nowhere. Eventually I googled around and found this article that detailed using exiftool to bypass file upload filtering. Sadly my notes here are spotty but I believe I did exiftool -Comment=$(cat webshell.php) meow.jpg, where webshell.php can be found here. I then renamed it to 'meow2.php.jpg', uploaded it, accessed it directly and was pleased to see it had worked:

Since the box is running php, I went with a php reverse shell:

With a netcat listener, I caught a shell as www-data:

User Pivot

There were some interesting files in /var/www/Magic:

There were plaintext creds in db.php5:

Those creds worked for mysql. Whoever left the 'all_databases.sql' saved me the trouble of doing it myself but I believe mysqldump -u thesus Magic -p would have dumped the database to that file. Within it, are another set of creds:

That password works for su:

User flag:

Privilege Escalation

I ran LinPEAS, which spit out a bunch of SUID files. One of them had a plausible name but I had never seen it before anywhere:

I ran strings /bin/sysinfo to take a peek at what it might be doing:

A bunch of commands (lshw, fdisk, cat, free) are being run without quoted paths and this is ripe for abuse. I chose free to be my victim and created a short bash reverse shell script named 'free' in /tmp:

I made it executable:

Now, the important step of setting the path to /tmp so that /bin/sysinfo would look there for free first:

I really should have done PATH=/tmp:$PATH so I could keep using standard commands without having to type their full path. Oops. Anyway, with that in place I ran /bin/sysinfo and with a netcat listener, I caught a root shell:

Root flag:

Traceback was an easy rated Linux machine that required finding a webshell on an already pwned website, using it to upload a php reverse shell, then catching a shell as webadmin. From there, webadmin had access to running luvit as sysadmin so a simple Lua script was used to catch a reverse shell as sysadmin. Finally, lax permissions on motd files allowed me to append reverse shell code to catch a shell as root. I added Traceback to my /etc/hosts and got started.

Enumeration

nmap scan:

Without any creds for ssh, let's check http:

I always check the source code for things like this and saw a nice little comment:

I ran gobuster first to see if it might find the backdoor:

No luck finding the backdoor but the .ssh file was a peek at the future:

Initial Foothold

I poked around a bit more but didn't find anything. Finally I googled 'some of the best web shells you might need' and found this. I saved the list of shells to shells.txt and ran gobuster again:

Accessing smevk.php showed a login page:

The hackers had bad opsec and admin/admin worked as creds:

I uploaded a php reverse shell, accessed via browser and caught a shell as webadmin:

I generated a ssh key pair and appended the public key to webadmin's authorized_keys file:

I now had a stable shell:

User Pivot

In the home dir was a nice little note:

It turns out that sysadmin gave webadmin the ability to run luvit as sysadmin:

I ran luvit to see wtf it was and had no idea what to do with it:

I found the github page and after googling a bit more, was not entirely surprised to see that PayloadsAllTheThings had an entry for it. I created rs.lua:

As webadmin, I ran `sudo -u sysadmin /home/sysadmin/luvit rs.lua' and caught a reverse shell as sysadmin:

User flag:

Privilege Escalation

I proceeded to append the same ssh public key generated earlier to sysadmin's authorized_keys file and got ssh access:

While enumerating the system, I saw an interesting set of commands being run:

This was a huge hint for the next step and was most likely there to clean up after lazy htb players. Let's take a look at /etc/update-motd.d:

All of these are owned by root and sysadmin has write access. These motd (message of the day) scripts are run when someone logs in. I appended bash reverse shell code to one of these, which should give us a reverse shell when someone logs in. I readied a netcat listener, ssh'ed in and caught a root shell:

Root flag:

Cascade was a medium rated Windows machine where a legacy password found in LDAP enabled access to SMB shares. In those shares were various files, one of which was a registry file containing a password for VNC which was decrypted and used to gain a shell. This password also allowed access to a share which had a database and an .exe file. The database contained an encrypted password and some light reverse engineering was done on the .exe to decrypt it. This allowed a pivot to another user account which had access to the Active Directory recycle bin, allowing us to recover a temporary administrator's password. This password was the same as the 'normal' administrator's and was used to gain an admin shell. This one was a bit involved to strap in and let's go!

Enumeration

nmap scan:

We can tell that this is a domain controller. Note that the domain is shown as 'cascade.local' so I added that to my /etc/hosts file.

Next I dumped all of the LDAP info with a script I wrote. This one isn't on my github yet as I want to test it against more HTB boxes first:

Let's check the usernames:

I tried a few things here like ASREP roasting which failed so I started sifting through the volumes of LDAP data. There was so much data that it took 2-3 tries to find what I needed in the users-full.txt file:

Base64 decoding the string:

Let's throw that password at CrackMapExec just to confirm I have the username right:

Ryan does not have permissions for Win-RM so let's check SMB:

He does not have permission for the juicy 'Audit$' share so let's check 'Data':

There are files scattered throughout the directories so I downloaded them all:

Let's check the meeting notes first:

Setting the temporary admin account password to the same as the normal admin account password? Genius!

ArkAdRecyclebin.log:

This tells us that the AD recycle bin program is being run as 'ArkSvc' and two objects were deleted - 'Test' and 'TempAdmin'.

Finally, the VNC .reg file:

Initial Foothold

See that strange looking password? A quick search turned up this article. The author links to an online decrypter but it either didn't load or skeeved me out so I went to github and found this tool instead. Running it yielded a password:

Let's throw that at CME:

I used the creds to score a shell as Steve:

User flag:

User Pivot

Steve has access to the 'Audit$' share:

I downloaded everything in there and started going through them. I checked out the database file first:

Sweet, creds for ArkSvc! Unfortunately they are encrypted so I kept looking. I opened up CascAudit in ILSpy and found this:

Okay, that's the key - wtf do I do with it?? I was stuck here for a while until I opened up the CascCrypto.dll file in ILSpy and saw this:

This was looking promising. Armed with the Initialization Vector, cipher mode and key, I headed over to CyberChef and plugged things in:

The password worked and we now have a shell as ark-svc:

Privilege Escalation

We can see that ark-svc belongs to the 'AD Recycle Bin' group:

I never knew that AD had a recycle bin. It makes sense but never occurred to me. Some googling around and I found this helpful article. The first thing I did was import the AD module:

The next step took was to output a list of deleted objects:

Now, to narrow down the query to just 'tempadmin' and show all properties:

Base64 decode that sucker:

Bacteria noodles??? Ok, let's go with that and try psexec:

Root flag:

Sauna was an easy rated Windows box with a focus on Active Directory. A list of users was generated from a website and AS-REP roasting was used to obtain a password hash. This hash was cracked and a shell gained with WinRM as the user 'fsmith'. A plain text password was found in the registry, allowing a pivot to the user 'svc_loanmgr'. Bloodhound was used to determine that 'svc_loanmgr' has 'GetChanges' privileges which allowed us to use the DCSync attack to get the administrator's password hash. PSExec was the final step to an system shell. I added sauna.htb to my /etc/hosts file and dove in.

Enumeration

nmap scan:

This looks to be a domain controller for egotistical-bank.local.

I took a look through LDAP but didn't find much other than a common name for Hugo Smith:

I couldn't access SMB so checked out HTTP:

There was a search box that threw errors but I couldn't get anywhere with it:

I tried changing it to a POST request and got nothing.

Elsewhere on the page there was a list of team members:

Initial Foothold

I compiled some possible usernames for the team members:

I dislike brute force attacks and tried an AS-REP roasting attack using GetNPUsers.py from the impacket suite and got a hash:

It was the 8th username that got a hash so I saved it as fsmith.hash and cracked it with rockyou.txt:

Evil-WinRM was used to get a shell with these creds:

User flag:

User Pivot

Let's see what user accounts are on the system:

Part of the enumeration process on Windows machines is checking the registry for passwords and I struck gold here:

I used these creds with Win-RM and now had a shell as svc_loanmgr:

Privilege Escalation

I poked around the system as svc_loanmgr and couldn't find anything interesting. Bloodhound is a great tool for AD environments that lets you visualize how you can exploit permissions and group memberships. I copied the SharpHound script to Sauna and imported it:

Next I ran the command to have it collect data:

I transferred this zip file to my machine and imported its data into Bloodhound. The first query I ran was naturally "Find Shortest Paths to Domain Admins" which wasn't very helpful. The next query was "Find Principals with DCSync Rights":

This was much more promising, showing that svc_loanmanager has both GetChanges and GetChangesAll privileges:

This meant that the DCSync attack was on the table. In a nutshell, svc_loanmgr has the ability to sync account password data from the domain controller. Impacket once again came into play with secretsdump.py:

With psexec.py, hashes are just as good as passwords. I fed it administrator's hash and got a shell as system:

Root flag:

Book was a very interesting medium rated Linux machine that introduced me to some new techniques. SQL Truncation was used to takeover the admin account in a web application. XSS was then used to read local files, including a SSH private key which yielded a stable shell. Finally a vulnerable version of logrotate was exploited to escalate privileges to root. I added book.htb to my /etc/hosts file and got to work.

Enumeration

nmap scan:

Let's see what HTTP has:

I created an account and logged in:

I clicked on 'Books':

Clicking on a plant downloads a pdf:

There's an upload function under 'Collection':

Naturally I tried uploading a php reverse shell which got me nowhere. There was some other functionality on the site like giving the admin some feedback that I couldn't do anything with as well.

Initial Foothold

I was stuck here for quite a while. I enumerated more, tried gobuster with different wordlists, etc and simply couldn't figure out a vector. After some hours, I caved and peeked at the forums to find many others stuck in the same position. I did come away with some valuable clues on what to look at - account takeover and a character limit on the sign up form. I checked the source code for the signup form and sure enough, there was a character limit I had glossed over previously:

Some googling around and I found this article detailing a SQL Truncation attack. This was a new one to me so I gave it a try and signed up for an account, making sure to use 'admin' as a name and that the email field was more than 20 characters and started with 'admin@book.htb':

The request looked like this from Burp:

After this, I was then able to login as admin!

As the admin user, there was now an option to export PDFs under the Collections menu:

I tried uploading a PHP reverse shell again to see if exporting would trigger it but had no luck - the uploaded file would just disappear. I flailed around here for a loooong time before eventually coming across this article. Like the SQL Truncation thing, this was new to me. I tried to read /etc/passwd first entering this as the book title: test<script>x=new  XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open("GET","file:///etc/passwd");x.send();</script>

Clicking on the PDF export by 'Collections' opened up a new file that contained the contents of /etc/passwd:

I created a ton of PDF files trying to find creds in various PHP files before it occurred to me I should look for SSH private keys. The user 'reader' seemed like a good option so I used this payload: test<script>x=new  XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open("GET","file:///home/reader/.ssh/id_rsa");x.send();</script>

I saved this to 'id_rsa' and it worked to get me a stable shell via SSH:

User flag:

Privilege Escalation

I looked around manually and all I found was a 'backups' folder in reader's home directory with some uninteresting log files inside:

Nothing else jumped out to me so I uploaded pspy and watched for a little while. I soon noticed an odd logrotate command being run:

I checked the version of logrotate:

A quick search found this post detailing a race condition where it was possible to escalate privileges if logrotate was being run as root and the user is in control of the logfile path. Both conditions were fulfilled so I gave it a try. That post had a link to a github page with code so I cloned the repo, compiled it and uploaded the binary to Book as logrotten. Following the rest of the post, I created a reverse shell payload:

Then I ran the exploit:

The last step was to modify the log file:

With a netcat listener, I caught a root shell:

Root flag:

ForwardSlash was a hard rated Linux box where a LFI vulnerability on a file upload function found on a vhost was exploited with PHP wrappers to find creds that worked for SSH. A backup utility was found that required a bash one-liner to read a backup file containing creds for another user. Finally, an encrypted disk partition was decrypted with a script to gain root's private SSH key for a root shell. I added forwardslash.htb to my /etc/hosts and got started.

Enumeration

nmap scan:

Let's check out http:

Uh oh, someone got hacked. Let's see what gobuster turns up:

Note.txt:

I took the hint and added backup.forwardslash.htb to my host file:

Initial Foothold

I didn't have an account but the sign up form worked:

I got in and checked out the dashboard:

A quick message about our environment:

The message continues in the source code:

The 'Change your profile picture' button looked ripe for abuse:

It was disabled via HTML as the source shows:

This is circumvented by interrupting it with Burp and deleting those pesky 'disabled' tags:

I sent a test URL with a Python http server running just to confirm it would work:

Yup, it works:

I played around with it and sent the site's login.php to see what would happen:

Looking at the POST request in Burp showed that the url parameter was in the body so in a Repeater tab, I tried /etc/password as a url:

Now that LFI is confirmed, time to figure out files to look at so gobuster once again comes out to play:

Config.php sounded promising but contained creds I couldn't do anything with:

'Dev' directories are often good targets but I had no access:

I was unable to view some of the php files with LFI and it took a while before I thought to look at PayloadsAllTheThings for ideas. There I learned about using php wrappers:

I tried it on index.php:

Got a base64 encoded block back:

Cool, it worked perfectly even though this particular file was of no help:

I checked out the other php files and turned up nothing. I scratched my head over this until I reviewed my notes and realized that the /dev directory might have an index.php file in it. I repeated the process above and found creds inside:

Those creds worked for SSH and we now have a stable shell on the box:

User Pivot

Chiv had access to Pain's home directory and in it there's a note:

Inside Pain's home directory was an 'encryptorinator' folder:

Let's check out this encrypter.py file:

I didn't know what to do with this yet so I continued to enumerate the system. I found another note in /var/backups:

The files in there:

That config.php.bak file looks tempting but I could not view it. Back to enumerating! I eventually found a SUID file /usr/bin/backup:

Let's run it to see what happens:

I flailed here for a good while trying to be fancy - figuring out the time, hashing it, etc. before I got a nudge that I had everything I needed already. That set off a lightbulb/facepalm combo and I shortly had a bash one-liner that would read the value from the error message, create a symlink to the config.php.bak file and re-run the /usr/bin/backup file:

These creds allowed me to su to Pain:

User flag:

Privilege Escalation

Let's see what Pain has sudo access to:

Further enumeration revealed an encrypted file:

Let's try decrypting just to see what it looks like:

The intended route appears to be decrypting the backup and mounting it. I believe some people took an unintended route of uploading their own image, mounting it and getting root that way but I didn't think of that :/.

Remember that 'encryptorinator' folder in Pain's home directory? It's what was used to encrypt the disk image and from what I gathered from HTB Discord, the encryption is weak  and easily defeated. I tried to figure out the flaw but the math gave me a headache and so I went brute force with rockyou.txt. I was able to bumble/copy-paste my way into throwing rockyou.txt at the problem but had major issues trying to figure out how to parse the results which was screenfuls of junk. I finally teamed up with someone and here's the final script we came up with:

It was basically a lot of guesswork and experimentation where we wanted to have results that contained more than 145 ASCII characters shown. Running the script wasn't pretty but it worked:

The password let me decrypt the file:

Mount it:

Inside we find an id_rsa file:

This private key lets us SSH in as root:

Root flag:

PlayerTwo was an insane rated Linux box that was a hell of a journey. I debated about doing this writeup because I got the root flag in an unintended way but hey, it's still a win! First you had to get the correct vhost name in order to find a Twirp installation. Interacting with that yielded some creds for a login page which promptly stopped you with a 2FA prompt. A bit of guesswork with an API got some backup codes that gave access to a website. A PDF file was hosted on the site that detailed firmware architecture with a download link to the firmware, along with a link to upload and verify firmware. The firmware was downloaded, edited and exploited to gain a shell. Once on the system, Mosquitto was used to read a SSH private key and a stable SSH shell was gained. From here, the intended route was binary exploitation but I'm horrible at that. I added playertwo.htb to my /etc/hosts file and started scoping things out.

Enumeration

nmap scan:

Port 80 showed an error message:

Port 8545 wasn't much help either:

I started enumerating more and got nowhere fast, getting stuck for a little while. Finally while looking through notes, I looked closer at the error message on port 80 and saw that it said 'Please contact MrR3boot@player2.htb'. I added player2.htb to /etc/hosts and got a better result:

The rest of the page talks about how Player was compromised without much else. Time to start gobusting:

I proceeded to gobust each of those directories searching for the same extensions and got nowhere. After quite some time, I got a nudge to look for .proto files:

I downloaded the file and checked it out:

I never heard of Twirp or .proto files and had to do a lot of googling. It turns out that Twirp is "a framework for service-to-service communication emphasizing simplicity and minimalism." The proto file is written in Go which I know next to nothing about - yay. Port 8545 had given the Twirp error so I started there. It took a lot of time, experimentation and reading two articles on Twirp's docs over and over again but I finally got a curl command working that gave me creds of some kind:

I played around with this for a while getting ever changing creds for 0xdf, mprox and jkr. At some point I noticed that sending the number 0 resulted in the password staying the same while the name changed:

Ok, where do these creds go?? A short while later, I checked the source code of player2.htb and saw this:

Let's check it out:

I used the generated creds above then got hit with 2FA:

Time for more enumeration. Gobuster turned up some things:

I was stuck here for a long time, gobusting everything, fuzzing for potential php parameters and all kinds of failure. I don't even remember how I came across it but while flailing at the API, I got an error message:

I threw the request to Burp and changed it to a POST request:

Ok, a change in error messages is good - that means something is right. The error message is in JSON format so I tried POSTing the cookie as the session value and got a different error message, "Missing parameters". Cue all kinds of flailing on my end before I took a breath and thought about TOTP and what it stood for - Time-based One Time Password. If you've ever used Google Authenticator, they give you backup codes to use so I started playing around looking for that:

Some more flailing and I eventually got the syntax right:

Entering that finally let me in to the website whose animations promptly bogged down my VM:

Initial Foothold

I browsed around the site and found a link to a PDF about their firmware:

I downloaded the tar file and extracted it:

strings is a handy command to run on binaries to show what may be stored as plain text inside:

I don't know much about bin ex and needed a nudge that the 'stty raw -echo min 0 time 0' was the thing to focus on. I did know that the 'system' call is important and googling around taught me that stty line reads user input so that started making some sense. Bin ex is not my strength but I do know how to use a hexeditor so gave that a try. The idea was to replace the 'stty' line called by system with my own command. In order to not completely throw off the binary, the length of my command needs to be the same. Let's count the characters in the 'stty' line:

So we need to match the length of 28 characters. I decided to start with ping and came up with a padded command that matched the length:

I opened up Protobs.in in hexedit and found the 'stty' line:

Then I headed to CyberChef to convert my ping command to hex:

I changed the hex and saved:

I tarred up the edited firmware and uploaded:

I had tcpdump listening for icmp requests and got a ping:

So the next step was going for a shell. I created a short reverse shell script:

I was able to get PlayerTwo to download a shell script from me pretty easily but it took a little while for me to realize that just because it grabbed the file from me successfully didn't mean it was able to write to whatever location it was trying by default. Here's the hex to download my script and write it to /tmp/e:

Hex to make the script executable and run it:

With a netcat listener, I finally got a shell:

User Pivot

I went down a lot of rabbitholes looking at mysql and whatnot before running linpeas. It flagged mosquitto.conf:

ps -aux shows that it is running:

I had never heard of Mosquitto and only vaguely heard of MQTT. A bit of googling and I found an excellent article describing it and how to hack it. I copied his script from section 6:

I proceeded to run it on PlayerTwo and got a ton of stuff flying by before I spied a private key:

Linpeas also flagged a couple of users from /etc/passwd:

I copied the key, saved it and now had SSH access as observer:

User flag:

Privilege Escalation

There's a PDF in observer's home dir:

I downloaded and viewed it:

I poked around the system some more and found the binary for the configuration utility mentioned in the PDF:

Seeing the libc included with the binary gave me a sinking feeling - binary exploitation that I don't really know how to do.

The Unintended Win

I thought I might have to be satisfied with just the user flag when a HTB buddy gave me a cryptic clue to use what I had already done. I had to think it over for a bit before settling on the MQTT thing. What if I could use that to read a file other than observer's id_rsa? I backed up the private key and was surprised I was able to create a symlink to the root flag:

I re-ran the MQTT script and where I saw the id_rsa file earlier, now sat the root flag:

I look forward to watching how Ippsec does the intended route :D.

ServMon was an easy rated Windows box that took me longer to solve than I expected given the rating. Sensitive files stored on an anonymous FTP server, a directory traversal vulnerability in a web server and some password spraying were used to gain a low privilege shell. From there, the admin password for NSClient++ was found stored in plain text and port forwarding was used to access the NSClient++ web server. These admin privileges were abused to upload and run a reverse shell script resulting in a system shell. I added servmon.htb to my /etc/hosts and got to work.

Enumeration:

nmap:

Nmap scan report for servmon.htb (10.10.10.184)
Host is up (0.070s latency).
Not shown: 65516 closed ports
PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|01-18-20  12:05PM

Users
| ftp-syst:
|  SYST: Windows_NT
22/tcp    open  ssh           OpenSSH for_Windows_7.7 (protocol 2.0)
| ssh-hostkey:
|   2048 b9:89:04:ae:b6:26:07:3f:61:89:75:cf:10:29:28:83 (RSA)
|   256 71:4e:6c:c0:d3:6e:57:4f:06:b8:95:3d:c7:75:57:53 (ECDSA)
|_  256 15:38:bd:75:06:71:67:7a:01:17:9c:5c:ed:4c:de:0e (ED25519)
80/tcp    open  http
| fingerprint-strings:
|   GetRequest, HTTPOptions, RTSPRequest:
|     HTTP/1.1 200 OK
|     Content-type: text/html
|     Content-Length: 340
|     Connection: close
|     AuthInfo:
|    
|    
|    
|    
|    
|    
|    
|    
|    
|   NULL:
|     HTTP/1.1 408 Request Timeout
|     Content-type: text/html
|     Content-Length: 0
|     Connection: close
|_    AuthInfo:
|_http-title: Site doesn't have a title (text/html).
|_http-trane-info: Problem with XML parsing of /evox/about
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
5040/tcp  open  unknown
5666/tcp  open  ssl/nrpe?
|ssl-date: TLS randomness does not represent time
6063/tcp  open  tcpwrapped
6699/tcp  open  tcpwrapped
7680/tcp  open  pando-pub?
8443/tcp  open  ssl/https-alt
| fingerprint-strings:
|   FourOhFourRequest, HTTPOptions, RTSPRequest, SIPOptions:
|     HTTP/1.1 404
|     Content-Length: 18
|     Document not found
|   GetRequest:
|     HTTP/1.1 302
|     Content-Length: 0
|     Location: /index.html
|    tings.
| http-title: NSClient++
|_Requested resource was /index.html
| ssl-cert: Subject: commonName=localhost
| Not valid before: 2020-01-14T13:24:20
|_Not valid after:  2021-01-13T13:24:20
|_ssl-date: TLS randomness does not represent time
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49668/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49670/tcp open  msrpc         Microsoft Windows RPC

Let's see what the website looks like:

NVMS eh? Let's see if searchsploit has anything on it:

Let's try it out:

Well, that worked. The problem with LFI is that you need to know specific filenames since you can't browse directories so I put that on the backburner for now.

Without any creds, I checked FTP to see if anonymous access was enabled. It was and I downloaded a juicy looking file from Nadine's home directory:

I found another text file in Nathan's directory and grabbed that too:

Let's see what's in 'Confidential.txt':

Nathan's to-do list:

Initial Foothold

Now that we have a file name and location to check out courtesy of Nadine, it's time to use that directory traversal vulnerability from earlier:

I saved the potential passwords to 'passwords.txt' and created a 'users.txt' with Nadine and Nathan's names inside. Time to spray with crackmapexec:

Let's just verify it works with SMB as I could not list shares with a null session before:

I tried the password on SSH and got in:

User flag:

Privilege Escalation

While enumerating the system, I saw that NSClient++ was installed, matching the nmap results:

Let's check searchsploit again:

Let's see what the text says:

Let's see if that holds true for us:

With the password ready to paste in, I hit up http://servmon.htb:8443 to try and sign in:

I got bonged at the door:

Looks like some port forwarding is needed:

Now I'm able to log in and access NSClient++:

NSClient++ was originally made as an agent for Nagios, which I am pretty familiar with so I thought I had it made.

NSClient++ has the ability to run external scripts but its GUI was so vastly different than what I had seen in Nagios that I simply could not get it to work. I failed for hours trying various things before finally taking a breather and looking at some api docs. I tried to list the external scripts installed:

Encouraged by that, I tried running a script:

Sweet, that worked! Time to create a reverse shell script using nc.exe that I uploaded to c:\temp:

Now to upload it:

OCD required me to make sure it was there:

I probably could have run the script with curl like I did the other one but I was so annoyed at the GUI I had to show it who's boss. I found my script under 'Queries':

I clicked on 'rs' then 'run:

With a netcat listener, I caught a shell as system:

The root flag:

Monteverde was a medium difficulty Windows box in which lazy password practice combined with password spraying allowed access to a SMB share. An Azure XML file was found with another password which was again sprayed to get a shell. The compromised user was a member of the 'Azure Admins' group and these privileges were abused to become domain admin on the box. Pretty nifty and I got to learn a bit about Azure.

Enumeration

nmap scan:

This looks like a domain controller for Megabank. SMB and WinRM stick out to me. I could not get a list of SMB shares without creds so I ran enum4linux and got a list of users and saved it to a file 'users.txt':

Initial Foothold

One all too common password scheme is to set the password to the same as the login, presumably because you can never forget it. So I fired up crackmapexec and sprayed:

Those creds work and we can now get a list of shares:

I started poking around in the shares and was somewhat surprised to find that 'SABatchJobs' had access to the 'users$' share:

In mhope's directory, there's an XML file so I grabbed it:

In it we find a password:

In theory, I could have just tried the password with mhope's account but it's quite fun to password spray so that's what I did:

I fired up Evil-WinRM and got a shell:

User flag:

Privilege Escalation

It's always helpful to know what you're working with when you've got a shell so let's see what groups we are a member of:

'Azure Admins' caught my eye as it's not something I usually see on HTB.  After some googling around I found this article detailing how you can get plain text credentials when the Azure AD Connect service syncs things between the local AD domain and the Azure domain. This reminded me of the DCSync attacks that some boxes have used on HTB and elsewhere. Anyway, that article has a PoC script - problem is, it didn't work as is. It took a lot of time and a nudge to get it working. There were 3 changes that needed to be made. Unfortunately, I somehow managed to delete the edited file so here are my notes on the changes made :

1. Remove the '@_xpn_' from this line: Write-Host “AD Connect Sync Credential Extract POC (@xpn)\n”
2.  The connection string should be $client = new-object System.Data.SqlClient.SqlConnection -ArgumentList "Server=LocalHost;Database=ADSync;Trusted_Connection=True;"
3. This line has the wrong type of quote marks. It needs the double quotes: add-type -path 'C:\Program Files\Microsoft Azure AD Sync\Bin\mcrypt.dll’

Here's what it looks when run:

I have a feeling that vbscrub (a Windows wizard who has created some boxes for HTB and has a great youtube channel) took pity on everyone struggling to get the above PoC working because he posted an article a few days after Monteverde was released. In it, he goes over the exploit and links to a compiled program you can simply run:

With the administrator password, we use Evil-WinRM again to get an admin shell:

Root flag:

Resolute was a medium rated Windows machine in which LDAP was queried for a list of users and an initial account password. This password was sprayed across the found usernames for a shell. Enumerating the system yielded a password for another user who was a member of the DnsAdmins group. These privileges were combined with a DLL injection attack to gain a system shell. All in all, a fun box. Let's get started.

Enumeration

nmap:

This is a pretty typical port list for a domain controller. I checked SMB first but couldn't list any shares so it was time to check LDAP. A piece of key information from this is that the domain is listed as 'megabank.local'. Let's see if we can get a list of users first:

With some bash-fu, I cleaned this up and saved the sAMAccountName fields to 'users.txt'. Next, I dumped everything LDAP would give me into a file 'ldap.txt':

Initial Foothold

This was a ton of info to sift through in the LDAP dump but eventually I found a password in the description field for Marlo Novak:

Does this happen in real life? Yes it does - some admins incorrectly assume that only someone with administrative privileges can read the 'description' field. Anyway, this password didn't work for Marko so I used CrackMapExec to try the password on my list of users:

The nmap scan showed that port 5985 is open. It's the default port for WinRM so I gave that a shot and got a shell:

User flag:

User Pivot

I enumerated the system for quite a while and turned up nothing before remembering that PowerShell needs a flag to view hidden files (on Linux, I do ls -al reflexively without thinking about it). I found an interesting folder 'PSTranscripts' in the root of the drive:

Inside it we find a text file:

In the text file we find creds for Ryan:

I try those creds and they work, giving us a new WinRM shell as Ryan:

Privilege Escalation

On Ryan's desktop there's an interesting note:

I think it's basically to clean up after HTB players who don't clean up after themselves and to avoid spoiling the machine when multiple people are hacking at it - nothing helpful with privilege escalation. Anyway, with Windows machines when I pivot to another user, one of the things I always check is group membership:

The DnsAdmins group caught my eye. A bit of googling around and I found this article which detailed how to escalate to SYSTEM from DnsAdmins.  Basically you create a malicious DLL, run dnscmd to load said DLL, then restart the DNS service.

The DLL

My first thought was to use msfvenom to create a DLL but I ran into allllll kinds of headaches with Windows Defender detecting and killing my attempts. After quite some time, I eventually found this script which uses C for the reverse shell. It required some tweaking as it downloads nc.exe from github.com by default. I edited it to download it from me instead:

I ran the script to generate the DLL with a nc.exe reverse shell payload:

Injecting the DLL

I hosted the DLL in a Samba share and ran dnscmd to inject the DLL:

Restarting the DNS service = pwned

First I started a Python simple HTTP server to host nc.exe for Resolute to download from. The final step was to restart the DNS service:

I saw nc.exe being downloaded from my HTTP server and with a netcat listener, I caught a shell as SYSTEM:

The root flag:

This blog is hosted on a server that I control and I check the logs pretty regularly to make sure things are on the up and up. While checking logs yesterday, I noticed a spike of referrals from a website I didn't recognize so I checked it out:

Looks pretty innocuous right? I clicked on his Obscurity writeup and instantly recognized images and word-for-word plagiarism from my writeups. I did some investigation and found he ripped off other people as well for at least four writeups - Obscurity, OpenAdmin, Traverxec and Mango.

Obscurity

This is lifted straight from my writeup:

My writeup:

Here's more plagiarism from Manish Bhardwaj:

My writeup:

Here's the page info from Firefox:

Manish Bhardwaj hotlinked to all of the images for my Obscurity writeup:

OpenAdmin

Manish Bhardwaj also ripped off my writeup on OpenAdmin:

More word-for-word plagiarism from Manish Bhardwaj:

My writeup:

I guess I should be thankful he linked to my github instead of claiming that as his own too:

I'm not the only person he steals from though:

The original source:

You can find that original post he stole from here.

Traverxec

Yet more plagiarism. Manish Bhardwaj is passing this off as his own:

The real source:

The only time Manish Bhardwaj hosts an image on his site is when it's stolen and snipped:

The original post Manish Bhardwaj stole from can be found here.

Mango

More plagiarism:

Again, the only time Manish Bhardwaj hosts the image is when it's snipped:

The original post Manish Bhardwaj stole from can be found here.

An Unplesasant Surprise (for Manish Bhardwaj)

Since I have full control of this server, I made some tweaks to my webserver configuration. Without touching anything on his server, his writeups that plagiarized my images now look like this:

I would love to see his face when he discovers this :D.

The Plagiarizer

Look at this guy's profile:

Manish Bhardwaj bills himself as a Certified Ethical Hacker and appears to be teaching courses on the subject:

Part of being an ethical hacker is well, being ETHICAL. There is nothing ethical about plagiarizing other people's work and passing it off as your own. I strongly encourage anyone thinking of hiring Manish Bhardwaj to reconsider and look elsewhere. Can you really trust him not to do anything shady with your network given the behavior exhibited here?

To add insult on top of injury, he is trying to profit off plagiarizing others by monetizing with Google ads!

To sum it all up: