Nous allons entamer prochainement l’écriture d’un cours de WEB hacking.

Aujourd’hui je vais tenter de vous expliquer la méthodologie / scénario d’une attaque WEB puis dans les jours qui viennent nous nous attarderons sur la technique nécessaire afin d’exploiter des vulnérabilités.

La première étape consiste à fouiller et identifier la cible:

-Convertir le nom en IP. (un simple ping sur le domaine suffit).

-Enumérer les autres virtualhost (autres sites présents sur le serveur). Pour cela on peut utiliser le moteur de recherche bing avec la requête: :<ip address>.

-Trouver tous les sous-domaines associés au domaine cible. Cela est faisable avec « bidiblah » renommé il y a quelque temps « Yeti ».

Pour continuer nous devons acquérir des informations un peu plus « critique »:

Y-a t-il un WAF (Web application firewall) sur le serveur ? Pour le savoir il suffit d’utiliser WAFWOOF.

Quelle est la plateforme, les services installés dessus (NMAP, Nessus)…

Une fois qu’on a récolté un maximum d’informations sur la cible, on cherche sur tous les hosts d’éventuels point d’attaque (paramètre, formulaire, session).

si le site cible possède un espace membre s’enregistrer afin d’analyser l’espace membre, les éventuels cookies reçus…

-Utiliser des web spider ou scanner.

-webScarab : proxy qui montre les champs cachés (input de type hidden).

Après, on devient un poil plus offensif et on cherche des vulnérabilités SQL (à la main, ou avec des outils comme The Mole).

Une bonne injection SQL nous permet par la suite de lancer des commandes serveur (ls, rm..)

-Escalade de privilèges.

-lire le fichier bash_history (historique des commandes).

-defacer le site.

-sniffer les paquets.

-cracker les passwords.

Dans les chapitres suivant nous allons voir en détail les injections SQL, les Blinds injection, les failles XSS, le directory transversal, les failles de type CRSF… et ainsi que quelques outils nous facilitant ces tâches et automatisant quelqu’un de ces processus d’attaque.

Aujourd’hui dans un bref article qui ressemblera plus à un brouillon qu’autre chose nous voir et étudier les headers attachés à tous les mails envoyés / reçus email:

« Received header » : ils montrent comme l’email a été routé sur internet, et a été ajouté par les serveurs ou il est passé (certains d’entre eux). Ce sont sans doute les headers les plus importants si l’on souhaite faire du troubleshooting.

« from » : c’est un complément arbitraire qui peut-être défini par l’expéditeur, et comme il y a vraiment aucune authentification il est utilisé par les mécréants afin de tromper le destinataire sur l’envoyeur en se faisant passer par exemple pour bill.gates@microsoft.com .

Lorsque vous recevez un email, l’adresse email de l’expéditeur qui apparait sur votre client/boite mail provient de cet header « from ».

Si vous faites partis d’une mailing-list  vous pouvez voir des headers : « list-id« , « list-unsubsribe« , « list-archive », « list-post« .

Ces champs sont souvent cachés mais parfois utilisé par votre client email afin de faire certaines choses automatiquement.

Autres headers communs, sont ceux commençant par « x-« :

ça signifie « experimental », ce sont des headers qui ne sont pas officiellement définis mais

on peut y trouver pas mal de choses intéressantes dans ce type d’header:

x-mailer, x-priority, x-MSmail : il s’agit d’indices sur le logiciel qui a envoyé l’email.

L’adresse IP source peut est trouvé dans x-originating, même si cela de moins en moins fréquent aujourd’hui.

Les headers de   »date » : correspond aux dates de l’email qui peuvent être forgé…

Revenons au « received header:

-Il faut savoir qu’ils se lisent de bas en haut!

-L’explication est que chaque nouveau « hop » ajoute son header en haut du message

-Pour connaitre la provenance d’un mail: trouver la frontière de confiance, jusqu’à quel serveur pouvons-nous faire confiance. (le notre par exemple :p)

-Tous les autres pourraient être forgés: en passant par un relai ou un proxy et ainsi ajouter 10 header avant qu’il n’est réellement commencé de voyager.

En cas de problème de délai au niveau de la réception des emails,  analyser les « received header » peut vous aider à trouver le serveur fautif…

That’s all for today.

Beaucoup de personnes ne le savent pas, mais dans vos documents (images, documents word, pdf… ) y sont attachés ce que l’on appelle métadonnées.

