Manipulate lsass.exe for fun and profit.

Bonjour à tous,
Alors déjà tout d'abord, un joyeux noël s'impose!
En espérant que le barbu vous a comblé :].
Revenons aux choses sérieuses.

C'est le fichier SAM qui va nous intérésser aujourd'hui.
Tout d'abord qui ne connais pas le fichier SAM?
C'est enfaite le fichier qui va contenir, les informations de sessions : les mots de pass y compris.
Il faut savoir que ce fichier est biensure, illisible, et inaccessible lorsque nous sommes sur notre session.
Il est en quelque sorte 'verrouillé' par le systeme.
Il existe donc deux alternatives pour nous :

- L'on boot sur une distribution linux par exemple, où l'on va copier le sam sur un périphérique de stockage.
- On utilise un outil comme pwdump.

Le fichier SAM contient les mots de pass encodé dans deux algorithme différent à savoir : LM hash et le NTLM hash.
Parlons à présent de lsass.exe.
C'est un processus natif de windows depuis Windows 2000 me semble t-il, lsass tout d'abord signifie "Local Security Authority Subsystem Service".
Autrement dit ce processus va permettre de gerer la connection aux sessions localement.
C'est en quelque sorte le serveur local d'authentification de windows.
Bon certains d'entres vous, pourraient se demander pourquoi on injecte dans lsass.exe et non dans un autre processus system?Comme svchost.exe.
J'ai moi même tenter d'injecter dans svchost.exe, mais sans réussite, je serais donc tenter de dire que les fonctions utilisées sont résérvées à lsass.exe ?
Je vous tiens au courant, lorsque j'en serais plus -> c'est qu'enfaite le service manipulant les users locaux est 'dirigé' par lsass.exe voir lien en bas de page.
Le mode opératoire est donc simple :

- Nous allons tout d'abord donner les droits de debugs à notre executable.
- Notre executable ira injecter une dll dans lsass.exe, c'est pour cela qui nous faut le debug privilege, afin d'injecter lsass.exe
- A présent à la dll de jouer !
- Elle va appeler successivement des apis exportés par samsrv.dll, qui seront ni plus ni moins des fonctions utilisés afin de 'rentrer' en contact avec le SAM.

Au final nous aurons 'manipuler' lsass.exe afin de pouvoir récupérer la liste des users, ainsi que leurs mot de pass hashés dans les deux algorythme cités plus haut.
Pour mener à bien ce projet, je me suis permis d'analyser les sources de pwdump un petit peu : ça permet de savoir un peu où l'on va.
Ce que je vous recommande aussi, c'est d'éviter de faire des tests sur votre propre système, car lsass.exe en cas de problème va vous faire redemarer.
Je vous conseille alors l'utilisation de machine virtuel, souvent abrégée 'vm' afin de pouvoir mener à bien vos tests !
Les quelques nostalgiques d'entre nous, se rappelleront du célèbre ver Sasser qui utilisait une faille présente dans le processus lsass.exe justement.
Enfin bref, je vous présente une petite vidéo réalisé par mes soins afin d'illustrer un peu cette article.
Elle montre que mon petit outil fonctionne à merveille :).
Voici le lien : s4mmy.wmv.

Je vous présente aussi un petit screenshot :



Et un autre :



Et enfin mon petit code :
- L'injecteur : s4mmy.c.
- La dll : sc0ubi.c.

Liens et outils utiles :

-Les sources du projet pwdump -> http://www.google.com/codesearch?hl=fr&q=show:XLfFm6CSy7k:uYtRtXzYO5g&sa=N&ct=rdp&cs_p=http://www.openwall.com/passwords/dl/pwdump/pwdump2.zip&cs_f=pwdump2
- Et notre fidèle LordPe, pour aller voir l'Export Address Section de samsrv.dll par exemple.
- Et biensure une machine virtuelle.
- LM Hash -> http://en.wikipedia.org/wiki/LM_hash.
- NTLM Hash -> http://en.wikipedia.org/wiki/NTLM.

Voilà pour cette article, en espérant que ça servira a certains cya.
scoubidoubidou !

PS : merci santa -> http://assiste.com.free.fr/p/services_windows/gestionnaire_de_comptes_de_securite.html

Ownz fucking PE ou Comment corrompre un binaire?

Bonjour à tous,
En ce début de vacance, j'en profite pour vous faire part d'un petit article plutôt sympathique je trouve.
Il portera sur la corruption du Portable Executable, abrégé PE.
J'ai décidé de faire un tel article, pour m'introduire au vxing, ou l'art de créer un virus.
Le but de cet article est non pas de pouvoir comprendre comment un virus se reproduit ou autres, mais de s'amuser avec le PE.
Ce bricolage est, je trouve extremement intérréssant dans le sens ou l'on va jouer au 'bob le bricoleur'.
Le code illustrant l'article est enfaite un petit binaire qui va infecter un PE.
Il va l'infecter en lui faisant éxecuter une messagebox toute simple.
Je vous expose donc la technique que j'ai utilisé :

