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.

SetWindowsHookEx() ou le hook 'facile' :).

Bonsoir à tous ,
je profite de ce petit week-end pour vous faire partager ma 'release' de la semaine .
Après mon post sur les hooks , je voulais continuer dans cette voie-ci
et donc m'intérésser à la fonction SetWindowsHookEx().D'après ce que l'on a put me raconter la fonction va hooker elle-même certaines apis au niveau du kernel ,cela permettant donc d'analyser les messages envoyés par les différentes applications.
Le but est donc de pouvoir 'capter' toutes les informations liées à la souris et au clavier dans mon petit post .Comme précédemment , nous allons choisis la technique par dll ,on appelle ça un hook système.Notre technique sera donc la suivante :

-Nous allons coder un programme se chargeant d'appeler les fonctions de notre dll.
-Notre programme va donc appeller ces fonctions , les fonctions de filtres vont donc rentrer en actions.

Pour le code ,j'ai opté pour l'utilisation de variable globale ,permettant de retrouver le handle du hook ou celui du fichier de log ,dans tous le programme par exemple.
Je tiens à préciser aussi que les adresses des fonctions contenus dans les dlls auraient put être retrouvées en chainant plusieurs apis ,seulement j'ai choisis de linker le .a de ma dll pour compiler le programme 'principale'.
La source présente donc une utilisation de la fonction SetWindowsHookEx pour deux types de messages ,à savoir les messages liés à la souris et aux claviers.
Lorsque le pointeur de la souris sera dans le coin inférieur droit ,où dans le coin supérieur gauche le programme enverra un OutputDebugString().
De plus le programme se chargera de logger toutes les touches du clavier ,biensûre .
Et puis je vois déjà tous me pointer du doigt : -"Henn , il ouvre et ferme le fichier à chaque écriture!" et bien oui j'ai choisis d'opérer ainsi car cela me permettait de pouvoir ouvrir le fichier log pendant que le prog tourner par exemple.
Je voulais aussi préciser que ce projet est un petit échec ,je me rend compte que lorsque qu'on 'bourrine' le clavier on aperçoit des inversions de lettres..un problème auquel je n'ai trouvé aucune solution donc si des personnes ont reussis merci de prendre contact avec moi merci.
Donc je vous expose cette petit saloperie de code :
-FuckingKeylogger.
-La dll contenant les hooks.

Un petit screenshot :) :




cya.
PS : si quelqu'un aurait une façon valable pour gérer le problèmes des deads keys aussi...

Quelques liens sympa :
- http://vbman.free.fr/articles/hacking/KEYLOG.htm
- http://tcharles.developpez.com/simul/

API Hooking - IAT patching

Bonjour à tous ,
Aujourd'hui je vais essayer de vous présenter l'api hooking via l'iat patching.
En effet notre but lors de ce petit billet sera de détourner l'appel d'apis.
J'illustrerais avec un petit exemple de hooking sur le notepad.exe , cependant vous pourriez , après avoir compris le principe , laisser cours à votre imagination afin de creer de multiples attaques.
Cette démonstration de hook sera réalisé dans l'userland (ring3).

Tout d'abord je vais vous exposer ma façon d'opérer :
- Nous allons coder un programme chargé d'injecter notre dll dans le processus cible ( voir billet sur l'injection ).
- Ensuite nous allons coder une dll qui ira modifier directement l'iat du processus cible ( voir billet sur le dump de l'iat ).

Voilà donc les grandes étapes :
- On retrouve le pid de notre processus.
- Nous ouvrons notre processus afin d'avoir un handle sur celui-ci , avec l'api OpenProcess.
- On alloue de la mémoire dans le processus cible , on y écrira le full path de notre dll.
- Nous créons un thread dans le processus sur l'adresse de LoadLibraryA ( exporté par kernel32.dll ) avec comme arguement le path de la dll donc .
- A présent notre dll est loadé par l'application cible.
- Notre dll dès son chargement va aller modifier l'adresse de la fonction à hooker par l'adresse de notre fonction dans l'iat.

L'application à chaque appel de l'api hooké appelera enfaite notre fonction , c'est pour cela qu'elle doit posséder le même prototype que la fonction hooké.
Je tiens aussi à préciser , que la modification de l'iat ne peut se faire qu'après un appel à l'api VirtualProtect.Et ce pour changer l'acces à la zone mémoire , après la modification
nous rétablissons l'accès originel de la zone mémoire.

Voici donc les illustrations :
Tout d'abord l'injecteur : InjecteurDll.
La dll pour hooker le ShellAbout de notepad.exe : HookShellAboutW.dll.
Un petit screenshot pour les plus fainéants :




Puis pour terminé j'ai voulu faire un exemple un peu plus concret mais qui reste très simple.
Imaginons le code d'une petite application permettant de lister les fichiers et dossiers dans le current directory.
Notre but serait de cacher un fichier .
Voici les codes : - HookFindNextFirstFile.dll.
- cible.exe.

