Step 274. HTB Hard Challenge 2 — Repaying Technical Debt: Turn What You Don’t Know into a List and Pay It Off

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★★★ | Estimated time: 2 days (three half-day debt repayments + 1 retry day)

Prerequisites: the hypothesis tracker and attack log from Step 273 (HTB Hard Challenge 1) are still on hand.

What you need: your Step 273 attack log, a Markdown editor, Python 3 (for the ledger aggregator), a Hack The Box account, and one new Hard machine. The HTB assault scenes in this chapter are screen examples; the Python aggregator runs are marked as measured (2026-09-09, Python 3.12).
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Hack The Box (hackthebox.com) is a legal learning platform officially opened by its operators for attack practice — do not use today’s techniques on anything except this platform’s machines.
This is a training methodology chapter. The goal is not new attack techniques but building "a system for handling what you don’t know."

If your first Hard challenge (Step 273) is over, then whether you finished or got stuck, you’re holding one precious thing — a list of the blank spaces on your knowledge map. Protocols you skipped because you didn’t know them, frameworks you’d never seen, tools whose output you couldn’t read. Those blanks are exactly technical debt.

Skill grows not from the number of attempts but from the rotation count of the loop "attempt → discover gaps → learn → retry." Today is the second turn of that loop — ledger the blanks from your first Hard, repay them half a day at a time, and retry with a different type of Hard. The goal is just this: get farther than last time.

1. Learning Objectives

By the end of this chapter, you will be able to:

Extract "what I couldn’t do because I didn’t know" from an attack log using [UNKNOWN] tags
Build a technical-debt ledger and manage each item’s state (unpaid / repaying / repaid)
Execute a procedure for learning one unknown technique to "usable-in-the-field level" within half a day
Pick a machine of a different type from your first Hard and verify strength expansion rather than weakness avoidance
Compare two Hard assaults stage by stage and confirm progress in numbers

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Markdown (log, ledger), Python 3 (aggregator), Hack The Box Hard machines
Today’s commands	All review + reading official docs and HackTricks during the learning phase
Concepts needed	Technical debt, the debt ledger, the half-day learning unit, the retry loop
Today’s deliverable	`tech_debt_ledger.md` (3+ items repaid) + a second Hard attack log

2-1. Technical Debt — What You Skip Accrues Interest

In software engineering, technical debt is "the correct implementation you postponed to go fast." The same thing happens in penetration learning — when you meet a technique you don’t know on a Hard machine, you detour around it or read a hint and move on, and the knowledge you skipped comes back with interest on the next machine. The same protocol reappears wearing a different face, and you stop at the same spot every time.

The scary thing about debt is that it’s invisible. If the memory settles as "that machine was just hard," the blank stays blank forever. So this chapter’s first rule is — the moment you meet something you don’t know, write it in the ledger. Debt written in the ledger can be repaid; debt never written down follows you for life.

2-2. Designing the Debt Ledger — Number, Field, Discovery Context, State

Four boxes per ledger item are enough.

DEBT-002 | Field: Web | State: unpaid → repaying → repaid
- Found: Hard machine A, froze at the SAML login screen on 443/tcp (Step 273 log 1:10)
- Content: the SAML authentication flow and common vulnerabilities (XML signature wrapping, etc.)
- Study plan: official docs overview 1h → HackTricks SAML section 1h → mini hands-on 2h

The most important box here is the discovery context. Write just "study SAML" and the learning expands without end; attach "froze at machine A’s login screen" and the learning scope narrows to "as much as a login bypass needs." The goal of repayment is not becoming an expert in that technology — it’s passing the same spot on the next assault.

2-3. The Half-Day Learning Unit — Docs, Cheat Sheets, Mini Hands-on

Cap each item at half a day (4 hours). The order is fixed.

Official docs overview (1 hour): what the technology exists for, what the normal flow looks like. If you don’t know normal, you can’t recognize abnormal (vulnerabilities).
Attacker’s cheat sheet (1 hour): skim "the typical patterns by which this technology gets broken" in a reference like HackTricks or PayloadsAllTheThings. Don’t memorize everything — just the pattern names and their telltale signs.
Mini hands-on (2 hours): your hands have to move before the item leaves the ledger. Succeed once with the technique in a related THM room, an HTB Academy module, or a Docker environment you stood up yourself.

