Επίθεση μέσω Microsoft Teams: πώς οι επιτιθέμενοι έκλεψαν δικαιώματα Domain Admin με

Η πρόσφατη αποκάλυψη της Microsoft για δύο εισβολές όπου οι επιτιθέμενοι προσποιούνταν το IT help desk σε Microsoft Teams αναδεικνύει έναν επικίνδυνο και αποτελεσματικό συνδυασμό social engineering και πολιτικών πιστοποιητικών που έχουν λάθη. Αντί για εκμετάλλευση ευπάθειας στο Teams, οι επιτιθέμενοι έπειθαν χρήστες να ανοίξουν απομακρυσμένες συνεδρίες υποστήριξης, έκλεβαν πρόσβαση σε endpoints και στη συνέχεια εκμεταλλεύονταν αδύναμες ρυθμίσεις στο Active Directory Certificate Services (AD CS) για να εκδώσουν πιστοποιητικά ταυτότητας υψηλών δικαιωμάτων.

Η αναφορά της Microsoft στις 30 Οκτωβρίου 2026 περιγράφει δύο ξεχωριστά περιστατικά με κοινά μοτίβα: καλλιεργημένη εμπιστοσύνη μέσω Teams, χρήση φορητών runtime (π.χ. Python, Java, Bun), και κατόπιν κακόβουλη αλληλεπίδραση με υπηρεσίες πιστοποιητικών και πρωτόκολλα αυθεντικοποίησης. Η εξέλιξη αυτών των επιθέσεων δείχνει πώς μια «απλή» κοινωνική μηχανική επίθεση μπορεί να γίνει πύλη για πλήρη κατάληψη του domain.

Πώς οι επιτιθέμενοι ξεκίνησαν τις επιθέσεις μέσω Teams

Οι επιτιθέμενοι επικοινωνούσαν μέσω μηνυμάτων και κλήσεων στο Microsoft Teams, παρουσιάζοντας διακριτικά ονόματα και tenant identifiers που έκαναν την επαφή να φαίνεται εσωτερική. Με αυτόν τον τρόπο έπειθαν θύματα να εκκινήσουν το εργαλείο απομακρυσμένης βοήθειας Quick Assist και να μοιραστούν κωδικούς σύνδεσης για πρόσβαση στη συνεδρία.

Αφού πήραν έλεγχο ενός υπολογιστή, οι επιτιθέμενοι μετέφεραν αρχεία στον φάκελο Downloads, αποσυμπίεζαν payloads σε φακέλους με πρόθεμα KB- κάτω από το προφίλ χρήστη και εκτελούσαν φορητές εκδόσεις runtime, αποφεύγοντας εγκατάσεις που θα άφηναν μόνιτα ίχνη. Αυτά τα προγράμματα έκαναν έρευνα του host, σάρωση για υπηρεσίες πιστοποιητικών και έστησαν συνδέσεις προς την υποδομή του domain μέσω LDAPS και SMB.

Κακή διαμόρφωση του AD CS και εκμετάλλευση template

Στο πρώτο περιστατικό οι επιτιθέμενοι βρήκαν ένα template πιστοποιητικού που ήταν ευάλωτο στην κατάσταση που η Microsoft χαρακτηρίζει ως ESC1. Ο συνδυασμός ευρέων δικαιωμάτων εγγραφής (enrollment), δυνατότητας παροχής ταυτότητας από τον αιτούντα και ανεπαρκούς ελέγχου έκδοσης επέτρεψε σε λογαριασμό χαμηλών δικαιωμάτων να αιτηθεί και να λάβει πιστοποιητικά που αναπαριστούσαν λογαριασμούς με υψηλά προνόμια ή ακόμα και έναν domain controller.