Et un petit screnshot :



J'essairais plus tard de coder un petit rootkit userland prenant le contrôle de l'userland par le biais de hook justement.
Sur ce bonne fin de journée , cya.

Dump Own iat.

Après avoir coder le viewer de pe , je me trouvais plutôt frustré de ne pas avoir bien saisis l'iat , chose résolu je vous file le code permettant de dumper les adresses et noms des fonctions exportées par les dlls.
DumpFuckingIat.

Par contre j'ai pas compris desuite le fonctionnement j'avoue avoir fais pas mal de test et lu plusieurs tutoriaux :) .
Doc pour éclaircir :

• l'excellent tuto d'izcelion : http://ivanlef0u.free.fr/repo/windoz/pe/_pe-tuts/_pe-tut6.html
• un autres paper : http://ivanlef0u.free.fr/repo/windoz/pe/Le_format_PE.pdf

Voilà cya.

Process env block.

Cette fois-ci c'est le peb qui attire mon attention , j'ai donc coder un petit programme qui se ballade dans les structs liées au peb afin d'aller dumper le nom des dlls loadées par le programme.
Je signale que je n'ai pas reussi à compilé ce code avec Code::Blocks , je l'ai compilé directement avec gcc ( 3.4.2 ).Je me suis aussi permis de 'troncater' les structs vu que le membre qui m'interessait ce trouver au début de celle-ci .
Processenvblock.


Pour la compréhension du code :

• les structs : struct.

voilà cya.

Unload de dll.

Après avoir coder l'injecteur de dll , je me suis intérogé sur le "Comment décharger une dll d'un processus ?". Pour la technique , rien de compliqué , nous allons creer un remote thread sur FreeLibrary cette fois .La seule petite difficulté (oupa) c'est de trouver le handle de la dll dans le processus cible biensûre , nous y allons donc à grand coup de CreateToolhelp32Snapshot et on voilà.
Unload fucking dll.

Cya.

Injection de code / dll.

Pour ce billet je vais vous présenté la fameuse injection de code et de dll.
Le principe est plutôt simple , en effet nous allons alouer de la mémoire dans le processus cible ou nous allons écrire par exemple notre full path vers notre dll , nous créons ensuite un remote thread sur directement sur le shellcode ou encore sur LoadLibraryA exporté par kernel32.dll. Résultat nous avons notre dll qui va se charger en mémoire , ou l'éxécution direct de notre shellcode.
Je vous présente le code de l'injecteur ainsi que d'une dll d'exemple :
Inject Dll into fucking process.
Dll de démonstration.


Pour ce code vous pourrez trouver de multiples articles expliquant 'pas à pas' la technique.
Je vous recommande comme toujours la msdn pour l'utilisation des apis.
Cya.

Process.

C'est maintenant les processus et leurs 'gestions' qui m'interesse .Je vous fais alors pars d'un petit code que j'ai réalisé dans le but de me familiariser avec ceux-ci , il permet de killer les processus et d'en faire la liste .
Le code est assez simple , je me passerais donc d'explications.

ProcessViewer.

Pour la compréhension du code , je vous conseil vivement la msdn qui est vraiment excellente pour l'utilisation des apis .
Cya.

View fucking pe.

Comme vous le savez peut-être , le portable executable ou PE est un format de fichier utilisé pour les éxécutables windows ou encore les dlls.
Je me suis donc intéréssé à celui-ci , voici un code plutôt simple permettant la lecture de quelques informations le concernant ( ce viewer de pe est loin d'être complet , je pense à l'import table qui n'a pas été exploré dans ce code ).
Je tiens aussi à précisé que dans ce genre de code l'utilisation des casts est très importantes , étant donné que l'on a affaire à "des adresses virtuelles relatives" (RVA) et que nous devons additionner celles-ci à des membres des structures utilisées pour le PE.
ViewFuckingPe.

Je vous file un peu de doc qui m'a pas mal servis :

• les structures : http://ivanlef0u.free.fr/repo/windoz/pe/pe.txt
• le format pe : http://ivanlef0u.free.fr/repo/windoz/pe/_pe-tuts/_index.html
• pis un tool du genre LordPe pour verifier toussa

cya.

Ouverture.

Bonsoir ,
Voilà le premier billet de ce modeste blog , j'ai enfin décidé d'en ouvrir un afin de faire partager mes quelques recherches et codes sur le thème de la sécurité informatique.
Je voudrais remercier tout particulièrement les personnes avec lesquelles j'évolue au quotidien que ce soit sur le net ( #carib0u@irc.worldnet.net && #nibbles@irc.worldnet.net ) ou dans ma petite vie.
En espérant que vous passerez une agréable visite.