Skip to main content

OSINT — Καθοδηγούμενη επίδειξη

Ένας στόχος. Πραγματικός. Δεν πρόκειται να του στείλουμε τίποτα. Και στο τέλος, θα ξέρουμε: τους υποτομείς του, τις τεχνολογίες του, τους βασικούς υπαλλήλους του, τις διαρροές του, και τα πέντε πιθανά αδύναμα σημεία του.

Η επιλογή του στόχου για αυτή τη demo

Χρησιμοποιούμε ένα πρόγραμμα δημόσιου bug bounty, όπου η εταιρεία εξουσιοδοτεί ρητά τις δοκιμές μέσα σε ένα καθορισμένο πλαίσιο. Μπορείτε να κάνετε το ίδιο στο σπίτι σας επιλέγοντας ένα πρόγραμμα στο HackerOne ή στο Bugcrowd. Στην επίδειξη που ακολουθεί, χρησιμοποιούμε ένα πλασματικό όνομα demo-corp.com για επίδειξη — αλλά όλα όσα βλέπετε είναι αναπαραγώγιμα σε πραγματικό, εξουσιοδοτημένο στόχο.

Τι θα ξέρετε να κάνετε μετά από αυτό το μάθημα​

  • Να περάσετε από ένα απλό όνομα τομέα σε έναν χάρτη υποδομής σε 90 λεπτά.
  • Να χρησιμοποιήσετε το crt.sh, subfinder, amass -passive, dnsx (παθητική λειτουργία), theHarvester, whatweb.
  • Να διακρίνετε τους ζωντανούς υποτομείς από τους νεκρούς χωρίς να τους αγγίξετε.
  • Να διασταυρώσετε τρεις ανεξάρτητες πηγές πριν βγάλετε συμπέρασμα.
  • Να παράξετε ένα φύλλο στόχου 2 σελίδων, αξιοποιήσιμο ήδη από την ενότητα 4.

Βήμα 0 — Το σημείο εκκίνησης​

Μια απλή γραμμή:

Στόχος: demo-corp.com
Πρόγραμμα: δημόσιο bug bounty, scope in-scope = *.demo-corp.com

Αυτό είναι όλο. Ξεκινάμε από εκεί.

Δημιουργήστε τον φάκελο εργασίας:

mkdir -p ~/osint/demo-corp/{dns,subs,tech,people,leaks,archive}
cd ~/osint/demo-corp

Κάθε οικογένεια πηγών θα έχει τον υποφάκελό της. Πειθαρχία από την αρχή.

Βήμα 1 — Βασικό DNS (2 λεπτά)​

Οι βασικές εγγραφές, μία προς μία:

for t in A AAAA MX NS TXT SOA CAA; do
  echo "=== $t ==="
  dig +short demo-corp.com $t
done | tee dns/racine.txt

Τυπική έξοδος:

=== A ===
104.21.44.15
172.67.187.219
=== AAAA ===
=== MX ===
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
=== NS ===
ada.ns.cloudflare.com.
kirk.ns.cloudflare.com.
=== TXT ===
"v=spf1 include:_spf.google.com include:mailgun.org -all"
"google-site-verification=abc123def456..."
"MS=ms84726311"
"stripe-verification=xyz789..."
=== SOA ===
ada.ns.cloudflare.com. dns.cloudflare.com. 2354...
=== CAA ===
0 issue "letsencrypt.org"
0 issue "digicert.com"

Ανάγνωση:

  • A: δύο IP στη δεξαμενή Cloudflare (104.21.x και 172.67.x). Ο ιστότοπος είναι πίσω από το Cloudflare — δεν θα δούμε την πραγματική IP χωρίς προσπάθεια.
  • MX: Google Workspace. Κανένας δικός τους διακομιστής email απευθείας.
  • NS: ada.ns.cloudflare.com — το Cloudflare διαχειρίζεται και το DNS. Συνεπές.
  • TXT:
    • Το SPF εξουσιοδοτεί Google και Mailgun. Δύο υπηρεσίες SaaS εντοπίστηκαν.
    • google-site-verification: χρησιμοποιούν Google Search Console.
    • MS=: χρησιμοποιούν Microsoft (Bing Webmaster, συνήθως).
    • stripe-verification: επεξεργάζονται πληρωμές Stripe. Αυτό σημαίνει PCI-DSS κάπου.
  • CAA: μόνο το Let's Encrypt και το DigiCert μπορούν να εκδώσουν. Καλό σημάδι από την πλευρά της υγιεινής.

