CRTP Outside CRTP: Do the Skills Survive in the Wild?

Passing CRTP proves you can execute the path. It does not prove the path exists.

So I ran a quick 2-day experiment. As part of my effort to learn the mental landscape of an attacker, I took the exact CRTP playbook — same commands, same tool chains, same mental models — seperated it and dropped it like a living alien creature into a different Active Directory environment: HTB Academy’s Inlanefreight assessment.

No walkthroughs, no adapting from spoilers, no Dollarcorp assumptions. The only sure similarity would be that both had vulnerable environments.

Just: does it transfer?

This write-up isn’t about finishing the box. It’s about answering a harder question:

To what extent is CRTP teaching durable tradecraft — vs fantasy and storytelling curated to a particular school of thought?

1. The Experiment

Goal: Measure how much of the CRTP tradecraft is universal / transferable vs. tightly coupled to the Dollarcorp lab’s happy-path sequences, tooling defaults, and minimal defensive friction.

2. Why Transferability Matters (Even If Nothing Is Truly Universal)

Red teaming always contains unknowns:

• Defender detections absent in training
• Group Policy that silently breaks expected behavior
• Credential state (expired, must-change, disabled)
• Network segmentation and proxying requirements
• Lab resets that wipe your artifacts mid-attack

Every lab will be and should be an unknown landscape and different. If you internalize rigid “this exact command always works” muscle memory, you quickly fall into LLM patterned matching mentality… a “see what sticks” mode — both tactically and architecturally.

And that kills actual attacker instinct. The more protocol-level, permission-level, and behavior-level understanding you carry forward, the less brute-force blind trial-and-error you need.

So the real question wasn’t “can I finish the box?” It was: How much of CRTP survives outside CRTP?

Of course, with a dash of realization that the ultimate test will be real world environments. This experiment is a practical step along that path, a way to verify the certification industry, to cross compare attacker models and methodologies. We offer this as a preflight test, before more risky in-flight validation.

3. Reconstructed Attack Chain (HTB Inlanefreight flavor — no copyrighted walkthroughs reproduced)

Although I initially sought out to conquer HTB blindly, to fully test my CRTP tool belt, I am providing a rough overview of the HTB experience here so the experiment is more clear.

The HTB Inlanefreight scenario we are testing against runs something like an escape room. After some Kali Linux footwork you more or less find yourself locked in a web server, constrained as it were, but you discover a peephole (a reverse shell) that allows you some meaningful communication and execution privleges. At a high level the present CRPT labs offers a similar starting point in Learning Objective 07, but while the heroes in CRTP labs gain the option to storm the castle and branch out, the HTB AD Lab is more linear and follows a different path. This different path ensures our experiment is worthwhile.

In HTB our hero is able to smuggle in a tiny shell into his webserver prison and from there implement a more permanent shell. This enables him to effectively communicate outside the webserver, with other hosts and DCs on the directory.

This is quite a different branch from the CRTP lab in which our hero eventually commanders the hosts and steals the castle keys via Mimikatz, while our hero in HTB is expected to run the remainder of the attack through the reverse shell peephole in his prison.

The overall attack chain discussed on HTB’s site follows approximately this path:

1. Initial Foothold → initial code execution via uploaded a webshell and then a more stable reverse shell
2. Enumeration involving a Low-priv foothold → PowerView / SharpHound and/or BloodHound → discovery of control plane vulnerabilities
3. Exploitation in the form of Identity and Credential Abuse → DCSync to steal some AD control plane keys (not the castle keys)
4. Lateral Movement / tunneling → reaching the Domain Controller
5. Privileged Access Compromise → NTLM pass-the-hash for remote execution on DC01 (checkmate!)

This is gathered from the lesson itself as well as public facing content in the HTB Academy official module page.

So the initial conditions are very close to our CRTP / Dollarcorp sequences — but where our heroes go, the environments, attack paths should be quite different.

3. A Reconstructed Attack Chain

Roughly speaking the general HTB attack chain discussed looks like this:

At a high level this matches much of the CRTP toolset but we will find the devil in the details!

Now that we have built this pattern out we can account for whether or not CRTP commands provided in materials actually work when set loose in the lab. Effectively I designed a CRTP script and walked through the lab environment to see how far I could get, then identified points of failure.

In the following tables we compare results, which CRTP parallel attacks worked and where they failed (and we needed to try HTB pathways).

Initial Foothold — FAIL

For the Initial Foothold component I felt far away from home; much of my CRTP tooling was directly useless. For one the HTB lab involved a Linux foothold and like many CRTP students I trained in Windows (although CRTP provides both sets of commands). Getting to the first foothold also seemed to require some degree of networking and scanning, which is not a CRTP strength. Third, the HTB Meterpreter shells that worked did not resemble the Powershell reverse shell one-liners I was used to in CRTP. Attempts to actuate shells using CRTP commands initially worked but resulted in many crashes and I could not proceed with them. Eventually I had to turn to HTB’s Meterpreter to move forward.

