CompTIA Exam Prep - ITF+, A+, Network+, Security+, CySA+

Kerberos attacks are among the most common findings in Active Directory assessments, and almost none of them exploit a software vulnerability. They abuse features the protocol offers to any authenticated domain user . That is what makes them hard to patch away and why the defenses are configuration and monitoring rather than an update. If the protocol itself is unfamiliar, start with how Kerberos issues tickets, because every attack below is a twist on the normal ticket flow. Kerberoasting Any authenticated domain user may request a service ticket for any service principal name in the domain. That is not a bug — it is how a client obtains access to a service. The ticket it receives is encrypted with the password hash of the account the service runs under. So an attacker with any valid domain account enumerates service principal names, requests tickets for the ones tied to user accounts rather than machine accounts, and takes the tickets offline to crack. Nothing is tried aga...

Kerberos is the authentication protocol at the heart of Active Directory, and it is the reason you type your password once at login and then reach file shares, printers, and applications all day without typing it again. It is named after the three-headed dog of Greek myth, which is a fair description of its three-party design. Kerberos proves who you are without ever sending your password across the network — not even encrypted. That is the central idea, and it is what separates Kerberos from the protocols it replaced. Older schemes transmitted passwords or password hashes that could be captured and replayed. Kerberos instead uses your password locally, as a key, to decrypt something only you should be able to decrypt. The Three Parties The client — the user or service requesting access. The Key Distribution Center (KDC) — the trusted third party, which in Active Directory is every domain controller. It has two functions: The Authentication Service (AS) , which verifies...

Lateral movement is how an attacker gets from wherever they landed to wherever they wanted to be. The first compromised machine is almost never the objective — it is a receptionist's laptop, and the target is a file server, a database or a domain controller. This article covers the movement itself and how to detect it. For the proxy and tunnelling mechanics that carry it, see the companion article linked at the end. Why it matters more than initial access Initial access will eventually succeed. Someone will click something, a credential will be reused, an internet-facing service will be unpatched. What determines whether that becomes a breach is whether the attacker can move. A foothold on an isolated workstation with no reusable credentials and no reachable neighbours is an incident; the same foothold on a flat network with a cached domain administrator token is a catastrophe. This is the argument for segmentation, tiered administration and zero trust, and it is why detection...

Service accounts are the identities nobody owns. They were created for an application years ago, their passwords were chosen by a human and never changed because rotating them breaks something, and they frequently hold far more privilege than the service requires. They are the most reliable route to domain compromise in most environments, and the fix is structural rather than technical. Why they end up weak Three pressures push in the same direction. A service account's password must be known to whoever configures the application, so it tends to be human-chosen and human-memorable. Changing it requires coordinated updates wherever it is configured, so it is not changed. And granting it broad rights avoids the tedious work of determining what it actually needs, so it accumulates privilege. The result is a domain account with a weak, static password, excessive rights, and no interactive user to notice anything unusual. The specific attack that exploits this is Kerberoasting : any...

Kerberos, RADIUS, and SAML all show up on the CompTIA Security+ (SY0-701) exam as answers to the same underlying question: how does this user or device prove who they are? The trouble is that scenario questions rarely name the protocol directly — they describe a situation and expect you to recognize which one fits. This guide is built around that recognition problem: a quick fingerprint for each protocol, the exact clues that point to one over the others, and where the three fit together in a real network rather than competing for the same job. Each of these has a full deep-dive elsewhere on this site, so this article stays focused on telling them apart under exam pressure rather than re-explaining the internals. The One-Line Fingerprint for Each Kerberos — ticket-based authentication inside a single Windows domain. You log in once at your desk and reach file shares, printers, and internal apps without typing your password again. See our full Kerberos guide for the ...

Privileged access management controls the accounts that can do the most damage: domain administrators, root, service accounts, database owners, cloud root accounts and network device credentials. The premise is that these accounts are the real prize in almost every intrusion, so they deserve controls that ordinary accounts do not. The problem with standing privilege Traditionally an administrator holds privileged credentials permanently. Those credentials exist continuously, which means they can be stolen continuously — by phishing, by credential dumping on a machine the administrator logged into, or by an attacker finding them in a script. Shared administrative accounts make it worse. If five people know the root password, an action taken by that account cannot be attributed to a person, which destroys accountability and makes investigation guesswork. PAM attacks both problems: remove standing privilege, and make every privileged action attributable. The core capabilities Crede...

Password policy is one of the few areas where expert guidance reversed itself, and where a lot of organizations are still enforcing rules that current standards actively recommend against. The direction of the change is consistent: fewer arbitrary rules, longer passwords, and screening against what attackers already know. Length over complexity Composition rules — one uppercase, one number, one symbol — were meant to enlarge the search space. In practice they enlarge it very little, because people satisfy them predictably. A requirement for a capital produces a capital first letter; a requirement for a number produces a digit at the end; a requirement for a symbol produces an exclamation mark. Cracking tools encode these patterns, so the transformations add almost nothing. Length is different. Each additional character multiplies the search space, and a long passphrase of ordinary words beats a short mangled password on both security and memorability. Current guidance se...

NTLM is the authentication protocol Windows used before Kerberos and still falls back to constantly. Its two fundamental weaknesses — the password hash functions as the credential, and the authentication is not bound to a service — are the reason two of the most durable Windows attacks exist. This article is about the protocol itself; how attackers get clients to authenticate to them in the first place is covered under LLMNR and NBT-NS poisoning . The challenge-response exchange A client requests access. The server sends a random challenge. The client computes a response using the challenge and its NT hash — a hash derived from the password — and returns it. The server, or a domain controller on its behalf, computes the same value and compares. The password itself never crosses the network, which was the design goal. What matters is what follows from the details. NTLMv1 uses a weak construction that can be broken to recover the hash outright and should be d...

Active Directory compromise rarely comes from one catastrophic misconfiguration. It comes from a chain of individually reasonable permissions that nobody ever looked at end to end. Attack path mapping is the practice of treating the directory as a graph of who can control whom and asking the only question that matters: from where I am now, how do I reach domain administrator? Why a checklist misses it Audits examine objects one at a time. This group has these members; this account has this right; this administrator can reset these passwords. Each looks defensible in isolation. The compromise lives in the composition. A helpdesk group can reset passwords for a service desk group; a member of that group sits in a group with local administrator rights on a server; a domain administrator logged on to that server last week and left credentials in memory. No single step is wrong. The path is fatal, and no per-object review will ever surface it. Graph analysis finds it because it asks f...

Offline password cracking is what happens after a breach. The attacker has the hashes and no longer has to talk to your service, so rate limiting, lockout and monitoring are all irrelevant. What remains is arithmetic: how many guesses per second the attacker can make, and how many guesses your passwords require. Why hashing, and why that is not enough Storing passwords hashed means a breach does not immediately reveal them. Hashes are one-way, so the attacker must guess a candidate, hash it, and compare. The problem is speed. General-purpose hash functions were designed to be fast, which is exactly wrong here — a modern GPU computes billions of fast-hash guesses per second, and dedicated hardware does far more. Against that rate, any password a human chose and can remember falls quickly. So a password hash function needs to be deliberately slow, and slow in a way that does not help the attacker more than the defender. Salting A salt is a unique random value stored alongsid...