Σε 2 λεπτά, ήδη ξέρουμε: Cloudflare, Google Workspace, Mailgun, Stripe. Δεν στείλαμε κανένα πακέτο στο demo-corp.com.

Βήμα 2 — DMARC και στάση email (1 λεπτό)​

dig +short _dmarc.demo-corp.com TXT

Έξοδος:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@demo-corp.com"

Ανάγνωση: p=none. Η πολιτική DMARC υπάρχει αλλά δεν κάνει τίποτα. Συγκεκριμένο αποτέλεσμα: ένας επιτιθέμενος μπορεί να κάνει spoof emails που υποτίθεται στάλθηκαν από το demo-corp.com, αυτά τα emails θα περάσουν στον παραλήπτη ακόμη κι αν αποτύχουν στο DMARC. Είναι φορέας phishing που πρέπει να σημειωθεί για την ενότητα 6.

Καταγράψτε το στο dns/dmarc.txt.

Βήμα 3 — Υποτομείς μέσω crt.sh (3 λεπτά)​

Certificate Transparency, η καλύτερη πηγή για την πρώτη παρτίδα υποτομέων. Ερωτούμε σε JSON, καθαρίζουμε με jq:

curl -s 'https://crt.sh/?q=%25.demo-corp.com&output=json' \
  | jq -r '.[].name_value' \
  | tr '[:upper:]' '[:lower:]' \
  | sed 's/^\*\.//' \
  | sort -u \
  > subs/from-crt.txt

wc -l subs/from-crt.txt

Τυπική έξοδος:

127 subs/from-crt.txt

Ένα απόσπασμα:

admin.demo-corp.com
api.demo-corp.com
api-dev.demo-corp.com
api-staging.demo-corp.com
beta.demo-corp.com
blog.demo-corp.com
cdn.demo-corp.com
customer.demo-corp.com
demo-corp.com
dev.demo-corp.com
docs.demo-corp.com
help.demo-corp.com
internal.demo-corp.com
jenkins.demo-corp.com
jira.demo-corp.com
mail.demo-corp.com
monitoring.demo-corp.com
old-admin.demo-corp.com
partners.demo-corp.com
prod.demo-corp.com
sso.demo-corp.com
staging.demo-corp.com
status.demo-corp.com
support.demo-corp.com
vpn.demo-corp.com
web.demo-corp.com
www.demo-corp.com

Τρεις γραμμές που κάνουν έναν επιτιθέμενο να χαμογελά:

  1. internal.demo-corp.com — ένας υποτομέας που δεν έπρεπε να είχε βγει προς τα έξω.
  2. jenkins.demo-corp.com — ένας διακομιστής CI/CD, ιστορικά ορυχείο ευπαθειών.
  3. old-admin.demo-corp.com — ο παλιός πίνακας διαχείρισης. Αυτό μυρίζει ξέχασμα.

Σε 3 λεπτά, περάσαμε από 1 όνομα σε 127.

Βήμα 4 — Διασταύρωση με subfinder και amass -passive​

Το subfinder ερωτά περίπου είκοσι τρίτες API (Shodan, VirusTotal, SecurityTrails, DNSDumpster…) και επιστρέφει μια λίστα. 100% παθητικό.

subfinder -d demo-corp.com -silent -all -o subs/from-subfinder.txt
wc -l subs/from-subfinder.txt
143 subs/from-subfinder.txt

Ομοίως, το amass σε παθητική λειτουργία:

amass enum -passive -d demo-corp.com -o subs/from-amass.txt

Στη συνέχεια συγχωνεύουμε:

cat subs/from-*.txt | sort -u > subs/all-passive.txt
wc -l subs/all-passive.txt
178 subs/all-passive.txt

Από 127 σε 178. Κάθε πηγή έφερε κάποιες ανακαλύψεις. Γι' αυτό διασταυρώνουμε.

Βήμα 5 — Παθητική ανάλυση με dnsx​

Προσοχή: το dnsx αναλύει τα ονόματα. Κάθε ανάλυση περνά από δημόσιο resolver DNS (Google 8.8.8.8 εξ ορισμού). Παραμένει παθητικό για τον στόχο αν χρησιμοποιείτε resolver που δεν ανήκει στον στόχο. Επαληθεύστε ότι οι NS του demo-corp.com δεν είναι οι resolvers σας (αυτή είναι η περίπτωση εδώ: το Cloudflare διαχειρίζεται το DNS τους, αλλά το δικό σας dnsx θα ερωτήσει το 1.1.1.1 του Cloudflare Public — είναι διαφορετική υπηρεσία).