Ces métadonnées selon le support peuvent être par exemple un nom / prénom (Word, OpenOffice, PDF), des coordonnées GPS (images) ou diverses informations pouvant être utiles lors d’une enquête.

Ces informations peuvent être très dangereuses pour le suspect lambda n’ayant pas de compétences informatiques particulières et n’étant donc pas au courant de la présence de ces métadonnées.

Une fois que l’on a exporté et isolé nos fichiers pouvant potentiellement comporter des métadonnées (une image, un document word, un pdf et une charge .rar) on utilise exiftool un outil permettant l’extraction des métadonnées des images, audio et vidéo…

A noter que exiftool peut être utilisé pour créer de fausses métadonnées (coordonnées GPS, date…) ou au contraire supprimer des métadonnées associées à un document.

Sur l’image ci-dessus on voit que notre image  a notamment été retouché sur Photoshop, on voit la date de modification, et que la photo provient à l’origine d’un HTC Desire.

Malheureusement les coordonnées GPS ne sont pas présentes… (ce dernier n’étant pas activé lors de la prise de la photo).

Ensuite analysons notre document PDF avec pdfinfo (exiftool aurait aussi bien fait l’affaire ici):

On peut voir que le suspect (en l’occurrence moi), à généré le PDF avec PDFCreator qui est une imprimante virtuelle…

A noter que PDFCreator nous permet de gérer les métadonnées de nos documents PDF.

Ensuite pour analyser notre .doc, nous allons utiliser Doc Scrubber fonctionnant sous Windows.. (exiftool peut aussi faire l’affaire).

On peut retrouver des informations assez extravagantes comme la date de la dernière impression, le nombre de révisions du document word…

Enfin nous avons une archive « rar » qui est verrouillé par un mot de passe.

Cela nous intriguant on peut tenter de lancer une attaque Bruteforce avec rarcrack (qui sera un échec si le mot de passe est trop complexe et donc trop long à cracké):

A noter que pdfcrack fait la même chose avec les pdf…

Ainsi avec l’extraction de « métadonnées« , on a vu qu’il était possible de récupérer certaines données « cachées » pouvant nous mener vers le suspect (ou son but), l’utilisateur moyen n’ayant pas connaissance de la présence de ces métadonnées dans ses documents / images.

Voici comment s’achève cette petite introduction à l‘analyse Forensique, j’espère que cela vous a plu !

N’hésitez pas à commenter les articles…

Aujourd’hui nous allons revenir sur le fichier MFT que nous avons vu dans le chapitre précédent.

Ce fichier peut être considéré comme  un des points clés du système de fichiers NTFS, dans le sens ou il contient des informations sur tous les fichiers / dossiers présents sur le DD avec entre autres:

•         Nom long du fichier.
•         Nom au format 8.3.
•         Index (numéro d’ordre du fichier).
•         Taille du fichier.
•         Dates et heures de création / modification / accès.
•         Attributs du fichier.
•         Droits d’accès (voir ACL)
•         Liste des blocs (clusters) contenant le fichier.

Afin de l’analyser on peut utiliser analyseMFT pour l’explorer le contenu du fichier MFT (on spécifie à analyseMFT l’image ou se trouve notre fichier MFT) qui généra un CSV.

Ou utiliser MFTparser qui charge un fichier MFT puis crée une base sqLite étant explorable directement avec MFTparser.

Ce dernier étant plus performant (pour faire des recherches…) est celui que nous utiliserons.

Pour cela il faut d’abord exporter votre fichier $MFT depuis Autopsy.

Une fois l’export réalisé on lance MFTparser et on charge notre fichier MFT en cliquant sur : « Process MFT Record ».

Cette action va générer une base SQLite contenant toutes les informations de votre MFT, ainsi si vous désirez explorer à nouveau votre fichier MFT ultérieurement vous n’aurez qu’a faire « Load Previous Case » et sélectionner la base SQLite correspondant à votre MFT.

A ce moment plusieurs fenêtres devraient s’ouvrir:

« file type listing » liste les différents enregistrements, et permet d’effectuer une recherche sur un fichier précis rapidement.

Comme avec anlayseMFT vous pouvez générer un CSV avec les enregistrements MFT Allez sur « Temporal Analysis« , cochez les cases qui vous intéresse pour générer le CSV correspondant à votre MFT.

