Task Scheduler credentials dumper

juillet 25th, 2008 at 03:56 admin

Maître newsoft à un problème, parfois durant ses pentests de Windows (qu’il réussit toujours, bien évidemment) il voit que l’admin a programmé des taches planifiées, il sait grâce à son immense sagesse que le task manager de Windows a demandé à l’admin son login/pass pour pouvoir lancer la tâche. Donc en toute logique maître newsoft se demande ou sont stocké les credentials de l’admin par le système et surtout si il est possible de les récupérer, le pire c’est qu’il ne connaît aucun tool qui fait cela pour le moment. Il faut dire que dumper la base SAM avec pwdump puis péter les hash NTLM avec John c’est long et chiant, ça serait donc bien d’avoir une technique plus smooth pour obtenir les credentials. C’est à ce moment que moi, simple padawan, intervient, mon but ? Regarder comment fonctionne le Task Manager sous Windows et comprendre comment sont stockés les credentials des tâches planifiées.

C’est partit, première étage, jouer avec l’application et observer son comportement, direction le Panneau de configuration, icône « Tâches planifiées », une GUI se lance qui me demande le nom de la tâche, quelle appli je veux planifiée, à quelle date puis me demande mon login/pass. En parallèle je surveille avec Process Explorer le processus explorer.exe, la Dll mstask.dll (Fichier DLL d’interface du Planificateur de tâches) a été chargée dans explorer.dll. Un coup de IDA suffit à comprendre que c’est juste une Dll qui utilise des RPC pour communiquer avec le provider du Task Scheduler, reste plus qu’a trouver avec quels RPC elle communique.

Pour cela, on peut regarder le paramètre EndPoint passé à la fonction RpcStringBindingCompose car c’est lui qui contient le nom pipe ou du port RPC sur lequel vont se faire les requêtes. Dans mstask.dll on retrouve la string «  »\PIPE\atsvc », un coup de Process Explorer nous indique que ce pique appartient à un processus svchost, il nous manque cependant le nom de la Dll qui crée le serveur RPC. En regardant les descriptions des Dll on peut voir pour schedsvc.dll « Moteur du Planificateur de tâches », un coup d’oeil dans les strings de la Dll (toujours avec Process Explorer) et on retrouve notre « \PIPE\atsvc », ok c’est celle la !

On va utiliser un plugin très pratique pour IDA de Tenable Network Security, Mida pour obtenir l’ensemble des interfaces RPC crée par schedsvc.dll à travers leurs structures MIDL :

---------------------------------------------------
mIDA Plugin v1.0.8
Copyright (C) 2006, Tenable Network Security
---------------------------------------------------

Scanning database for MIDL structures ...
Found MIDL structure at address 0x76B12D48 : 378e52b0-c0a9-11cf-822d-00aa0051e40f v1.0
Opcode : 0x00 , address : 0x76B24F60, name : _SASetAccountInformation
Opcode : 0x01 , address : 0x76B23905, name : _SASetNSAccountInformation
Opcode : 0x02 , address : 0x76B23C32, name : _SAGetNSAccountInformation
Opcode : 0x03 , address : 0x76B24DAF, name : _SAGetAccountInformation
Found MIDL structure at address 0x76B12F90 : 1ff70682-0a51-30e8-076d-740be8cee98b v1.0
Opcode : 0x00 , address : 0x76B262A0, name : _NetrJobAdd
Opcode : 0x01 , address : 0x76B269FD, name : _NetrJobDel
Opcode : 0x02 , address : 0x76B26502, name : _NetrJobEnum
Opcode : 0x03 , address : 0x76B26B0F, name : _NetrJobGetInfo
Found MIDL structure at address 0x76B136C0 : 0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53 v1.0
Opcode : 0x00 , address : 0x76B33493, name : _ItSrvRegisterIdleTask
Opcode : 0x01 , address : 0x76B32D83, name : _ItSrvUnregisterIdleTask
Opcode : 0x02 , address : 0x76B3215C, name : _ItSrvProcessIdleTasks
Opcode : 0x03 , address : 0x76B32151, name : _ItSrvSetDetectionParameters
Number of MIDL structures found: 3

On peut voir que schedsvc fournit 3 types d’interfaces les Sa*, NetrJob* et ItSrv*. Un peu de google et on tombe sur ça mais aussi sur « [MS-TSCH]: AT Service Remote Protocol Specification« , w0ot ces protocoles sont documentés depuis que Microsoft a été obligé de les mettre en ligne. Dans notre cas on a les protocoles SASec et ATSvc pour le dernier on s’en fou. Petite description:

1.3 Protocol Overview (Synopsis)
The Task Scheduler Remoting Protocol is used to register and configure tasks or to query the statu
of running tasks on a remote server. The Task Scheduler Remoting Protocol primarily consists of
three separate remote procedure call (RPC) interfaces:
- Net Schedule (ATSvc)
- Task Scheduler Agent (SASec)
- Windows Vista Task Remote Protocol (ITaskSchedulerService)
All three interfaces use RPC as their transport to configure and manage tasks remotely, as shown
Figure 1. The three interfaces represent a continuum of increasing functionality, with ATSvc providing
rudimentary functionality and ITaskSchedulerService providing the most functionality.
Historically, the ATSvc interface is the oldest. The SASec interface was introduced in Windows 2000
and the ITaskSchedulerService interface made its debut in Windows Vista. The three interfaces
are not independent—they operate on the task store, shared persistent storage for tasks.

Pour le moment avec les interfaces disponibles on ne peut que ajouter/supprimer des jobs, énumérer/définir des infos dessus, il n’y a rien concernant les credentials. Pour info, la commande at.exe utilise la lib netapi32 (Schedule Functions) qui fonctionne aussi avec l’interface RPC ATSvc.

Arrivé à ce point on sait donc comment communiquer avec le Task Scheduler, c’est un service qui fournit des interfaces RPC avec une interface de base ATSvc et une plus aboutie SASec. Maintenant il faut creuser dans la Dll schedsvc pour trouver la fonction qui lancer les tâches puis voir comment elle récupère les credentials, IDA est notre ami en plus on accès aux symbols. Après quelques recherches on trouve une fonction intéressante nommée DecryptCredentials de proto :

__int32 __stdcall DecryptCredentials(const struct _RC2_KEY_INFO *, unsigned __int32, unsigned __int8 *, struct _JOB_CREDENTIALS *, int)

Avec au dessus des appels à ReadLsaData, GetCSPHandle (le provider crypto) et ComputeCredentialKey. A partir de là on peut donc penser que la Dll va récup les credentials cryptés dans le provider LSA, demander d’utiliser un custom cryptographic service provider avec les APIS CryptAcquireContext et CryptGenKey sur du RC2 http://en.wikipedia.org/wiki/RC2 puis calculer la clé de chiffrement qui à servit a crypté les credentials. D’après ce que j’ai pu voir cette clé dépend du nom de la machine de son SID et de d’autres valeurs, je ne me suis pas amusé à rentrer dans les détails, la flemme ! En regardant le graph de crossref à DecryptCredentials on peut voir :

Regardez la chaines de calls MainServiceLoop->RunLogonJobs->RunJobs->RunNtJobs->LogonAccount->GetAccountInformation->DecryptCredentials, cette série de calls montre que pour lancer une tâche, le Task Scheduler va récupérer les credentials du user qui la enregistré, normal :] Pour vérifier cela on se crée un tâche bidon on sort le kernel debugger puis mettre un BP sur DecryptCredentials dans schedsvc.dll. Svchost n’aimant pas du tout se faire debug par OllyDbg. Ensuite, on lance cette tâche à la main on espérant que ca break puis on examine la stack avant et après en espérant trouver des infos intéressantes, surtout on regarde le 4 ème paramètre de DecryptCredentials qui un pointeur sur un structure non documentée _JOB_CREDENTIALS.