Half a day passes and it still doesn’t click? Leave the item as repaying and move to the next one. Charging in while still not knowing is also a strategy — sometimes the desperation of meeting it again in the field is the best teacher.

2-4. Choosing the Retry Machine — Avoid the Same Type

Pick a different type for your second Hard than your first. If the first was an AD (Active Directory) machine, go web-centric or Linux this time; if it was web, pick something with a reversing element. Repeat the same type and you can’t measure the repayment’s effect — there’s no telling whether you solved it with what you already knew or with what you newly repaid.

3. Follow Along

3-1. Extracting Debt from the Attack Log — The Ledger Aggregator

First, open your Step 273 log and, in past tense, tag every "moment I stopped because I didn’t know" with [UNKNOWN] field: content. Long logs tire the eyes, so use a small aggregator that collects the tags into a ledger.

Input (the core of tmp_test/debt_ledger.py):

def parse_log(path):
    """Extract lines of the form '[UNKNOWN] field: content' from an attack log."""
    debts = []
    pat = re.compile(r"\[UNKNOWN\]\s*([^:]+):\s*(.+)")
    for i, line in enumerate(Path(path).read_text(encoding="utf-8").splitlines(), 1):
        m = pat.search(line)
        if m:
            debts.append({"field": m.group(1).strip(),
                          "what": m.group(2).strip(), "state": "unpaid"})
    return debts

Input (log excerpt — sample material):

# Hard machine A attack log (excerpt)
0:40 Anonymous bind on 389 LDAP works. Now what? [UNKNOWN] AD: LDAP query syntax for pulling the user list
1:10 443 web is a SAML login. Don't even know what SAML is [UNKNOWN] Web: SAML auth flow and common vulnerabilities
2:30 Ran certipy but can't interpret the output [UNKNOWN] AD CS: certificate template misconfiguration attacks (ESC1-8)

Output (measured 2026-09-09, Python 3.12):

No.       Field         Status  Content
----------------------------------------------------------------
DEBT-001  AD            unpaid  LDAP query syntax for pulling the user list
DEBT-002  Web           unpaid  SAML auth flow and common vulnerabilities
DEBT-003  AD CS         unpaid  certificate template misconfiguration attacks (ESC1-8)
----------------------------------------------------------------
3 items total | 3 unpaid

How to read it: the vague memory "it was a hard machine" has become three lines of concrete debt. The repayment targets now have names. In your real log the item count will differ — 3 or 10, both are normal.

Why a script: you could do it by hand, but when building the ledger is a single command, you can repeat it frictionlessly every time the retry loop turns. Training systems last longer the more they’re automated.

3-2. Repaying One Debt — DEBT-001’s Half Day

Let’s walk the repayment procedure with DEBT-001 (LDAP query syntax).

Hour 1: what LDAP is — a directory service, tree structure, the meaning of dn, ou, cn, at the official-docs level.
Hour 2: from the AD enumeration section of HackTricks, collect the typical queries for pulling the user list after an anonymous bind, like (&(objectClass=user)).
Hours 3–4: in a THM AD room or an HTB Academy module, fire queries yourself with ldapsearch and obtain a user list.

Screen example (the mini hands-on success scene — verify it yourself in your own environment):

$ ldapsearch -x -H ldap://10.10.11.x -b "dc=corp,dc=local" "(objectClass=user)" sAMAccountName
# ... (snip) ...
sAMAccountName: administrator
sAMAccountName: svc_backup
sAMAccountName: j.smith

How to read it: more important than the "got the list" result is this — the next time an anonymous bind succeeds during an assault, your hands will type this query automatically. That is the definition of repaid. Change the item’s state in the ledger to repaid.

3-3. The Second Hard Assault — Mark the Moments Repaid Knowledge Fires

Pick a new Hard machine and attack it with the same hypothesis-tracker method from Step 273. But this time there’s one added rule — every time repaid knowledge fires in the field, tag [REPAID] in the log.

Screen example (excerpt from the second Hard log):

# Hard machine B attack log (excerpt)
0:15 389/tcp LDAP open — trying anonymous bind
0:20 [REPAID DEBT-001] user list of 14 secured with ldapsearch — passed with no stall!
0:45 found a service account in the list, marked as an AS-REP roasting candidate
...
3:10 user shell secured. Took 2 days to get here on the first machine; 3 hours this time.

