Μετάβαση στο κύριο περιεχόμενο

Postmortem: πώς ένα Word έγινε Domain Admin

από Datatrek NightWatch 4-λεπτο διάβασμα

Δήλωση: Στοιχεία αναγνώρισης του οργανισμού έχουν αλλοιωθεί. Η τεχνική αλυσίδα είναι πραγματική και ανακατασκευάστηκε από τηλεμετρία agent, network logs και τη συνέντευξη με τον IT lead μετά το περιστατικό. Δημοσιεύεται με τη συγκατάθεση του πελάτη.

Σύνοψη

  • T+0: Χρήστης οικονομικών ανοίγει ελληνόφωνο email τιμολογίου με .docm με μακροεντολές.
  • T+0:01: Macro εκκινεί regsvr32.exe με remote scriptlet — first-stage download.
  • T+0:04: Δημιουργία scheduled task για persistence, ονομασμένο ώστε να μοιάζει με Office update.
  • T+0:12: Credential dump μέσω νόμιμου-φαινομενικά υπογεγραμμένου binary (LoL-bin variant).
  • T+0:31: Lateral movement σε file server με cached domain admin token.
  • T+0:47: Domain admin από DC μέσω remote DCSync.
  • T+0:53: Datatrek SOC ειδοποιείται σε ανώμαλο DCSync από workstation· το XEDR απομονώνει τον αρχικό host.
  • T+1:08: Κυνήγι ολοκληρωμένο. Όλη η persistence αφαιρέθηκε. Καμία διαρροή.

Τι λειτούργησε

Το catch του XNDR. Ο πελάτης είχε Datatrek XEDR στους DCs αλλά μόνο single-EDR στα workstations. Το single-EDR δεν εντόπισε το credential dump — το binary φαινόταν νόμιμο. Αυτό που το έπιασε ήταν η ανίχνευση από την πλευρά δικτύου του XNDR στο ασυνήθιστο DCSync traffic. Αυτή είναι η θέση του defense-in-depth: όταν ένα στρώμα αστοχεί, ένα άλλο δεν αστοχεί.

Τα 5 μήνες retention του SIEM. Μόλις ξέραμε τι ψάχναμε, διαβάσαμε το SIEM προς τα πίσω. Το ίδιο C2 domain είχε pinged δύο φορές τις προηγούμενες 11 εβδομάδες, από το ίδιο workstation, αρκετά σύντομα ώστε να μην ενεργοποιηθεί ανίχνευση. Με μικρότερο retention θα είχαμε χάσει αυτή τη μαρτυρία και δεν θα ξέραμε αν ήταν μεμονωμένο ή συστηματικό συμβάν.

Το dual-EDR στον DC. Ο επιτιθέμενος είχε domain admin για 6 λεπτά πριν το δεύτερο EDR του DC ειδοποιήσει για την προσπάθεια DCSync. Το πρώτο EDR είδε την ίδια δραστηριότητα αλλά ο κανόνας του για αυτό το pattern ήταν επιεικής (signed binary, kerberos-issued ticket, "φαινόταν φυσιολογικό"). Ο behavioural rule του δεύτερου EDR ενεργοποιήθηκε αμέσως. Δύο ανεξάρτητοι vendors, δύο διαφορετικές αποφάσεις· χρειαζόμαστε μόνο μία να είναι σωστή.

Τι δεν λειτούργησε

Το email gateway του πελάτη. Το κακόβουλο doc δεν εντοπίστηκε από το εμπορικό email gateway τους. Η λογική macro ήταν αρκετά νέα ώστε το signature scanning να την παρακάμψει. Το doc μπορούσε τεχνικά να μπλοκαριστεί από macro-disable policy — αλλά ο πελάτης είχε νόμιμη ανάγκη για macros σε Excel από έναν συγκεκριμένο προμηθευτή, και είχε χαλαρώσει την policy domain-wide. Το διορθώσαμε με scoping της εξαίρεσης μόνο σε αυτόν τον προμηθευτή, μέσω document signature verification.