1: kd> bp schedsvc!DecryptCredentials
breakpoint 0 redefined
1: kd> g
Breakpoint 0 hit
schedsvc!DecryptCredentials:
001b:77312787 8bff            mov     edi,edi
1: kd> kv
ChildEBP RetAddr  Args to Child
0120ee30 77313c65 0120ee84 00000038 037724c4 schedsvc!DecryptCredentials (FPO: [Non-Fpo])
0120efd0 77317ce1 01ef35f0 0120f00c 0000001c schedsvc!GetAccountInformation+0x174 (FPO: [Non-Fpo])
0120f448 773182c9 01ef35f0 01ef3320 0120f974 schedsvc!LogonAccount+0x1ca (FPO: [Non-Fpo])
0120f938 7730ff5b 01ef3320 00359b80 0120f994 schedsvc!CSchedWorker::RunNTJob+0xfa (FPO: [Non-Fpo])
0120fbe8 773106c6 00359ee8 530995a0 00000102 schedsvc!CSchedWorker::RunJobs+0x304 (FPO: [Non-Fpo])
0120fe74 773109c5 7c80a6a9 00000000 00000000 schedsvc!CSchedWorker::CheckDir+0x36a (FPO: [Non-Fpo])
0120ff28 77310e9c 7730b532 00000000 000c979c schedsvc!CSchedWorker::MainServiceLoop+0x2b1 (FPO: [Non-Fpo])
0120ff2c 7730b532 00000000 000c979c 00099894 schedsvc!SchedMain+0xb (FPO: [1,0,0])
0120ff5c 7730b63f 00000001 000c9798 0120ffa0 schedsvc!SchedStart+0x266 (FPO: [Non-Fpo])
0120ff6c 010011cc 00000001 000c9798 00000000 schedsvc!SchedServiceMain+0x33 (FPO: [Non-Fpo])
0120ffa0 77deb48b 00000001 000c9798 0007e898 svchost!ServiceStarter+0x9e (FPO: [Non-Fpo])
0120ffb4 7c80b683 000c9790 00000000 0007e898 ADVAPI32!ScSvcctrlThreadA+0x12 (FPO: [Non-Fpo])
0120ffec 00000000 77deb479 000c9790 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])

1: kd> dd esp
0120ee34  77313c65 0120ee84 00000038 037724c4
0120ee44  0120f00c 00000001 0120f994 0120f974
0120ee54  00000000 00000000 00000078 00000084
0120ee64  03772484 0000004c 00000000 0120ef7c
0120ee74  037a6480 03772478 037c7580 00000000
0120ee84  00000000 00000000 29852de1 9a45f9f4
0120ee94  b347543e 4007221f 263c713a 7bafc308
0120eea4  d1d64357 90b82461 25100c36 eefab642