dnsx -l subs/all-passive.txt -a -resp -silent -r 1.1.1.1,8.8.8.8 \
  -o subs/all-resolved.txt
head subs/all-resolved.txt

Έξοδος:

admin.demo-corp.com [104.21.44.15]
api.demo-corp.com [104.21.44.15]
api-dev.demo-corp.com [3.98.14.202]
api-staging.demo-corp.com [104.21.44.15]
internal.demo-corp.com [192.168.10.5]
jenkins.demo-corp.com [3.98.14.209]
old-admin.demo-corp.com [66.42.11.198]

Τρεις γραμμές που μιλούν:

  • Το internal.demo-corp.com αναλύεται σε 192.168.10.5 — μια ιδιωτική IP δημοσιευμένη στο δημόσιο DNS. Ο υποτομέας προορίζεται για πρόσβαση μέσω VPN, αλλά η παρουσία του στο DNS επιβεβαιώνει ότι αυτή η υπηρεσία υπάρχει. Προς σημείωση.
  • Το api-dev.demo-corp.com στο 3.98.x.x — block AWS ca-central-1, όχι πίσω από το Cloudflare. Είναι ο πραγματικός διακομιστής εκτεθειμένος. Προτεραιότητα στόχος για την ενεργητική φάση.
  • Το old-admin.demo-corp.com στο 66.42.x.x — Vultr. Ένας ξεχασμένος διακομιστής, εκτός του κύριου CDN. Επίσης προτεραιότητα στόχος.

Σημειώστε αυτές τις τρεις γραμμές. Θα κατευθύνουν όλη την ενότητα 4.

Βήμα 6 — Παθητικό fingerprinting τεχνολογίας​

Προσοχή: τα whatweb και wappalyzer φορτώνουν τη σελίδα — αυτό είναι ενεργητικό. Για να παραμείνουμε σε αυστηρά παθητική φάση, χρησιμοποιούμε:

  • BuiltWith (μέσω της διεπαφής web από τον περιηγητή σας — αλλά ο περιηγητής σας θα φορτώσει το BuiltWith, όχι τον στόχο).
  • Shodan: το shodan host <IP> επιστρέφει ό,τι έχει ήδη συλλέξει το Shodan.
shodan host 3.98.14.202 > tech/shodan-api-dev.txt
cat tech/shodan-api-dev.txt

Τυπική έξοδος:

3.98.14.202
Hostnames: ec2-3-98-14-202.ca-central-1.compute.amazonaws.com
Country:  Canada
City:     Montréal
Organization: Amazon.com, Inc.

Open Ports: 22, 80, 443, 8080

22/tcp     SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
80/tcp     nginx/1.18.0
443/tcp    nginx/1.18.0 — TLSv1.3 — CN=api-dev.demo-corp.com
8080/tcp   Django DEBUG page found

Χρυσή γραμμή: Django DEBUG page found. Το Shodan έχει ήδη δει μια σελίδα λειτουργίας debug του Django εκτεθειμένη στο :8080. Μια λειτουργία debug του Django εκθέτει:

  • Το πλήρες stack σε περίπτωση σφάλματος.
  • Τις μεταβλητές περιβάλλοντος (άρα συχνά μυστικά κλειδιά).
  • Μερικές φορές ολόκληρο το SECRET_KEY.

Μόλις βρήκαμε, χωρίς να στείλουμε πακέτο στο demo-corp.com, μια πιθανώς κρίσιμη ευπάθεια. Θα την επιβεβαιώσουμε στην εβδομάδα 4.

Σημειώστε την ανακάλυψη στο tech/decouvertes.md:

- [ΚΡΙΣΙΜΟ] api-dev.demo-corp.com:8080 — Django σε DEBUG (πηγή: Shodan)
- [ΠΛΗΡΟΦΟΡΙΑ] api-dev.demo-corp.com: Nginx 1.18, OpenSSH 8.2 σε Ubuntu 20

Βήμα 7 — Βασικά πρόσωπα (theHarvester + LinkedIn)​

theHarvester -d demo-corp.com -b linkedin,bing,duckduckgo -l 500 \
  -f people/harvester.html