Record : corresponds au numéro d’enregistrement.

D’autre part avec MFTparser vous pouvez effectuer des recherches, cliquer sur un des enregistrements pour avoir plus d’informations sur ce dernier (date de création, dernier accès, modification…).

On lance regRipper sous une machine Windows en spécifiant le chemin de notre NTUSER.dat, puis dans plugin on sélectionne « ntuser ».

Une fois la ruche rippé, deux fichiers textes sont créés:

    Un contenant des logs (encadré en rouge sur l’image ci-dessous).

   L’autre contenant contenu du fichier NTUSER avec les informations qui nous intéressent (encadré en vert).

Parmi ces informations on peut retrouver les documents récents, on voit notre fichier « ailes.odt » créé par le suspect juste avant la copie du disque et toutes les informations sur le profil de la session ( application, bureau, environnement, connexion réseau, imprimante…).

Nous allons travailler sous SIFT WORKSTATION une distrib orienté Forensique disposant de tous les tools nécessaires à un bon technicien effectuant une analyse!

Disponible ici: http://computer-forensics.sans.org/community/downloads

Nous allons commencer par utiliser Autopsy nous permettant d’analyser les images précédemment copiées.

Autopsy se gère via l’interface d’un navigateur: http://localhost:9999/autopsy

Dans un premier temps cliquez sur « new case » afin de créer notre « investigation ».

Ensuite vous avez la possibilité d’ajouter un « host »:

« timeskew adjustment » correspond au décalage qu’il pouvait avoir entre l’heure BIOS de son poste et l’heure réel. C’est un champ important qui permet lors de notre étude d’avoir l’heure exacte des différentes actions du suspect sur son PC.

Enfin « add images ». Vous montez le disque dur où sont stockés vos images puis pour les ajouter toutes en utilisant /dossierimages/name* » (comme montré sur l’image ci-dessous)

Maintenant nous voyons notre partition « c: » sous Autopsy.

Cliquons sur « Files Activity TimeLines »qui  permet de voir dans l’ordre chronologique l’accès / modification / supressions des fichiers sur la partition. (encadré en vert)

La première chose à faire c’est « create data file » sur notre partition « C: »

Une fois votre data file généré (par défaut dans ../output/body) on s’occupe de trier la Timeline simplement en cliquant sur « OK ».

On sélectionne le fichier à trier (body pour nous).

Une fois le tri effectué, vous pouvez aller dans l’onglet « view Timeline » afin de voir les fichiers vus/accédés en fonction de leur date..

Le problème avec cette vue, c’est que l’on peut filtrer uniquement par mois, alors qu’il se passe déjà énormément de chose en une heure… c’est pourquoi on n’utilisera pas cette vue pour analyser notre DD mais il me paraissait essentiel de vous en parler;).

Quittez maintenant la timeline pour revenir sur la vue présentant votre / vos partition(s).

Nous allons maintenant analysez la partition « C: » (encadré en rouge sur l’image  précédente 2)

On peut désormais naviguer dans la partition en voyant les dossiers / fichiers présents.

On notera la possibilité d’exporter le contenu d’un fichier.

A la racine on repère le fichier « $MTF » (pour Master File Table ) qui est intéressant:

C’est un des éléments du système de fichiers NTFS qui contient la liste de tous les fichiers stockés sur un disque. Il fonctionne un peu à la façon d’une base de données.

Nous y reviendrons dans la prochaine partie.

$Recycle.Bin: la poubelle de Windows, à l’intérieur vous retrouverez un dossier par utilisateur (le nom du dossier correspond au SID de l’utilisateur).

Sinon nous allons allez dans le dossier « /Users » , puis « Creativeo » ou se trouve un fichier (ntuser.dat) que nous allons analyser contenant le profil de notre victime.

Une fois le fameux fichier trouvé on clique dessus afin d’afficher le contenu et d’avoir la possibilité de l’exporter (ce que nous faisons).

Avant de quitter Autospy je vais vous parler d’une autre fonctionnalité intéressante « keyword search »

qui permet de chercher une string en ASCII, unicode … contenu dans un fichier.

Selon la taille de l’image la recherche peut prendre un certain temps à se faire…

L’option « extract string » permet d’extraire les chaines de caractères comme son nom l’indique, afin d’accélérer les recherches. 