- On mappe le fichier en mémoire pour avoir une plus grande aisance à modifier le PE.
- On va ajouter une entête de section (IMAGE_SECTION_HEADER).
- On va incrementer le membre spécifiant le nombre de section au sein du binaire.
- On incremente la SizeOfImage de la taille de notre section, autrement dit on lui ajoute la taille de notre section.
- On va aussi rediriger le point d'entré de l'éxécutable sur notre futur section.
- On démappe le fichier.
- On l'ouvre CreateFile, on utilise SetFilePointer pour se positionner au PointerToRawData (membre de la structure IMAGE_SECTION_HEADER).
- On écrit en dur notre section.
- On écrit aussi l'adresse du 'vrai' point d'entré.
- On remplit la différence entre la taille écrite et la taille spécifié dans le PE c'est à dire la taille aligné sur le fileAlignment.

Voilà comment nous allons opérer notre binaire.
J'ai oublié de préciser que notre section sera composée d'un shellcode essentiellement (codé par 0mega7 et modifié par Baboon).
J'ai donc ajouter un jmp à la fin de notre shellcode, c'est pour cela qu'après l'avoir écrit, nous écrivons l'adresse du vrai point d'entré : Pour sauter dessus !
Bon je suis tout à fait d'accord avec vous, c'est un peu laborieux mon histoire, mais en codant ce pseudo-infecteur on y apprend, plusieurs choses comme l'alignement des données.
J'entend déjà d'ici les gouroux vxers me huer, je leur répondrais que c'est une étape avant de coder mon propre petit vx, prochain article peut être :).
Pour réaliser un tel code il faut absolument avoir une documentation détaillé sur le portable executable, biensure, je vous fournis ça en fin d'article.
Je voulais aussi revenir sur l'alignement des données : c'est enfaite avoir une taille multiple d'une autre définit dans le pe, tout simplement pour une manipulation plus aisée.
N'oublier pas d'utiliser LordPE, un outil vraiment génial pour controler les actions menées sur le PE, vérifier le nombre de section et j'en passe.
C'est un peu tout ce que j'ai à dire pour ce petit code, voici :
un petit screenshot :



le code : OwnzFuckingPE.c

Liens : - LA documentation -> http://ivanlef0u.free.fr/repo/windoz/pe/Le_format_PE.pdf .
- Pour vous documenter un peu sur le vxing -> http://ebixad.next-touch.com/repo/Vxing/Vx%20guide/intro.html .

L'article est normalement terminé, mais je tenais à vous faire part d'un petit crackme avec un niveau vraiment simple.
Ce qui m'a intéréssé c'est de coder le keygen, car il fallait tout simplement aller lire dans la mémoire du processus.
Juste un petit code de quelques lignes histoire d'illustrer l'api ReadProcessMemory.
Un petit Screenshot :



Le petit code : KeygenDefiGutte1.c

Voilà bonne journée à vous, en esperant que cela vous à intéréssé, cya.

PS : N'oublier pas de changer les adresses qui sont dites, hardcodé dans le shellcode.

h0l0c4ust ou l'illustration d'une technique utilisée dans les rootkits ring3.

Bonsoir à tous,
Comme chaque semaine ,je vais vous exposer mon petit article et un petit code dans le but d'illustrer le tout.
Après ces plusieurs posts ,j'ai décidé de faire un petit truc plutôt intéréssant pour celui-ci.
En effet il met en action de l'injection de dll ,l'utilisation d'api native ,du hook ( en modifiant l'iat ).
Mon but a donc été de montrer un code pouvant être intégré dans un rootkit ring 3.
Celui-ci va cacher un dossier au processus cible.
Bon à présent je vous expose la technique :

- Tous d'abord ,nous allons injecter notre dll dans un processus. ( à l'aide d'un d'injecteur )
- Ensuite ,notre dll va allez corrompre l'iat de kernel32.dll ,afin de détourner l'api native ( exporté par ntdll.dll ) NtQueryDirectoryFile.
- Et enfin le plus complexe ,est de réaliser une fonction capable de cacher notre dossier.

Voilà donc le mode opératoire.
Normalement si vous avez suivis les précédents post ,vous n'aurez aucun problème à injecter la dll ,et corrompre l'iat de kernel32.dll.
Ce qui peut poser problème en revanche,c'est l'élaboration de la fonction qui va cacher notre dossier.
J'ai décidé de ne pas l'expliquer ,car c'est plutôt complexe à expliquer et je vous conseil de faire énormement de test ,de tattonner le tout.
Je vais par contre vous renvoyez vers de la documentation française sur le "Comment faire ?" de la chose ( en fin de page ).
Comme je parlais de rootkit userland ,ce code est loin d'en être un ,tout d'abord le code ne prend en aucun cas le contrôle de l'userland.
Il va s'injecter dans un seul processus donc ,cependant il serait facilement réalisable d'injecter tous les processus lancés au moment de l'éxécution de l'injection.
Mais un petit problème resterait le cas des nouveaux processus : eux ne seraient pas injecter par notre dll.
Enfin bref tout cela pour susciter votre curiosité à vous de jouer à présent.
Un petit screenshot ,injection du notepad.exe :