1: kd> gu
schedsvc!GetAccountInformation+0x174:
001b:77313c65 85c0            test    eax,eax
1: kd> db 0120f00c
0120f00c  04 00 00 00 69 00 76 00-61 00 6e 00 00 00 1d 00  ....i.v.a.n.....
0120f01c  a2 3f 83 7c 68 f5 20 01-02 00 80 00 04 f3 20 01  .?.|h. ....... .
0120f02c  00 00 00 00 d8 f0 20 01-a0 10 08 00 52 d6 6c 53  ...... .....R.lS
0120f03c  8c f0 20 01 c9 55 91 7c-04 00 80 00 04 f4 20 01  .. ..U.|...... .
0120f04c  02 00 80 00 45 09 91 7c-4e 09 91 7c c4 f3 20 01  ....E..|N..|.. .
0120f05c  24 00 02 00 b0 f1 20 01-02 00 00 00 90 41 91 7c  $..... ......A.|
0120f06c  00 d0 fd 7f 05 10 90 7c-58 f0 20 01 00 00 00 00  .......|X. .....
0120f07c  28 f1 20 01 18 ee 90 7c-70 09 91 7c c0 e4 97 7c  (. ....|p..|...|

1: kd> db 0120f00c+22C
0120f238  03 00 00 00 66 00 66 00-73 00 00 00 f8 00 00 00  ....f.f.s.......
0120f248  20 33 ef 01 00 00 00 00-00 00 00 00 00 00 00 00   3..............
0120f258  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0120f268  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0120f278  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0120f288  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0120f298  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0120f2a8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

Alors, « ivan » est mon login et « ffs » mon pass sur ma machine de test. Vous allez me demandez comment j’ai trouvé l’offset 0x22C ? Tout simplement en mattant le dissas de DecryptCredentials qui faisait des memcpy sur ces offsets. Dans tout les cas, on le login et le pass en clair qui apparaissent à la sortie de DecryptCredentials, cool ! On peut donc reconstituer la structure JOB_CREDENTIALS par :

typedef struct _JOB_CREDENTIALS
{
	ULONG LoginLen; //+0
	WCHAR Login[256]; //+4

	UCHAR Padding[40];

	ULONG PassLen; //+0x22C
	WCHAR Pass[256];
}JOB_CRENDENTIALS, *PJOB_CREDENTIALS;

Si on regarde plus loin dans le binaire on voit que la tâche est lancée avec CreateProcessAsUser avec un token fournit par LogonUser.

Maintenant on va prendre un café et on pense. On sait que les credentials sont gérés par le provider LSA et qu’ils sont chiffrés par un algo RC2 avec une clé dépendant de la machine. Une première tentative d’attaque pourrait consister à reproduire le fonctionnement de schedsvc en allant obtenir les credentials dans LSA, recalculer la clé de chiffrement et recoder DecryptCredentials, bref un travail super long qui en plus requiert d’avoir le token « SYSTEM » pour aller taper les credentials de LSA, c’est mort ! Une approche plus smooth serait de tout simplement hooker la fonction DecryptCredentials dans schedsvc.dll en injectant un Dll dedans, même si cela requiert le SeDebugPrivilege on en revient à un pwdump qui fait lui aussi une injection de Dll sauf que c’est dans lsass.exe. Problème c’est que l’appel à la fonction DecryptCredentials se fera uniquement lorsque la tâche sera lancée c’est à dire aussi bien dans 1 minute que dans 1 mois, pas super pour un pentest surtout que le newsoft c’est un nerveux. Par contre si vous regardez attentivement le graph de crossrefs à DecryptCredentials vous pouvez voir quelle est appelée par GetNSAccountInformation et GetAccountInformation, intéressant car ces APIs font partie de celles fournies par l’interface RPC.

On pourrait donc monter une attaque qui consisterait à injecter une dll dans le svchost qui héberge schedsvc.dll, hooker la fonction DecryptCredentials, faire un appel RPC sur SaGetAccountInformation ou SaGetNSAccountInformation puis lire la sortie de DecryptCredentials, cela nous éviterait d’attendre que la tâche se lance pour obtenir les credentials, parfait !

Reste un gros souci que je n’ai toujours pas réussi à corriger, la fonction DecryptCredentials n’est pas exportée par schedsvc.dll et ne se trouve pas non plus près d’une fonction exportée. Le problème c’est que pour procéder à notre hook nous devons connaître son adresse précise dans le process svchost.exe. Pour le moment j’utilise donc un offset hardcodé relatif à l’ImageBase de schedsvc.dll pour calculer l’adresse de cette fonction, ouais je sais c’est moche, je vais voir si il est possible de faire une recherche par pattern matching dans le binaire pour avoir quelque chose de plus générique.

Arrivé à ce niveau on peut designer proprement l’attaque :

  1. Vérifier qu’on peut obtenir le SeDebugPrivilege sur la machine pour pouvoir jouer avec les processes des autres accounts.
  2. Vérifier que le service du Task Scheduler tourne sur la machine, pour cela on utilise les api du SCM (Service Control Manager) en regardant l’état du service nommé « Schedule », si il n’est pas actif on arrête.
  3. Vérifier qu’il y a des tâches dans le gestionnaire. On peut utiliser la méthode Enum de la classe IEnumWorkItems, si il n’y pas de tâche on stop.
  4. Retrouver le processus svchost.exe qui a chargé la Dll schedsvc.dll, pour cela on énumère les processus avec CreateToolHelp32Snapshot puis leurs modules avec EnumProcessModules.
  5. Pour pouvoir monitorer les messages provenant de la Dll qui va être injectée j’ai décidé de surveiller le buffer fournit sous forme de mapped section servant aux debug strings. La Dll va donc écrire dedans avec l’API OuputDebugString et notre process va crée un thread chargé de monitorer ce buffer, ce thread va filtrer la provenance des messages afin de ne conserver que ceux qui proviennent du process svchost contentant la Dll schedsvc.dll.
  6. On inject la Dll dans le bon svchost, elle va hooker la fonction DecryptCredentials avec un inline hook. Pour réaliser le hook j’ai utilisé la lib detours de Miscrosoft superbement bien foutue. La fonction qui remplace DecryptCredentials ne fait juste qu’appeler la vraie fonction DecryptCredentials puis dumper les champs Login et pass de la structure JOB_CRENDENTIALS avec des OutputDebugString qui seront filtré par la suite avec le thread du process injecteur.
  7. Pour trigger la fonction DecryptCredentials on demande d’obtenir les noms des users ayant crée les taches. J’ai choisit arbitrairement d’utiliser l’interface SAGetNSAccountInformation qui peut être appelé avec la méthode GetAccountInformation de la classe IScheduledWorkItem.
  8. Le hook nous renvoie les credentials, on les affiche, newsoft est content, il peut faire un beau rapport!
  9. On n’oublie pas bien sur de virer le hook et la Dll injectée afin de rendre quelque chose de propre après l’attaque.

Plusieurs utilisateurs peuvent en enregistrer des tâches planifiées, ce qui cool c’est que chaque user peut voir les tâches planifiées des autres. Cela veut dire que l’attaque va aussi dumper les credentials des tâches installés par les autres utilisateurs, et ça, c’est priceless ! Dans l’exemple suivant j’ai crée 2 tâches, chacune avec un user différent, le premier ivan:ffs, le second barp:rofl. Je crois que l’output de l’attaque parle de lui même :

Windows Task Scheduler credentials dumper
By Ivanlef0u, thanks to Nicolas Ruff
BE M4D!
Works on Windows XP SP3 and schedsvc.dll version 5.1.2600.5512
    /|
\`O.o'
=(_|_)=
    U
There is 2 tasks in queue
Current tasks are :
Command Prompt
barp
Error with EnumProcessModules : 299
schedsvc.dll found in process [svchost.exe:332]
Task Scheduler svchost pid is : 332
Dll to inject : C:\Test\tasksched\TaskPwdDmpDll.dll
Injecting DLL in process : 332
[Msg from PID 332]-> Dll injected in process 332

[Msg from PID 332]-> schedsvc dll is at : 0x77300000

[Msg from PID 332]-> Hooking DecryptCredentials at 0x77312787

[Msg from PID 332]-> Credentials barp:rofl

[Msg from PID 332]-> Credentials ivan:ffs

Dll successfully unloaded

Au final, on a une attaque qui permet de récup les credentials stockés en local par les users de la machine à travers les tâches planifiées. Je pense que cela est toujours pratique dans le cadre d’une intrusion même si 2 fortes contraintes interviennent, la première est le besoin du tool du SeDebugPrivilege, la seconde la difficulté de retrouver l’adresse de DecryptCredentials. Je vais essayer de travailler sur le second point.

En attendant je vous livre les sources de l’outil TaskPwdDump ainsi que les binaires. Pour l’utilisation il vous suffit de mettre le binaire TaskPwdDump.exe et la Dll TaskPwdDumpDll.dll dans le même dossier. Le tout ce DL ici :
http://ivanlef0u.fr/repo/TaskPwdDmp.rar

N’hésitez pas à me contacter pour tout problème rencontré.
Enjoy !
Au final je tient à remercier maître newsoft pour son aide sur le dev de cet outil !

Sinon Converge en concert, ca défonce !

Entry Filed under: RE

22 Comments

  • 1. santabug  |  juillet 25th, 2008 at 16:25

    Très instructif !

    Thx.


  • 2. mxatone  |  juillet 25th, 2008 at 19:18

    Maitre newsoft à de quoi être content. Bon article, l’approche du hook de la fonction est très bonne et fait gagner pas mal de temps de reverse. Pour le debug privilege, bah une petit local privilege escalation suffit ;).


  • 3. Taron  |  juillet 25th, 2008 at 23:34

    Très intéressant, surtout par rapport au gain de temps lorsqu’on doit dumper la SAM (encore faut-il avoir des tâches planifiées !).

    Thx


  • 4. newsoft  |  juillet 26th, 2008 at 10:56

    Good game, la communauté du pentest te dit merci :)

    PS. Login et Pass, ne sont-ce pas des UNICODE_STRING tout simplement ?


  • 5. admin  |  juillet 26th, 2008 at 13:18

    Nan pour une UNICODE_STRING on a :

    lkd> dt nt!_UNICODE_STRING
       +0x000 Length           : Uint2B
       +0x002 MaximumLength    : Uint2B
       +0x004 Buffer           : Ptr32 Uint2B
    

    Ici on retrouve bien la taille de la string mais sur 4 bytes (ou alors la MaximumLength=0) et puis ensuite on doit avoir un pointeur sur une string unicode donc ce c’est pas ça.


  • 6. b0l0k’s blog »&hellip  |  juillet 27th, 2008 at 00:01

    [...] Et oui … Me revoilà ! Quoi de neuf ? Ben le BTS c’est fini, je l’ai obtenu avec 16.7 de moyenne, il n’y pas de quoi sans réjouir (j’avoue que 20/20 en math ca m’a fait plaisir). Je n’ai pas beaucoup programmé durant cette année en dehors des cours, mais pendant ceux-ci, j’ai développez un projet de fin d’année qui consistai à extraire les objets en mouvement devant une caméra. Je ne publierai pas ce code, car les prochaines promos auront surement ce sujet et je ne voudrai pas leur donner tout fait ! Pour ceux que ca intéressent, n’hésitez pas à me contacter. En ce moment, je me penche sur le projet Singularity de Microsoft. Pour ceux qui n’en n’ont vraiment pas entendu parler, il s’agit d’un prototype de système d’exploitation conçu par une équipe de recherche Microsoft. L’équipe de recherche a publié des designs notes qui se trouvent dans le RDK de Singularity 1.1. Je vais essayez d’écrire un article pour chaque design note et vous exposes les différentes choses que l’on apprend. A part ca, je vous conseille toujours le blog de l’autre fou, j’ai nommé Ivanlef0u ! Notamment son dernier post qui m’a énormément plus : http://www.ivanlef0u.tuxfamily.org/?p=173 [...]


  • 7. Neitsa  |  juillet 28th, 2008 at 16:39

    Salut,

    Bravo Ivan, encure une fois, très intéressant et superbement mené, comme d’hab’ :D


  • 8. admin  |  juillet 28th, 2008 at 16:55

    <3 Neitsa et les autres.


  • 9. admin  |  juillet 30th, 2008 at 23:38

    Correction d’un bug à la con dans les sources, j’avais mit WCHAR pour la champ PassLen de la JOB_CREDENTIALS alors que c’est ULONG, mauvais C/C et oublier de tester après, toutes mes escuses. J’ai update les sources sur le repo.


  • 10. newsoft  |  juillet 31st, 2008 at 09:11

    Ah c’est pour ça que ma démo client a lamentablement échoué …


  • 11. nicolasfr  |  août 14th, 2008 at 12:03

    Waou! J’ai trouvé ton blog en lisant celui de newsoft. Impressionant.
    PS: Je ne vois pas de mail de contact, à quelle adresse peut-on t’écrire?


  • 12. admin  |  août 14th, 2008 at 12:13

    Yo, tu peux me contact à l’adresse ivanlef0u@security-labs.org


  • 13. kinsk  |  août 22nd, 2008 at 12:26

    Superbe.
    C’est sympa un article comme ça, j’ai presque l’impression de comprendre ça change…
    Bravo pour tes travaux.


  • 14. admin  |  août 22nd, 2008 at 16:57

    Update des sources et binaires de TaskPwdDump sur le repo. Gestion de Windows server 2003 !


  • 15. Tester  |  octobre 28th, 2008 at 11:26

    Ca marche terrible !

    Merci bcp.


  • 16. SacRoyale  |  octobre 30th, 2008 at 15:02

    You say the SID is one of the values used for calculating the encryption key – Can you confirm if MAC address is another one of the values used in the encryption key calculations? Any other info on these boring details would be much appreciated. Thanks.

    Excellent work on the dumper!


  • 17. admin  |  novembre 1st, 2008 at 13:20

    Yo,
    I didn’t see the computer MAC used for key calculation. In fact in schedsvc!ComputeCredentialKey you can see the computer’s name and account sid are used. All is these args are passed to MarshalData which seems to used Windows crypto API for MD5 (AlgId 0×00008003). This MD5 is used for decrypting the credentials with an RC2 algorithm.


  • 18. xort  |  avril 22nd, 2009 at 21:51

    Nice read


  • 19. Nicosoft  |  février 26th, 2010 at 02:02

    Avé !

    Bel article … assez, comment dire …
    intriguant :) !

    Dump ok en tant qu’admin.

    Dump pas ok en tant qu’utilisateur lambda et même en tant qu’ « Utilisateurs avec pouvoir » (serveur 2003 membre)

    Alors ? y a ty quand même un trou dans la carlingue 2mi3 zerveur ?

    @+


  • 20. admin  |  février 26th, 2010 at 20:28

    @Nicosoft
    Thx ! C’est juste qu’il faut être admin pour avoir accès au process qui nous intéresse afin d’y injecter une DLL. Il te renvoie quelle erreur ?


  • 21. Nicosoft  |  février 26th, 2010 at 23:33

    Error with OpenProcess : 5
    Error with EnumProcessModules : 6

    Task Scheduler svchost pid is : 0
    Dll to inject : C:\Admin\Bin\TaskPwdDmpDll.dll
    Injecting DLL in process : 0
    Error with OpenProcess : 87
    Error while injecting Dll ! Exiting


  • 22. admin  |  février 27th, 2010 at 19:22

    @Nicosoft
    Apparemment il manque un droit pour que ma fonction GetTaskServerPid() fonctionne correctement. En tout cas elle n’arrive pas à trouver le processus svchost qui nous intéresse lorsqu’on est power user sous 2k3. Tu peux faire un : accesschk.exe -p svchost.exe -f ( http://live.sysinternals.com/accesschk.exe )


Trackback this post


Calendar

mars 2017
L Ma Me J V S D
« fév    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Most Recent Posts