On remarque ci-dessus en rouge « ailes », il s’agit d’une de mes précédentes recherches qui est automatiquement enregistré

Pour finir nous allons ouvrir le fichier « timeline.txt » précédemment créé avec gedit.

(Si vous ne savez pas où il a été enregistré, un petit locate timeline.txt devrait vous trouver votre fichier).

On remarque beaucoup de lignes classées chronologiquement.

En effectuant une petite recherche sur « ailes » (je sais que ce document existe sur le PC du suspect, je n’ai pas deviné tout seul :p) qu’il a été crée le Lundi 2 janvier 2012 à 14h47.

Les lettres qu’on retrouve encadré en rouge signifient:

m: « modification »

a: « access »

c: « creation »

b: « birth »

 Conclusion: Nous avons fait un petit tour rapide des fonctionnalité première d’Autospy, dans le prochain article nous allons analyser le fameux fichier MFT ainsi que le registre.

Dans l’article traitant des fraudes à la carte bancaire nous avons vu que beaucoup des revendeurs récupéraient ces informations bancaires via des dumps de bases de données de sites marchands…
Ce genre d’histoire où la base de données d’un site a été compromise se répète trop souvent.
En ce moment nous entendons surtout parler des Antisec / Anonymous / Wikileaks qui arrivent régulièrement à compromettre des systèmes et de voler des bases de données contenant des données privés.
Que leurs actions soient légitimes ou non, cela n’arriverait pas si les bases de données était un peu mieux protégées…

Nous vous conseillons de d’abord jeter un œil à la vidéo réalisée par la team Cymru (en anglais) :

Il suffirait en effet de chiffrer au moins les mots de passe, numéro de cartes bancaires et autres informations confidentielles pour éviter l’exploitation de certaines données d’une base de données volées.
L’idéal est de trouver le juste milieu, chiffrer ce qui peut être dangereux en cas de vol, mais ne pas en abuser non plus. En effet si vous chiffrez toute votre base de données, les performances en prendront un coup!
Ensuite même si vous voulez chiffrer vos données faites attention à comment souhaitez-vous le faire.
Par exemple il y a beaucoup de sites qui proposent de déchiffrer du MD5, préférez chiffrer avec le SHA-1 ou SHA-256 .
Autre bonne pratique, l’utilisation d’un SALT.
Le SALT c’est une valeur aléatoire que nous intégrons au début ou à la fin de la chaine de caractère avant de chiffrer cette chaine (le mot de passe concaténé au SALT) avec une fonction de hash (SHA1…).
Après on stocke donc le mot de passe chiffré, et le SALT dans notre BDD mais surtout pas le mot de passe en clair !
Afin de vérifier si le mot de passe est valide, on exécute la même fonction de hash sur notre « string+salt » et one le compare à notre mot de passe chiffré stocké dans la base.

Voici un petit schéma pour résumer la situation:

Note: Il n’est pas possible de récupérer le mot de passe d’origine si on ne le connait pas, c’est pourquoi la plupart des sites ne vous renvoient pas votre mot de passe quand vous l’avez perdu mais qu’il vous propose d’en générer un nouveau.
Les inconvénients : par ce fait, lors d’une demande de génération de mots de passe une question de sécurité est souvent demandé afin de vérifier que la personne qui demande un nouveau mot de passe est bien la propriétaire du compte…
Personnellement je ne trouve pas cette pratique très sécurisée les questions de sécurité étant du genre « quel est votre animal préféré », « quel est le nom de votre meilleur ami d’enfance? » avec un peu de social engineering il est très facile d’obtenir la réponse à ces questions…

D’ailleurs un bon nombre de célébrités se sont fait hacké à cause de ces questions de sécurité! (via Gmail, Facebook…).

L’objectif d’aujourd’hui sera d’effectuer une copie bit par bit du disque dur saisi.

C’est cette copie que nous analyserons ensuite, et non directement le média du suspect.

Pour l’acquisition de données nous allons utiliser un LiveCD d’une distrib orienté sécurité / forensique

Téléchargeable gratuitement ici: http://www.e-fense.com/helix/

Mais pour ce que nous allons faire vous pouvez aussi utiliser Backtrack ou un Ubuntu avec les paquets nécessaires .

Je veux vous montrer comment Helix fonctionne car il est utilisé par un bon nombre des techniciens effectuant des analyses Forensique.

