{ "id": "3d77a6a0-f800-4f09-b90d-c1e38037b294", "created_at": "2026-04-06T00:16:50.707514Z", "updated_at": "2026-04-10T03:20:34.397897Z", "deleted_at": null, "sha1_hash": "85e1e567cddecc8537c6f4665f5d01af7fc60597", "title": "Taking the FIRST look at Crypt0l0cker", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 922918, "plain_text": "Taking the FIRST look at Crypt0l0cker\r\nBy Alexander Chiu\r\nPublished: 2017-08-03 ยท Archived: 2026-04-05 15:05:55 UTC\r\nThursday, August 3, 2017 11:35\r\nThis post is authored by Matthew Molyett.\r\nExecutive Summary In March, Talos reported on the details of Crypt0l0cker based\r\non an extensive analysis I carried out on the sample binaries. Binaries -- plural --\r\nbecause, as noted in the original blog, the Crypt0l0cker payload leveraged\r\nnumerous executable files which shared the same codebase. Those executables had\r\nnearly identical functions in each, but identifying all of those functions repeatedly\r\nis tedious and draws time away from improving the analysis. Enter FIRST, the\r\nFunction Identification and Recovery Signature Tool released by Talos in\r\nDecember 2016.\r\nFIRST allowed me to port my analysis from the unpacking dll to the payload file instantly. Once I was satisfied\r\nmy analysis across both files, I was then handed a suspected previous version of the sample. FIRST was able to\r\nidentify similar code across the versions and partially port the analysis back to the older file. When the next\r\nversion of Crypt0l0cker comes out, I will be able to get a jump on my analysis by using FIRST to port that work\r\nforward to the similar code. You can use it to port my work to your sample as well. I will demonstrate doing just\r\nthat with a Crypt0l0cker sample which appeared on VirusTotal in April 2017, more than a month after the Talos\r\nblog about it. There has been no targeted analysis of this file to provide background for this post.\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 1 of 9\n\nLocating the Sample Procuring a malware sample of a known family without\r\nanalyzing it can feel like a heavy challenge to overcome. Thankfully, Talos can\r\nleverage Threat Grid sandbox reports of suspected malware samples that we\r\nreceive. Such reports can be scanned for family IOCs. Per our previous analysis\r\ninto Crypt0l0cker, the infection status of that version is stored in a file named\r\newiwobiz. By searching Cisco Threat Grid telemetry for files which created\r\newiwobiz, I identified a file which was probably a Crypt0l0cker executable.\r\nWith a report to investigate, I needed to procure the actual sample. My sandbox report shows that the suspected\r\nCrypt0l0cker file is nearly 400 kb and likely a Nullsoft Installer file, which is a common packager. Static file\r\ninformation gives me the file hash which arms me with the ability to continue my investigation on VirusTotal.\r\nWhile the sample is clearly malicious, my VirusTotal inspection does not suggest that the sample belongs to any\r\nknown family. No detections refer to Crypt0l0cker, TorrentLocker, a listed alias in the original Talos blog, nor\r\nTeerac.\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 2 of 9\n\nWith a file sample in hand, and no static indication that I have located Crypt0l0cker, I move onto FIRST to\r\ndiscover how similar it is to known files.\r\nExploring the Sample\r\nAs the FIRST client code is an IDA Pro plugin, my first step was opening the file in my local IDA copy and allow\r\nauto-analysis. Upon completion, the start function was displayed in front of me at the graph view. I opened up the\r\ngraph view context menu and requested FIRST lookups for all of the discovered functions.\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 3 of 9\n\nAfter a minute, the FIRST display shows that 13 of the functions have been previously identified and uploaded.\r\nExpanding the matched functions displays the metadata associated with that function, including a proposed name\r\nand function prototype. Notice that the files detected in this installer have been named to draw attention to the fact\r\nthat these functions are known to be in NullSoft Installers. I had previously marked up a different NullSoft\r\nInstaller before and uploaded significant functions from it to assure that I would not do so again. In general, a\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 4 of 9\n\nmalware analyst is wasting any time spent inspecting such a file. Identifying when a packer is in use and moving\r\nalong to the true payload is a much better use of time.\r\nCheck the Select Highest Ranked checkbox and click Apply. The function names get applied across the database\r\nand we can see clearly that the sandbox analysis was correct. This file is a packer and we need to extract the\r\noriginal.\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 5 of 9\n\nUnpacking the Sample I admit that at this point I cheated to perform the unpack.\r\nFrom previous extraction of Crypt0l0cker files protected with NullSoft I already\r\nknew that the install script consisted of consuming multiple encrypted blobs,\r\ninternally decrypt the payload, and run it via Process Hollowing. As such, allowing\r\nit to run debugged and breaking on WriteProcessMemory should present the\r\npayload buffer to me.\r\nThere was a complication though, because the install script loaded and unloaded System.dll many times. The\r\nModLoad notification caused the debugger to consume the majority of the process cycles, effectively causing a\r\ndenial of service against the debugger. I allowed this system to run for over an hour without getting beyond this\r\ndelay.\r\nBy disabling the ModLoad notification via `sxi ld` I could get my debugger to allow the System.dll file to be\r\nloaded without triggering the significant extra processing. Crypt0l0cker then was able to spike up to 99% of the\r\nCPU use to, rather than the debugger holding on to 80%.\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 6 of 9\n\nI dumped out the PE image file and prepared to continue with FIRST.\r\nExploring the Real File\r\nAgain, the first step of using FIRST was opening the extracted file in IDA Pro. This file was built as a Windows\r\nGUI file on top of the Visual Studio C runtime. Thus, the runtime was identified during auto-analysis and I was\r\nleft with a graph view displaying the _WinMain@16 function. Using the FIRST command from the context menu,\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 7 of 9\n\nI checked for the existence of metadata for just that one function. It was discovered as\r\nCrytp0l0cker_WinMain@16. Looking pretty likely that this is, in fact, Crytp0l0cker.\r\nWith confidence that FIRST will be useful, since it had a result for _WinMain@16, I began the search for the full\r\nfile. At 436 functions this is not a quick lookup, so go get a fresh cup of coffee and let FIRST work. Since this file\r\nuses a known runtime, the runtime files are also known to FIRST. You can filter those functions with the Show\r\nonly \"sub_\" functions checkbox.\r\nAfter FIRST completes 78 new function markups are applied out of 295 total known functions. With 78\r\nCrytp0l0cker_* functions identified, you can now dig in on the shoulder of days of professional malware analysis.\r\nIOC\r\nFile Hash d845e4f2292ba78a993dbbf6f1317894ce1a795c096d7959f3d718e583f1cea3\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 8 of 9\n\nSource: http://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nhttp://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "http://blog.talosintelligence.com/2017/08/first-look-crypt0l0cker.html" ], "report_names": [ "first-look-crypt0l0cker.html" ], "threat_actors": [], "ts_created_at": 1775434610, "ts_updated_at": 1775791234, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/85e1e567cddecc8537c6f4665f5d01af7fc60597.pdf", "text": "https://archive.orkl.eu/85e1e567cddecc8537c6f4665f5d01af7fc60597.txt", "img": "https://archive.orkl.eu/85e1e567cddecc8537c6f4665f5d01af7fc60597.jpg" } }