Hydra

Úvod a kontext

Hydra se v tomto projektu objevuje vždy ve chvíli, kdy už existuje realistická hypotéza o přihlašovacích údajích a je potřeba ji rychle ověřit proti konkrétní službě. Není to nástroj, který by měl řešit slepé “zkusím všechno na všechno”. Je praktický právě tehdy, když už jsou známí kandidátní uživatelé, krátký seznam hesel nebo konkrétní autentizační endpoint.

Na Admireru ověřuje kombinace nalezené v credentials.txt proti SSH. Na Monteverde testuje velmi úzkou hypotézu username = password proti LDAP. Na Wallu míří přímo na Centreon autentizační endpoint místo hlučného zkoušení webového formuláře. To je důležitý pattern: Hydra dává největší smysl tam, kde z předchozí enumerace vznikl přesný a malý prostor kandidátů.

Co Hydra v praxi řeší

Hydra je nástroj pro online ověření přihlašovacích údajů proti konkrétní službě. Prakticky odpovídá na otázku:

• funguje tahle kombinace uživatelů a hesel proti SSH, LDAP nebo webovému loginu?

To zní jednoduše, ale právě tahle vrstva bývá v řetězcích zásadní. Často už totiž neřešíte exploit, ale hodnotu credential clue:

• heslo z konfigurace,
• seznam uživatelů z adresáře,
• nebo výchozí údaje z administračního rozhraní.

Nejčastější scénáře využití v tomto projektu

Ověření nalezených přihlašovacích údajů proti SSH

Na Admireru už web a interní soubory vydaly kombinace účtů a hesel. V tu chvíli nemá smysl nic hádat naslepo. Je potřeba rychle ověřit, které dvojice jsou skutečně použitelné proti SSH:

hydra -L users.txt -P pass.txt $IP ssh

To je velmi praktický scénář pro Hydru:

• user list vznikl z konkrétního nálezu,
• password list je krátký a odůvodněný,
• a úspěšná kombinace okamžitě otevírá stabilní shell.

Tady je důležité, že Hydra nic “nevymyslela”. Jen velmi levně převedla nalezený credential leak do použitelného přístupu.

Úzká hypotéza proti LDAP nebo jiné autentizační službě

Na Monteverde je použití ještě disciplinovanější. Už existuje seznam validních uživatelů a pracovní hypotéza, že některý servisní účet může používat heslo shodné se jménem účtu.

hydra -L Monteverde-users.txt -P Monteverde-users.txt $IP ldap2 -I

Výsledek:

login: SABatchJobs   password: SABatchJobs

To je dobrý praktický příklad toho, kdy online test dává smysl:

• prostor kandidátů je úzký,
• hypotéza je konkrétní,
• a další krok závisí na tom, jestli účet opravdu funguje.

Přímé míření na autentizační endpoint místo GUI

Na Wallu není hlavní hodnota Hydry v tom, že zkouší hesla proti webu. Důležité je, že míří přímo na Centreon API endpoint:

hydra -v -l admin -P /usr/share/wordlists/metasploit/unix_passwords.txt 10.10.10.157 http-post-form "/centreon/api/index.php?action=authenticate:username=^USER^&password=^PASS^:S=authToken"

Tady Hydra funguje dobře proto, že:

• cíl není “web obecně”,
• ale konkrétní autentizační request,
• s konkrétní známkou úspěchu.

Právě to výrazně snižuje šum a zvyšuje praktičnost výsledku.

Kdy je Hydra nejlepší volba

Největší smysl dává tehdy, když:

• už existuje malý a odůvodněný seznam kandidátů,
• služba má jasný autentizační mechanismus,
• a úspěšný login má okamžitou praktickou hodnotu.

To je zásadní rozdíl proti slepému brute force. V tomto projektu Hydra funguje tam, kde už předchozí enumerace udělala většinu analytické práce.

Co Hydra neumí vyřešit za vás

Hydra:

• sama neobjeví správný user list,
• sama nevytvoří credential clue,
• a neříká nic o tom, zda bude úspěšný účet provozně zajímavý i po loginu.

Na Admireru má úspěch okamžitou hodnotu, protože SSH otevře shell. Na jiném hostu může validní účet vést jen k omezenému přístupu nebo k další enumeraci.

Nejčastější chyby při použití

Příliš široký a neodůvodněný brute force

Praktická hodnota Hydry rychle klesá, když se z ní stane hlučný pokus o prolomení všeho. V místních rozborech funguje právě proto, že scope je úzký:

• konkrétní seznam uživatelů,
• konkrétní seznam hesel,
• nebo konkrétní endpoint.

Záměna validace za exploit

Úspěšný login ještě není konec. Je to potvrzení, že credential clue má reálný dopad. Praktický řetězec pak obvykle pokračuje přes:

• SSH,
• SMB,
• WinRM,
• nebo další interní službu.

Použití proti špatné vrstvě

Na Wallu by slepé zkoušení formuláře bylo méně přesné než cílené míření na autentizační endpoint. Právě proto se vyplatí chápat, proti čemu služba skutečně ověřuje login.

Nejčastější praktické scénáře

Už mám credential leak a potřebuji zjistit, co skutečně funguje

To je Admirer.

Mám úzkou identitní hypotézu typu user = password

To je Monteverde.

Potřebuji mířit na konkrétní webový autentizační request

To je Wall.

Související články v projektu

• Rozbory: Admirer, Monteverde, Wall
• Techniky: Password reuse a rozpad hranic mezi aplikací, SSH, WinRM a admin nástroji, Dokumentová metadata jako vstup do domény

Co si odnést do praxe

• Hydra je nejpraktičtější jako úzký online validátor konkrétní autentizační hypotézy.
• Největší hodnotu má tehdy, když už user list i hesla vycházejí z předchozí enumerace a nejsou náhodné.
• Úspěch v Hydře je nejlepší chápat jako potvrzení dopadu, ne jako náhradu za analytickou práci, která mu předcházela.

Další Související Články V Projektu

HTB Stroje

• Sauna
• Resolute
• Nest

Techniky

• kid/jku a vzdálené načítání klíčů
• OAuth a zneužití autorizačního toku
• NoSQL injection v loginu a extrakce přes `$regex` / `$ne`

Nástroje

• enum4linux
• Impacket pro AD enumeraci a první identity
• BloodHound