Google Dork çoğu zaman yanlış anlaşılan bir kavramdır. Genellikle bir "hacking aracı" ya da saldırı tekniği gibi düşünülür. Oysa Google Dork, saldırıdan çok farkındalıkla ilgilidir.Bu yazı, neden bazı sistemlerin Google'da görünmemesi gerektiğini anlatırGoogle Dork'u teoride bırakmadan, örnekler ve gerçek senaryolar üzerinden ele alacağım. "Google Dork nedir?" sorusuna geçmeden önce, daha önemli bir noktayı netleştirmek gerekiyor: Google Dork ne değildir?

Google Dork bir hacking aracı ya da wordlist değildir. Yetkisiz erişim sağlamaz, sistemlere sızmaz. Aksine, Google tarafından zaten indekslenmiş, zaten açıkta olan ve genellikle yanlış yapılandırılmış sistemleri fark etmeye yarayan gelişmiş arama tekniklerini ifade eder. Kısacası Google Dork, gizli olanı ortaya çıkarmaktan değil; zaten görünür olanı doğru şekilde görmeyi öğrenmekten ibarettir.

Google Dork'u Kimler Öğrenmeli?

Google Dork'un bir hacking aracı olmadığı artık yanlış bilenlerin de öğrendiği bir gerçek. Açık kaynaklı bir yöntem olması nedeniyle teorik olarak herkes tarafından öğrenilebilir ve kullanılabilir. Ancak bu, herkes için gerekli veya anlamlı olduğu anlamına gelmez. Google Dork'u özellikle öğrenmesi gereken belirli bir kesim vardır:

• Siber güvenlik öğrencileri
• Blue Team / SOC / Incident Response ekipleri
• Web ve backend geliştiriciler (özellikle DevOps süreçlerine dokunanlar)
• OSINT ile ilgilenen araştırmacılar

Bu gruplar için Google Dork, bir saldırı aracı değil; yanlış yapılandırmaları fark etmeyi, açık yüzeyleri görmeyi ve riskleri erken aşamada tespit etmeyi sağlayan bir farkındalık aracıdır.

Kimler Öğrenmekle Vakit Kaybetmemeli? Öte yandan Google Dork, herkes için doğru bir öğrenme alanı değildir. Özellikle şu gruplar için zaman kaybına dönüşür:

• Sadece "pentest videoları izleyip havalı hissetmek" isteyenler
• Script kiddie mantığıyla ezber sorguların peşinde koşanlar
• Güvenliği anlamaktan çok "bir şeyler ele geçirme" motivasyonuyla hareket edenler.

Google Dork + OSINT

Google Dork anlatırken OSINT'e değinmem gerekir. Çünkü Google Dork daha geniş bir yaklaşımın ilk adımıdır. OSINT, yetkisiz erişim olmadan, tamamen açık kaynaklardan elde edilen verilerle yapılan analiz ve keşif sürecini ifade eder. Bu yaklaşımda amaç sisteme girmek değil; zaten dışarıdan görülebilen yüzeyi doğru okumaktır. Google Dork tam olarak bu noktada devreye girer.

Google Dork, OSINT dünyasına açılan en temel ve erişilebilir giriş kapısıdır. Bir sistemin, bir uygulamanın ya da bir servisin Google tarafından nasıl göründüğünü anlamayı öğretir. Yanlış yapılandırılmış dizinler, herkese açık dosyalar, test ortamları ya da unutulmuş paneller çoğu zaman bu aşamada fark edilir.Bu sebepten Google Dork OSINT'e başlayanlar için ilk adımdır.

Ancak OSINT yalnızca web sayfalarıyla sınırlı değildir. Google'ın indeksleyebildiği içerikler, keşif sürecinin yalnızca bir bölümünü oluşturur. İnternete açık sistemlerin portları, servisleri ve banner bilgileri gibi daha altyapı odaklı detaylar için farklı araçlara ihtiyaç duyulur. Bu noktada Shodan gibi platformlar devreye girer.

Shodan, Google'dan farklı olarak web sayfalarını değil; internete açık servisleri tarar. Yani bir sistemi "içeriğiyle" değil, çalıştırdığı servislerle görünür kılar. Bu yönüyle Google Dork ve Shodan rakip değil, birbirini tamamlayan araçlardır. Google Dork, bir sistemin varlığını ve yüzeydeki izlerini gösterirken; Shodan bu sistemin teknik olarak nasıl konumlandığını anlamaya yardımcı olur.

