{
	"id": "82a7f4d6-d41a-4f4b-ab3b-813fd2b3a512",
	"created_at": "2026-04-06T00:22:05.0453Z",
	"updated_at": "2026-04-10T13:11:49.005307Z",
	"deleted_at": null,
	"sha1_hash": "b0826e418e582d763cad60eec39a29f4cb35e309",
	"title": "Sogeti ESEC Lab",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 218692,
	"plain_text": "Sogeti ESEC Lab\r\nBy Sogeti ESEC Lab\r\nArchived: 2026-04-05 22:09:13 UTC\r\nTL;DR\r\nThis article explains why it is still worth trying to reverse engineer a ransomware in order to retrieve your\r\nencrypted files. You may find a tool to decrypt the files modified by this specific ransomware at the end of the\r\narticle.\r\nContext\r\nA few weeks ago, Sogeti ESEC was called on an incident that took place in a client information system.\r\nThe client noticed some strange activities ongoing on one computer within their network. Indeed, some files on\r\nthat computer, including the ones available on network shares, were unreadable. Unfortunately most of those files\r\nincluded vital documents for our client, such as financial information, strategic information and so on. This data\r\nwere the achievement of a couple dozen years of work, thus could not be allowed to be lost. That is the reason\r\nwhy several backups of those data were done.\r\nAfter some investigations, they quickly understood that a malware was running on it. On their own, they\r\nsuspected the presence of a ransomware.\r\nTheir moves were to:\r\nend the process that was running\r\ndelete all the encrypted files\r\nreboot\r\nplug the backup storage and copy original files to the infected computer\r\nObviously the malware was still present on the system and had executed itself at boot time, infecting all freshly\r\nmounted backups, ending up with the loss of their three (3) backups (i.e.: averaging 1To worth of data).\r\nThrough a private company they were able to retrieve 40Go of encrypted data. Our mission was to understand\r\nhow that incident happened and if we were able to retrieve their data.\r\nThis mission has been conducted in collaboration with the Pentest and R\u0026D teams of Sogeti/ESEC.\r\nIntroduction\r\nWikipedia well defines what a ransomware is:\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 1 of 14\n\nA ransomware is a type of malware which restricts access to a machine data in\r\nsome way. Most of the time, the malware encrypts the content of all disks\r\navailable locally and remotely. Then the encryption key is sent to the\r\nattacker and destroyed.\r\nThe instructions to recover the files are also dropped by the malware. The\r\nattacker commonly asks for a ransom to get the files decrypted.\r\nRansomware is the easiest and quickest way of preventing a company to work, creating a leverage to get paid, or\r\n\"ransom\". Of course there is no guarantee of being able to retrieve the lost data. On the top of that,\r\ncryptocurrencies - like Bitcoin - allow fast transactions and are more or less easy to cash out. That is one of the\r\nreasons this kind of malware is on the rise.\r\nA 2015 study published by Microsoft [1] shows this increase:\r\n2014 saw exponential infections from ransomware, with families such as Ransom:JS/Krypterade, Win32/C\r\nWin32/Reveton, and Win32/Teerac garnering more than 4 million infections. The start of 2015 introduce\r\ncharacters such as Win32/Tescrypt and Win32/Troldesh.\r\nDue to their nature, most of the files encrypted with a ransomware are impossible to retrieve. Microsoft agrees [2]:\r\nDue to the encryption of the files, it can be practically impossible to reverse-engineer the encrypti\r\nthe files without the original encryption key – which only the attackers will have access to.\r\nCompromise\r\nThe discovery of the so-called Patient Zero is really important in order to understand how an incident happened.\r\nIn our case, we easily identified a RDP service opened on the Internet. Through the computer's logs, we identified\r\nthat a successful authentication of the Administrator user on that service was the root of that compromise. Indeed\r\nwe then noticed that the password used was really weak and could be found in any dictionaries.\r\nFrom there we were able to locate the malware (that was still running on the infected computer) and decided to\r\nanalyze it.\r\nAnalysis\r\nIn this section, we describe the main steps of the ransomware which are common to this kind of malware.\r\nConfiguration decryption\r\nThe first task done by the ransomware is to decrypt a block of 73476 bytes located at the address 0x00413FF8:\r\ni = 0;\r\ndo\r\n{\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 2 of 14\n\nif ( i * 4 \u0026 1 )\r\n config[i] ^= 0xAF67D12E;\r\n else\r\n config[i] ^= 0xF76742E2;\r\n ++i;\r\n}\r\nwhile ( i \u003c 18369 );\r\nThis block contains its configuration. Here is a list of the data contained in it:\r\nSize (on 4 bytes) of the RSA key in bytes\r\nThe RSA modulus\r\n00413FF8 80 00 00 00 B5 EF D6 45 33 3D 7B 75 57 96 FD 0A Ç...Á´ÍE3={uWû².\r\n00414008 2A E3 DB 56 78 38 57 CA 2C E3 64 33 AC 8A 75 57 *Ò¦Vx8W-,Òd3¼èuW\r\n00414018 6A 71 64 A0 62 53 1B AC C7 05 A7 23 60 CA 00 47 jqdábS.¼Ã.º#`-.G\r\n00414028 C2 62 58 EC C2 34 AA D1 AE FD 86 F9 EA 78 56 6D -bXý-4¬Ð«²å¨ÛxVm\r\n00414038 C9 83 A4 7D A1 59 C2 29 F7 07 42 F1 C0 40 AE E6 +âñ}íY-)¸.B±+@«µ\r\n00414048 CB F4 E3 EA 47 36 56 03 7F 99 31 D6 CE E8 AB 94 -¶ÒÛG6V..Ö1Í+Þ½ö\r\n00414058 F5 B9 AC 64 F1 0D C8 17 ED 0A 90 24 DB CA 71 00 §¦¼d±.+.Ý..$¦-q.\r\n00414068 30 E8 80 93 3B 93 24 E9 F6 8F 8C 5B BB D3 78 76 0ÞÇô;ô$Ú÷.î[+Ëxv\r\n00414078 CE 5F FB C3 00 00 00 00 00 00 00 00 00 00 00 00 +_¹+............\r\nThe RSA exponent\r\n004141F2 00 00 00 00 00 00 04 00 00 00 00 01 00 01 00 00 ................\r\nList of drive letter to infect\r\n00414472 00 00 00 00 00 00 41 00 42 00 43 00 44 00 45 00 ......A.B.C.D.E.\r\n00414482 46 00 47 00 48 00 49 00 4A 00 4B 00 4C 00 4D 00 F.G.H.I.J.K.L.M.\r\n00414492 4E 00 4F 00 50 00 51 00 52 00 53 00 54 00 55 00 N.O.P.Q.R.S.T.U.\r\n004144A2 56 00 57 00 58 00 59 00 5A 00 00 00 00 00 00 00 V.W.X.Y.Z.......\r\nThe magic number for the encrypted file's footer\r\n004144F8 30 30 35 50 52 5A 00 00 00 00 00 00 00 00 00 00 005PRZ..........\r\nThe email address to ask the ransom from\r\n00414578 2E 00 7B 00 61 00 5F 00 70 00 72 00 69 00 6E 00 ..{.a._.p.r.i.n.\r\n00414588 63 00 40 00 61 00 6F 00 6C 00 2E 00 63 00 6F 00 c.@.a.o.l...c.o.\r\n00414598 6D 00 7D 00 00 00 00 00 00 00 00 00 00 00 00 00 m.}.............\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 3 of 14\n\nThe extension for the encrypted file\r\n004145F8 2E 00 78 00 74 00 62 00 6C 00 00 00 00 00 00 00 ..x.t.b.l.......\r\nThe name of the mutex\r\n00414678 47 00 6C 00 6F 00 62 00 61 00 6C 00 5C 00 73 00 G.l.o.b.a.l.\\.s.\r\n00414688 6E 00 63 00 5F 00 00 00 00 00 00 00 00 00 00 00 n.c._...........\r\nThe folder to exclude from encryption\r\n00415678 25 00 77 00 69 00 6E 00 64 00 69 00 72 00 25 00 %.w.i.n.d.i.r.%.\r\nThe registry key for persistence\r\n004147F8 53 00 6F 00 66 00 74 00 77 00 61 00 72 00 65 00 S.o.f.t.w.a.r.e.\r\n00414808 5C 00 4D 00 69 00 63 00 72 00 6F 00 73 00 6F 00 \\.M.i.c.r.o.s.o.\r\n00414818 66 00 74 00 5C 00 57 00 69 00 6E 00 64 00 6F 00 f.t.\\.W.i.n.d.o.\r\n00414828 77 00 73 00 5C 00 43 00 75 00 72 00 72 00 65 00 w.s.\\.C.u.r.r.e.\r\n00414838 6E 00 74 00 56 00 65 00 72 00 73 00 69 00 6F 00 n.t.V.e.r.s.i.o.\r\n00414848 6E 00 5C 00 52 00 75 00 6E 00 00 00 00 00 00 00 n.\\.R.u.n.......\r\nA list of files to exclude from encryption\r\n004151F8 45 00 78 00 70 00 6C 00 6F 00 72 00 65 00 72 00 E.x.p.l.o.r.e.r.\r\n00415208 2E 00 65 00 78 00 65 00 3B 00 53 00 76 00 63 00 ..e.x.e.;.S.v.c.\r\n00415218 68 00 6F 00 73 00 74 00 2E 00 65 00 78 00 65 00 h.o.s.t...e.x.e.\r\nThe name of the files that contain decryption instructions to follow in order to pay the ransom (dropped on\r\ndisk):\r\n00414978 44 00 45 00 43 00 52 00 59 00 50 00 54 00 2E 00 D.E.C.R.Y.P.T...\r\n00414988 6A 00 70 00 67 00 00 00 00 00 00 00 00 00 00 00 j.p.g...........\r\n00414A78 44 00 45 00 43 00 50 00 59 00 50 00 54 00 20 00 D.E.C.P.Y.P.T. .\r\n00414A88 46 00 49 00 4C 00 45 00 53 00 2E 00 74 00 78 00 F.I.L.E.S...t.x.\r\n00414A98 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 t...............\r\nThe file DECPYPT FILES.txt obviously contain a typo (P instead of R). The only reason we found is the fact the\r\nP and R are on the same keyboard key on russian keyboard layout..\r\nThe instructions picture looks like that:\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 4 of 14\n\nThanks to a famous search engine and a russian OCR tool, this is the text in english:\r\nYour data is encrypted using the latest encryption algorithm.\r\nIf you want to restore the data, send 1 encrypted file by e-mail to\r\nа_princ@аоl.com\r\nYou have 48 hours otherwise keys are removed\r\nHe wants one encrypted file, probably to be sure that we have been infected by his cryptolocker. Ransom demand\r\nprobably comes as a response to the email.\r\nPersistence\r\nThe ransomware tries to copy itself in %windir% then %appdata%.\r\nOnce done, it creates a registry key System Service under\r\nSoftware\\Microsoft\\Windows\\CurrentVersion\\Run in order to be run at startup, thus achieving persistence\r\nif (v9 \u0026\u0026 GetModuleFileNameW(0, v0, 0x7FFFu))\r\n{\r\n if ((wcscpy_s(v1, 0x7FFFu, \"%windir%\\\\System32\"), wcscat_s(v1, 0x7FFFu, L\"\\\\\"), wcscat_s(v1, 0x7F\r\n ExpandEnvString(v1)) \u0026\u0026 CopyFileTo(v0, v1) ||\r\n (wcscpy_s(v1, 0x7FFFu, \"%localappdata%\"), wcscat_s(v1, 0x7FFFu, L\"\\\\\"), wcscat_s(v1, 0x7FFFu, C\r\n ExpandEnvString(v1)) \u0026\u0026 CopyFileTo(v0, v1))\r\n {\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 5 of 14\n\nif (RegOpenKeyExW(HKEY_LOCAL_MACHINE, \u0026SubKey, 0, 0x20106u, \u0026phkResult) ||\r\n (v5 = RegSetValueExW(phkResult, \"System Service\", 0, 1u, v1, 2 * wcslen(v1)) == 0,\r\n RegCloseKey(phkResult), !v5))\r\n {\r\n if (!RegOpenKeyExW(HKEY_CURRENT_USER, \u0026SubKey, 0, 0x20106u, \u0026phkResult))\r\n {\r\n RegSetValueExW(phkResult, \"System Service\", 0, 1u, v1, 2 * wcslen(v1));\r\n RegCloseKey(phkResult);\r\n }\r\n }\r\n }\r\n}\r\nNote: The name of this registry key is contained in the configuration data inside the binary and may change.\r\nOperation\r\nAfter this, the ransomware adds three files to the exception list:\r\nDECRYPT.jpg\r\nDECPYPT FILES.txt\r\nthe name of the running binary\r\nIt then uses the GetLogicalDrives function to get the list of drives present on the machine.\r\nwhile (1){\r\n v2 = GetLogicalDrives();\r\n v14 = v2;\r\n if ( v1 != v2 ){\r\n driveIndex = 0;\r\n v13 = v2 \u0026 ~v1 \u0026 0xFFFFFFFC;\r\n v16 = 1;\r\n v15 = 0;\r\n do{\r\n if (v13 \u0026 v16){\r\n Src = *\u0026aAbcdefghijklmn[driveIndex];\r\n v10 = malloc(0x1002Cu);\r\n *v10 = *lpThreadParameter;\r\n *(v10 + 16385) = *(lpThreadParameter + 16385);\r\n *(v10 + 16386) = *(lpThreadParameter + 16386);\r\n *(v10 + 16387) = *(lpThreadParameter + 16387);\r\n wcscpy_s(v10 + 2, 0x7FFFu, \u0026Src);\r\n CreateThread(0, 0, sub_401A90, v10, 0, 0);\r\n driveIndex = v15;\r\n v2 = v14;\r\n }\r\n driveIndex += 2;\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 6 of 14\n\nv16 = __ROL4__(v16, 1);\r\n v15 = driveIndex;\r\n }\r\n while ( driveIndex \u003c '@' );\r\n v1 = v2;\r\n }\r\n Sleep(0x64u);\r\n}\r\nOn each of these logical drives, a thread is launched. Inside each of those threads, four other threads are launched\r\ndo\r\n *(\u0026Handles + v1++) = CreateThread(0, 0, StartAddress, \u0026Parameter, 0, 0);\r\nwhile ( v1 \u003c 4 );\r\nEach of these previous threads will walk through folders recursively and will encrypt each file.\r\nEncryption\r\nIn this section, we analyzed the different steps involving the encryption scheme used by the ransomware.\r\nKey generation\r\nThe key is the most important operation of the ransomware as all the files will be encrypted with it.\r\nThe ransomware uses two (2) different sources of data, more or less random, to generate the 256 bits of the key.\r\nFirst, it calls the _ftime64 function to get a 64-bit time value by default. Only the epochs time in seconds\r\nand the current number of milliseconds will be used by the ransomware. This data represents 8 bytes of\r\ndata stored at 0x00426c44.\r\n_ftime64(\u0026data);\r\ndword_426C44 ^= 1000 * ms;\r\ndword_426C48 ^= ((1000 * ms) \u003e\u003e 32) | data;\r\nThe second source of data is the result of a call to the rand function of the libc. This call will add 4 bytes of\r\ndata.\r\nqword_426C4C = rand() ^ qword_426C4C; // qword_426C4C = 0\r\nA 256 bits memory space is allocated for the key and then filled with zeroes. The number of milliseconds\r\nmultiplied by 1000 is copied. Then the epochs time in seconds. And finally, the rand value.\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 7 of 14\n\n00426C44 08 3A 04 00 FE 56 4F 57 29 00 00 00 00 00 00 00 .:..¦VOW).......\r\n00426C54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\r\nAs shown on the previous picture, more than 50% of the space is not updated with random or selected values and\r\nstay filled with zeroes.\r\nFrom there, the ransomware computes the MD5 hash of these 256 bits to get 16 bytes of data.\r\nmd5CTX[0] = 0x67452301;\r\nmd5CTX[1] = 0xEFCDAB89;\r\nmd5CTX[2] = 0x98BADCFE;\r\nmd5CTX[3] = 0x10325476;\r\nmd5_update(32, md5CTX, \u0026dword_426C44);\r\nmd5_final(md5CTX);\r\nThese 16 bytes are then used as a key to encrypt the 256 bits using the RC4 algorithm.\r\nrc4_init(\u0026rc4CTX, \u0026data);\r\n...\r\nmemcpy(a1, \u0026data, lenToGenerated);\r\nrc4_encrypt(\u0026rc4CTX, a1, 32);\r\nThe resulting encrypted data is the key used to encrypt the files of the system.\r\nTo sum up:\r\nKEY = RC4(MD5(data), data)\r\ndata = [epochs][milliseconds*1000][rand()][0000][0000][0000][0000][0000]\r\n(each [] = 4 bytes)\r\nWe can consider that the key is computed from 96 bits of data or only 74 bits if we consider the maximal\r\nmillisecond value being 999.\r\nWeaknesses\r\nYou may have already found the weaknesses in this encryption scheme.\r\nThe epochs time in seconds can be guessed from the date of last modification of the encrypted files. Even\r\nif the timestamp has been corrupted, it is still possible to bruteforce the value over a few days.\r\nRegarding the number of milliseconds, there is no real weakness other than the number of milliseconds\r\nitself. Only 1000 possible values.\r\nThe third weakness is the call of the rand function. As it is not securely seeded before, and this call is\r\nalways the first call to this function, the value returned by rand is always the same (0x00000029).\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 8 of 14\n\nFinally, if we consider that we want to bruteforce the timestamp on 10 days, the key generation algorithm\r\ntakes around 20 bits for the timestamp and 10 bits for the number of milliseconds.\r\nA bruteforce should then require only a few minutes to find the key.\r\nKey encryption\r\nAfter the key generation, the key is encrypted using RSA and a 1024 bits key located in the config at 0x00413ffc.\r\nExponent is also in the config at 0x004141fc.\r\n00413FFC B5 EF D6 45 33 3D 7B 75 57 96 FD 0A 2A E3 DB 56 Á´ÍE3={uWû².*Ò¦V\r\n0041400C 78 38 57 CA 2C E3 64 33 AC 8A 75 57 6A 71 64 A0 x8W-,Òd3¼èuWjqdá\r\n0041401C 62 53 1B AC C7 05 A7 23 60 CA 00 47 C2 62 58 EC bS.¼Ã.º#`-.G-bXý\r\n0041402C C2 34 AA D1 AE FD 86 F9 EA 78 56 6D C9 83 A4 7D -4¬Ð«²å¨ÛxVm+âñ}\r\n0041403C A1 59 C2 29 F7 07 42 F1 C0 40 AE E6 CB F4 E3 EA íY-)¸.B±+@«µ-¶ÒÛ\r\n0041404C 47 36 56 03 7F 99 31 D6 CE E8 AB 94 F5 B9 AC 64 G6V..Ö1Í+Þ½ö§¦¼d\r\n0041405C F1 0D C8 17 ED 0A 90 24 DB CA 71 00 30 E8 80 93 ±.+.Ý..$¦-q.0ÞÇô\r\n0041406C 3B 93 24 E9 F6 8F 8C 5B BB D3 78 76 CE 5F FB C3 ;ô$Ú÷.î[+Ëxv+_¹+\r\n...\r\n004141FC 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................\r\nAs the size of the data to encrypt is only 32 bytes (256 bits), padding is added to the key before encryption.\r\nPadding is generated from the rand function, probably following the OAEP padding scheme.\r\nFile encryption\r\nThe ransomware uses the AES encryption algorithm with a 256 bits key in CBC mode. For each file, a random IV\r\nis generated using the same function than the key.\r\nThis IV is added in the data at the end of each encrypted file with the magic, the padding length and the encrypted\r\nkey.\r\nWriteFile(f, \u0026magic, 6u, \u0026NumberOfBytesWritten, 0); // 005PRZ\r\nWriteFile(f, \u0026IV, 0x10u, \u0026NumberOfBytesWritten, 0);\r\nWriteFile(f, \u0026paddingLen, 1u, \u0026NumberOfBytesWritten, 0);\r\nWriteFile(f, (RSA + 32), 0x80u, \u0026NumberOfBytesWritten, 0);\r\nAn example result is depicted below:\r\n00103810 30 30 35 50 52 5A D2 5A 22 94 F0 BD DA A1 A0 2B 005PRZ.Z\"......+\r\n00103820 3F 97 C4 0F 23 F8 10 57 5D BA C9 61 03 AF 34 0C ?...#..W]..a..4.\r\n00103830 76 4D 73 6B 3A 6D 15 77 DD E6 83 EE FD 3C 9E D1 vMsk:m.w.....\u003c..\r\n00103840 15 BC B9 91 38 BC 16 9E 02 3C 83 F2 42 2F 3F 89 ....8....\u003c..B/?.\r\n00103850 89 33 E0 94 C6 C7 FB EE C2 28 7B 0B 65 69 D8 76 .3.......({.ei.v\r\n00103860 FC 55 E4 E9 FA 74 74 26 6C 01 52 19 6B CC 4F 1D .U...tt\u0026l.R.k.O.\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 9 of 14\n\n00103870 0B 36 3E 55 63 29 1F 9E 87 F0 90 EB 12 81 5A 08 .6\u003eUc)........Z.\r\n00103880 E5 15 27 10 28 41 6A 14 6A DF 48 E2 BE 2D FE 71 ..'.(Aj.j.H..-.q\r\n00103890 55 63 22 83 CB C4 BA 4B AE 92 98 73 5C E0 B9 04 Uc\"....K...s\\...\r\n001038A0 F2 3F 3F CF 26 56 AD .??.\u0026V.\r\nAfter the file is encrypted, it is deleted.\r\nif ( v8 )\r\n{\r\n SetFileAttributesW(a4, dwFileAttributes);\r\n if ( !*(v12 + 172) )\r\n DeleteFileW(lpFileName);\r\n}\r\nresult = v8;\r\nDecryption\r\nIn this section, we describe the different steps to recover the encryption key and decrypt the files.\r\nBruteforce the secret key\r\nBruteforcing the key requires a way to identify when we find the correct key. For that, we use the first 4 bytes\r\n(magic number) of several known filetypes because their header never changes. So, we need at least one encrypted\r\nfile with the corresponding filetype.\r\nIn the following tables, some of the magic numbers values:\r\nExtension First 4 bytes\r\n.exe,.dll 4D5A9000\r\n.docx 504b0304\r\n.xlsx 504b0304\r\n.pptx 504b0304\r\n.zip 504b0304\r\n.jpeg ffd8ffe0\r\n.png 89504E47\r\n.pdf 25504446\r\n.rtf 7b5c7274\r\nThe algorithm used to bruteforce the key is :\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 10 of 14\n\nfor timestamp in range(start, end):\r\n for millisecond in range(1000):\r\n Key = GenerateKey(timestamp, millisecond*1000)\r\n if Decrypt(encryptedFile[:4]) == header:\r\n return KEY_FOUND\r\nreturn KEY_NOT_FOUND\r\nKey identification\r\nAs the ransomware is designed to be run at startup, it is possible that files on the same machine were encrypted\r\nwith different keys. If we want to decrypt all files on a machine, we need a way to identify whether we have the\r\nright key or not.\r\nFor that, we use the encrypted key block located at the end of each encrypted file. For each run, the ransomware\r\nwill encrypt the key using the RSA 1024 bits key and the result is added at the end of the encrypted file.\r\nWhen we finally find the right key for a file, we can store the encrypted key separately. And when we need to\r\ndecrypt a file, we only need to compare the encrypted key stored against the one stored previously.\r\nKey decryption\r\nThe ransomware uses a 1024 bits modulus with 0x10001 exponent to encrypt the key. Thus, there is no way of\r\ndecrypting the key except if you made some progresses in quantum computing.\r\nFile decryption\r\nIf we have the encryption key, we are able to decrypt the file using the IV stored at the end of each encrypted file\r\nwith AES256 in CBC mode using the freshly retrieved key.\r\nWe also need to remove the last x bytes of the decrypted data by using the padding value stored in each encrypted\r\nfile footer.\r\nIndicator of compromise\r\nHere is a list of IOCs for this ransomware:\r\nFiles with xtbl or {a_princ@aol.com}.xtbl extension\r\nProcess with mutex starting with snc_\r\nPE files present in %appdata% or %windir% with that fingerprint:\r\nAlgorithm Fingerprint\r\nMD5 ebcdda10fdfaa38e417d25977546df4f\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 11 of 14\n\nAlgorithm Fingerprint\r\nSHA1 5b58de17843ac44adc91b41883828cf5b3a11744\r\nSHA256 3c4588fe87146b9c1d0c97a5175bc287d8350ace3f4188d3cd2458638fcd8d97\r\nMachoc\r\nhttps://raw.githubusercontent.com/sogeti-esec-lab/ransomware-xtbl-decrypt-tool/master/machoc-signature.txt\r\nDecryption\r\nWe developed a tool that decrypts files encrypted by this malware only. First, the tool will recover the encryption\r\nkey using one encrypted file.\r\nPlease use an encrypted file with the last modification timestamp untouched.\r\nThen the files on each disk of the machine will be decrypted.\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 12 of 14\n\nThos tool is available on github:\r\nSources\r\nCompiled executable\r\nConclusion\r\nStatistics show that the threat of being infected by a ransomware has only begun. Each month, more and more\r\nransomware variants are detected.\r\nSome of them do not use state of the art cryptography yet, or badly use it to encrypt files, such as in our case. But\r\nin most cases, there is no way to decrypt the file without having the secret key of the attacker.\r\nHere, the fail comes from the rand function call which is not correctly seeded beforehand, the use of the\r\ntimestamp which can easily be bruteforced and the number of milliseconds which holds a limited space of\r\npossibilities.\r\nThis post also highlights the good cooperation between the Pentest and the R\u0026D team of Sogeti ESEC. For that,\r\nspecial thanks to lerobert, jbedrine, meik, who also worked on this incident response.\r\n[1] https://www.microsoft.com/security/portal/enterprise/threatreports_september_2015.aspx\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 13 of 14\n\n[2] https://www.microsoft.com/en-us/security/portal/mmpc/shared/ransomware.aspx\r\nSource: http://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.htm\r\nl\r\nhttp://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html\r\nPage 14 of 14\n\nSize (on The RSA 4 bytes) of the RSA modulus key in bytes  \n00413FF8 80 00 00 00 B5 EF D6 45 33 3D 7B 75 57 96 FD 0A Ç...Á´ÍE3={uWû².\n00414008 2A E3 DB 56 78 38 57 CA 2C E3 64 33 AC 8A 75 57 *Ò¦Vx8W-,Òd3¼èuW\n00414018 6A 71 64 A0 62 53 1B AC C7 05 A7 23 60 CA 00 47 jqdábS.¼Ã.º#`-.G\n00414028 C2 62 58 EC C2 34 AA D1 AE FD 86 F9 EA 78 56 6D-bXý-4¬Ð«²å¨ÛxVm\n00414038 C9 83 A4 7D A1 59 C2 29 F7 07 42 F1 C0 40 AE E6 +âñ}íY-)¸.B±+@«µ\n00414048 CB F4 E3 EA 47 36 56 03 7F 99 31 D6 CE E8 AB 94-¶ÒÛG6V..Ö1Í+Þ½ö\n00414058 F5 B9 AC 64 F1 0D C8 17 ED 0A 90 24 DB CA 71 00 §¦¼d±.+.Ý..$¦-q.\n00414068 30 E8 80 93 3B 93 24 E9 F6 8F 8C 5B BB D3 78 76 0ÞÇô;ô$Ú÷.î[+Ëxv\n00414078 CE 5F FB C3 00 00 00 00 00 00 00 00 00 00 00 00 +_¹+............\nThe RSA exponent   \n004141F2 00 00 00 00 00 00 04 00 00 00 00 01 00 01 00 00 ................\nList of drive letter to infect   \n00414472 00 00 00 00 00 00 41 00 42 00 43 00 44 00 45 00 ......A.B.C.D.E.\n00414482 46 00 47 00 48 00 49 00 4A 00 4B 00 4C 00 4D 00 F.G.H.I.J.K.L.M.\n00414492 4E 00 4F 00 50 00 51 00 52 00 53 00 54 00 55 00 N.O.P.Q.R.S.T.U.\n004144A2 56 00 57 00 58 00 59 00 5A 00 00 00 00 00 00 00 V.W.X.Y.Z.......\nThe magic number for the encrypted file's footer \n004144F8 30 30 35 50 52 5A 00 00 00 00 00 00 00 00 00 00 005PRZ..........\nThe email address to ask the ransom from  \n00414578 2E 00 7B 00 61 00 5F 00 70 00 72 00 69 00 6E 00 ..{.a._.p.r.i.n.\n00414588 63 00 40 00 61 00 6F 00 6C 00 2E 00 63 00 6F 00 c.@.a.o.l...c.o.\n00414598 6D 00 7D 00 00 00 00 00 00 00 00 00 00 00 00 00 m.}.............\n   Page 3 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://web.archive.org/web/20191008053714/http://esec-lab.sogeti.com/posts/2016/06/07/the-story-of-yet-another-ransomfailware.html"
	],
	"report_names": [
		"the-story-of-yet-another-ransomfailware.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434925,
	"ts_updated_at": 1775826709,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b0826e418e582d763cad60eec39a29f4cb35e309.pdf",
		"text": "https://archive.orkl.eu/b0826e418e582d763cad60eec39a29f4cb35e309.txt",
		"img": "https://archive.orkl.eu/b0826e418e582d763cad60eec39a29f4cb35e309.jpg"
	}
}