Dans un premier temps on affiche la liste des disques dur présent avec « fdisk -l » .

On repère le disque que nous souhaitons cloner.

Ensuite « ewfacquire » permet d’effectuer une copie bit par bit d’un média.

on spécifie le disque que nous souhaitons dupliquer (qu’on a précédemment repéré avec notre FDISK):

ewfacquire /dev/sda

Ensuite ewfcquire va nous demander certaines informations:

Avec entre autres la destination de la copie (dans mon cas sur mon DD externe que j’ai monté avec la commande « mount »).

le nom de l’affaire, quelques notes, la description.

le type de media (fixe, usb…), la compression utilisée, la taille de chaque segment, le nombre de bits à copier (et où commence la copie « offset »), la taillle des blocs.

Une fois ces informations entrées la copie commence.

Pour copier bit par bit le contenu d’un disque dur de plusieurs centaines de Giga le traitement prendra plusieurs heures.

D’autre part une copie bit par bit peut se faire simplement avec la commande « dd » même si je la trouve un peu moins adaptée que ewfacquire dans le cas de l’utilisation de la copie pour une future analyse comme celle-ci .

dd if=/dev/sda1 of=/dev/sda2 bs=1024

Avec sda1 le disque que vous souhaitez cloner, et sda2 ou il sera copié.

et bs correspond à la taille d’un bloc.

That’s all for today

Prochaine étape: analyse des données.

Ce tutorial fait suite à une série de vidéos réalisées pour securityube.

L’objectif de cette série est  d’étudier un cas d’analyse forensique

Je ne suis pas un expert en Forensique, mais je ferais de mon mieux pour partager mon apprentissage

en essayant tout de même de respecter les grandes lignes d’une analyse forensique.

Situation:

En tant que technicien nous avons l’ordinateur d’un suspect à étudier:

L’utilisateur tourne sous Windows 7

Le disque dur n’est pas chiffré, et un mot de passe de session Windows est utilisé.

Avant d’aller plus loin, il faut savoir que pour faire une analyse forensique il y a certaines règles à respecter.

 Déjà pour commencer qu’est-ce que l’analyse forensique?

C’est la préservation et la collecte de preuves.

Afin de bien faire son travail il faut suivre les lignes directrices de ACPO:

Il s’agit de bonnes pratiques à suivre afin de ne pas créer un « maillon » faible dans la chaine des preuves ayant pour principe premier:

De ne pas altérer / modifier les données qui sont analysées ou utilisées en tant que preuves (que ça soit sur un ordinateur, disque dur…)

Mais en tant que techniciens certaines fois vous devrez le faire, dans ce cas vous devez documenter vos actions, avoir un témoin pour éviter que la partie adversaire ne prennent avantage de cela lors du jugement (en décrédibilisant le technicien).

Principe 2 : rejoins le principe 1, lorsque le technicien accède aux données du suspect et que pour une raison X il a du en modifier certaines, justifier son acte.. démontrer que l’action effectuée est légitime.

Principe 3 : Notez , créez des rapports pour tout ce que vous faites afin qu’un tiers parti puisse prendre votre documentation afin d’arriver aux mêmes résultats, aux mêmes conclusions.

S il n’y arrivent pas les gens vont se demander « pourquoi ? »

La saisie de produits:

Documentez, datez si il y a interaction avec le matériel.

Prenez des photos de l’équipement complet.

Si l’ordinateur est allumé, prenez des photos des programmes lancé , des processus qui tournent…

Eteignez l’ordinateur en débranchant le câble / en enlevant la batterie dans le cas d’un portable. Il est important de ne pas arrêter l’ordinateur à la « main »!

L’acquisition:

L’acquisition c’est lorsque vous faites une copie bit par bit des données stockées sur le matériel saisi

(avec la commande DD où d’autres outils…) Il s’agira de cette copie qui sera examiné afin de ne pas altérer les données originales..

Nous allons nous attarder sur l’acquisition de données dans la prochaine partie.

Pour résumer, l‘analyse forensique est un travail minutieux ou il faut savoir être  rigoureux. Tout doit être reporté et fait dans les règles.

L’objectif  consiste à accéder au bureau de l’ordinateur, pour cela nous allons voir comment contourner le mot de passe mis en place par l’utilisateur.

Pour cela il vous faut un live CD d’un système Linux (Ubuntu ou autres).