Το theHarvester ερωτά τρίτες API και το LinkedIn (γενικά μέσω Bing). Τυπική έξοδος:

[*] Emails found: 34
    admin@demo-corp.com
    contact@demo-corp.com
    j.dupuis@demo-corp.com
    m.tremblay@demo-corp.com
    ...

[*] Hosts found:
    (Ίδιο, επαναλαμβανόμενο με ό,τι έχουμε ήδη)

[*] LinkedIn profiles (via Bing):
    Marie Tremblay - CTO at Demo Corp
    Jean Dupuis - Senior DevOps at Demo Corp
    Étienne Roy - Support Lead at Demo Corp
    ...

Το πρότυπο email ξεχωρίζει αμέσως: initiale.nom@demo-corp.com. Από το LinkedIn, μπορείτε να μαντέψετε το email της πλειοψηφίας των υπαλλήλων του πελάτη, χωρίς ποτέ να τους το ζητήσετε.

Ενοποιήστε στο people/personnes.csv:

prenom,nom,titre,email,linkedin
Marie,Tremblay,CTO,m.tremblay@demo-corp.com,https://www.linkedin.com/in/marietremblay
Jean,Dupuis,Senior DevOps,j.dupuis@demo-corp.com,...
Étienne,Roy,Support Lead,e.roy@demo-corp.com,...

Αυτό το αρχείο εξυπηρετεί την ενότητα 6 (κοινωνική μηχανική).

Βήμα 8 — Δημόσιες διαρροές​

# HaveIBeenPwned ανά τομέα — απαιτεί κλειδί API (επί πληρωμή αλλά φθηνό).
curl -s -H "hibp-api-key: $HIBP_KEY" \
  "https://haveibeenpwned.com/api/v3/breacheddomain/demo-corp.com" \
  | jq . > leaks/hibp.json

# Επισκόπηση:
jq -r 'keys[] as $k | "\($k) → \(.[$k] | join(", "))"' leaks/hibp.json | head

Έξοδος:

j.dupuis  → Adobe, Collection#1, MyFitnessPal
support   → Collection#1
etienne.roy → LinkedIn, Dropbox

Δύο τεχνικοί λογαριασμοί (j.dupuis, etienne.roy) έχουν ήδη διαρρεύσει σε δημόσια dumps. Αν ο πελάτης επαναχρησιμοποιεί κωδικούς (password reuse) — και στατιστικά, ένας pentester μπορεί να το υπολογίζει αυτό — θα μπορέσουμε να δοκιμάσουμε password spraying στην εβδομάδα 5.

Συμπληρώστε με GitHub Search:

Ψάξτε για repositories με ονόματα demo-corp-*, scripts, backups, dotfiles. Εκεί βρίσκουμε τακτικά:

  • Ένα .env με μυστικά.
  • Scripts με κωδικούς πρόσβασης hardcoded.
  • Εσωτερικά URL.

Στην demo μας, ένα δημόσιο dotfiles πρώην υπαλλήλου περιέχει ένα αρχείο deploy.sh με:

ssh deploy@old-admin.demo-corp.com -i ~/.ssh/deploy-key

Επιβεβαιωμένος στόχος: old-admin.demo-corp.com, λογαριασμός deploy. Προς εκμετάλλευση στην εβδομάδα 4.

Βήμα 9 — Αρχεία (Wayback Machine)​

curl -s "https://web.archive.org/cdx/search/cdx?url=demo-corp.com/*&output=json&limit=200" \
  | jq -r '.[1:] | .[] | .[2]' \
  | sort -u > archive/urls-historiques.txt

wc -l archive/urls-historiques.txt

Έξοδος:

612 archive/urls-historiques.txt

Ένα grep σε αποκαλυπτικές λέξεις-κλειδιά:

grep -iE 'admin|backup|test|debug|swagger|api-doc|internal' archive/urls-historiques.txt
https://demo-corp.com/admin-old/
https://demo-corp.com/api/v1/debug
https://demo-corp.com/backup.sql          (2019)
https://demo-corp.com/swagger.json

Το backup.sql το 2019 — πιθανώς διαγράφηκε έκτοτε, αλλά θα το επιβεβαιώσουμε στην ενότητα 4: η Wayback Machine δεν εγγυάται τη διαγραφή στην πλευρά του διακομιστή.

Βήμα 10 — Ενοποίηση του φύλλου​