Bu iki yaklaşımı birleştiren ortak nokta ise pasif keşif mantığıdır. Ne Google Dork ne de Shodan, sisteme aktif bir saldırı gerçekleştirir. Paket göndermez, exploit denemez, kimlik doğrulama aşamalarını zorlamaz. Sadece zaten açık olan bilgiyi toplar ve anlamlandırır. Bu da onları özellikle Blue Team, SOC ve Incident Response ekipleri için değerli kılar.

Sonuç olarak Google Dork, OSINT zincirinin başlangıç noktasıdır. Tek başına yeterli değildir; ancak doğru bağlamda kullanıldığında, daha derin analizlere giden yolu açar. Önemli olan kullanılan araçlar değil, bu araçlarla kazanılan bakış açısıdır.

En Çok Kullanılan Google Dork'lar ve Uygun Senaryolar

Aşağıda, Google dork'ların ne işe yaradığını ve nasıl kullanıldığını gösteren örnekler bulunmaktadır:

site:

Kullanım örneği: site:example.com Bir araştırmacı, belirli bir kurumun internetteki görünürlüğünü anlamak ister. Arama sonuçlarını yalnızca tek bir alan adıyla sınırlandırarak, o siteye ait hangi sayfaların Google tarafından indekslendiğini genel hatlarıyla gözlemler. Bu yaklaşım, bir web sitesinin dış dünyaya hangi içeriklerle açıldığını anlamak için kullanılır.

filetype:

Kullanım örneği: filetype:pdf

Bir web sitesinde yayımlanan doküman türleri incelenir. Raporlar, sunumlar veya kılavuzlar gibi dosyalar üzerinden, sitenin hangi içerikleri belge formatında paylaştığı fark edilir. Bu yöntem, kurumsal içerik üretim alışkanlıklarını gözlemlemek için kullanılır.

intitle:

Kullanım örneği: intitle:"login"

Sayfa başlıkları çoğu zaman içeriğin amacını doğrudan yansıtır. Başlık üzerinden yapılan aramalar, giriş ekranları veya özel amaçlı sayfaların nasıl adlandırıldığını anlamaya yardımcı olur.

inurl:

Kullanım örneği: inurl:admin

Bazı sayfalar URL yapılarıyla kendilerini ele verir. URL içinde geçen kelimeler üzerinden yapılan aramalar, sitelerin içerik organizasyonu ve sayfa isimlendirme alışkanlıkları hakkında fikir verir.

cache:

Kullanım örneği: cache:example.com

Bir sayfanın güncel sürümüne erişilemese bile, arama motorunun daha önce sakladığı kopyası incelenebilir. Bu, bir içeriğin geçmişte nasıl göründüğünü anlamak açısından öğreticidir.

link:

Kullanım örneği: link:example.com

Bir web sayfasına hangi sitelerin bağlantı verdiği incelenir. Bu yaklaşım, bir sitenin internet üzerindeki bağlantı ilişkilerini genel hatlarıyla görmeyi sağlar.

related:

Kullanım örneği: related:example.com

Benzer içerik yapısına veya sektöre sahip siteler araştırılır. Bu, dijital ekosistemleri ve benzer platformları tanımak için kullanılır.

intext:

Kullanım örneği: intext:"password"

Sayfa içeriğinde geçen belirli kelimeler üzerinden yapılan aramalar, metinlerin hangi bağlamlarda kullanıldığını anlamaya yardımcı olur.

allintitle:

Kullanım örneği: allintitle:login admin

Başlığında birden fazla anahtar kelime geçen sayfalar incelenir. Bu yöntem, daha dar ve spesifik başlık yapılarını gözlemlemek için kullanılır.

allinurl:

Kullanım örneği: allinurl:admin login

URL yapısında birden fazla kelimenin birlikte geçtiği sayfalar araştırılır. Bu, site mimarisinin nasıl kurgulandığını anlamaya yardımcı olur.

allintext:

Kullanım örneği: allintext:username password

Birden fazla kelimenin aynı anda geçtiği içerikler incelenir. Bu, metinlerin detay seviyesi hakkında fikir verir.