Posting tools to the compromised AD host posed minor challenge however. I was able to upload shells via the compromised web server with ease and once Meterpreter was running I merely used Invoke-WebRequest to transfer files.

Phase 2 Enumeration — 100% PASS

Once my reverse shells got me into an actual Powershell on an AD host I felt a deep sense of relief since this was the CRTP environment I was used to. Now the CRTP commands functioned successfully with only a little flag and environmental tuning. I successfully enumerated and executed most of the enumeration contained in CRTP Learning Objectives 1–8.

As a matter of efficient tactics and strategy, Powerview generated a lot of noise. In future hacking escapades I recommend relying on it less and instead focusing on Bloodhound, which provides key signaling to drive strategy decisions at the control plane. This was the same lesson CRTP material had implied, and the additional exposure cemented this approach for me. Bloodhound findings specifically included:

Shortest Path to DA analysis — “WHERE is the DA? can I quickly take an elevator to DA?”. However there was not much signal detected for this lab; I did not see a clear path.

Admin Group Control- “WHO controls the DA? Am I adjacent to such a group?” The point of this check is to see if the builders gave a user privleges they should not have. I did not see a clear signal and path in HTB as only the EA and DA maintained control over the Admin Group.

Kerberoastable Users- “Whose tickets can I potentially steal?” This provided a clear signal, as there were many SQL and Backup users. It aptly predicted the next attack.

DCSYNC Users- “Who can copy a domain” While AD creates the illusion of a single Identity and Control plane, in the age of the Internet there is rarely a true identity singularity. AD appears centralized but technologists know under the hood it is a trust fabric (we will take this concept to the cloud later).

As a matter of architecture and decentralized-centralized security, AD security depends on DCs sharing data behind the scenes. Replication is continuous and it is why when you login to the ASPAC DC, you are able to successfully authenticate with the same credentials as when you log into your NAM DC. But domain replication means everything: schema, keys, secrets, passwords, so DCSYNC architectural necessity (a security trade-off for distributed security) becomes Red Team gold.

Architecture precedes hacking.

To top it off we have an opening for misconfiguration; many builders mistakenly provide these functions to users and machines, sometimes as a matter of convenience (ex: say someone wants to troubleshoot this function). In the case of this HTB lab this was a huge signal, a user has DCSYNC rights. This aptly predicted later stages of the attack because an attacker knows if they can get to a DC they can DCSYNC with this user. Predictably, after Kerberoasting users we likely make a few lateral moves to a DC and DCSYNC.

This was the second huge takeaway in terms of attacker mentality and strategic insight and it also proved just why Bloodhound and Powerview (which leverages AD’s architectural constraint to communicate) and DCSYNC are necessarily universalized and applicable across labs.

Red Teams and Sec Architects take note, for AD hacking time and time again Bloodhound will act as your strategic advisor. Time and time again the signals in Bloodhound predicted the next move an attacker would make, including in this lab.

A Strategic Mistake

Curiousity kills and here I thought, even in the midst of Bloodhound screaming at me to enjoy a tasty kerberoast, why don’t I run mimikatz and see if there is hidden treasure beneath my host? After all that is, I believe OCSP mentality and many HTB reflect this.

I tried Mimikatz and SafetyKatz with no luck and stopped as this proved to be a poor strategic decision. A strategic takeaway for me was: commit to follow Bloodhound. Bloodhound should supercede any lower level control signaling if the goal of the lab or test. In this way, in this HTB lab, CRTP and HTB show clear alignment... they are preaching from the same scripture. The sin of mimikatz use must be conditionalized.

Phase 3 Kerberoast — 100% PASS

Phase 3B was a partial pass, with a CRTP Pass The Hask/Ticket attack only partly working. I ran nltest /dsgetdc:<domain> and got the flags I needed to try Kerberoasting attacks derived from CRTP notes, instead of the Powerview lookup HTB method. This successfully gave me the hash of the SQL user.

With the hash in hand now it was time to crack open the hash shell and hopefully find the hidden keys inside… yet again the CRTP commands worked! This was proof yet again that CRTP carried universality and I was beginning to see architecturally why this was a necessity.

Phase 4 — Tunneling & Pivoting — FAIL

Up to this point I was thrilled; my new CRTP toolset was proving itself to be quite universal. And then I came across a real roadblock, a very HTB roadblock.

I’ve previously written about how awful HTB can be for beginners. In fact for this lab I had to reset and start over no less than 8 times to get to Phase 4 and this required re-executing every step to the point that I wanted to chuck my laptop across the coffee shop I was working in. However tunneling created and additional point of frustration due to a unique HTB issue that was absent from HTB instructions:

WDigest Clear-Text Passwords: Stealing More than a Hash

Essentially instead of providing a misconfigured or dated system HTB decided to throw a wrench in the process and add a security control to prevent people from performing what their lab encourages them to do. Perhaps a seasoned hacker would appreciate this wrench but to the beginner this can be a huge setback because neither HTB nor CRTP lessons seem to discuss it.

Fortunately it was a quick fix even if it will likely cost a CRTP or HTB person a lot of stress to overcome:

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

gpupdate /force