Et un second screen ,cette fois-ci plus intéréssant : explorer.exe :



Les codes : h0l0c4ust's injector.c
h0l0c4ust.c (dll)

Les documents : - http://ivanlef0u.free.fr/repo/windoz/hidingfr.txt -> article sur lequel j'ai basé l'élaboration de ma fonction.
- http://www.rit.edu/~jrk9185/rootkit/6-7/rootkit.c -> une source trouvée ,qui peut aider je pense.

Voilà en espérant que vous allez bien assimilez la technique.
Bonne fin de soirée à vous cya.

PS : désolé pour le retard du post ,je suis en pleine période d'examen blanc.
PS2 : j'ai finalement commenté le code de la dll un petit peu .

Ntdll ou la libraire cachée de windoz.

Bonsoir à tous ,
Je ne sais pas si vous avez déjà écouté le dernier live des dafts punks ,mais dans ce cas là : lancez la mule ;).
Après cette petite publicitée pour les dieux de l'électro ,je laisse place à mon modeste post de la semaine donc.
Cette-fois ci c'est ce qu'on appelle "l'api native" qui a attiré mon attention.
Je vais vous parler un peu de ce beau bordel.
Tout d'abord il faut savoir que l'on appelle api native ,soit les fonctions exportées par ntdll.dll donc.Celles-ci sont dîtes 'undocumented' ( une poignée de fonction d'écrite dans le DDK ).
Nous parlerons un peu plus tard de l'aspect coding ,ce qui va nous intéressé c'est un peu l'histoire de cette librairie un peu spécial ,je dirais.
Une petite anecdote raconterait qu'il y a quelques années ,nos amis windoziens pensaient justement ,que cette dll ,plutôt mystérieuse ,contenait des fonctions cachées.Cependant leurs craintes étaient loin d'être injustifiées ,car en effet windoz nous a caché pas mal de petites choses.
Deplus cette dll étant loadé par tous les processus ,cela attirait l'oeil ,dirais-je.

Après cette petite anecdote passons à l'aspect technique ,coding.
Je vous vois d'ici vous demander : - "Mais comment vas-t-on connaître leurs noms etc ..?".
Tout d'abord pour le nom des fonctions exportées par cette dll ,il suffirait d'allez s'engoufrer dans l'EAT ( Export Address Table cf Portable Executable ).
Nous disposons donc de l'information la plus simple à récupérer pour le moment ,leurs noms.
Ensuite plusieurs personnes ce sont décarcassés afin de produire un prototype de ces apis ( voir liens en bas de page ).
Maintenant à nous de jouer.
Après cette brève introduction au sujet ,je vais vous parler de l'exemple accompagnant l'article.Celui-ci va lister le nom des processus ,les treads identifier ( TID ) des threads associés aux processus.
Un code tout à fait basique donc ,qui pouvait être réalisé avec un CreateToolhelp32Snapshot().
Je vais commenter un petit peu le code ,car celui-ci est peut être un peu velu au première abord.
Tout d'abord la technique pour appeler les fonctions :

- Nous définissons un pointeur de fonction nous permettant d'appeler notre fonction un peu plus tard.
- Vue qu'aucun header à définit ces fonctions nous sommes obligés de trouver son adresse grâce à deux apis : GetModuleHandle() et GetProcAddress().
- Nous assignons donc cette adresse au pointeur de fonction ,notre fonction est prête à étre utilisée.

Une fois cela compris ,vous avez tout compris car le reste n'est que de la manipulation de structures , de pointeurs de structures etc..
On google un peu pour connaitre les structures associées ,les constantes utiles etc.
Je vous donne un petit screenshot du code en action :



Ensuite pour bien vérifier la véracitée des informations renvoyées ,nous codons un petit programme faisant appel à l'api GetCurrentThreadId().



Place aux petits codes à présent :
DumpFuckingProcAndTID.
ThreadID.

Voilà voilà ,vous devez être capable à présent avec un minimum de documentation d'utiliser les apis natives.

Liens :
- ftp://ftp-developpez.com/windows/cours/api-native.pdf -> Petit article sympa traitant des apis natives
- http://ivanlef0u.free.fr/repo/windoz/Ntdll_EAT.txt -> Export Address Table de la librairie.

- NtQuerySystemInformation Function (Windows)

PS : J'ai déclaré entièrement les structures dans la source afin de pouvoir vous amusez avec ,si vous en avez envie ;).

Cya.