Republishing course material and lab walkthroughs isn’t something I’m interested in doing - it isn’t mine to give away, and the internet has enough copied notes already. What I’d actually found useful, over months of study, was forcing myself to explain a mechanism from scratch until it held together. So that’s what this became: original write-ups on how things actually work, built from public research and specifications, in my own words.
The first batch is up:
Alongside the writing, the Projects page now covers the two tools I maintain - OffsetInspect and OffsetScan - both read-only, both built for detection engineering and malware triage without ever touching endpoint protection.
Everything here stays defensive and educational. The goal isn’t a wall of tradecraft; it’s a small, honest set of explanations I’d have wanted when I was first figuring these out. More to come.
TLSH slides a window across the file, populates a table of buckets based on byte triplets, and derives a compact digest from the statistical distribution of those buckets - plus a header capturing overall properties like length and quartile ratios. Two files built from mostly the same bytes populate the buckets similarly, so their digests land close together.
Comparison isn’t equality; it’s a distance score. Zero means effectively identical; the number climbs as files diverge. You pick a threshold and cluster everything within it:
offsetscan cluster ./samples --recurse --threshold 40
# lower threshold = tighter, fewer clusters
# ClusterId shared = near-duplicates; null = a singleton
Exact-hash dedup collapses only byte-identical files. A repacked or recompiled variant has a fresh SHA-256 and slips the net - but TLSH still parks it next to its siblings. Across a few thousand samples that turns an undifferentiated pile into a handful of families, and a new arrival can be scored against known clusters instead of analyzed cold.
A few honest limits. TLSH needs a minimum amount of data and variance - very small or very uniform files won’t produce a usable digest. Threshold choice is a judgment call: too loose and unrelated families merge, too tight and genuine variants split. And like imphash, similarity is a lead, not attribution - pair it with import hashing and the build-toolchain fingerprint so agreement across independent axes carries the weight, not any single score. It shines exactly where single-file inspection can’t answer the question: which of these thousands are the same thing wearing different clothes?
]]>In Kerberos, when a user wants to reach a service, the KDC issues a TGS
(service ticket). A portion of that ticket is encrypted with the service
account’s long-term key. For a machine account that key is random and
effectively uncrackable. But when the SPN is registered to a regular user
account - a SQL service running as svc_sql, say - the key derives from a
human-chosen password. That’s the whole game.
The attacker never needs to authenticate to the service. They just ask the KDC for the ticket, which the KDC will hand to any valid domain principal:
1. Enumerate accounts that have an SPN set (LDAP: servicePrincipalName=*).
2. Request a TGS for each SPN.
3. Extract the encrypted blob and crack it offline against a wordlist.
Because step 3 is offline, there’s no lockout, no failed-logon noise on the target, and no rate limit.
Tickets encrypted with RC4-HMAC (etype 23) are far faster to crack than AES, and a downgrade to RC4 is often possible. Defenders should watch for a spike in TGS requests (event 4769) for RC4 etype, especially many distinct SPNs from one principal in a short window.
AMSI is a thin, in-process API that scripting hosts call to submit content for inspection. PowerShell, the Windows Script Host, the .NET runtime, and Office VBA all wire into it. The important property is timing: the host calls AMSI with the content it’s about to execute, after any obfuscation or decoding the host itself performs. So a Base64-wrapped, string-concatenated payload is handed to AMSI in its final, deobfuscated form - which is why “just encode it” rarely beats AMSI on its own.
The two functions that matter are AmsiScanBuffer and AmsiScanString. The host
passes the bytes; AMSI forwards them to the registered antimalware provider
(Microsoft Defender by default, via a COM provider interface) and returns an
AMSI_RESULT. A value at or above AMSI_RESULT_DETECTED (32768) means block.
Script host ──(deobfuscated content)──► amsi.dll::AmsiScanBuffer
amsi.dll ──(COM)──► registered provider (e.g. Defender)
provider ──► AMSI_RESULT → clean / detected
Everything is in memory and in-process. Nothing is written to disk, which is what lets a scanner inspect content that only ever exists at runtime.
Because the scan happens inside the host’s own process, the trust boundary is weak by design. The publicly documented failure classes are:
The defensive reading is the useful one: AMSI is a strong tripwire on decoded content, but it’s not a security boundary against code already running with your privileges. Treat an AMSI hit as high-value telemetry, correlate it with the process and command line that produced it, and test whether your own signatures survive trivial content mutation - a robust signature keys on structure, not on a single literal string.
]]>DS-Replication-Get-Changes)
to pull any account’s hashes straight from a DC, no code on the box. It looks
like legitimate replication, which is what makes it quiet.Every one of these captures something structural - a domain-wide key, a replication right, a CA - rather than an account. Reset the obvious credentials and the foothold remains. That’s why real remediation after a DA compromise is heavy: rotate krbtgt twice, audit and revoke replication rights, treat the CA as compromised, and in the worst cases rebuild trust from a known-good state.
4662 with the replication GUIDs) from anything that
isn’t a DC.Assume the keys, then verify visibility. Dominance is only durable against a defender who doesn’t know these exist.
]]>Entropy is defined over the byte-value distribution of a window:
H = -Σ p(b) · log2 p(b) for each byte value b in 0..255
A whole-file average hides the interesting part, so scan in windows and look at the shape:
Get-OffsetEntropy .\sample.bin -HighOnly |
Select-Object -ExpandProperty Windows
A packer usually leaves a tell: a low-entropy stub (the unpacking code) sitting
in front of a high-entropy body (the compressed payload). PE section headers
reinforce the story - a .text section whose raw size dwarfs a tiny virtual
size, or an oddly named section pegged at 7.9, is worth a closer look.
Two honest caveats. High entropy is not malicious on its own: legitimately compressed resources, embedded PNGs, and TLS certificates all read high. And low entropy doesn’t clear a file - plenty of malware is plaintext script. Entropy tells you where to look, not what you found. Cross-reference the flagged windows with the strings that survive there and with the PE section they fall in, and the packed regions usually announce themselves.
]]>A computer trusted for unconstrained delegation caches the TGT of any user who authenticates to it. So if you control such a host and can convince a privileged account to authenticate to it - the classic trick is coercing a domain controller with the printer bug - its TGT lands in your memory, ready to reuse. One caching service plus one coerced DC equals Domain Admin.
Constrained delegation (msDS-AllowedToDelegateTo) limits a service to named
SPNs, which sounds safer. The catch is S4U2Self + S4U2Proxy: an account
with constrained delegation and protocol transition can request a service
ticket to itself as any user, then forward it to the allowed SPNs - no
password from the victim required. And because delegation targets an SPN, not a
service, an attacker can often swap the service class (http → cifs) to reach
more than intended on the same host.
RBCD flips the trust: the resource declares who may delegate to it, in
msDS-AllowedToActOnBehalfOfOtherIdentity. That attribute lives on the target
computer object - so if you have write access to it (a GenericWrite, or the
right to create a machine account), you can point delegation at an account you
control and impersonate any user to that host.
ms-DS-MachineAccountQuota of 0 closes the easy RBCD path).TrustedForDelegation flags and unexpected msDS-AllowedToActOnBehalf
writes in your directory as configuration drift, not just at attack time.The recipe (originally described by Mandiant) is deterministic:
library.function, lowercased.
The library name has its extension stripped (kernel32.dll → kernel32).ordNNN, except for a few special
libraries (ws2_32, wsock32, oleaut32) whose well-known ordinals resolve
back to real names.Get-OffsetPEInfo .\sample.exe |
Select-Object Machine, ImpHash, ImportedDllCount
Because the hash is driven by which functions are imported and in what order, two samples built from the same source with the same toolchain tend to share an imphash even when their bytes differ - different strings, different resources, recompiled with a new campaign ID.
The import order is largely a property of the linker and the source, not of the
payload, so imphash clusters build lineage rather than behavior. That’s the
strength: it survives cosmetic change. It’s also the weakness - collisions are
common for anything built with the same packer or framework, so a shared imphash
is a lead, not proof. Delay-loaded imports and pure dynamic resolution
(LoadLibrary + GetProcAddress) don’t appear in the static table at all, so
malware that resolves APIs at runtime has a nearly empty imphash that says
little.
Treat it as one signal among several: pair it with the Rich-header toolchain fingerprint (build environment), a fuzzy hash like TLSH (byte-level similarity), and the Authenticode signer. When three independent axes agree, the attribution is a lot harder to argue with than any one hash alone.
]]>A golden ticket is a forged TGT, and it works because every TGT is encrypted with the krbtgt account’s key. Recover that key - the krbtgt NTLM hash or AES key, typically via DCSync after reaching Domain Admin - and you can fabricate a TGT for any principal, with any group memberships, and an arbitrary lifetime. The KDC has no way to tell a forged TGT from one it issued, because it validates the ticket by decrypting it with the very key you copied.
The uncomfortable part: rotating a compromised user’s password does nothing. The only cure is rotating krbtgt twice (the account keeps its previous key for compatibility, so one rotation isn’t enough), which invalidates every outstanding TGT in the domain.
A silver ticket is narrower and quieter. Instead of forging a TGT, you forge a
service ticket for one specific service, signed with that service account’s
key. Because the service validates the ticket with its own key and never consults
the KDC, a silver ticket generates no 4768/4769 events - there’s no
authentication traffic to log. The tradeoff is scope: the forgery only works for
that one service (and any SPN sharing the account’s key).
A diamond ticket is the stealthy evolution of the golden ticket. Rather than building a TGT from scratch, the attacker requests a legitimate TGT from the KDC, decrypts it with the krbtgt key, modifies the PAC (adding privileged group SIDs, for example), and re-encrypts it. It still needs the krbtgt key - so the root defense is identical - but because the ticket started as a real, KDC-issued TGT, it carries genuine, internally consistent fields and a real preceding AS-REQ/AS-REP.
That’s what makes it evasive: many golden-ticket detections lean on the artifacts of forging a ticket from nothing - default lifetimes baked in by tooling, implausible values, or a service ticket that has no matching authentication event. A diamond ticket inherits the KDC’s own values, so those tells largely disappear. The forgery hides inside a legitimate shell.
All three share one root cause and one root fix: protect the key material. Rotate krbtgt twice on any DA-level compromise, give service accounts long random keys (gMSAs), and treat the krbtgt key and CA as the crown jewels they are - because once they leak, the tickets they sign are indistinguishable from the real thing.
]]>AS-REQ / AS-REP - authentication. The client encrypts a timestamp with a key derived from the user’s password (pre-authentication) and sends it to the KDC. If the KDC can decrypt it, the user is who they claim. It returns a Ticket-Granting Ticket (TGT), encrypted with the krbtgt account’s key - so only a domain controller can read it back.
TGS-REQ / TGS-REP - authorization. To reach a service, the client presents its TGT and names a Service Principal Name (SPN). The KDC issues a service ticket (TGS), and here’s the key detail: a portion is encrypted with the service account’s long-term key.
AP-REQ - access. The client hands the service ticket to the service, which decrypts it with its own key. The service never talks to the KDC to validate it - it trusts anything encrypted with its key.
Client ──AS-REQ──► KDC (pre-auth timestamp)
Client ◄─AS-REP─── KDC (TGT, sealed with krbtgt key)
Client ──TGS-REQ─► KDC (TGT + target SPN)
Client ◄─TGS-REP── KDC (service ticket, sealed with service key)
Client ──AP-REQ──► Service (present the ticket)
Every well-known technique keys on one of these facts:
4768/4769.Hold this map and the rest of AD attack tradecraft stops being a list of tricks and starts being consequences of one protocol.
]]>