Dans un premier temps je configure le bios afin de donner la priorité à mon live CD (afin que celui-ci se lance au boot).

Puis je boot sur mon live CD.

Comme nous le voyons sur l’image ci-dessus nous montons le système d’exploitation du suspect avec « mount », puis nous allons ensuite remplacer utilman.exe par cmd.exe en faisant un

mv cmd.exe utilman.exe

Une fois les modifications effectuées, rebootez sous Windows 7

Faites « Windows + U », et vous allez voir apparaitre la console de Windows

(à la base la combinaison effectuée lance utilman.exe  un utilitaire Windows remplacé ici par notre console Windows…)

Tapez dans la console « net user administrateur /activer:yes »

Rebooter, et vous pouvez désormais vous loguer avec un autre compte que celui du suspect (« administrateur », pas de mot de passe!)

Vous avez maintenant accès à son Windows, son environnement…

Conclusion: en quelques minutes nous avons vu comment bypasser l’authentification d’un windows, utile si vous avez perdu votre mot de passe!

Nous avons vu comment créer une Backdoor sur le poste de la victime avec Metasploit, maintenant nous allons voir comment créer une Backdoor exécutable.

Afin de réaliser cela nous allons utiliser « msfPayload », permettant en autre de générer des .exe depuis n’importe quelle Payload.

« S » pour avoir un résumé du Payload choisi (voir les options…)

On spécifie donc le RHOST (ip de notre victime) :

« X » pour générer un exécutable.

Le but est que la victime exécute l’exe.

Nous aurions pu uploader l’exe nous-mêmes et ainsi l’exécuter en utilisant l’exploit RPC/DCOM vu précédemment, mais nous allons ici simuler un cas ou l’utilisateur télécharger lui-même l’exe depuis son navigateur :

On copie notre exe sur notre Xebserver (démarrez apache si nécessaire…)

L’utilisateur va ensuite surfer sur notre « site » et télécharger notre exécutable (dans un cas réel on tromperait l’utilisateur en lui faisant croire qu’il va télécharger un jeu sympathique, ou un petit utilitaire ).

Utiliser le search engineering toolkit pour avoir des techniques / méthodes sur comment délivrer un .exe sans éveiller les soupçons de l’utilisateur.

Si vous ouvrez le gestionnaire de tâche sur le poste victime, vous devez voir la tâche tourner en fond : (bind_tcp.exe dans notre cas).

Après pour nous connecter à notre Backdoor, comme d’habitude on utilise Msfconsole avec l’exploit multi/handler.

L’inconvénient de cette méthode est qu’une fois le shell meterpreter quitté le processus est tué et vous ne pouvez plus prendre l’avantage sur le poste de la victime.

L’autre inconvénient est qu’un tel exe contenant notre Payload réveille l’antivirus…

Nous allons donc voir comment encoder ce Payload afin d’éviter de se faire repérer…

On utilise Msfencode en conjonction avec msfPayload .

Msfencode prend entrée un fichier brut, pas un exe.

Donc à l’aide de Msfpayload nous générons ce fichier brut et non le exe…

« e » : on sélectionne l’encodeur (shikata est le plus utilisé)

« c » le nombre de fois que l’on souhaite encoder notre fichier.

On place notre fichier exe sur notre Webserveur…

Pour aller plus loin, vous pouvez prendre un exe existant, ajouter le code « payload » afin d’associer votre Backdoor un programme légitime existant et fonctionnant :

« x » est le paramètre à ajouter pour spécifier un template (programme exe fonctionnant).

Nous avons utilisé ici l’exe de notepad++ afin d’associer notre Backdoor dessus.

Ce qui est intéressant est que le poids de l’exécutable reste le même.

Même l’icône de l’exe reste telle quelle (sur le programme légitime).

Cependant lorsque la victime exécute le exe, la programme ne lance pas, par contre notre Backdoor est prête ;)

C’est mauvais car cela peut attirer les soupçons de l’utilisateur…

Pour éviter cela, et faire marcher le programme légitime il faut utiliser l’option « -k » avec Msfencode afin de lancer le Payload dans un nouveau thread.

Afin de réaliser cette attaque dans des conditions réelles je vous conseille de jeter un œil à SET ; « social engineering toolkit » qui très performant.

De très bons tutoriaux sont disponibles sur : http://secmania.com/