Ανοίξτε το ~/osint/demo-corp/fiche-cible.md και συμπληρώστε με όσα προηγήθηκαν. Προτεραιότητα στόχοι να αναδεικνύονται με έντονη γραφή.

# Φύλλο στόχου — demo-corp.com  (2026-04-15)

## 1. Επιβεβαιωμένα assets
- Ριζικός τομέας: demo-corp.com (Cloudflare DNS + proxy)
- Υποτομείς: 178 συλλεγμένοι, μεταξύ των οποίων:
  - **api-dev.demo-corp.com  → AWS ca-central-1 (3.98.14.202), Django DEBUG στο :8080**
  - **old-admin.demo-corp.com → Vultr (66.42.11.198), πιθανός λογαριασμός deploy**
  - internal.demo-corp.com  → 192.168.10.5 (ιδιωτική), λάθος δημοσιευμένη
  - jenkins.demo-corp.com   → AWS
  - jira.demo-corp.com      → Atlassian Cloud (εκτός εύρους προς διευκρίνιση)

## 2. Εύρος προς διαπραγμάτευση με τον πελάτη
- internal.demo-corp.com (δημοσιευμένη ιδιωτική IP): προσθήκη στο RoE;
- Υποτομείς Atlassian και Google: εκτός εύρους.

## 3. Τεχνολογίες
- Front (www): Next.js πίσω από Cloudflare
- API prod: άγνωστο, φιλτραρισμένο από Cloudflare
- API dev: Django, Nginx 1.18, Ubuntu 20 (πηγή: Shodan)
- Αλληλογραφία: Google Workspace
- Συνδεδεμένα SaaS: Stripe, Mailgun, Atlassian, Sentry

## 4. Πιθανές ευπάθειες (προς επιβεβαίωση στην εβδομάδα 4)
- ΚΡΙΣΙΜΟ: Django DEBUG εκτεθειμένο στο api-dev:8080
- ΥΨΗΛΟ   : old-admin.demo-corp.com — κληρονομημένος πίνακας διαχείρισης
- ΜΕΤΡΙΟ  : DMARC p=none → πιθανό spoofed phishing
- ΜΕΤΡΙΟ  : backup.sql (2019) — παρόν στον τρέχοντα διακομιστή;

## 5. Βασικά πρόσωπα (πηγή: LinkedIn + theHarvester)
- Marie Tremblay, CTO — m.tremblay@demo-corp.com
- Jean Dupuis, Sr DevOps — j.dupuis@demo-corp.com  [διαρροή HIBP × 3]
- Étienne Roy, Support Lead — e.roy@demo-corp.com  [διαρροή HIBP × 2]
+ 21 άλλοι στο people/personnes.csv

## 6. Δημόσιες διαρροές
- HIBP: 2 λογαριασμοί υψηλής αξίας με πιθανή επαναχρησιμοποίηση
- GitHub: dotfiles πρώην υπαλλήλου αναφέρει old-admin.demo-corp.com και λογαριασμό deploy

## 7. Επόμενο βήμα (ενότητα 4)
1. Επιβεβαίωση Django DEBUG στο api-dev:8080 — 30 λεπτά.
2. Χαρτογράφηση old-admin.demo-corp.com: θύρες, εκδόσεις — 45 λεπτά.
3. Έλεγχος /backup.sql στο www — 5 λεπτά.
4. Προσεκτικό password spraying στους 2 λογαριασμούς HIBP — 30 λεπτά.

Απολογισμός​

Σε 90 λεπτά, χωρίς να στείλουμε κανένα πακέτο στο demo-corp.com:

  • Έχουμε 178 υποτομείς.
  • Έχουμε μία κρίσιμη ευπάθεια σχεδόν βέβαιη (εκτεθειμένο Django DEBUG).
  • Έχουμε δύο δευτερεύοντες στόχους υψηλής αξίας (old-admin, internal).
  • Έχουμε ένα σχέδιο επίθεσης για την εβδομάδα 4.
  • Έχουμε διαρρεύσαντες λογαριασμούς αξιοποιήσιμους αργότερα.
  • Ο στόχος δεν ξέρει τίποτα.

Αυτή είναι η δύναμη ενός καλά διεξαγόμενου OSINT. Είναι η ενότητα που αποδίδει περισσότερο ανά επενδυμένο λεπτό.

Επόμενο μάθημα: σειρά σας. Επιλέγετε ένα πρόγραμμα bug bounty και ξανακάνετε το ίδιο, αυτόνομα.