Dictionary and Brute-Force Attacks, Responsibly, in a Lab

Guessing a password sounds simple, and in principle it is: try candidates until one matches. In practice, doing this responsibly, efficiently, and within the law requires real discipline. This lesson covers dictionary and brute-force techniques strictly as a method to understand and to practise inside your own authorised lab.

Two families of guessing strategies

• Dictionary attacks: trying passwords from a prepared list of likely candidates, typically common passwords, words from a given language, or terms related to the target (such as a company name or product name combined with common patterns). This is efficient because real-world passwords cluster heavily around a relatively small set of common choices and patterns.
• Brute-force attacks: systematically trying every possible combination of characters up to a given length. This is exhaustive but can be extremely slow for anything beyond short passwords, since the number of combinations grows very quickly with length and the range of allowed characters.

In practice, testers and attackers alike favour dictionary attacks, often combined with common transformation rules (such as adding a digit at the end, or substituting a letter for a similar-looking symbol) rather than pure brute force, precisely because real passwords are rarely random.

Online versus offline guessing

This distinction matters enormously for both effectiveness and risk:

• Online guessing means trying candidate passwords directly against a live login interface (a website, an SSH service, and so on), one attempt at a time, over the network. This is slow (limited by network round-trips and, ideally, by the target's own protections) and highly visible: a well-defended system will log, rate-limit, or lock out accounts after repeated failed attempts, which is exactly why those defences exist.
• Offline guessing means computing hashes of candidate passwords locally and comparing them against hashes already obtained (as discussed in the previous lesson), with no interaction with the live system at all during the guessing itself. This can be far faster, limited only by the tester's own computing power, and generates no login attempts for the target to notice.

Why rate limiting and lockouts matter so much

From a defensive standpoint, which you have studied throughout this track, the single most effective practical defence against online guessing is to slow attackers down or stop them after a small number of failed attempts, combined with multi-factor authentication so that a guessed password alone is not enough. When you test a live login interface, observing whether these protections exist, and how they behave, is itself one of the most valuable findings you can report, often more valuable than whether you personally managed to guess any specific password.

Practising offline guessing in your lab

Because offline guessing does not touch a live service, it is the safer, more instructive exercise for a lab setting, using hashes you have legitimately obtained from your own lab machines (for example, following the official material of a training platform machine designed to teach exactly this). The general shape of the process:

1. Obtain the hash value and identify, as far as possible, which hashing method produced it.
2. Choose a wordlist appropriate to the exercise; many training platforms and Kali Linux itself include publicly available wordlists of common passwords specifically intended for this kind of learning exercise.
3. Run a password-cracking tool that hashes each candidate from the wordlist using the identified method and compares the result to the target hash, stopping when a match is found.

A generic illustration of the shape of such a command, using a widely known open-source cracking tool, against a hash obtained from your own lab exercise:

# Conceptual illustration only — follow your specific lab exercise's
# own instructions for the exact tool, method flag and wordlist to use.
hashcat -m 0 my_lab_hash.txt rockyou.txt

Here, -m 0 would specify a particular hashing method for the tool to use when generating candidates, and the two file names represent the hash to test and the wordlist of candidates; the exact values depend entirely on the specific lab exercise you are following, which is why this course presents it only as an illustration of the pattern, not a ready-to-run recipe.

Reading the result honestly

If a candidate from a common wordlist matches quickly, this is a strong, reportable finding: it demonstrates that the password was weak and common, with real, concrete evidence. If nothing matches within a reasonable, agreed time and resource budget, this is also worth reporting honestly: "no match found within the agreed wordlist and time budget" is a true, useful statement, very different from "the password is strong", which cannot be concluded from a limited attempt alone.

Your fil rouge: a password strength note for Lighthouse Labs

Using a training-platform lab exercise built specifically for password-hash cracking practice (follow that platform's own official instructions for the exact tool and wordlist), attempt to recover one lab password hash offline, and write a journal entry following the "read the result honestly" principle above: what you tried, what wordlist and time budget you used, and the precise, honest conclusion, whether a match was found or not.

Your turn: online or offline?

For each scenario, say whether online or offline guessing is the appropriate, authorised approach, and why.

1. You have, through authorised exploitation, obtained a copy of a lab system's password hash database.
2. The client has explicitly asked you to check whether their public login page has any rate-limiting or lockout protection, as part of the agreed scope.
3. You want to quickly try one extremely common password against a live lab login page, with the client's explicit agreement covering exactly this limited test.

See a solution

For (1), offline guessing is appropriate and far more efficient, since you already hold the hashes and no further interaction with the live system is needed. For (2), this requires deliberately sending a number of failed login attempts against the live interface, which is inherently an online approach, explicitly agreed in scope because of its potential to trigger lockouts affecting real users. For (3), a small, explicitly agreed online attempt is appropriate, precisely because the scope covers this specific, limited technique; without that explicit agreement, even a single such attempt would be inappropriate given the risk of triggering account lockout or alerts on a system you do not fully control.

Guessing a password is only one way to gain access to an account. The next lesson introduces another: reusing an already-known credential through pass-the-hash and replay techniques.