Τα πιστοποιητικά αυτά λειτουργούν σαν ψηφιακές ταυτότητες: αν ένας server ή υπηρεσία τα αποδεχθεί, ο κάτοχός τους μπορεί να αυτοπροσδιορίζεται ως ο αντίστοιχος χρήστης ή μηχάνημα. Στην πρώτη φάση, από ένα αρχικό κύμα phishing σε 3 χρήστες και τη διαφθορά 1 workstation, οι επιτιθέμενοι απέκτησαν πιστοποιητικά για 3 λογαριασμούς με υψηλά δικαιώματα. Στη συνέχεια, περίπου 90 λεπτά αργότερα, ένα δεύτερο κύμα έπληξε 16 χρήστες, kompromised ακόμη ένα endpoint και απέσπασε πιστοποιητικά για 8 επιπλέον privileged accounts.

PetitPotam, NTLM relay και απόκτηση πιστοποιητικού domain controller

Στο δεύτερο περιστατικό οι επιτιθέμενοι αξιοποίησαν την τεχνική PetitPotam, που κακοποιεί το πρωτόκολλο EFSRPC για να αναγκάσει έναν domain controller να αυθεντικοποιηθεί σε έναν παραπλανητικό αποδέκτη. Στη συνέχεια, το NTLM authentication που προέκυψε μεταφέρθηκε (relayed) στην υπηρεσία Web Enrollment του AD CS, η οποία δεν είχε επαρκή προστασία και ήταν ευάλωτη στην κατάσταση ESC8.

Με αυτή τη μέθοδο οι επιτιθέμενοι απέκτησαν πιστοποιητικό για τον domain controller, το οποίο τους επέτρεψε να χρησιμοποιήσουν Kerberos PKINIT ώστε να λάβουν ένα ticket-granting ticket (TGT) για τη μηχανή αυτή. Έτσι εξασφάλισαν έγκυρα Kerberos tickets που αντιπροσωπεύουν την ταυτότητα του domain controller — και αυτό ανοίγει την πόρτα για άδειες που συνήθως θεωρούνται αποκλειστικές του συστήματος.

Πρακτικές συνέπειες: DCSync, εξαγωγή δεδομένων και επιμονή

Μόλις αποκτήθηκε ένα πιστοποιητικό υψηλού προφίλ, οι επιτιθέμενοι εκτέλεσαν DCSync σύντομα μετά — μια λειτουργία που επιτρέπει σε έναν επιτιθέμενο να ζητήσει από έναν domain controller δεδομένα που συμπεριλαμβάνουν hash κωδικών χρηστών, συμπεριλαμβανομένου του KRBTGT. Η επίθεση κινηματογραφήθηκε ενώ το Microsoft Defender μπλόκαρε πάνω από 1.000 προσπάθειες πρόσβασης αρχείων μέσω SMB και επιπλέον προσπάθειες logon.

Παρόλα αυτά, ένα προνομιακό λογαριασμό που είχε εξαιρεθεί από αυτόματη καραντίνα παρέμεινε ενεργό, επιτρέποντας στους επιτιθέμενους να έχουν πρόσβαση σε file servers και να τρέξουν εργαλεία όπως Rclone με το όνομα SearchApp.exe για εξαγωγή αρχείων σε εξωτερικό SFTP dest. H ικανότητα να κινούνται γρήγορα και να χρησιμοποιούν εκπομπές που μοιάζουν νόμιμες έκανε την ανίχνευση και την πλήρη εκκαθάριση πιο δυσχερή.

Τι πρέπει να γίνει στην ανίχνευση και απόκριση

Η ανάκληση κωδικών δεν ακυρώνει πιστοποιητικά που έχουν ήδη εκδοθεί, και η ανάκληση πιστοποιητικού δεν ακυρώνει απαραίτητα υπάρχοντα Kerberos tickets. Γι’ αυτό οι αποκρίσεις πρέπει να περιλαμβάνουν ξεχωριστή διερεύνηση των Kerberos ticket logs και ανάκληση/ακύρωση πιστοποιητικών από τις υπηρεσίες έκδοσης και CRL/OCSP όπου απαιτείται.

Επιπλέον, είναι κρίσιμο να εντοπιστεί και να απομονωθεί οποιοδήποτε endpoint που χρησιμοποιήθηκε για αρχική πρόσβαση, να ελεγχθούν τα permissions των templates πιστοποιητικών, και να εξεταστούν οι ρυθμίσεις web enrollment για την εφαρμογή HTTPS και Extended Protection for Authentication (EPA). Η αυτόματη καραντίνα privileged λογαριασμών πρέπει να ελέγχεται ώστε να μην υπάρχουν εξαιρέσεις που θα αφήνουν «ανοιχτές πόρτες».

