WordPress cloaking νέας γενιάς: όταν το malware «αναγνωρίζει» τον Googlebot από το IP του

Τα «κλασικά» redirects τύπου “πήγαινε τον επισκέπτη αλλού” γίνονται όλο και πιο σπάνια σε σοβαρές μολύνσεις. Οι επιθέσεις που βλέπουμε τελευταία στο WordPress οικοσύστημα κινούνται προς πιο επιλεκτικές τεχνικές: φιλτράρουν ποιος βλέπει τι, ώστε ο ιδιοκτήτης να μην αντιληφθεί τίποτα, αλλά οι μηχανές αναζήτησης να καταγράψουν spam/κακόβουλο περιεχόμενο.

Σε πρόσφατη ανάλυση περιστατικού, εντοπίστηκε μόλυνση μέσα στο βασικό index.php ενός WordPress site, όπου το αρχείο λειτουργούσε σαν “θυρωρός”: για τους κανονικούς χρήστες φόρτωνε το site όπως πάντα, αλλά για Googlebot και σχετικά Google εργαλεία φόρτωνε remote payload από εξωτερικό domain και το εμφάνιζε σαν να ήταν εγγενές περιεχόμενο του site.

Τι είδους επίθεση είναι αυτή (και γιατί σε νοιάζει ως developer)?

Μιλάμε για selective content injection με χαρακτηριστικά SEO cloaking: το site σερβίρει διαφορετικό HTML ανάλογα με την «ταυτότητα» του επισκέπτη. Το αποτέλεσμα είναι ότι στο browser σου όλα φαίνονται φυσιολογικά, αλλά η Google μπορεί να βλέπει ένα εντελώς άλλο σύνολο σελίδων/κειμένων/links.

Η ζημιά σε τέτοιες περιπτώσεις δεν είναι μόνο θέμα “ασφάλειας” με τη στενή έννοια. Είναι κυρίως θέμα search reputation: deindexing, blacklisting, πτώση κατάταξης, και το πιο ύπουλο, καθυστερημένη ανίχνευση επειδή ο άνθρωπος που ελέγχει το site δεν βλέπει την παραποίηση.

Τι ήταν διαφορετικό σε αυτό το δείγμα: IP verification με Google ASN ranges (CIDR) + bitwise έλεγχος

Cloaking έχουμε ξαναδεί. Το «καινούργιο» εδώ είναι η ποιότητα του φιλτραρίσματος. Τα περισσότερα scripts σταματούν στο User-Agent (π.χ. αν περιέχει “Googlebot”). Αυτό είναι εύκολο να γίνει spoof. Το συγκεκριμένο δείγμα, όμως, κουβαλούσε μεγάλη hardcoded λίστα με Google ASN IP ranges σε CIDR μορφή και έκανε μαθηματική επαλήθευση ότι το IP του αιτήματος ανήκει όντως σε αυτά τα ranges.

Με απλά λόγια: δεν αρκεί να “πεις” ότι είσαι Googlebot. Πρέπει να έρχεσαι από πραγματική υποδομή της Google.

ASN και CIDR σε 2 λεπτά

• ASN (Autonomous System Number): πρακτικά μια «ταυτότητα» δικτύου/οργανισμού στο Internet. Ένα ASN αντιστοιχεί σε IP blocks που διαχειρίζεται ο οργανισμός (εδώ: Google).
• CIDR: συμπαγής τρόπος να περιγράψεις εύρος IP διευθύνσεων. Π.χ. 192.168.1.0/24 σημαίνει 256 διευθύνσεις (0–255) στο ίδιο block.

Επιπλέον, το script δεν έμεινε σε πρόχειρα string checks. Χρησιμοποίησε bitwise operations για να ταιριάξει IP σε network blocks και είχε και σοβαρή κάλυψη για IPv6, κάτι που αρκετά παλιότερα cloaking kits αγνοούν. Αυτό κάνει την επίθεση πολύ πιο δύσκολη να αναπαραχθεί με “χειροκίνητο” έλεγχο από έναν admin.

Πώς «δένει» μέσα στο WordPress: γιατί το index.php είναι ιδανικός στόχος

Το index.php είναι το σημείο εισόδου του site. Αν ο attacker το τροποποιήσει, μπορεί να αποφασίζει πριν φορτώσει κανονικά το WordPress, τι θα δει ο επισκέπτης. Σε αυτό το περιστατικό το μολυσμένο index.php είτε bootstrapp-άρει το WordPress περιβάλλον, είτε σερβίρει τρίτο περιεχόμενο.

Το σημαντικό εδώ είναι ότι ο κώδικας αξιοποιεί core αρχεία για να μη «σπάει» η κανονική λειτουργία:

• wp-load.php: χρησιμοποιείται για να φορτώσει το WordPress environment (ρυθμίσεις, DB access κ.λπ.).
• wp-blog-header.php: είναι μέρος της φυσιολογικής ροής του τυπικού index.php στο WordPress.

Ανάλυση ροής: το malware σαν gatekeeper

Η λογική είναι πολυεπίπεδη. Στόχος: να εμφανίσει το “σωστό” κακόβουλο περιεχόμενο σε Google υποδομή και να κρύβεται από όλους τους άλλους.

1) Multi-layer επαλήθευση ταυτότητας

Ξεκινά με έλεγχο HTTP_USER_AGENT (το κλασικό header που δηλώνει browser/device/crawler). Επειδή όμως αυτό γίνεται spoof, ακολουθεί έλεγχος IP με βάση τα Google ranges.

2) Bitwise έλεγχος ότι το IP ανήκει σε CIDR block

Αντί για απλό “starts with” ή regex, γίνεται μαθηματικός έλεγχος network match. Η βασική ιδέα για IPv4 είναι η κλασική σύγκριση με netmask, σε μορφή bitwise AND:

// Η βασική λογική match ενός IP σε CIDR range (ενδεικτικό snippet)
// (ip_decimal & netmask_decimal) == (range_decimal & netmask_decimal)

if ( ($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal) ) {
    // Το IP ταιριάζει στο συγκεκριμένο network block
}

// Η βασική λογική match ενός IP σε CIDR range (ενδεικτικό snippet)
// (ip_decimal & netmask_decimal) == (range_decimal & netmask_decimal)

if ( ($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal) ) {
    // Το IP ταιριάζει στο συγκεκριμένο network block
}

3) Remote payload μέσω cURL (σερβίρεται σαν “native” περιεχόμενο)

Όταν επαληθευτεί ότι το request προέρχεται από legit Google υποδομή, ο κώδικας κάνει fetch περιεχόμενο από εξωτερικό endpoint (σε pages.dev) και το τυπώνει απευθείας στο response. Έτσι ο crawler “νομίζει” ότι το site φιλοξενεί αυτό το περιεχόμενο.

hxxps://amp-samaresmanor[.]pages[.]dev

hxxps://amp-samaresmanor[.]pages[.]dev

4) Εκτεταμένο User-Agent filtering για Google υπηρεσίες

Δεν περιορίζεται στο “Googlebot”. Περιλαμβάνει strings που σχετίζονται με site verification, inspection εργαλεία και API crawlers. Στόχος: το κακόβουλο περιεχόμενο να περάσει από περισσότερα “μονοπάτια” της Google και να επιβεβαιωθεί/ευρετηριαστεί.

5) Conditional logic με logging και fallbacks

Το “decision engine” είναι σχεδιασμένο για να μην εκθέτει το site σε broken responses προς τη Google. Αν όλα περάσουν, σερβίρει payload και καταγράφει επιτυχία. Αν το payload αποτύχει να φορτώσει, γίνεται redirect σε /home/ για να μη δει η Google σφάλμα. Αν κάποιος κάνει spoof Google User-Agent αλλά το IP δεν ταιριάζει, καταγράφεται “Fake GoogleBot detected” και πάλι redirect σε ασφαλές σημείο. Για όλους τους υπόλοιπους χρήστες, η ροή γυρίζει στο κανονικό home.

Πώς φαίνεται προς τα έξω: «άλλο site» για Google, κανονικό για εσένα

Το πιο επικίνδυνο στοιχείο του cloaking είναι ότι μπορεί να το ανακαλύψεις από τα συμπτώματα (SERP, Search Console) και όχι από την καθημερινή χρήση του site. Σε αντίστοιχες περιπτώσεις, οι επισκέπτες βλέπουν το αυθεντικό περιεχόμενο, ενώ η Google βλέπει spam/ενέσεις περιεχομένου.

Ενδείξεις ότι κάτι δεν πάει καλά

Αν υποψιάζεσαι παρόμοια μόλυνση, τα “σήματα” συνήθως είναι πιο πολύ λειτουργικά/SEO παρά ορατά στο UI:

• Παράξενα ή κακής ποιότητας αποτελέσματα στο Google (τίτλοι/περιγραφές που δεν αναγνωρίζεις).
• Πρόσφατα τροποποιημένα core αρχεία (ιδίως index.php).
• Ύποπτα URLs/domains σε κώδικα ή logs, ειδικά αν δεν ανήκουν στο stack σου.
• Απρόσμενες εγγραφές σε logs (redirects, errors, περίεργες διαδρομές).

Αντιμετώπιση: τι κάνεις πρακτικά σε ένα WordPress project

Η αποκατάσταση δεν είναι μόνο “σβήνω τον κακόβουλο κώδικα”. Χρειάζεται να κόψεις την πρόσβαση, να καθαρίσεις persistence και να μειώσεις την πιθανότητα επαναμόλυνσης.

1. Έλεγχος/καθαρισμός αρχείων: αφαίρεσε άγνωστα αρχεία/φακέλους και επανάφερε core αρχεία (όπως index.php) από αξιόπιστη πηγή/backup.
2. Audit χρηστών: έλεγξε για ύποπτους administrators ή “helper” accounts που δεν πρέπει να υπάρχουν.
3. Reset credentials: άλλαξε κωδικούς για WP admins, FTP/SFTP, hosting panel και database.
4. Έλεγχος τοπικού υπολογιστή: πλήρες AV/malware scan (αν υπάρχει credential theft, το καθάρισμα του server δεν αρκεί).
5. Updates παντού: WordPress core, themes, plugins — ειδικά αν υπήρξε αρχικό entry μέσω ευπάθειας.
6. WAF (Web Application Firewall): ένα WAF μπορεί να βοηθήσει στο blocking γνωστών C2/κακόβουλων endpoints και να μειώσει την πιθανότητα αρχικού upload/εκμετάλλευσης.

Πρόληψη: γιατί το file integrity monitoring είναι πλέον απαραίτητο

Αυτού του τύπου οι μολύνσεις είναι σχεδιασμένες να μην τις βλέπεις. Αν δεν έχεις μηχανισμό που να σε ειδοποιεί όταν αλλάζουν core αρχεία, μπορεί να “τρέχουν” για καιρό μέχρι να φανεί η ζημιά στο SEO.

Δύο πρακτικές που αξίζει να μπουν ως default σε production sites:

• File Integrity Monitoring: ειδοποιήσεις για μη εξουσιοδοτημένες αλλαγές σε core files όπως index.php.
• Συστηματικός έλεγχος Google Search Console: αναζήτησε μη αναμενόμενες σελίδες/URLs στο index (σημάδι cloaking ή injection).