How to read it: the [REPAID] tag is evidence of the loop turning. The act of repaying debt becomes measurable progress instead of abstract "studying."

3-4. Comparing the Two Machines — The Stage-by-Stage Progress Table

When the assault ends (or the timebox ends), place the two machines side by side, stage by stage.

| Stage | First Hard (machine A) | Second Hard (machine B) |
|-------|------------------------|-------------------------|
| Recon → attack surface mapped | 4 hours | 1 hour |
| First meaningful find | End of day 1 | 0:45 |
| First shell | Not reached | 3:10 |
| Entering privilege escalation | Not reached | In progress |

How to read it: compare each stage’s arrival time, not completion. "First find: 1 day → 45 minutes" is the difference repayment made. This table sets the priorities of the next debt list — the stage that took long again this time is the next loop’s learning target.

4. Missions & Exercises

Mission — Repay 3 Debts and Retry

Retro-tag your entire Step 273 attack log with [UNKNOWN] field: content tags, and build the debt list with the aggregator.
Attach a study plan (docs 1h + cheat sheet 1h + mini hands-on 2h) to each debt and complete tech_debt_ledger.md.
Repay at least 3 debts in half-day units and update their states — keep the mini hands-on success scenes as evidence.
Pick a Hard machine of a different type from your first, attack it with the hypothesis tracker, and record the moments tagged [REPAID].
Build the stage-by-stage comparison table for the two machines, and pick the debt candidates to repay in the next loop.

Exercises

Exercise 1. Explain the concrete form that technical debt’s "interest" takes in penetration learning.

Exercise 2. Why does the ledger’s "discovery context" box narrow the learning scope?

Exercise 3. In the half-day learning unit, explain why the order "official docs → cheat sheet → mini hands-on" is fixed, together with each step’s role.

Exercise 4. Why should the retry machine be a different type from the first? Explain the measurement error that arises when you pick the same type.

5. Model Answers & Completion Criteria

Mission Model Answer

Whether you finish the retry is not graded. Check against the verification criteria.

The ledger exists: starting from [UNKNOWN] tags, is there a ledger with number, field, discovery context, and state?
Evidence of repayment: does every item marked repaid carry a success screen or command record from its mini hands-on — "I read it" is not repayment; "I did it" is.
The [REPAID] tag appears: is there at least one moment in the second assault log where repaid knowledge was used?
The comparison table’s honesty: is the stage-by-stage comparison in times, not feelings? Even if the second machine went worse, if that fact is written down, it’s a success — because that’s the discovery of the next debt.

Exercise Answers

Answer 1. It takes the form of stopping at the same spot every time the same technology reappears wearing a different face on a different machine. Skip LDAP unknown, and you meet the same wall at port 389 on the next AD machine, and again at the user-enumeration stage of the machine after that. Debt doesn’t disappear; it bills you repeatedly — which is why you must write it in the ledger and repay it instead of waving it off as "that machine was hard."

Answer 2. Because the discovery context is the boundary line of "how much of this technology do I need." "Study SAML" has infinite scope, but if the requirement is "pass machine A’s login screen," the learning goal narrows to "understand the login flow + common bypass patterns." Since the goal of repayment is not expertise but never stalling at the same spot again, learning without context has no end, while learning with context has a completion condition.

Answer 3. Official docs give you the normal flow — without knowing normal you can’t recognize abnormal (vulnerabilities). The cheat sheet gives you the names and telltale signs of attack patterns — the instinct to recognize "this is that pattern" in the field. The mini hands-on gives you muscle memory — what you’ve read can be searched for, but only what you’ve made succeed comes out under the pressure of a live assault. Flip the order and you have no frame for interpreting anything you meet in the hands-on, and you wander.

Answer 4. Because the repayment’s effect becomes unmeasurable. Repeat the same type and you can’t separate whether progress came from "what I already knew" or "what I newly repaid" — an experiment needs a single variable. A stage you pass without stalling on a different type of machine can be recorded purely as repayment’s fruit.

Completion Criteria Checklist

