Εν ολίγοις: Ξένους λογαριασμούς διαχειριστή βρίσκετε μόνο αν ελέγξετε όλα τα επίπεδα: το CMS ή το κατάστημα, το πάνελ φιλοξενίας, τους χρήστες συστήματος του διακομιστή, τις προσβάσεις SSH και τους χρήστες της βάσης δεδομένων. Μην βασίζεστε στη λίστα χρηστών του backend, γιατί ο παρεισφρήσας κώδικας μπορεί να κρύβει εκεί λογαριασμούς. Τεκμηριώστε και κλειδώστε πρώτα τα ευρήματα, διευκρινίστε την αιτία και διαγράψτε μόνο μετά.
Γιατί ένας άγνωστος διαχειριστής είναι τόσο επικίνδυνος
Ένας πρόσθετος λογαριασμός διαχειριστή είναι για τους επιτιθέμενους η πιο βολική κερκόπορτα. Δεν χρειάζεται κακόβουλο κώδικα, δεν ξεχωρίζει στις σαρώσεις αρχείων και επιβιώνει σε κάθε ενημέρωση. Όποιος συνδεθεί αργότερα με αυτόν τον λογαριασμό, φαίνεται στο πρωτόκολλο σαν κανονικός συντάκτης.
Μετά το PHP2Shell αυτός ο έλεγχος αποκτά βάρος. Οι ευπάθειες CVE-2026-109618 και CVE-2026-109619 επιτρέπουν την εκτέλεση κακόβουλου κώδικα χωρίς σύνδεση. Όποιος μπορεί να εκτελέσει κώδικα στον διακομιστή, μπορεί και να γράψει στη βάση δεδομένων και έτσι να δημιουργήσει λογαριασμούς. Μια ενημέρωση PHP κλείνει την ευπάθεια, δεν αφαιρεί όμως κανέναν λογαριασμό που δημιουργήθηκε νωρίτερα.
Για το PHP2Shell δεν υπάρχουν δημοσιευμένοι, επιβεβαιωμένοι Indicators of Compromise, δηλαδή κατάλογος τυπικών ιχνών. Ένας άγνωστος λογαριασμός δεν είναι γι' αυτό απόδειξη PHP2Shell, αλλά σαφής ένδειξη μη εξουσιοδοτημένης πρόσβασης, ανεξάρτητα από τον δρόμο. Μια επισκόπηση περαιτέρω ενδείξεων υπάρχει στο Έχω ήδη παραβιαστεί;.
Πού μπορούν να κρύβονται ξένοι λογαριασμοί διαχειριστή
Πολλοί διαχειριστές κοιτάζουν μόνο στο CMS. Οι επιτιθέμενοι σκέφτονται σε επίπεδα και κάθε επίπεδο έχει δικούς του λογαριασμούς:
| Επίπεδο | Πού να κοιτάξετε | Τι να προσέξετε |
|---|---|---|
| CMS ή κατάστημα | διαχείριση χρηστών και πίνακας βάσης δεδομένων των χρηστών | ρόλος Administrator, ημερομηνία δημιουργίας, ξένη διεύθυνση email |
| Πάνελ φιλοξενίας | χρήστες, πρόσθετοι λογαριασμοί, λογαριασμοί FTP | λογαριασμοί που δεν δημιούργησε κανείς στην ομάδα |
| Διακομιστής Linux | /etc/passwd, ομάδες sudo ή wheel, sudoers |
περαιτέρω λογαριασμοί με UID 0, νέα shells σύνδεσης |
| SSH | authorized_keys όλων των χρηστών |
κλειδιά χωρίς γνωστό κάτοχο |
| Βάση δεδομένων | πίνακας χρηστών του διακομιστή βάσης δεδομένων | χρήστες με καθολικά δικαιώματα ή host % |
| Εξωτερικές υπηρεσίες | domain, DNS, Search Console, CDN | πρόσθετοι ιδιοκτήτες ή εξουσιοδοτημένοι |
Το επίπεδο SSH είναι αρκετά αυτόνομο ώστε να έχει δικό του άρθρο: Εύρεση και αφαίρεση άγνωστων κλειδιών SSH.
Εύρεση ξένων λογαριασμών διαχειριστή στο CMS, και κρυφών
Η λίστα χρηστών στο backend παράγεται από την ίδια την εφαρμογή. Αν τρέχει παρεισφρήσας κώδικας, μπορεί να φιλτράρει μεμονωμένες εγγραφές. Πιο αξιόπιστα είναι γι' αυτό εργαλεία που κοιτάζουν απευθείας τα αποθηκευμένα δεδομένα. Για το WordPress το WP-CLI απαριθμεί όλους τους διαχειριστές με ημερομηνία δημιουργίας:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Ένα επίπεδο βαθύτερα πηγαίνει ένα ερώτημα ανάγνωσης στη βάση δεδομένων. Δείχνει κάθε λογαριασμό στον οποίο έχει αποδοθεί ο ρόλος διαχειριστή, ανεξάρτητα από το τι εμφανίζει η διεπαφή. Το πρόθεμα πίνακα wp_ το προσαρμόζετε στην εγκατάστασή σας:
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Συγκρίνετε τα αποτελέσματα του backend, του WP-CLI και της βάσης δεδομένων. Αν ένας λογαριασμός εμφανίζεται μόνο στη βάση δεδομένων, αυτό είναι ισχυρό προειδοποιητικό σημάδι, επειδή τότε εμπλέκεται επιπλέον κώδικας που τον κρύβει. Για άλλα συστήματα όπως το Shopware, το TYPO3 ή το Joomla ισχύει η ίδια αρχή: ερωτήστε απευθείας τον πίνακα χρηστών και συγκρίνετε με την εμφάνιση στο backend. Ποιοι είναι αυτοί οι πίνακες, αναγράφεται στην τεκμηρίωση του κατασκευαστή.
Έλεγχος χρηστών συστήματος και χρηστών βάσης δεδομένων
Στον ίδιο τον διακομιστή ενδιαφέρουν κυρίως λογαριασμοί με δικαιώματα root και λογαριασμοί που μπορούν να συνδεθούν. Οι παρακάτω εντολές απλώς διαβάζουν:
# Λογαριασμοί με UID 0 (κανονικά μόνο root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Λογαριασμοί με πραγματικό shell σύνδεσης
grep -vE '(nologin|false)$' /etc/passwd
# Μέλη των ομάδων διαχείρισης
getent group sudo wheel
# Πρόσθετοι κανόνες sudo
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Τελευταίες συνδέσεις με πλήρη ημερομηνία
last -F | head -30
Στον διακομιστή βάσης δεδομένων ελέγχετε ποιοι χρήστες υπάρχουν και ποια δικαιώματα έχουν:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Μια εφαρμογή χρειάζεται κατά κανόνα έναν χρήστη με δικαιώματα σε ακριβώς μία βάση δεδομένων. Ένας πρόσθετος χρήστης με καθολικά δικαιώματα, που επιτρέπεται να έχει πρόσβαση από οποιοδήποτε host (%), πρέπει να διευκρινιστεί.
Μην ξεχνάτε τους λογαριασμούς εκτός του διακομιστή. Όποιος έχει πρόσβαση στη σύμβαση του domain ή στη διαχείριση DNS, μπορεί να ανακατευθύνει επισκέπτες ή να εκδώσει πιστοποιητικά σε ξένους διακομιστές. Ένας πρόσθετος ιδιοκτήτης στο Google Search Console μπορεί να υποβάλλει sitemaps και να αλλάζει ρυθμίσεις. Διατρέξτε γι' αυτό σε registrar, πάροχο DNS, CDN και Search Console τη λίστα των εξουσιοδοτημένων και συγκρίνετέ την με όσα γνωρίζει η ομάδα σας.
Πώς χειρίζεστε σωστά ένα εύρημα
Η πρώτη παρόρμηση είναι να διαγράψετε αμέσως τον ξένο λογαριασμό. Έτσι όμως εξαφανίζεται και ένα σημαντικό ίχνος: η ημερομηνία δημιουργίας περιορίζει συχνά πότε ήταν ο επιτιθέμενος στο σύστημα. Καλύτερη είναι αυτή η σειρά:
- Τεκμηρίωση: Καταγράψτε όνομα χρήστη, ID, email, ημερομηνία δημιουργίας, ρόλο και τελευταία δραστηριότητα με ώρα, ιδανικά ως στιγμιότυπο οθόνης και εξαγωγή.
- Κλείδωμα αντί για διαγραφή: Αφαιρέστε τον ρόλο, αντικαταστήστε τον κωδικό με τυχαία τιμή ή απενεργοποιήστε τον λογαριασμό.
- Περιορισμός της περιόδου: Ελέγξτε τα logs γύρω από την ημερομηνία δημιουργίας. Ποια αιτήματα υπήρξαν λίγο πριν, ποια αρχεία άλλαξαν;
- Έλεγχος περαιτέρω επιπέδων: Όποιος δημιουργεί έναν λογαριασμό, αφήνει σπάνια μόνο έναν. Ελέγξτε επίσης αρχεία, cronjobs, κλειδιά SSH και βάση δεδομένων.
- Καθαρισμός και ανανέωση προσβάσεων: Μόνο μετά τον καθαρισμό και την ενημέρωση PHP ανανεώστε όλους τους κωδικούς, τα κλειδιά και τις συνεδρίες.
Μια υπόδειξη προσοχής: δεν είναι κακόβουλος κάθε άγνωστος λογαριασμός. Γραφεία, πρώην πάροχοι υπηρεσιών ή plugins συντήρησης δημιουργούν μερικές φορές δικούς τους λογαριασμούς. Διευκρινίστε το πριν σημάνετε συναγερμό, αλλά διευκρινίστε το έγκαιρα.
Αποτροπή επανάληψης
Μετά τον καθαρισμό οι λογαριασμοί διαχειριστή πρέπει να είναι η εξαίρεση και όχι ο κανόνας. Έχουν αποδειχθεί χρήσιμοι προσωπικοί λογαριασμοί αντί για κοινές προσβάσεις, όσο το δυνατόν λιγότεροι διαχειριστές και ένας έλεγχος ταυτότητας δύο παραγόντων για προσβάσεις διαχειριστή. Ορίστε επιπλέον ποιος επιτρέπεται να δημιουργεί νέους λογαριασμούς διαχειριστή και πού τεκμηριώνεται αυτό.
Ένα τακτικό ερώτημα όπως τα παραπάνω, για παράδειγμα εβδομαδιαίο και με σύγκριση με την προηγούμενη εβδομάδα, κάνει γρήγορα ορατούς τους νέους λογαριασμούς. Στο WordPress βοηθά επιπλέον ο οδηγός Εύρεση backdoors στο WordPress.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Ελέγχουμε όλα τα επίπεδα λογαριασμών από το CMS έως τον διακομιστή και τη βάση δεδομένων και αντιπαραβάλλουμε την εμφάνιση του backend με τα αποθηκευμένα δεδομένα.
- Διασφαλίζουμε τα ευρήματα με χρονοσημάνσεις πριν κλειδωθούν ή αφαιρεθούν λογαριασμοί.
- Διευκρινίζουμε στο πλαίσιο της αντιμετώπισης περιστατικών (Incident Response) πώς δημιουργήθηκε ο λογαριασμός και αν υπάρχουν περαιτέρω κερκόπορτες.
- Ανανεώνουμε προσβάσεις με τη σωστή σειρά και ρυθμίζουμε μια συνεχή παρακολούθηση νέων λογαριασμών διαχειριστή.
Συχνές ερωτήσεις
Πρέπει να διαγράψω αμέσως έναν άγνωστο λογαριασμό διαχειριστή;
Καλύτερα όχι αμέσως. Τεκμηριώστε πρώτα όνομα χρήστη, ημερομηνία δημιουργίας, διεύθυνση email και τελευταία δραστηριότητα και κλειδώστε τον λογαριασμό. Η διαγραφή γίνεται μόνο όταν διασφαλιστούν τα ίχνη, γιατί η ημερομηνία δημιουργίας είναι συχνά σημαντική ένδειξη για τη χρονική στιγμή της εισβολής.
Μπορεί ένας λογαριασμός διαχειριστή να είναι αόρατος στο backend;
Ναι. Ο παρεισφρήσας κώδικας μπορεί να αποκρύψει μεμονωμένους λογαριασμούς από τη λίστα χρηστών της διεπαφής. Ένα άμεσο ερώτημα στη βάση δεδομένων ή ένα εργαλείο γραμμής εντολών δείχνει αντίθετα όλους τους αποθηκευμένους λογαριασμούς. Γι' αυτό δεν πρέπει να κοιτάτε μόνο στο backend.
Ποια επίπεδα πρέπει να ελέγξω εκτός από το CMS;
Πάνελ φιλοξενίας, προσβάσεις FTP και SFTP, χρήστες συστήματος του διακομιστή συμπεριλαμβανομένων των δικαιωμάτων sudo, κλειδιά SSH, χρήστες βάσης δεδομένων καθώς και λογαριασμούς σε domain, DNS και Search Console. Ένας επιτιθέμενος χρειάζεται μόνο μία από αυτές τις πόρτες για να επιστρέψει.
Αρκεί να αλλάξω όλους τους κωδικούς μετά το εύρημα;
Όχι. Ένας ξένος λογαριασμός δείχνει ότι κάποιος είχε πρόσβαση. Τότε πρέπει να διευκρινιστούν και η πύλη εισόδου, περαιτέρω κερκόπορτες και πιθανές διαρροές δεδομένων. Τους κωδικούς τους αλλάζετε μόνο μετά τον καθαρισμό και από καθαρή συσκευή.