Η υπάρχουσα στρατηγική backup. Πριν τη Datatrek, ο πελάτης έτρεχε νυχτερινά snapshots σε NAS. Domain admin θα επέτρεπε διαγραφή. Αν δεν είχαμε πιάσει την παραβίαση εγκαίρως, η επόμενη κίνηση του επιτιθέμενου θα ήταν σχεδόν σίγουρα διαγραφή backups πριν την κρυπτογράφηση. Είχαν εγγραφεί στο Datatrek S3 Backup με Object Lock τρεις εβδομάδες νωρίτερα. Το lock θα κρατούσε ακόμα και με έγκυρα credentials.

Tier-1 outsourced helpdesk. Το tier-1 IT helpdesk του πελάτη ήταν outsourced στο εξωτερικό. Ο πρώτος χρήστης πραγματικά τους τηλεφώνησε στο T+0:14 επειδή το Word ήταν "αργό". Το tier-1 κατέγραψε ticket και πήγαν σπίτι. Η πρώτη επαφή με τη Datatrek ήταν στο T+0:53, μέσω της δικής μας ειδοποίησης SOC, όχι μέσω του πελάτη.

Τι προτείναμε

  1. Macro policy ανά πιστοποιητικό υπογραφής, όχι domain-wide allow.
  2. Μετάβαση workstations σε dual-EDR — τουλάχιστον για executives και οικονομικούς που χειρίζονται τιμολόγια.
  3. Block DCSync από οτιδήποτε-εκτός-DC στο firewall, όχι μόνο στο EDR layer.
  4. Διώξτε το outsourced tier-1. Η εξοικονόμηση κόστους εξαφανίστηκε κατά 80% από ένα 47-λεπτο παράθυρο μη παρακολουθούμενης παραβίασης.
  5. Προσθέστε NightWatch direct-line. Όταν κάτι μοιάζει περίεργο, η κλήση μας πρώτα είναι ταχύτερη από καταγραφή ticket.

Τι μάθαμε

Ο μεγαλύτερος προγνωστικός παράγοντας για ένα ελεγχόμενο vs καταστροφικό περιστατικό, στην εμπειρία μας, είναι η εύρος ανίχνευσης, όχι το βάθος. Ένα εξαιρετικό EDR είναι χειρότερο από δύο αρκετά καλά EDR διαφορετικών vendors. Ένας λαμπρός αναλυτής είναι χειρότερος από τρεις μηχανικούς σε βάρδια. Η NIS2 το λέει αυτό σε αφηρημένους όρους — "κατάλληλα τεχνικά μέτρα" — αλλά λειτουργικά σημαίνει: μην βάζετε την εταιρεία σας σε ένα μόνο προϊόν ή ένα μόνο ανθρώπινο μάτι.

Για αυτό κάθε υπηρεσία Datatrek είναι σχεδιασμένη ως στρώμα σε μια στάση, όχι ως αυτόνομο προϊόν. Αν πάρετε XEDR χωρίς XNDR ή χωρίς SIEM, έχετε ακόμα κάνει ουσιαστική βελτίωση — αλλά έχετε επίσης κρατήσει μέρος του single-point-of-failure ρίσκου που εκμεταλλεύτηκε αυτό το περιστατικό.

Ο πελάτης είναι καλά. Οι DCs ξαναχτίστηκαν το επόμενο σαββατοκύριακο από καθαρή παρανοϊκή λογική (δεν είχαμε ένδειξη persistence σε επίπεδο DC, αλλά το DC trust είναι δύσκολο να ξανακερδίσεις μετά από domain admin event). Τα backups ήταν άθικτα. Καμία διαρροή. Καμία ransom.

Αυτό δεν έγινε είδηση. Τα περισσότερα δεν γίνονται. Δημοσιεύουμε ανωνυμοποιημένα postmortems επειδή τα μαθήματα πρέπει να είναι δημόσια, ακόμα κι όταν τα ονόματα δεν μπορούν να είναι.

Μιλήστε με το SOC