define:

Kullanım örneği: define:OSINT

Belirli bir terimin arama motoru tarafından nasıl tanımlandığı incelenir. Teknik kavramların genel kabul görmüş anlamlarını görmek için kullanılır.

"keyword"

Kullanım örneği: "admin login"

Bir kelime öbeği tırnak içinde arandığında, yalnızca birebir geçen ifadeler görüntülenir. Bu, kesin ifadelerin nerelerde kullanıldığını anlamaya yardımcı olur.

-keyword

Kullanım örneği: password -example

Bazı kelimeler hariç tutularak daha temiz ve hedefli arama sonuçları elde edilir.

OR

Kullanım örneği: login OR signup

Birden fazla ihtimal aynı anda değerlendirilmek istendiğinde kullanılır. Bu, farklı ama ilişkili kavramların birlikte ele alındığı içerikleri görmek için tercih edilir.

*

Kullanım örneği: intitle:"admin *"

Belirli bir kelimenin yerine farklı ifadelerin gelebileceği durumları gözlemlemek için kullanılır.

..

Kullanım örneği: filetype:pdf 2020..2022

Belirli bir tarih veya sayı aralığında yayımlanmış içerikler incelenir.

info:

Kullanım örneği: info:example.com

Bir site hakkında arama motorunun tuttuğu temel bilgiler görüntülenir.

maps:

Kullanım örneği: maps:New York

Belirli bir konuma ait harita tabanlı sonuçlar incelenir.

stocks:

Kullanım örneği: stocks:GOOG

Bir şirketin borsa ile ilgili temel bilgileri görüntülenir.

Google Dork ve benzeri OSINT teknikleri, doğru bağlamda kullanıldığında güvenlik açısından son derece değerlidir. Ancak bu tür yöntemlerin hangi koşullarda ve hangi amaçlarla kullanıldığı, en az teknik detaylar kadar önemlidir.

Gerçek hayatta bu tür keşif çalışmaları; bug bounty programları, yetkili sızma testleri veya kurum içi güvenlik denetimleri kapsamında gerçekleştirilir. Ortak nokta şudur: İnceleme yapılan sistem için açık ve yazılı bir yetkilendirme bulunur.

Bu bölümde yer alan örnekler, herhangi bir sistemi hedef almayı amaçlamaz. Amaç; güvenlik çalışmalarında sık karşılaşılan ihmal türlerini ve bu ihmallerin arama motorları üzerinden nasıl görünür hale gelebildiğini kavramsal olarak anlatmaktır.

Açık Web Kamera ve IoT Arayüzleri

Örnek kullanım: intitle:"IP Camera" site:example.com

Senaryo: Bir işletme, IP tabanlı bir kamera veya IoT cihazı kurar. Kurulumdan sonra varsayılan ayarlar değiştirilmez ve cihaz internete açık şekilde bırakılır. Web tabanlı arayüze sahip olduğu için bu cihaz zamanla arama motorları tarafından indekslenebilir.

Bu tür durumlar genellikle kötü niyetten değil, cihazların da birer web servisi olduğu gerçeğinin göz ardı edilmesinden kaynaklanır.

Açık FTP ve Dosya Paylaşım Servisleri

Örnek kullanım: intitle:"index of" inurl:ftp site:example.com

Senaryo: Bir ekip, dosya paylaşımı amacıyla geçici bir FTP servisi açar. Proje tamamlandıktan sonra bu servis kapatılmaz. Başlangıçta önemsiz görünen bu durum, zamanla farklı dosyaların aynı alana eklenmesiyle görünür hale gelir.

Açık Yapılandırma Dosyaları

Örnek kullanım: filetype:yml site:example.com

Senaryo: Geliştirme sürecinde kullanılan yapılandırma dosyaları, test ortamından production'a geçerken temizlenmez. Dosyalar doğrudan erişilebilir bir dizinde kalır ve arama motorları tarafından indekslenebilir.

Bu senaryoda sorun dosyanın varlığı değil, erişim sınırlarının yanlış yerde kurulmuş olmasıdır.

Açık Git Depoları ve Geliştirme Artıkları

Örnek kullanım: intitle:"index of" ".git" site:example.com