Finally, Chisel port forwarding was certainly not a tool covered in CRTP materials even if port forwarding was briefly covered. The intent was to provide Kali Linux tools access to the victim network (after all Kali linux Red Team tools are often more developed than Windows). I did not find a CRTP method that could compensate, perchance because CRTP is designed for both Windows and Linux Red Teams.

A Very HTB Headache

I managed to avoid the headache having seen HTB work… or not work this way before, but I think it’s important to share just how painful this is for beginners. I’d like to share on user’s review that I found on this point:

“This box is so cooked.”

“First try I did, on my web shell no matter what I did with nc.exe it would crash the whole thing and i wouldn’t get a stable shell.”

“Second try, I used the same chisel.exe and transferred it, with the same commands it didn’t work. It says Class Not Registered. Ended up using local port fwd on meterpreter, and tried proxychains with autoroute, both didnt work.”

“Third try, same chisel didn’t work, even after i downloaded a new one. Local port fwd with the same commands finally worked… but no matter what the wdigest couldn’t work, even with the suggestions here. Secretsdump.py wouldn’t work as well.”

“Fourth try, I tried to get a shell with meterpreter instead. Set up reverse port forwarding so that remote host could download from my attack host through the jumphost. The InvokeWebRequest to get revshell actually worked, but only once. Afterwards i tried downloading other files over, or the same file again, and it couldn’t make a connection to my attacker http.server. Revshell couldn’t make a connection as well”

You’ve been warned: HTB flakiness will destroy your psyche with slim pedagogical upsides.

Phase 5 — Privileged Compromise

This phase was not a clean win.

It was a partial success that exposed a deeper architectural difference.

The HTB crowd largely used:

Kali → Impacket (via packet forwarding) → DC DCSYNC → remote shell (SYSTEM)

I intentionally stuck to my CRTP toolbelt.

My model looked like this:

Compromised Webservice → Rubeus PTT → DC

And at first, it seemed superior.

My CRTP agent successfully:

• Injected a Kerberos ticket (PTT)
• Masqueraded as the DCSYNC-enabled user
• Executed DCSYNC
• Extracted the Domain Admin hash

CRTP worked.

But the final step — lateral movement to the DC — failed. The issue wasn’t privilege it was execution semantics.

Rubeus PTT does this:

• Injects a Kerberos ticket locally
• Spawns a process using that Kerberos context
• Enables outbound Kerberos-authenticated actions

It upgrades your local identity and does not force remote execution.

Impacket psexec, on the other hand, does this:

• Authenticates to the remote host over SMB using NTLM
• Installs a temporary service
• Executes a shell directly on the target
• Returns a SYSTEM shell

It forces remote execution and this permits an older, weaker NTLM path.

My Kerberos-centric CRTP model assumed:

“Being inside the network and impersonating via Kerberos should be superior.”

In many environments, that intuition is correct but in this configuration, it just wasn’t.

The network’s interoperability concessions to NTLM made remote NTLM execution the winning path.

Results

Roughly speaking CRTP prepared me 50% of the way for HTB box pops

Initial Foothold: Fail Enumeration: 100% Pass Kerberoast & Hash Abuse: 100% Pass Tunneling & Pivoting: Fail Privileged Compromise: Partial

The 50% that transferred was the most important 50%. It proved a not only that these elements of CRTP training are universal but also helped my grasp why they are universal due to necessary physics baked into distributed identity systems that carry architectural trade-offs:

• Permission model reasoning
• Kerberos primitives
• SPN hunting
• DCSYNC logic
• BloodHound-driven strategy

What did not transfer cleanly:

• Shell stability under friction
• Segmented network pivoting
• NTLM-forced remote execution workflows
• Tool reliability assumptions
• Kali-Linux dependencies

CRTP reinforced durable identity abuse and control-plane logic.

HTB also reinforced this message but coupled it with operational flexibility and cross-platform execution semantics.

Both matter in the real world and this goes to prove why learning from one school or completing one CERT is not really enough to get the full Red Team mental model.

Final Takeaway

If your Red Team or Blue Team tradecraft assumes the network is flat, forgets NTLM, pivoting and assumes tools behave predictably, then you don’t have tradecraft. You have choreography or at best pedagocial material.

CRTP does not teach fantasy. It teaches a coherent and powerful attack philosophy. But it optimizes for a particular worldview: Kerberos-first, identity-centric, control-plane abuse. That model is elegant and strategically sound. It rewards understanding replication, ticket semantics, SPN logic, and permission graphs.

HTB exposed where that philosophy collides with operational reality. In this lab, interoperability concessions to NTLM mattered and CRTP attack mentality did not prepare me for them. Network segmentation mattered. Tool reliability mattered. Execution semantics mattered. The difference between upgrading local identity and forcing remote execution mattered.

The ultimate test will always be real-world environments. Labs can simulate friction, but production networks introduce unpredictable combinations of policy, legacy compatibility, and defensive layering.

This experiment was not the final exam or a real world execution but it did serve as a valuable preflight check — a way to verify the certification model before in-flight validation.

And for that purpose, it passed.