Full port scan reveals a classic domain controller profile: Kerberos, LDAP, and SMB. SSH on port 22 is unusual for Windows — it's OpenSSH for Windows, and it becomes the primary shell method throughout because WinRM is absent. HTTP on port 80 redirects to a Gibbon LMS instance.

Add the DC hostname to /etc/hosts — and critically, put the FQDN first. This matters for Kerberos SPN lookups (explained in detail in the Kerberos Setup section).

Confirm the NTLM situation before going further. Both SMB and LDAP null sessions return STATUS_NOT_SUPPORTED — NTLM is completely disabled at the domain level.

The HTTP site at http://frizzdc.frizz.htb/home/ runs Gibbon LMS — an open-source school management system. Research for this version reveals a known file-write RCE that doesn't require authentication.

Gibbon LMS has an unauthenticated file-write vulnerability that allows uploading a PHP web shell. The exploit abuses an AJAX endpoint in the Rubrics module that writes attacker-controlled content to the web root without any authentication or path sanitisation check.

Upgrade to a stable reverse shell by uploading nc.exe while the web shell is still alive.

The first thing to check in any PHP application is the database configuration file. Gibbon LMS stores its DB credentials in config.php at the application root.

Query the gibbonPerson table for user hashes. The passwordStrong and passwordStrongSalt columns hold the credentials.

Before cracking, always read the source to understand exactly how the hash was constructed. Getting the salt order wrong means zero cracks even with the correct password in the wordlist.

With NTLM disabled, every tool needs a valid Kerberos TGT. This is where TheFrizz forces you to understand how Kerberos authentication actually works rather than relying on the usual pass-the-hash shortcuts. The three things needed are: a correctly configured krb5.conf, a TGT obtained at the right system time, and SSH using GSSAPI to consume that TGT.

With a valid TGT in the cache, SSH uses GSSAPI (Kerberos) automatically — no password prompt. The key insight is that SSH does a reverse lookup on the hostname to build the Kerberos SPN, which is why /etc/hosts order is critical (covered in the Enumeration section).

With valid Kerberos credentials, run BloodHound collection using the --kerberos flag. NTLM is off, so bloodhound-python falls back to Kerberos authentication when collecting from LDAP and SMB.

BloodHound reveals the following attack path:

Move to M.SchoolBus using the same Kerberos workflow: obtain a TGT for the new account and SSH in. Confirm group memberships to verify the GPO creation rights are in place before attempting the escalation.

The goal is to create a GPO with a malicious scheduled task that runs as SYSTEM on the DC, delivering a reverse shell. Three components make this possible:

· Group Policy Creator Owners — M.SchoolBus can create new GPOs in the domain
· WriteGPLink — M.SchoolBus can link GPOs to OUs
· Computer Scheduled Task — runs as SYSTEM when Group Policy refreshes on any in-scope computer

This section covers four failed attempts before the working approach — each failure teaches something important about how GPO scoping actually works.

Step 1: Upload tools. C:\Windows\Temp is write-denied for M.SchoolBus. C:\ProgramData is writable and works as a staging location.

Step 2: Create the GPO and link it. Linking to just Class_Frizz is insufficient for a computer task (explained in the failures below). The GPO must also be linked to the domain root so that the DC computer object inherits it.

What failed and why — four attempts before it worked.

Step 3: Verify SYSTEM execution before deploying the shell. Test with a harmless command-to-file write first — if the output file contains nt authority\system, the computer task is running correctly.

Step 4: Deploy the reverse shell.

This is worth understanding deeply. GPO task scoping is what made this box hard, and it's a concept that trips up most people because the distinction between computer and user policy isn't obvious from the BloodHound graph.

GPO Scope — what a GPO applies to.

A GPO applies to the objects in the OU it's linked to:

· Linked to an OU containing users → user configuration applies to those users
· Linked to an OU containing computers → computer configuration applies to those machines
· Linked to the domain root → applies to all objects in the domain through inheritance

Scheduled Tasks in GPO — when they run.

Why network logon breaks user GPO tasks.

SSH creates a network logon (logon type 3). User GPO preferences and scheduled tasks are designed for interactive logons (logon type 2 — what you get at a physical console or RDP). When you run gpupdate /force in an SSH session, Windows processes computer policy reliably but silently skips user GPO preferences and scheduled tasks because there's no interactive logon context to attach them to.

The winning combination — why it worked.