Archives par mot-clé : lsass

mimikatz @ sekurlsa : Credman et le planificateur de tâches

Publié le par
Répondre

Vendredi soir, mgrzeg (http://zine.net.pl/blogs/mgrzeg/) m’a posé une petite colle sur les mots de passe associés à des tâches planifiées :

22:27 – Michal: Have you ever tried to recover passwords for scheduler tasks?

Et bien non ! Je pensais naïvement que beaucoup d’outils permettaient déjà de récupérer les mots de passe de tâches planifiées… mais, à part une version historique pour NT5 d’Ivan (http://www.ivanlef0u.tuxfamily.org/?p=173), rien de bien précis dans le paysage des outils pour les versions actuelles de Windows…

penguins_ho

Recherches

Créons une petite « Tâche de test » associée au compte de « Gentille Tâche »
gentilletache

> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Tâche de test"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Tâche de test
    Id    REG_SZ    {B0261D58-1302-40C8-A547-3AFD8F76BB4C}
    Index    REG_DWORD    0x3

> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{B0261D58-1302-40C8-A547-3AFD8F76BB4C}"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{B0261D58-1302-40C8-A547-3AFD8F76BB4C}
    Path    REG_SZ    \Tâche de test
    Hash    REG_BINARY    913E7022936A887F6CA5DD1C5BCAF21BCB7B8A120FA1551CCB19DBC7EC10D93D
    Triggers    REG_BINARY    150000000000000000F3A401A4F76772FFFFFFFFFFFFFFFF00F3A401A4F7677200000000000000002821440048484848EA0DE31E484848480048484848484848004848484848484801000000484848481C000000484848480105000000000005150000003C07DD79702A63251C051BB6E903000048484848360000004848484876006D002D00770037002D0075006C0074005C00470065006E00740069006C006C00650020005400E2006300680065000000000000004848380000004848484800000000FFFFFFFF80F40300FFFFFFFF0700000000000000000000000000000000000000000000000000000018A20F010000000000000000

Vous l’aurez sans aucun doute reconnue :

vm-w7-ult      | 76 00 6D 00 2D 00 77 00 37 00 2D 00 75 00 6C 00 74 00
\              | 5C 00
Gentille Tâche | 47 00 65 00 6E 00 74 00 69 00 6C 00 6C 00 65 00 20 00 54 00 E2 00 63 00 68 00 65 00
<NULL>         | 00 00 
<NULL><NULL>   | 00 00 00 00

Cela tombe bien, il y a une référence à son SID (S-1-5-21-2044528444-627255920-3055224092-1001) pas très loin :

> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\CredWom\S-1-5-21-2044528444-627255920-3055224092-1001"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\CredWom\S-1-5-21-2044528444-627255920-3055224092-1001
    Count    REG_DWORD    0x1
    Index    REG_SZ    {55DEDD5A-70DE-49AC-98C2-9D86B9A437FA}

Point de mot de passe… mais un GUID très utile…, le planificateur de tâche va appeler :
CredMarshalCredential avec :

  • CredType : UsernameTargetCredential
  • Credential : TaskScheduler:Task:{55DEDD5A-70DE-49AC-98C2-9D86B9A437FA}

… et se servir du résultat pour appeler LogonUser puis CreateProcessAsUser.

Explications

UsernameTargetCredential

Specifies that the credential is a reference to a CRED_FLAGS_USERNAME_TARGET credential described by a USERNAME_TARGET_CREDENTIAL_INFO structure.

Il s’avère donc que les comptes associés aux tâches planifiées sont enregistrés dans le « Gestionnaire d’identification » de SYSTEM.
Cohérent, puisque le planificateur de tâches fonctionne en tant que service local, même si la session de l’utilisateur ayant créé la tâche, ou ciblée par la tâche, est fermée.

Test

Qu’à cela ne tienne, mimikatz permet de dumper les différents éléments du gestionnaire d’identification de NT6 via : divers::secrets full

En ayant obtenu un mimikatz « SYSTEM » :

mimikatz # divers::secrets full
Nombre de secrets : 1
TargetName         : Domain:batch=TaskScheduler:Task:{55DEDD5A-70DE-49AC-98C2-9D86B9A437FA} / <NULL>
Type               : DOMAIN_PASSWORD (2)
Comment            : <NULL>
UserName           : vm-w7-ult\Gentille Tâche
Credential         : <NULL>

Damn, pas de mot de passe ici :(

mario_princess-in-another-castle

If the Type member is CRED_TYPE_DOMAIN_PASSWORD, this member contains the plaintext Unicode password for UserName. The CredentialBlob and CredentialBlobSize members do not include a trailing zero character. Also, for CRED_TYPE_DOMAIN_PASSWORD, this member can only be read by the authentication packages.

La solution sera donc plus générale que pour les mots de passe de tâches planifiées…, en effet la catégorie CRED_TYPE_DOMAIN_PASSWORD englobe aussi les credentials pré-enregistrés de lecteurs , de partages ou RDP…

A voir dans un prochain post ;)

Bonus

Dans le contexte de l’utilisateur ayant créé la tâche planifiée (et donc inacessible à SYSTEM si session fermée…) :

mimikatz # divers::secrets full
Nombre de secrets : 1
TargetName         : LegacyGeneric:target=VM-W7-ULT\Gentille Tâche / <NULL>
Type               : GENERIC (1)
Comment            : <NULL>
UserName           : VM-W7-ULT\Gentille Tâche
Credential         : wazawaza12341234//

Mais là, je ne vois pas la raison de sa présence… c’est le moteur du planificateur de tâche qui a besoin des credentials, pas l’utilisateur d’origine… (?)

mimikatz :: sekurlsa – récupération des clés depuis LSASS

Publié le par
Répondre

Je l’avais pourtant suggéré lors de mon passage aux PHDays 2012 ; pour dumper les hashes et mot de passe, il suffirait d’aller lire les clés de (dé)chiffrement de LSASS pour éviter d’y injecter la librairie sekurlsa.

sekurlsa_idea
Personne ne l’a fait :(

même pas wce qui, en plus de copier certains patterns / concepts de mimikatz, injecte sournoisement la librairie wceaux.dll pour dumper les mots de passes via WDigest, parfois à l’aide d’un service…

Approche

Le déchiffrement des mots de passe est effectué directement par :
LsaUnprotectMemory – http://msdn.microsoft.com/library/windows/desktop/ff714510.aspx

Le chiffrement des mots de passe est quant à lui effectué par :
LsaProtectMemory – http://msdn.microsoft.com/library/windows/desktop/ff714509.aspx

Ces deux fonctions reposent sur : LsaEncryptMemory

Windows NT 5

  • Algorithme : RC4
    Clé : dérivée depuis g_pRandomKey, de longueur g_cbRandomKey (256)
  • Algorithme : DES
    Clé : g_pDESXKey, de longueur 144
    IV : g_Feedback, de longueur 8

Méthodologie

  1. Charger lsasrv.dll dans mimikatz
  2. Copier les 8 octets de LSASS:lsasrv!g_Feedback vers mimikatz:lsasrv!g_Feedback
  3. Copier les 4 octets (DWORD) de LSASS:lsasrv!g_cbRandomKey vers mimikatz:lsasrv!g_cbRandomKey
  4. Instancier un nouveau tableau de taille mimikatz:lsasrv!g_cbRandomKey octets
  5. Placer l’adresse de ce tableau dans mimikatz:lsasrv!g_pRandomKey
  6. Copier les mimikatz:lsasrv!g_cbRandomKey octets ciblés par LSASS:lsasrv!g_pRandomKey vers le tableau ciblé par mimikatz:lsasrv!g_pRandomKey
  7. Instancier un nouveau tableau de taille 144 octets
  8. Placer l’adresse de ce tableau dans mimikatz:lsasrv!g_pDESXKey
  9. Copier les 144 octets ciblés par LSASS:lsasrv!g_pDESXKey vers le tableau ciblé par mimikatz:lsasrv!g_pDESXKey

Windows NT 6

  • Algorithme : 3DES
    Clé : référencée par le handle h3DesKey
    IV : InitializationVector, de longueur 8 (sur 16)
  • Algorithme : AES
    Clé : référencée par le handle hAesKey
    IV : InitializationVector, de longueur 16

Méthodologie

  1. Charger lsasrv.dll dans mimikatz
  2. Copier les 16 octets de LSASS:lsasrv!InitializationVector vers mimikatz:lsasrv!InitializationVector
  3. Appeler la fonction mimikatz:lsasrv!LsaInitializeProtectedMemory pour initialiser correctement les handles de clés h3DesKey et hAesKey
    Ces handles pointent vers des structures de ce types :

    typedef struct _KIWI_BCRYPT_KEY {
	DWORD size;
	DWORD type;
	PVOID unk0;
	PKIWI_BCRYPT_KEY_DATA cle;
	PVOID unk1;
} KIWI_BCRYPT_KEY, *PKIWI_BCRYPT_KEY;

    avec

    typedef struct _KIWI_BCRYPT_KEY_DATA {
	DWORD size;
	DWORD tag;
	DWORD type;
	DWORD unk0;
	DWORD unk1;
	DWORD unk2;
	DWORD unk3;
	PVOID unk4;
	BYTE data; /* etc... */
} KIWI_BCRYPT_KEY_DATA, *PKIWI_BCRYPT_KEY_DATA;
  4. Copier les LSASS:lsasrv!h3DesKey->KIWI_BCRYPT_KEY->KIWI_BCRYPT_KEY_DATA.size octets de LSASS:lsasrv!h3DesKey->KIWI_BCRYPT_KEY->KIWI_BCRYPT_KEY_DATA vers mimikatz:lsasrv!h3DesKey->KIWI_BCRYPT_KEY->KIWI_BCRYPT_KEY_DATA
  5. Copier les (LSASS:lsasrv!hAesKey->KIWI_BCRYPT_KEY->KIWI_BCRYPT_KEY_DATA.size - 2*sizeof(PVOID)) octets* de LSASS:lsasrv!hAesKey->KIWI_BCRYPT_KEY->KIWI_BCRYPT_KEY_DATA vers mimikatz:lsasrv!hAesKey->KIWI_BCRYPT_KEY->KIWI_BCRYPT_KEY_DATA

*il y a deux pointeurs internes à la fin de la structure AES, l’initialisation de départ fait qu’ils sont déjà corrects :)

Une fois ces opérations réalisées, la fonction LsaEncryptMemory fonctionne correctement ! Nous permettant ainsi de bénéficier du même déchiffrement que LSASS dans mimikatz…

mimikatz et sekurlsa sans injection ?

soon

mimikatz @ sekurlsa – une librairie à injecter

Publié le par
Répondre

La librairie sekurlsa permet, entre autre, de dumper des données de sécurité du processus LSASS (Local Security Authority Subsystem Service).
Très efficace, cela n’en reste pas moins un frein pour certain car elle doit être injectée dans le processus LSASS.

sekurlsa_extract

L’injection

  1. Ouverture du processus cible en écriture, avec possibilité de créer des threads
    • OpenProcess
  2. Allocation de mémoire, dans le processus cible, pour la routine de chargement
    • VirtualAllocEx
  3. Écriture, dans la mémoire allouée, du nom de la librairie à charger
    • WriteProcessMemory
  4. Création d’un thread dans le processus distant, commençant sur l’instruction LoadLibrary, avec comme argument l’adresse de notre mémoire allouée.
    • CreateRemoteThread, NtCreateThreadEx, ZwCreateThread, RtlCreateUserThread, NtQueueApcThread, …

    Ceci a pour effet de charger la librairie voulue dans le processus distant, et d’effectuer :

    • Un appel à la routine DllMain
    • Fortement conseillé : La création d’un thread avec le code nécessaire au fonctionnement de la libraire, se terminant par FreeLibraryAndExitThread
  5. Attente de la fin de l’opération de chargement (fin du thread initialement créé)
    • WaitForSingleObject
  6. Libération de la mémoire allouée
    • VirtualFreeEx

Avantages de cette méthode :

good_inject

  • S’exécute avec les droits du processus cible (pour LSASS : SYSTEM)
  • Bénéficie de toutes les données du processus cible de manière transparente
  • Les opérations effectuées dans le processus cible paraissent légitimes
  • Méthodes relativement bien connues et maitrisées

Inconvénients :

bad_inject

  • Écritures dans le processus cible
  • Modifications du contexte d’exécution du processus cible
  • Des opérations incorrectes dans la librairie peuvent entrainer un crash du processus cible
  • Les droits du processus cible peuvent être insuffisants pour accéder à des données externes (librairie sur un partage réseau par exemple)
  • Fonctionne difficilement en RDP sans proxy via un service (isolation de sessions)
  • Méthodes très connues par les antivirus et HIPS (une intrusion aussi affichée dans LSASS est quand même très louche !)

Alors pourquoi injecter ?

Beaucoup d’inconvénients…, pourquoi mimikatz doit-il donc injecter sekurlsa pour dumper les hashes et mots de passe ?

  • La facilité : toutes les structures utilisées contiennent des pointeurs et données qui ne sont valides que dans le processus LSASS, les utilisations de ces structures sont donc transparentes
  • La recherche d’éléments par LUID : les données utilisateurs sont placées dans des structures de type :
    • LIST_ENTRY ; nécessitant un parcours par pointeurs
    • RTL_AVL_TABLE ; nécessitant l’utilisation de RtlLookupElementGenericTableAvl
  • Le déchiffrement : les hashes et mots de passe ne sont pas en clair, ils sont déchiffrés par LsaUnprotectMemory, qui utilise des clés et méthodes du processus LSASS

Comment ne plus injecter ?

Il suffirait de résoudre les 3 points évoqués…

  • La difficulté : toutes données nécessaires seront lues du processus LSASS par ReadProcessMemory, donnant lieu à des proxys d’utilisation des structures UNICODE_STRING, KIWI_GENERIC_PRIMARY_CREDENTIAL, …
  • La recherche d’éléments par LUID : les données utilisateurs étant placées dans des structures de type :
    • LIST_ENTRY ; utilisera un proxy de parcours de listes, via ReadProcessMemory
    • RTL_AVL_TABLE ; utilisera un proxy de parcours d’arbres, via ReadProcessMemory
  • Le déchiffrement : il suffit d’aller récupérer les clés depuis LSASS pour les utiliser dans mimikatz

Récupération des clés

soon
Bientôt dans un post dédié…