Google-Hacking-Datenbank (GHDB): Was sie ist und wie man sie zur Abwehr einsetzt
Inhaltsübersicht
Wenn Sie jemals in einem Write-up über einen Google Dork gestolpert sind und sich gefragt haben, wo der Autor ihn gefunden hat, lautet die Antwort fast immer gleich: die Google Hacking Database.
Die GHDB ist die kanonische, öffentliche Bibliothek von Google-Suchanfragen, die im Internet offengelegte Informationen zutage fördern. Sie läuft seit 2004, beherbergt derzeit Tausende katalogisierter Dorks in 14 Kategorien und bildet die Grundlage für mehr Aufklärungsarbeit – sowohl von Angreifern als auch von Verteidigern – als jede andere einzelne Ressource im Internet.
Dieser Artikel ist für die Frage gedacht, die danach kommt: Was ist die GHDB, wie ist sie aufgebaut und wie sollte Ihr Sicherheitsteam sie tatsächlich nutzen?
Was ist die Google Hacking Database?
Die Google Hacking Database (GHDB) ist ein öffentliches, durchsuchbares Repository von Google Dorks — erweiterte Suchanfragen, die die Operatoren von Google verwenden, um sensible Informationen zu finden, die von der Suchmaschine indexiert wurden.
Jeder Eintrag in der Datenbank enthält die Suchanfrage selbst, die Kategorie der Informationen, die sie zutage fördert (wie etwa Anmeldeportale, offene Datenbanken, sensible Dateien), eine kurze Beschreibung und das Datum, an dem er eingereicht wurde. Zusammen bilden die Einträge eine funktionierende Bibliothek jeder dokumentierten Art und Weise, wie jemals eine Google-Suche genutzt wurde, um etwas zu finden, was sie wahrscheinlich nicht hätte finden sollen.
Die GHDB ist im strengen Sinne kein Hacking-Tool. Sie führt keinen Code aus. Sie nutzt nichts aus. Sie ist ein Katalog – aber ein Katalog menschlicher Fehler im Internet-Maßstab, weshalb sie nach wie vor eine der mächtigsten Ressourcen im OSINT-Toolkit ist.
Wer ist Johnny Long und wie hat die GHDB begonnen?
Die GHDB wurde 2004 von dem Sicherheitsforscher Johnny Long ins Leben gerufen, einer frühen Autorität auf dem Gebiet des von ihm als “Google Hacking” bezeichneten Ansatzes, bei dem Suchmaschinen als Erkundungswerkzeuge statt als Portale zu Webinhalten genutzt werden.
Long popularisierte das Konzept in seinem Buch Google Hacking für Penetrationstester, das zum Grundlagenwerk zu diesem Thema wurde. Neben dem Buch erstellte und pflegte er eine öffentliche Liste eingereichter Dorks, die er danach klassifizierte, was sie offenlegten und wie sie verwendet werden konnten. Die Community steuerte Einträge bei, Long kuratierte sie, und die GHDB wuchs von einem persönlichen Projekt zu einer anerkannten Referenz.
Im Jahr 2010 übergab Long die Wartung der Datenbank an Offensive Security, demselben Team hinter Kali Linux und der OSCP-Zertifizierung. Die GHDB wird seither auf ihrer Exploit Database (Exploit-DB) gehostet, wo sie weiterhin Einreichungen aus der Community annimmt und sie unter der ursprünglichen Kategoriestruktur pflegt.
Die Übergabe ist Teil dessen, was der GHDB ihre Langlebigkeit verleiht. Sie wird seit mehr als zwei Jahrzehnten kontinuierlich gepflegt, professionell moderiert und in gängige Pentesting-Tools integriert.
Wo wird die GHDB heute gehostet?
Derzeit befindet sich die GHDB in exploit-db.com/google-hacking-database, das von Offensive Security betrieben wird. Die Benutzeroberfläche ist unkompliziert: eine filterbare Liste von Einträgen, durchsuchbar nach Stichwort, Kategorie, Autor und Datum.
Die meisten professionellen Aufklärungstools integrieren die GHDB ebenfalls direkt. Das Metasploit-Framework enthält ein Suchmodul, das Abfragen aus der Datenbank abruft. Recon-ng kann GHDB-Einträge über sein Modulsystem abrufen. Auf OSINT ausgerichtete Distributionen wie Kali Linux und BlackArch werden mit vorinstallierten GHDB-fähigen Werkzeugen ausgeliefert.
Sie können die GHDB auch ohne Exploit-DB-Konto durchsuchen, was mit ein Grund dafür ist, warum sie sowohl für Angreifer als auch für Verteidiger eine so barrierefreie Ressource ist. Jeder mit einem Browser kann den vollständigen Katalog in Sekundenschnelle aufrufen.
Die 14 GHDB-Kategorien erklärt
Die GHDB strukturelles Rückgrat ist sein Kategoriesystem. Jeder eingereichte Dork wird in eine von 14 Kategorien einsortiert, von denen jede einer Expositionsklasse entspricht. Das Verständnis der Kategorien ist der schnellste Weg, die Datenbank produktiv zu nutzen: Anstatt durch Tausende von Einträgen zu scrollen, gehen Sie direkt zu der Art von Risiko, die auf Ihre Umgebung zutrifft.
| GHDB-Kategorie | Was es zutage fördert | Verteidigungsimplikation |
|---|---|---|
| Standorte | Erste Einstiegspunkte – freiliegende Shells, Befehlsinjektionspunkte, zugängliche Admin-Skripte. | Überprüfen Sie webbasierte Anwendungen auf vergessene administrative Endpunkte. |
| Dateien mit Benutzernamen | Logdateien, Dumps und Konfigurationsdateien, die gültige Benutzernamen enthalten. | Betrachte Benutzernamen als mittelsensibel – sie treiben Password-Spraying-Angriffe an. |
| Sensible Verzeichnisse | Offene VerzeichnisauflistungenIndex von /) bei der Offenlegung interner Dateistrukturen. | Deaktivieren Sie die Verzeichnisauflistung auf der Ebene des Webservers. Verlassen Sie sich nicht auf Verschleierung. |
| Webserver-Erkennung | Standardseiten und Banner, die Server-Software und -Version preisgeben. | Server-Banner entfernen. Standard-Startseiten ersetzen. |
| Anfällige Dateien | Mit bekannten CVEs verknüpfte Dateien — veraltete CMS-Plugins, angreifbare Skripte. | Patch-Hygiene und Versionsmanagement auf Anwendungsebene. |
| Anfällige Server | Durch Suche auffindbare Schwachstellen auf Serverebene. | Asset-Inventarisierung plus kontinuierliche Schwachstellenanalyse. |
| Fehlermeldungen | Ausführliche Anwendungsfehler, die Stack-Traces, Pfade und Datenbankstrukturen preisgeben. | Produktionsumgebungen sollten niemals Debug-Fehler anzeigen. Abfangen und im Hintergrund protokollieren. |
| Dateien mit saftigen Infos | Alles Sensible, das nirgendwo sonst passt – interne Dokumente, Richtlinienentwürfe, HR-Daten. | Überprüfen Sie, was sich in Ihrem öffentlichen Web-Root befindet. Anwenden noindex Überschriften wo angebracht. |
| Dateien, die Passwörter enthalten | Dateien, die buchstäblich Klartext- oder gehashte Passwörter enthalten. | Geheimhaltungsmanagement, Punkt. Keine Zugangsdaten im Quellcode. |
| Sensible Online-Shopping-Informationen | Kundendaten, Bestelldatensätze, Zahlungsinformationen aus falsch konfigurierten E-Commerce-Systemen. | PCI-Geltungsbereichsüberprüfung. Speichermedien-Segmentierung. |
| Netzwerk- oder Schwachstellendaten | Firewall-Protokolle, IDS-Ausgaben, Netzwerk Konfigurationsdateien. | Interne Überwachungsdaten dürfen niemals in ein öffentlich zugängliches Verzeichnis gelangen. |
| Seiten mit Anmeldeportalen | Admin-Panels, interne Dashboards und VPN-Portale, die dem offenen Web ausgesetzt sind. | MFA auf jeder Anmeldeoberfläche. Administratorenpfade nach IP einschränken. |
| Verschiedene Online-Geräte | Mit dem Internet verbundene IoT-Geräte, Kameras, Drucker und ICS-Schnittstellen. | Netzwerksegmentierung. Geräte sollten standardmäßig nicht öffentlich erreichbar sein. |
| Sicherheitshinweise und Schwachstellen | Dorks, die mit spezifischen veröffentlichten Sicherheitshinweisen verknüpft sind — ein schneller Weg, um ungeqatchte Instanzen zu finden. | Betrachten Sie neue Sicherheitshinweise als unmittelbare Bedrohungsanalysen, nicht als Papierkram. |
Die Kategoriebezeichnungen sind Jahrzehnte alt, aber die Expositionsarten, die sie beschreiben, sind zeitlos. Ein Webserver gibt seinen Banner immer noch genauso preis wie im Jahr 2008. Ein Index von / bringt immer noch dieselben Dateitypen zum Vorschein. Die Technologien ändern sich; die Konfigurationsfehler tun es nicht.
Wie Angreifer die GHDB nutzen
Für Angreifer ist die GHDB ein Ausgangspunkt, kein fertiges Spielbuch. Bed Akteure nutzen sie typischerweise in einem von drei Modi.
Gezielte Aufklärung. Angesichts einer bestimmten Zielorganisation zieht ein Angreifer Dorks aus relevanten Kategorien – Anmeldeportale, exponierte Geräte, anfällige Dateien – und hängt site:targetdomain.com jedem Einzelnen. Ein einziger Nachmittag dieser Arbeit kann ein vollständiges Bild der Fehlkonfigurationen, vergessenen Subdomains und exponierten Verwaltungsschnittstellen einer Organisation liefern.
Opportunistische Razzien. Anstatt eine bestimmte Organisation ins Visier zu nehmen, führen Angreifer breit angelegte GHDB-Abfragen im gesamten offenen Web durch — inurl:phpmyadmin/index.php gibt jede öffentlich zugängliche phpMyAdmin-Instanz im Internet zurück, unabhängig davon, wem sie gehört. Die Ausgabe wird zu einer Zielliste, sortiert danach, welche am einfachsten zu exploitern zu sein scheinen.
Beratungspiraterie. Wenn eine neue CVE veröffentlicht wird, suchen Angreifer sofort nach einem GHDB-Dork, der anfällige Instanzen der betroffenen Software sichtbar macht. Das Rennen findet zwischen Verteidigern, die Patches einspielen, und Angreifern statt, die durch Suche ungestopfte Instanzen finden. Die Suche gewinnt meistens, weil sie schneller skaliert als menschliche Patch-Zeitpläne.
Unsere Aufschlüsselung von Google Dorking bei realen Angriffen führt durch sechs dokumentierte Anwendungsfälle, die genau diesen Mustern folgen — einschließlich eines Ransomware-Vorfalls, der mit einer einzigen Suche im Stil der GHDB begann.
Wie Verteidiger die GHDB nutzen sollten
Die GHDB ist vermutlich genauso nützlich sogar nützlicher, für die Verteidigerseite des Stuhls. Die Asymmetrie, die ihn in den Händen von Angreifern gefährlich macht, wird zu einer Stärke, wenn man ihn nach innen wendet.
Die defensive Nutzung der GHDB lässt sich in drei Bereiche unterteilen:
Kontinuierliche Selbstreisehung. Nimm die Dorks in den Kategorien, die für deine Umgebung am relevantesten sind (Seiten, die Anmeldeportale enthalten, anfällige Dateien, Dateien, die Passwörter enthalten), und hänge site:yourdomain.com für jeden. Führen Sie sie wöchentlich aus. Alles, was Google über Sie indexiert hat, kann ein Angreifer finden – es zuerst zu finden, ist also der einzige Weg zu gewinnen.
Beratende Antwort. Wenn eine CVE für Software veröffentlicht wird, die Ihre Organisation nutzt, prüfen Sie, ob ein entsprechender GHDB-Eintrag existiert oder kürzlich eingereicht wurde. Wenn dies der Fall ist, gehen Sie davon aus, dass bereits opportunistisches Scannen begonnen hat. Patchen Sie nach Angreiferzeit, nicht nach Herstellerzeit.
Red-Team-Unterstützung. Interne Red Teams und autorisierte Penetrationstester können die GHDB nutzen, um realistische Reconnaissance-Übungen abzustecken. Das Ziel ist nicht, etwas Exotisches zu finden, sondern zu verfizieren, dass nichts aus dem bekannten Katalog auf Sie zutrifft.
Für Unternehmen ohne eigene Red Teams bieten Dienste wie die von CybelAngel Angriffsflächenmanagement automatisieren Sie diese Art von kontinuierlicher Selbstanalyse – indem Sie strukturierte Abfragen im offenen Web ausführen und auf Ihre Domain bezogene Schwachstellen aufdecken, bevor Angreifer sie entdecken.
Aufbau eines defensiven GHDB-Workflows
Ein einmaliger GHDB-Suchlauf findet die Exposures von gestern. Die Leaks, die wehtun, sind diejenigen, die indexiert werden. nach Ihre letzte Prüfung. Um die GHDB in eine laufende Kontrolle zu verwandeln:
- Erstellen Sie Ihre engere Auswahl an Kategorien. Von den 14 Kategorien werden drei bis fünf Ihr Risikoprofil dominieren. Für die meisten Organisationen sind dies Seiten mit Anmeldeportalen, Dateien mit Passwörtern, sensible Verzeichnisse, Webserver-Erkennung und verschiedene Online-Geräte. Erstellen Sie Ihre eigene Liste einmal und hinterfragen Sie sie dann nicht mehr.
- Pflegen Sie eine Bibliothek für domain-gebundene Dorks. Nehmen Sie jede relevante GHDB-Abfrage und hardcodieren Sie Ihre Domain darin
site:yourcompany.com), und speichern Sie das Ergebnis als Runbook. Die Bibliothek befindet sich in der Versionskontrolle, wird vierteljährlich überprüft und läuft nach einem Zeitplan. - Automatisieren Sie die Ausführung. Tools wie Recon-ng, theHarvester und die Metasploit-Suchmodule können GHDB-Abfragen programmgesteuert ausführen. Die Ergebnisse fließen in Ihr Ticket- oder SIEM-System und nicht in das Notizbuch eines Forschers.
- Bei Warnhinweisen auslösen. Wenn eine neue CVE für Software veröffentlicht wird, die Sie ausführen, sollte Ihr Workflow innerhalb von Stunden, nicht Wochen, in der GHDB nach einem entsprechenden Eintrag suchen.
- Messen Sie die Behebungszeit. Jeder Befund erhält eine Uhr. Die Verzögerung zwischen Erkennung und Rotation/Patching ist der allerbeste Indikator dafür, wie gut der Workflow tatsächlich funktioniert.
- Entwicklungsteams einbinden. Die meisten GHDB-Ergebnisse deuten auf eine Prozesslücke hin – ein
noindexHeader, der nicht gesetzt wurde, ein.bakeine Datei, die sich nicht im Web-Root befinden sollte, ein Standard-Admin-Pfad, der nie umbenannt wurde. Reparieren Sie den Prozess, nicht nur das Artefakt.
GHDB und ethische Überlegungen
Das Durchsuchen der GHDB ist legal. Das Einreichen von Einträgen ist legal. Das Ausführen von Abfragen daraus gegen die eigene Domain ist legal.
Wenn man sie gegen eine Domain laufen lässt, die einem nicht gehört – und dann aufgrund der Ergebnisse handelt –, ändert sich die Lage. Nach dem Computer Fraud and Abuse Act in den USA, dem Computer Misuse Act in Großbritannien und entsprechender Gesetzgebung in den meisten Ländern ist der Zugriff auf Systeme oder Daten, zu deren Berührung man keine Berechtigung hat, eine Straftat, unabhängig davon, wie einfach sie über Google zu finden waren.
Die ethische Nutzung der GHDB erfordert:
- Berechtigung. Führen Sie Abfragen nur für Ihre eigenen Assets oder für Assets aus, die ausdrücklich in einem Auftragsvertrag oder einem Bug-Bounty-Programm festgelegt sind.
- Zurückhaltung. Das Lesen einer öffentlich indizierten Datei ist im Allgemeinen legal. Sich mit Zugangsdaten anzumelden, die Sie darin gefunden haben, ist es nicht.
- Verantwortungsvolle Offenlegung. Wenn Sie zufällig die Schwachstelle einer anderen Person entdecken, melden Sie diese über deren Security-Disclosure-Kanal. Nutzen Sie sie nicht aus. Teilen Sie sie nicht öffentlich, bevor das Unternehmen Zeit hatte, sie zu beheben.
Die GHDB selbst ist eine defensive Ressource, die zufällig auch offensiv nützlich ist. Wie Sie sie nutzen, bestimmt, auf welcher Seite Sie stehen.
Grenzen der GHDB im Jahr 2026
Die GHDB ist eine ehrwürdige Ressource, aber sie ist nicht vollständig. Einige Einschränkungen sollte man kennen:
Verzögerung bei der Übermittlung. Die Datenbank ist auf Einreichungen aus der Community angewiesen. Neue Expositionssymptome oder -muster tauchen möglicherweise erst Wochen oder Monate nach Beginn ihrer aktiven Ausnutzung in freier Wildbahn auf.
Die Änderungen von Google. Google hat im Laufe der Jahre mehrere Operatoren eingestellt — Zwischenspeicher wurde 2024 aus dem Verkehr gezogen, Link: ist seit 2017 unzuverlässig, und + erzwingt keine exakten Übereinstimmungen mehr. Ältere GHDB-Einträge, die auf veralteten Operatoren basieren, funktionieren in ihrer bisherigen Form nicht mehr. Vor dem Verlassen darauf immer testen.
Deckungslücken. Die GHDB konzentriert sich auf Google. Sie deckt weder Bing, DuckDuckGo, Yandex noch Spezialsuchmaschinen wie Shodan und Censys ab – die allesamt unterschiedliche Expositionsklassen aufdecken. Ein Verteidiger, der sich ausschließlich auf die GHDB verlässt, hat Einblick in nur einen Suchindex.
Signal-Rausch-Verhältnis der Lautstärke. Einige Kategorien enthalten Tausende von Einträgen. Ohne Filterung nach Relevanz für Ihre Umgebung können Sie mehr Zeit mit der Sichtung der Datenbank verbringen als mit der Sichtung Ihrer tatsächlichen Bedrohungen.
Aus diesem Grund behandeln die meisten ausgereiften Sicherheitsprogramme die GHDB als einen Baustein einer umfassenderen Expositionsüberwachungsstrategie – und nicht als die Strategie selbst.
Einpacken
Jede Abfrage in der GHDB ist eine Suche, die ein Angreifer sofort gegen Ihre Domain ausführen kann. CybelAngel überwacht kontinuierlich Ihre externe Angriffsfläche auf die von der GHDB gefundenen Schwachstellen und alarmiert Ihr Sicherheitsteam, bevor ein Angreifer sie ausnutzt..
FAQs
\
Über den Autor