Προτάσεις για άμεσες προληπτικές ενέργειες

Οι οργανισμοί πρέπει να μειώσουν τον επιφανειακό χώρο επίθεσης του Teams, περιορίζοντας ή απαγορεύοντας εξωτερικές προσκλήσεις όταν δεν είναι απολύτως απαραίτητες, και επιβάλλοντας πολιτικές που απαιτούν επαλήθευση ταυτότητας πριν από απομακρυσμένη βοήθεια. Η εκπαίδευση χρηστών για την αναγνώριση ψευδο-αιτημάτων υποστήριξης και οι διαδικασίες δύο-βημάτων πριν από την αποδοχή Quick Assist είναι βασικές.

Τεχνικά, συστήνεται να:

• περιοριστούν τα δικαιώματα εγγραφής (enrollment) σε πιστοποιητικά σε συγκεκριμένους λογαριασμούς και μηχανήματα,
• απενεργοποιηθεί το NTLM όπου είναι δυνατόν και να προωθηθεί το Kerberos,
• επιβληθεί HTTPS και Extended Protection for Authentication σε όλα τα enrollment endpoints,
• αποτραπεί η εκτέλεση ανεξέλεγκτων φορητών runtimes (application allowlisting), και
• ενισχυθεί η παρακολούθηση των logs του AD CS, των Kerberos ticketing logs και των SMB access attempts.

Ενδείξεις συμβιβασμού (IOCs) και πρακτική χρήση τους

Η δημόσια αναφορά περιλαμβάνει SHA-256 hashes αρχείων που χρησιμοποιήθηκαν για αρχική πρόσβαση, ενδεικτικά: 85b6c4…9f17, f32620…f001, 06c5c1…69e7. Αυτές οι ενδείξεις πρέπει να εισαχθούν σε SIEM, EDR και συστήματα threat intelligence για αντιπαραβολή με τοπικά logs και δείγματα. Σημειώστε ότι IPs και domains έχουν intentional “qdefang” στην αναφορά για αποφυγή ακούσιας επίλυσης — χρησιμοποιήστε μόνο σε ελεγχόμενα περιβάλλοντα όπως MISP ή VirusTotal.

Οι ομάδες ασφαλείας πρέπει να ψάξουν για ασυνήθιστες χρήσεις Quick Assist, για δημιουργία φακέλων με πρόθεμα KB-, για εκτέλεση φορητών runtime και για μαζικές αποτυχημένες ή επιτυχημένες προσβάσεις SMB που ακολουθούνται από DCSync ή περίεργες Kerberos συναλλαγές.

Τι σημαίνει αυτό στην πράξη

Η υπόθεση δείχνει ότι το πιο επικίνδυνο δεν είναι πάντα ένα «zero-day» λογισμικό, αλλά το συνδυαστικό σφάλμα στο ανθρώπινο παράγοντα και στις πολιτικές υποδομής. Όταν οι διαδικασίες έκδοσης πιστοποιητικών δεν εφαρμόζουν αρχές least privilege και όταν υπηρεσίες δέχονται αυτοματοποιημένα NTLM authentication χωρίς προστασία, η μετάβαση από απλή πρόσβαση σε πλήρη κατάληψη του domain γίνεται εξαιρετικά γρήγορη.

Για τις ομάδες IT και ασφάλειας, ο πρακτικός οδηγός είναι σαφής: αναθεώρηση των permissions στο AD CS, σκληρές πολιτικές για απομακρυσμένη υποστήριξη, ενεργή παρακολούθηση Kerberos/AD logs και εφαρμογή τεχνολογιών που μειώνουν την ανάγκη για legacy πρωτόκολλα. Ο χρόνος ανίχνευσης και η ικανότητα άμεσης, πλήρους ανάκλησης πιστοποιητικών και διαθέσεως Kerberos tickets είναι πλέον κρίσιμος παράγοντας για την αποτροπή ευρείας καταστροφής.