English  ·  Ελληνικά

Αναγνώριση

Μια πλήρης σάρωση TCP δείχνει την τυπική επιφάνεια domain-controller — το box ανακοινώνει τον εαυτό του ως DC01 στο checkpoint.htb, Windows Server 2025 (build 26100).

Το box σου δίνει ένα αρχικό credential: alex.turner : Checkpoint2024!. Κάνει authenticate, οπότε πάμε κατευθείαν σε καταμέτρηση αντικειμένων.

Αρχική Πρόσβαση — Αναζωογόνηση Tombstone

Όταν ένα αντικείμενο AD διαγράφεται δεν εξαφανίζεται αμέσως — γίνεται ένα tombstone: γυμνωμένο από τα περισσότερα attributes και μετακινημένο στο CN=Deleted Objects, όπου παραμένει για τη διάρκεια ζωής tombstone (180 μέρες by default) πριν το garbage collector το θερίσει. Αν μπορείς να γράψεις σε ένα tombstone, μπορείς να καθαρίσεις τη σημαία isDeleted του και να ορίσεις νέο distinguishedName — επαναφέροντάς το, attributes και όλα. Το get writable του bloodyAD δείχνει ότι ο alex.turner έχει ακριβώς εκείνο το δικαίωμα:

Να το tombstone: ένας διαγραμμένος Mark Davies που μπορούμε να γράψουμε. Επανάφερέ τον σε μία κλήση:

Ένας επαναφερμένος λογαριασμός κρατά το παλιό του password. Ο Mark μοιραζόταν το default του domain, και μπορεί να δει ένα ακόμα share από όσα μπορούσε ο alex:

Foothold — Κακόβουλο Extension VS Code

Το ίδιο το remark του share DevDrop λέει την ιστορία: είναι ένας φάκελος drop για "εγκεκριμένα" extensions VS Code, engine 1.118.0. Κάτι στο box εγκαθιστά πακέτα .vsix που αφήνονται εδώ. Ένα extension VS Code είναι απλά ένα zip με ένα manifest και ένα entry point JavaScript, και το entry point τρέχει αυθαίρετο Node στο activation — οπότε ένα κακόβουλο extension είναι τετριμμένο RCE ενάντια σε όποιον το φορτώνει.

Το πακέτο είναι τέσσερα αρχεία: [Content_Types].xml, extension.vsixmanifest, και ένας φάκελος extension/ με package.json + extension.js. Το manifest δηλώνει το ταιριαστό engine· το package.json κάνει activate στο startup και δείχνει στον κώδικά μας· το extension.js γεννά ένα reverse shell:

Κάν' το zip σε ένα .vsix, ξεκίνα έναν listener, και ρίξ' το στο share με την πρόσβαση εγγραφής του mark.davies:

Ένα λεπτό αργότερα ο editor του προσομοιωμένου operator φορτώνει το extension και καλεί πίσω — σαν ryan.brooks, στο ίδιο το DC01:

Privilege Escalation — BadSuccessor (κατάχρηση dMSA)

Το BadSuccessor είναι μια τεχνική Server-2025 του 2025 (του Yuval Gordon της Akamai) που κάνει κατάχρηση delegated Managed Service Accounts. Τα dMSAs προορίζονταν να αντικαταστήσουν legacy service accounts: συνδέεις ένα νέο dMSA με τον προκάτοχό του μέσω msDS-ManagedAccountPrecededByLink, σημαίνεις τη μετάβαση ολοκληρωμένη, και το KDC αφήνει το dMSA να κάνει authenticate με τα κλειδιά του προκατόχου ώστε τίποτα να μη σπάσει κατά τη μετάβαση. Η παγίδα: αν μπορείς να δημιουργήσεις ένα dMSA σε ένα OU που ελέγχεις, μπορείς να δείξεις εκείνο το link σε οποιονδήποτε λογαριασμό και το KDC θα σου δώσει τα κλειδιά του. Το module του netexec επιβεβαιώνει ότι ο ryan.brooks είναι έγκυρος principal για αυτό:

Αποκτώντας ένα ticket χωρίς password

Το badSuccessor του bloodyAD χρειάζεται να κάνει authenticate σαν ryan.brooks — αλλά έχουμε μόνο ένα shell, όχι το password ή το hash του. Το Rubeus tgtdeleg το λύνει αυτό: κάνει κατάχρηση του Kerberos GSS-API delegation ώστε να κάνει το τοπικό session να παραδώσει ένα χρησιμοποιήσιμο TGT για τον τρέχοντα χρήστη, χωρίς να απαιτούνται secrets. Φιλοξενούμε το Rubeus μέσω HTTP, το τραβάμε μέσα στο shell, και το τρέχουμε:

Μετέτρεψε το kirbi σε ένα ccache που το impacket/bloodyAD μπορούν να χρησιμοποιήσουν:

Πλαστογραφώντας τον διάδοχο

Ο ryan μπορεί να γράψει μέσα στο OU=DMSAHolder, και προηγούμενη καταμέτρηση (bloodyAD get writable --right WRITE) έδειξε ότι έχει επίσης WRITE πάνω στο CN=svc_deploy — τον στόχο. Δημιούργησε το κακόβουλο dMSA συνδεδεμένο σαν διάδοχος του svc_deploy:

Το KDC επέστρεψε τα κλειδιά του svc_deploy. Εκείνο το κλειδί RC4 είναι το hash NT του svc_deploy — που σημαίνει ότι μπορώ να αφήσω το Kerberos και απλά να κάνω pass-the-hash μέσω NTLM, αποφεύγοντας εντελώς το πρόβλημα clock-skew. Ο svc_deploy μπορεί να διαβάσει το VMBackups:

Λάφυρα & Root — Credentials από ένα Memory Snapshot

Το VMBackups κρατά ένα νυχτερινό backup VMware ενός VM Windows Server 2019. Το ενδιαφέρον αρχείο είναι το .vmem — ένα memory snapshot VMware, δηλαδή ολόκληρη η RAM του guest τη στιγμή του snapshot, 2 GB από αυτήν:

Η RAM περιέχει τα registry hives όσο ένα μηχάνημα τρέχει. Το volatility3 τα σκαλίζει κατευθείαν από το image — SAM, SYSTEM και SECURITY είναι όλα όσα χρειαζόμαστε για να ανακατασκευάσουμε τα τοπικά secrets:

Με τα τρία hives στον δίσκο, το offline secretsdump χρησιμοποιεί το bootKey του SYSTEM για να κάνει decrypt το SAM και να τυπώσει τα τοπικά hashes λογαριασμών:

Το τοπικό password Administrator του server που έγινε backup επαναχρησιμοποιήθηκε για τον domain Administrator. Pass-the-hash κατευθείαν στον ζωντανό DC:

Γιατί Δούλεψε

Βασικές εντολές