Senaryo: Bir web uygulaması geliştirilirken kullanılan sürüm kontrol dizinleri, canlı ortama taşınırken silinmez. Uygulama çalıştığı için bu dizinler uzun süre fark edilmeden kalabilir.

Varsayılan Servis Sayfaları ve Eski Arayüzler

Örnek kullanım: intitle:"Apache Tomcat" site:example.com

Senaryo: Bir sunucu kurulduktan sonra varsayılan servis sayfaları değiştirilmez. Sistem çalıştığı için bu sayfalar sorun olarak görülmez, ancak bu durum kullanılan altyapı hakkında gereğinden fazla ipucu verir.

Metin Dosyaları ve Liste Halindeki Bilgiler

Örnek kullanım: filetype:txt site:example.com

Senaryo: Bir ekip, test sırasında bazı bilgileri düz metin dosyalarında tutar. Geçici olduğu düşünülen bu dosyalar temizlenmez ve herkese açık bir dizinde kalır.

Buradaki problem içerikten çok, dosyanın bulunduğu konumdur.

UYARI:

Bu örneklerin hiçbiri bir saldırı hikâyesi değildir. Hiçbirinde karmaşık teknikler veya yetkisiz erişim yoktur.Ortak nokta şudur: Basit yapılandırma hataları, zamanla görünür hale gelir.Google Dork bu noktada bir araç değil, bir ayna görevi görür.

Kapanış : Google Dork, çoğu zaman yanlış anlaşıldığı gibi bir "hacking tekniği" değildir. Bu yazıda ele alınan örnekler de gösteriyor ki, Google Dork'un ortaya çıkardığı şeyler genellikle karmaşık saldırıların sonucu değil; basit yapılandırma hatalarının doğal yansımalarıdır.

Asıl mesele, bir sisteme ne yapılabildiği değil; neden yapılabilir hale geldiğidir. İnternete açılan her servis, her dosya ve her arayüz, doğru şekilde sınırlandırılmadığında arama motorları tarafından görünür olabilir. Google Dork bu noktada bir saldırı aracı değil, sistemlerin dış dünyaya nasıl göründüğünü gösteren bir ayna görevi görür.

Bu nedenle Google Dork'u değerli kılan şey, yazılan sorgular değil; kazandırdığı bakış açısıdır. Güvenliğin yalnızca koddan ibaret olmadığını, konfigürasyonun ve operasyonel disiplinin en az teknik yetkinlik kadar önemli olduğunu hatırlatır.

Gerçek dünyada bu tür keşif çalışmaları, yalnızca etik ve hukuki çerçevede, yetkilendirilmiş ortamlarda anlamlıdır. Bug bounty programları, sızma testleri ve kurum içi denetimler bu bilginin doğru kullanıldığı alanlardır. Yetki olmadan yapılan her deneme, teknik olarak mümkün olsa bile profesyonel değildir.

Sonuç olarak Google Dork, bir şeylere ulaşmayı öğretmez; neyin neden görünür olduğunu anlamayı öğretir. Güvenlik bakış açısı da tam olarak burada başlar.

İletişim Adresleri :

linkedln : https://www.linkedin.com/in/isa-ergi%C5%9Fi-830a4a32b/ github : github.com/isaergisi e-posta : iergisi23@posta.pau.edu.tr

ENG

Google Dork is a concept that is often misunderstood. It is usually perceived as a "hacking tool" or an attack technique. However, Google Dork is more about awareness than about attacks. This article explains why certain systems should not be visible on Google. I will address Google Dork not only in theory, but through examples and real scenarios. Before moving on to the question "What is Google Dork?", it is necessary to clarify a more important point: What is Google Dork not?

Google Dork is not a hacking tool or a wordlist. It does not provide unauthorized access and does not infiltrate systems. On the contrary, it refers to advanced search techniques that help notice systems that are already indexed by Google, already exposed, and generally misconfigured.

In short, Google Dork is not about revealing what is hidden; it is about learning to correctly see what is already visible.

Who Should Learn Google Dork? The fact that Google Dork is not a hacking tool is now something even those who were mistaken have learned. Since it is an open-source method, it can theoretically be learned and used by anyone. However, this does not mean that it is necessary or meaningful for everyone.

There is a specific group that should especially learn Google Dork:

• Cybersecurity students
• Blue Team / SOC / Incident Response teams
• Web and backend developers (especially those touching DevOps processes)
• Researchers interested in OSINT

For these groups, Google Dork is not an attack tool; it is an awareness tool that enables noticing misconfigurations, seeing exposed surfaces, and detecting risks at an early stage.

Who Should Not Waste Time Learning It? On the other hand, Google Dork is not the right learning area for everyone. Especially for the following groups, it turns into a waste of time:

• Those who only want to "watch pentest videos and feel cool"
• Those who chase memorized queries with a script kiddie mindset
• Those who act with the motivation of "getting hold of something" rather than understanding security

Google Dork + OSINT When explaining Google Dork, I need to touch on OSINT, because Google Dork is the first step of a broader approach. OSINT refers to the analysis and reconnaissance process conducted entirely through open sources, without unauthorized access. In this approach, the goal is not to break into the system, but to correctly read the surface that is already visible from the outside. This is exactly where Google Dork comes into play.

Google Dork is the most fundamental and accessible gateway to the world of OSINT. It teaches how a system, an application, or a service appears through Google. Misconfigured directories, publicly accessible files, test environments, or forgotten panels are often noticed at this stage. For this reason, Google Dork is the first step for those starting OSINT.

However, OSINT is not limited to web pages. The content that Google can index constitutes only a part of the reconnaissance process. For more infrastructure-oriented details such as ports, services, and banner information of internet-facing systems, different tools are needed. At this point, platforms like Shodan come into play.

Unlike Google, Shodan does not scan web pages; it scans internet-facing services. In other words, it makes a system visible not by its "content," but by the services it runs. In this respect, Google Dork and Shodan are not competitors, but complementary tools. While Google Dork shows the existence of a system and its surface traces, Shodan helps to understand how this system is positioned technically.

The common point that unites these two approaches is the concept of passive reconnaissance. Neither Google Dork nor Shodan performs an active attack on the system. They do not send packets, attempt exploits, or force authentication stages. They only collect and interpret information that is already exposed. This makes them particularly valuable for Blue Team, SOC, and Incident Response teams.

As a result, Google Dork is the starting point of the OSINT chain. It is not sufficient on its own; but when used in the right context, it opens the path to deeper analyses. What matters is not the tools used, but the perspective gained through these tools.

Most Commonly Used Google Dorks and Appropriate Scenarios Below are examples showing what Google dorks do and how they are used:

site: Usage example: site:example.com A researcher wants to understand the online visibility of a specific organization. By limiting search results to a single domain name, they observe in general terms which pages belonging to that site are indexed by Google. This approach is used to understand which content a website exposes to the outside world.

filetype: Usage example: filetype:pdf The types of documents published on a website are examined. Through files such as reports, presentations, or guides, it becomes apparent which content the site shares in document format. This method is used to observe corporate content production habits.

intitle: Usage example: intitle:"login" Page titles often directly reflect the purpose of the content. Searches performed through titles help understand how login screens or special-purpose pages are named.

inurl: Usage example: inurl:admin Some pages reveal themselves through their URL structures. Searches based on words appearing in URLs provide insight into content organization and page naming habits of sites.

cache: Usage example: cache:example.com Even if the current version of a page is not accessible, the copy previously stored by the search engine can be examined. This is instructive for understanding how content appeared in the past.

link: Usage example: link:example.com The sites that link to a web page are examined. This approach makes it possible to broadly see a site's linking relationships on the internet.

related: Usage example: related:example.com Sites with similar content structures or operating in the same sector are researched. This is used to recognize digital ecosystems and similar platforms.

intext: Usage example: intext:"password" Searches performed through specific words appearing in page content help understand in which contexts texts are used.

allintitle: Usage example: allintitle:login admin Pages whose titles contain multiple keywords are examined. This method is used to observe narrower and more specific title structures.

allinurl: Usage example: allinurl:admin login Pages where multiple words appear together in the URL structure are researched. This helps understand how site architecture is designed.

allintext: Usage example: allintext:username password Content where multiple words appear simultaneously is examined. This provides insight into the level of detail in texts.

define: Usage example: define:OSINT How a specific term is defined by the search engine is examined. It is used to see generally accepted meanings of technical concepts.

"keyword" Usage example: "admin login" When a phrase is searched within quotation marks, only exact matches are displayed. This helps understand where precise expressions are used.