[ ] I extracted the debt list from my Step 273 log with [UNKNOWN] tags
[ ] I built tech_debt_ledger.md with number, field, discovery context, and state
[ ] I marked 3+ debts repaid via half-day learning units
[ ] Every repaid item carries mini hands-on success evidence
[ ] I attacked a Hard machine of a different type from my first and left a log
[ ] The [REPAID] tag appears at least once in the log
[ ] I built the stage-by-stage comparison table for the two machines

6. Common Pitfalls & Fixes

Wall 1. Running the aggregator throws FileNotFoundError

Symptom (measured 2026-09-09):

FileNotFoundError: [Errno 2] No such file or directory: 'no_such_file.md'

Cause: the script’s working directory and the log file’s location differ. Python resolves relative paths from the directory you ran the command in.

Fix: pass the log file’s absolute path, or cd into the log’s directory and run there. Checking the filename’s spelling with ls first is fastest — a typo in a Korean character or a space in the filename is this error’s most common real cause.

Wall 2. There’s too much debt (10+ items) and it’s overwhelming

Symptom: you tagged your first Hard log and it’s nothing but unknowns.

Cause: that’s normal — a first Hard is supposed to look exactly like that. The problem isn’t the debt count but the absence of priorities.

Fix: sort by "probability of meeting it again on the next machine." Things that recur across Hard machines — AD basics like LDAP and Kerberos — go on top. Repaying 3 items this loop is enough — the rest stay alive in the ledger, so they won’t be forgotten.

Wall 3. Some debts can’t possibly fit in half a day (e.g., "kernel exploitation")

Symptom: a topic so huge lands in the ledger that 4 hours wouldn’t even cover the introduction.

Cause: the debt wasn’t decomposed. "Kernel exploitation" is not a technique; it’s an academic field.

Fix: split it by discovery context — what the machine actually needed was not all of "kernel exploitation" but "the procedure of finding known CVEs for this kernel version and running a PoC." Ledger items must be rewritten to a size that finishes in half a day for the loop to turn.

Wall 4. Repaying debt turns into only studying, never attacking machines

Symptom: "I need to prepare more" keeps postponing the retry.

Cause: the very trap the source text points out — postponing gap-filling indefinitely is avoidance of anxiety, not strategy.

Fix: fix the rule in numbers — when 3 debts, half a day each are done, power on the retry machine no matter what. Charging in still-unknowing and stacking new items in the ledger is also the loop working normally. There’s no such thing as perfect preparation; there’s only the alternation of preparation and the field.

Wall 5. The second Hard went worse than the first

Symptom: you repaid debt and went in, yet your results got worse.

Cause: different machines demand different debt categories. Repay web debt and meet an AD machine, and the repayment never fires — it’s not skill regression; it’s category mismatch.

Fix: re-read the comparison table stage by stage. "The stage that took long again this time" is the new debt this loop discovered. And look at the totals too — if the ledger’s unpaid count is shrinking with each attempt, the loop is turning.

7. Summary

Today’s Concepts

Concept	One-line explanation
Technical debt	Knowledge you skipped without knowing — reappears on the next machine with interest
Debt ledger	A list that starts from `[UNKNOWN]` tags and manages number, field, context, and state
Discovery context	The boundary line that narrows learning scope to "as much as the next pass needs"
Half-day learning unit	Docs 1h (normal) → cheat sheet 1h (patterns) → mini hands-on 2h (hands)
`[REPAID]` tag	A record of the moment repaid knowledge fires in the field — evidence of the loop turning
Retry loop	Attempt → discover gaps → learn → retry. Skill grows from rotation count

Today’s Tools

Tool/command	What it does
`[UNKNOWN] field: content`	The tag that leaves debt in the log — the raw material of extraction
`debt_ledger.py` (example script)	Collects tags and prints the ledger table
Official docs → HackTricks → mini hands-on	The fixed order of half-day repayment
Stage-by-stage comparison table	The tool for comparing two attempts’ progress in times

An Instinct More Important Than Commands

Challenge Hard twice and you’ll know — the difference between a skilled player and a beginner is not the amount known but the system for meeting the unknown. Getting stuck happens to everyone; the fork in the road is whether it gets written in a ledger and repaid, or forgotten and billed repeatedly.

If your first Hard gave you a map of blanks, today you gained the debt-management system that fills that map in. Once this loop sticks to your body, Hard stops being a wall and becomes a machine that prints out your next study list.

Once every box is checked, Step 274 is complete. Click the checkbox in the sidebar to save your progress.