-keyword Usage example: password -example Cleaner and more targeted search results are obtained by excluding certain words.

OR Usage example: login OR signup Used when multiple possibilities are to be evaluated at the same time. This is preferred to see content where different but related concepts are addressed together.

* Usage example: intitle:"admin *" Used to observe cases where different expressions may replace a specific word.

.. Usage example: filetype:pdf 2020..2022 Content published within a specific date or number range is examined.

info: Usage example: info:example.com Basic information stored by the search engine about a site is displayed.

maps: Usage example: maps:New York Map-based results related to a specific location are examined.

stocks: Usage example: stocks:GOOG Basic stock-related information about a company is displayed.

Google Dork and similar OSINT techniques are extremely valuable from a security perspective when used in the right context. However, under which conditions and for what purposes these methods are used is at least as important as the technical details.

In real life, such reconnaissance activities are carried out within the scope of bug bounty programs, authorized penetration tests, or internal security audits. The common point is this: there is explicit and written authorization for the system being examined.

The examples in this section do not aim to target any system. The purpose is to conceptually explain the types of negligence frequently encountered in security work and how these negligences can become visible through search engines.

Open Web Cameras and IoT Interfaces Example usage: intitle:"IP Camera" site:example.com Scenario: A business installs an IP-based camera or IoT device. After installation, default settings are not changed and the device is left exposed to the internet. Since it has a web-based interface, this device may eventually be indexed by search engines. Such situations usually stem not from malicious intent, but from overlooking the fact that devices are also web services.

Open FTP and File Sharing Services Example usage: intitle:"index of" inurl:ftp site:example.com Scenario: A team opens a temporary FTP service for file sharing purposes. After the project is completed, this service is not shut down. This situation, initially seen as insignificant, becomes visible over time as different files are added to the same area.

Exposed Configuration Files Example usage: filetype:yml site:example.com Scenario: Configuration files used during the development process are not cleaned when moving from the test environment to production. The files remain in a directly accessible directory and can be indexed by search engines. In this scenario, the problem is not the existence of the file, but the incorrect placement of access boundaries.

Open Git Repositories and Development Artifacts Example usage: intitle:"index of" ".git" site:example.com Scenario: Version control directories used during the development of a web application are not deleted when moved to the live environment. Since the application works, these directories may remain unnoticed for a long time.

Default Service Pages and Legacy Interfaces Example usage: intitle:"Apache Tomcat" site:example.com Scenario: After a server is set up, default service pages are not changed. Since the system is operational, these pages are not seen as a problem, but this situation provides more clues than necessary about the underlying infrastructure.

Text Files and List-Based Information Example usage: filetype:txt site:example.com Scenario: A team stores some information in plain text files during testing. These files, thought to be temporary, are not cleaned up and remain in a publicly accessible directory. The problem here is not the content, but the location of the file.

WARNING: None of these examples are attack stories. None involve complex techniques or unauthorized access. The common point is this: Simple configuration errors become visible over time. At this point, Google Dork functions not as a tool, but as a mirror.

Closing: Google Dork is not a "hacking technique," as it is often misunderstood. The examples discussed in this article also show that what Google Dork reveals is usually not the result of complex attacks, but the natural reflections of simple configuration errors. The real issue is not what can be done to a system, but why it has become possible. Every service, file, and interface exposed to the internet can become visible to search engines if not properly restricted. At this point, Google Dork serves not as an attack tool, but as a mirror that shows how systems appear to the outside world.

Therefore, what makes Google Dork valuable is not the queries written, but the perspective it provides. It reminds us that security is not only about code, and that configuration and operational discipline are at least as important as technical competence.

In the real world, such reconnaissance activities are meaningful only within ethical and legal frameworks, in authorized environments. Bug bounty programs, penetration tests, and internal audits are the areas where this knowledge is used correctly. Any attempt made without authorization, even if technically possible, is not professional.

As a result, Google Dork does not teach how to reach things; it teaches how to understand what is visible and why. This is exactly where the security perspective begins.

Contact Information: LinkedIn: https://www.linkedin.com/in/isa-ergi%C5%9Fi-830a4a32b/ GitHub: github.com/isaergisi Email: iergisi23@posta.pau.edu.tr