{
	"id": "a79d449f-52a0-479c-b976-77f59c3b4389",
	"created_at": "2026-04-06T00:16:54.672735Z",
	"updated_at": "2026-04-10T03:21:17.255704Z",
	"deleted_at": null,
	"sha1_hash": "7a95992210e534fda9e7cf3195dd1bb6990e7ce2",
	"title": "Conti Ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1567482,
	"plain_text": "Conti Ransomware\r\nBy Chuong Dong\r\nPublished: 2020-12-15 · Archived: 2026-04-05 17:13:53 UTC\r\nReverse Engineering  · 15 Dec 2020\r\nOverview\r\nThis is my full analysis for the Conti Ransomware version 2. Over the last few months, I have seen quite a few\r\ncompanies getting hit by this ransomware, so it’s been interesting analyzing and figuring how it works.\r\nAs one of the newer ransomware families, Conti utilizes multi-threading features on Windows to encrypt files on\r\nmachines To the fullest extent, making itself a lot faster than most ransomware out there.\r\nFrom the analysis, it’s clear that Conti is designed to target and encrypt business environments that uses SMB for\r\nfile sharing and other services. Similar to the Sodinokibi family, Conti has the ability to scan existing ports and\r\nSMB shares on the network to spread its encryption, which can be a lot more impactful since it is not limited to\r\nthe local machine.\r\nBy the time this blog post comes out, researchers have found newer samples of the version 3. Even though this is\r\nan old sample, I still think it’s beneficial to provide the community with a deeper understanding about this\r\nmalware.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 1 of 25\n\nFigure 1: Conti overview\r\nIOCS\r\nConti Ransomware version 2 comes in the form of a 32-bit PE file (either .exe or .dll).\r\nMD5: 0a49ed1c5419bb9752821d856f7ce4ff\r\nSHA256: 03b9c7a3b73f15dfc2dcb0b74f3e971fdda7d1d1e2010c6d1861043f90a2fecd\r\nSample:\r\nhttps://bazaar.abuse.ch/sample/03b9c7a3b73f15dfc2dcb0b74f3e971fdda7d1d1e2010c6d1861043f90a2fecd/\r\nUnpacked sample:\r\nhttps://bazaar.abuse.ch/sample/d3c75c5bc4ae087d547bd722bd84478ee6baf8c3355b930f26cc19777cd39d4c/\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 2 of 25\n\nFigure 2: VirusTotal result\r\nRansom Note\r\nFigure 3: Conti Ransom Note\r\nThe ID appended at the end is actually hard-coded, so it’s not a victim’s ID. This ID is most likely just the ID of\r\nthis particular Conti sample.\r\nBelow is the HTTPS version of the website for recovery service.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 3 of 25\n\nFigure 4: Conti Website\r\nDependencies\r\nThe ransomware only has Kernel32.dll, User32.dll, and WS2_32.dll as visible imported DLLs.\r\nHowever, it does dynamically resolve a lot of DLLs through decrypting stack strings and calling LoadLibrary as\r\nseen here.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 4 of 25\n\nFigure 5: Conti resolving DLL string names (sub_571010)\r\nHere is the full list of the imported DLLs.\r\nKernel32.dll\r\nNtdll.dll\r\nOle32.dll\r\nShell32.dll\r\nWs2_32.dll\r\nShlwapi.dll\r\nAdvapi32.dll\r\nIphlpapi.dll\r\nRstrtmgr.dll\r\nNetapi32.dll\r\nOleAut32_dll\r\nUser32.dll\r\nPE Layout\r\nThe unpacked version of the malware is around 208 KB in size, which consists of the .text, .rdata, .data, .rsrc,\r\nand .reloc sections.\r\nOne of the main reasons why this executable is so big is because of the obsfucation method the developer uses.\r\nInstead of implementing a single string decryption function, they used one decrypting for loop for each encrypted\r\nstring, which greatly increased the amount of raw code.\r\nFigure 6: Conti Layout\r\nCode Analysis\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 5 of 25\n\nString Decryption\r\nAs mentioned above, Conti uses the method of building up a stack “string” that is encrypted and proceeds to\r\ndecrypt it with a for loop. Every string is encrypted differently, so the for loop changes slightly for each of them.\r\nFigure 7: String decryption of explorer.exe (sub_58B2D0)\r\nMost of the decryption loops can be simplified to this single form where buffer is the encrypted string, a and b\r\nare positive numbers, and c is either 1 or -1.\r\nfor i in range(len(buffer)):\r\n buffer[i] = (a * (c * (buffer[i] - b)) % 127 + 127) % 127\r\nDynamically Resolve API\r\nWhen resolving APIs, Conti calls a particular function that takes in an integer representing the DLL to find, an\r\nAPI hash value, and an offset into the API buffer.\r\nThe DLL name is retrieved from the given integer through a switch statement.\r\n15 ==\u003e Kernel32.dll\r\n16 ==\u003e Ws2_32.dll\r\n17 ==\u003e Netapi32.dll\r\n18 ==\u003e Iphlpapi.dll\r\n19 ==\u003e Rstrtmgr.dll\r\n20 ==\u003e User32.dll\r\n21 ==\u003e Ws2_32.dll\r\n22 ==\u003e Shlwapi.dll\r\n23 ==\u003e Shell32.dll\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 6 of 25\n\n24 ==\u003e Ole32.dll\r\n25 ==\u003e OleAut32.dll\r\n26 ==\u003e Ntdll.dll\r\nAfter getting the DLL name, Conti will manually locate the export directory of that DLL, loop through each API,\r\nhash the name, and compare it with the hash from the parameter. After finding the correct API with the right hash\r\nvalue, it will proceed to find the address to that function.\r\nFigure 8: Function looping through export table and hash API name (sub_5737C0)\r\nFor the hashing algorithm, the constant 0x5BD1E995 gives this away that this is Murmur Hash\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 7 of 25\n\nFigure 9: Conti’s Murmur Hashing implementation (sub_575970)\r\nAfter finding the address of the API, the malware adds that into its API array at the provided offset. This helps\r\nreducing the time to look up an API’s address if the malware has already resolved it before.\r\nRun-once Mutex\r\nConti attempts to decrypt the string “jkbmusop9iqkamvcrewuyy777” and use that as the name of a Mutex\r\nobject.\r\nThen, it checks if there is an instant of that Mutex running already. If there is, it will just wait until that thread\r\nexits before exiting.\r\nFigure 10: Checking for Mutex (sub_587E20)\r\nCommand-line Arguments\r\nConti can only be ran with command-line arguments, so it must be launched by a loader. Upon execution, it will\r\nprocess these arguments and behave accordingly.\r\nCMD Args Functionality\r\n-m local Encrypting the local machine’s hard drive with multiple threads\r\n-m net Encrypting network shares via SMB with mutiple threads\r\n-m all Encrypting both locally and on the network with multiple threads\r\n-p [directory] Encrypt a specific directory locally with 1 thread\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 8 of 25\n\nCMD Args Functionality\r\n-size [chunk mode] Large encryption chunk mode\r\n-log [file name] Logging mode. Log everything to the file with the given name\r\nbackups Unimplemented for some reason\r\nEncryption\r\nDespite having 3 different encrypting schemes, the main mechanism is relatively the same.\r\nFirst, it calls a function to populate a structure used to initialize information about the thread/threads of that\r\nencrypting schemes. These information includes the number of threads to spawn and a thread buffer that is used to\r\nstore thread HANDLE objects.\r\nFigure 11: Function initializing thread struct (sub_58BDB0)\r\nNext, it calls this function to launch child threads. It checks the thread struct to see if the encrypting flag is set. If\r\nit is, loop from 0 to thread_count - 1 and spawn a thread to encrypt each time. It also adds these threads into the\r\nthread buffer for easy clean-up later.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 9 of 25\n\nFigure 12: Function launching encrypting threads (sub_58BE30)\r\nMulti-threading\r\nBeside when the argument -p is provided, multi-threading is involved for every other scheme of encryption. Conti\r\nwill call GetNativeSystemInfo to retrieve information about the running system.\r\nIf the argument “-m all” is provided, the number of threads to spawn will be double the amount of processors\r\nbecause it needs to encrypt both locally and on the network.\r\nFor everything else, the number of threads to spawn is the same as the number of processors.\r\nFigure 13: Determining how many threads to spawn from number of processor (sub_587E20)\r\nBeing able to thread its encryption, Conti utilizes all of the CPU threads available to simultaneously go through\r\nand encrypt the file system with incredible speed.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 10 of 25\n\nFigure 14: Realistic representation of what happens when Conti runs\r\nThe most interesting information in the thread structure is the string of the path to be encrypted. After having\r\nlaunch the threads, Conti’s main program will continuously traverse the file system and provide the thread\r\nstructure with directory names. All of these threads will check this information and encrypt the updated path\r\nimmediately. Because the workload is divided efficiently, Conti is able to speed up its traversing and encryption to\r\na great extent.\r\nFigure 15: Main thread providing the drives to be encrypted (sub_587E20)\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 11 of 25\n\nEncrypting Locally\r\nRSA Public Key\r\nFirst, each thread will call CryptAcquireContextA with the cryptographic provider type PROV_RSA_AES to\r\nretrieve a handle of a CSP for RSA encryption. Using that CSP, it will call CryptImportKey to import from the\r\nhard-coded RSA public key.\r\nFigure 16: RSA Public Key embedded in the .data section\r\nFigure 17: CryptAcquireContextA and CryptImportKey called (sub_58BC20)\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 12 of 25\n\nNext, it will enter an infinite loop to wait for the main thread to add a target drive path or to send a stop signal.\r\nThis is accomplished solely through the shared thread struct that was created before launching these threads.\r\nBecause the struct is shared between multiple threads, calls to EnterCriticalSection and LeaveCriticalSection\r\nare critical to maintain a thread-safe environment during encryption.\r\nFigure 18: Each thread continuously polling for a path name and encrypt it (sub_58BC20)\r\nIn the main encrypting function, it will iteratively call FindFirstFile on the directory name to search for all files\r\nand folders inside, avoiding the two current path and parent path names ”.” and ”..” which can cause an infinite\r\nloop if processed.\r\nDirectory Check\r\nIf the file being checked is a directory, it will check to see if the directory name is valid or not. If it is, then the\r\nchild thread will add that path to the thread struct for itself or any other available thread to encrypt.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 13 of 25\n\nFigure 19: Checking if the path is a valid directory (sub_586340)\r\nThese are the directory name that Conti will avoid encrypting.\r\ntmp, winnt, temp, thumb, $Recycle.Bin, $RECYCLE.BIN, System Volume Information, Boot, Windows, Trend Micro\r\nNormal File Check\r\nIf the file is just a normal file, Conti will check to see if the file name is valid before proceed to encrypt it.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 14 of 25\n\nFigure 20: Checking if the path is a valid file (sub_586340)\r\nConti will avoid encrypting any file with these names or extensions.\r\nCONTI_LOG.txt, readme.txt, .msi, .sys, .lnk, .dll, .exe\r\nNormal File Encryption\r\nFirst, Conti populates a structure in memory. I call this structure CONTI_STRUCT.\r\nstruct CONTI_STRUCT\r\n{\r\n char *file_name;\r\n HANDLE hFile;\r\n LARGE_INTEGER file_size;\r\n int CHACHA8_const[4];\r\n int CHACHA8_256_KEY[8];\r\n int block_counter;\r\n int block_counter_ptr;\r\n int CHACHA8_none[2];\r\n int random1[2];\r\n int random2[8];\r\n BYTE encrypted_key[524]; // encrypted ChaCha8 key\r\n};\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 15 of 25\n\nConti will call CryptGenRandom to generate 2 different random buffers and put them into the\r\nCONTI_STRUCT. Then, it populates the ChaCha8 constants which is just “expand 32-byte k” in hex form.\r\nThe first buffer is 256 bits, which is later used as the ChaCha8 encrypting key, and the second one is 64 bits,\r\nwhich is used as the ChaCha8 nonce.\r\nNext, it will copy the key and nonce into the buffer at the end of the struct and encrypt it using the RSA key\r\nimported earlier. This is to ensure that the ChaCha key can not be recovered without the RSA private key.\r\nFigure 21: Generating random number (sub_5805A0)\r\nFigure 22: Populating ChaCha8 constants and encrypt the random numbers with the RSA key (sub_5805A0)\r\nConti has 3 file categories for encryption - small, medium, and large files. Small files are marked with the value of\r\n0x24, medium with 0x26, and large with 0x25.\r\nBefore encryption, Conti will write the encrypted ChaCha8 key from CONTI_STRUCT, this mark, and the file\r\nsize to at the end of the to-be-encrypted file.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 16 of 25\n\nFigure 23: Writing the encrypted random ChaCha8 key, mark, and size to file (sub_57E4B0)\r\nFigure 24: The key at the end of an encrypted file\r\n1. Small File\r\nSmall files are files that are potentially less than 1MB in size. Conti looks for all files that is smaller than 1MB or\r\nby checking for these extensions below.\r\n.4dd, .4dl, .accdb, .accdc, .accde, .accdr, .accdt, .accft, .adb, .ade, .adf, .adp, .arc, .ora,\r\n.alf, .ask, .btr, .bdf, .cat, .cdb, .ckp, .cma, .cpd, .dacpac, .dad, .dadiagrams, .daschema, .db,\r\n.db-shm, .db-wal, .db3, .dbc, .dbf, .dbs, .dbt, .dbv, .dbx, .dcb, .dct, .dcx, .ddl, .dlis, .dp1,\r\n.dqy, .dsk, .dsn, .dtsx, .dxl, .eco, .ecx, .edb, .epim, .exb, .fcd, .fdb, .fic, .fmp, .fmp12, .fmpsl,\r\n.fol, .fp3, .fp4, .fp5, .fp7, .fpt, .frm, .gdb, .grdb, .gwi, .hdb, .his, .ib, .idb, .ihx, .itdb, .itw,\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 17 of 25\n\n.jet, .jtx, .kdb, .kexi, .kexic, .kexis, .lgc, .lwx, .maf, .maq, .mar, .mas, .mav, .mdb, .mdf, .mpd, .mud,\r\n.mwb, .myd, .ndf, .nnt, .nrmlib, .ns2, .ns3, .ns4, .nsf, .nv, .nv2, .nwdb, .nyf, .odb, .oqy, .orx, .owc,\r\n.p96, .p97, .pan, .pdb, .pdm, .pnz, .qry, .qvd, .rbf, .rctd, .rod, .rodx, .rpd, .rsd, .sas7bdat, .sbf, .scx,\r\n.sdb, .sdc, .sdf, .sis, .spq, .sql, .sqlite, .sqlite3, .sqlitedb, .te, .temx, .tmd, .tps, .trc, .trm, .udb,\r\n.udl, .usr, .v12, .vis, .vpd, .vvv, .wdb, .wmdb, .wrk, .xdb, .xld, .xmlff, .abcddb, .abs, .abx, .accdw, .adn,\r\n.db2, .fm5, .hjt, .icg, .icr, .kdb, .lut, .maw, .mdn, .mdt\r\nEncrypting small files are straightforward. Since these files are small enough, it typically does not require to loop\r\nand encrypt more than once. The file content is read into a buffer and encrypted directly. Just to be safe, the\r\nmalware author did limit the maximum buffer size to read to 5MB, but it’s unlikely that the files going into this\r\nfunction is that big.\r\nFigure 25: Small File Encrypting mechanism (sub_580460)\r\n2. Medium File\r\nMedium files are files that are between 1MB to 5MB.\r\nFor these files, Conti only encrypts the first 1 MB of the files.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 18 of 25\n\nFigure 26: Medium File Encrypting mechanism (sub_5805A0)\r\n3. Large file\r\nLarge files are files that are larger than 5MB. Conti specifically looks for these by checking for these extensions.\r\n.vdi, .vhd, .vmdk, .pvm, .vmem, .vmsn, .vmsd, .nvram, .vmx, .raw, .qcow2, .subvol, .bin, .vsv, .avhd, .vmrs, .v\r\n.avdx, .vmcx, .iso\r\nThe large file encrypting function processes the -size chunk mode argument and uses it in a switch statement to\r\ndetermine the encrypting offset and the encrypting size.\r\nAccording to Michael Gillespie, here are the chunk mode values:\r\n0x14 (default) ==\u003e represent 3 chunks of (file_size / 100 * 7)\r\n0x32 ==\u003e represent 5 chunks of (file_size / 100 * 10)\r\nThe mechanism of encrypting can be simplify to this. Basically, Conti will encrypt encrypt_length amount of\r\nbytes and skip the next encrypt_offset before encrypting again until it reaches the end of the file. This makes\r\nencryption quicker for large files because it does not have to encrypt everything.\r\nAlso according to Michael, Conti has a bug where the keystream sometime goes out of sync in-between chunks\r\nduring encryption because the encrypted buffer size is rounded up to the nearest 64 which is the ChaCha state\r\nmatrix size.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 19 of 25\n\nFigure 27: Large File Encrypting mechanism (sub_57FFD0)\r\n4. ChaCha8 Encryption\r\nThe ChaCha8 implementation is pretty straightforward. The 256-byte key that was randomly generated earlier is\r\nthen used as the encrypting key.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 20 of 25\n\nFigure 28: Conti’s ChaCha8 implementation (sub_575AC0)\r\nIn order to be able to decrypt the files, we need to know the random key that Conti uses for each file, and the only\r\nway to retrieve it is through the encrypted key buffer at the end of the file.\r\nSince that buffer is encrypted with a public RSA key, we need the private RSA key to decrypt this.\r\nNonetheless, since they are using a hard-coded public key, if anyone pays the ransom for this Conti version, the\r\nprivate key can be retrieved. It will be simple to write a decrypting tool if that is the case, and all of the samples\r\nwith this ID will become useless after.\r\nThis implementation clearly reflects how the Conti group mainly targets big companies instead of aiming to\r\nspread the malware to normal computer users. Once a company (or anyone) pays off the ransom, they have to\r\ndiscard all of the samples that use the private key and develop newer samples to spread.\r\nFigure 29: Conti’s Encryption method\r\nDelete Shadow Copy with COM Objects\r\nBefore encrypting, Conti’s main thread calls CoInitializeEx, CoInitializeSecurity, and CoCreateInstance to\r\ncreates a single object of the class IWbemLocator with the specified CLSID 4590F811-1D3A-11D0-891F-00AA004B2E24.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 21 of 25\n\nFigure 30: Initializing COM Object (sub_576B80)\r\nNext, it checks if the processor architecture of the machine is x86-64 . If it is, then Conti will call\r\nCoCreateInstance to create a single object of the class IWbemContext with the specified CLSID 674B6698-\r\nEE92-11D0-AD71-00C04FD8FDFF.\r\nWith this Call Context object, it can modify the __ProviderArchitecture to force load the specified provider\r\nversion which is 64-bit architecture.\r\nFigure 31: Force load 64-bit if needed (sub_576B80)\r\nUsing the IWbemLocator object earlier, Conti calls its ConnectServer method to connect with the local\r\nROOT\\CIMV2 namespace and obtain the pointer to an IWbemServices object.\r\nFigure 32: Connecting to ROOT\\CIMV2 to get IWbemServices object (sub_576B80)\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 22 of 25\n\nWith this IWbemServices object, it executes the SQL query “SELECT * FROM Win32_ShadowCopy” to\r\nretrieve a enumerator of all the shadow copies stored in the local server.\r\nBy enumerating through these informations, Conti extracts the ID of each shadow copy, add that to the format\r\nstring “cmd.exe /c C:\\Windows\\System32\\wbem\\WMIC.exe shadowcopy where “ID=’%s’” delete”, and\r\ncreate a new process to execute. This will eventually deletes all the shadow copy storage areas in the computer.\r\nFigure 33: Building cmd string to delete shadowcopy based on ID (sub_576B80)\r\nNetwork Encryption\r\nFor the network encryption, Conti calls CreateIoCompletionPort to spawn as many concurrently running threads\r\nas there are processors in the system, and these threads waits for a list of network shares to start encryption.\r\nFigure 34: CreateIoCompletionPort to spawn network encrypting thread (sub_58A6F0)\r\nThe main thread then calls NetShareEnum to get an enumerator to extract information about shared network\r\nresources. This scans the system to see if there exists any existing SMB network shares.\r\nAfter getting this “ARP” cache, it will check if the IP addresses of hosts in the list start with “172.”, “192.168.”,\r\n“10.”, and “169.”. Since it only cares about encrypting local systems, any other IP address ranges is ignored.\r\nIt will then scan and look for every shares with the name that is not “ADMIN$”, get the full path to the shares,\r\nand add it to an array of network shares.\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 23 of 25\n\nFigure 35: Scanning SMB for all existing SMB network shares (sub_5898D0)\r\nAfter extracting this, it will loop through and call the function from Figure 15 to push these share names into the\r\nthread struct so the child threads can begin encrypting.\r\nIf scanning SMB for network hosts fails, Conti will perform just a port scan using CreateIoCompletionPort\r\nGetQueuedCompletionStatus, and PostQueuedCompletionStatus\r\nFigure 36: Conti port scans (sub_58A370)\r\nAfter this point, the encryption happens the same as the local encryption, with share names being pushed into the\r\nshared thread struct for the child processes to encrypt.\r\nKey findings\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 24 of 25\n\nOverall, Conti ransomware is a sophisticated sample with many unique functionalities. By sacrificing the\r\ntremendous increase in size, the Conti team has implement a really troublesome string encryption method, which\r\nended up taking me a while to go through and resolve all of the strings.\r\nThe encryption scheme is a bit boring with a randomly generated key protected by a hard-coded public RSA key.\r\nHowever, the multi-threading encryption is implemented elegantly using a shared structure between all of the\r\nthreads, which results in extreme encrypting speed. Conti also avoids encrypting large files entirely, so it’s\r\nobvious that the malware authors prioritize speed over encrypting quality. With its networking functionality, the\r\nransomware actively looks for available shares on the network to spread its encryption. This mainly targets small\r\nbusiness and enterprise fields that uses the SMB protocol for file sharing, as we have seen with Advantech,\r\nRiverside Community Care, Ixsight Technologies, Total Systems Services, …\r\nNOTE: For anyone who wants to analyze this sample further, you should set up a folder on your machine and\r\nruns the ransomware with the command line argument “-p [directory]” to test encryption on that directory only.\r\nIt’s a pretty neat way to set up a small environment for testing and dynamic analysis that the authors have\r\nprovided us with, so huge shoutout to them for that!\r\nReferences\r\nhttps://twitter.com/Arkbird_SOLG/status/1337565128561225728\r\nhttps://twitter.com/VK_Intel/status/1297252264126685185\r\nhttps://www.bleepingcomputer.com/news/security/conti-ransomware-shows-signs-of-being-ryuks-successor/\r\nhttps://www.carbonblack.com/blog/tau-threat-discovery-conti-ransomware/\r\nhttps://id-ransomware.malwarehunterteam.com/identify.php?\r\ncase=2c61281154a1c9df22081099c5c36503a63e9b01\r\nhttps://twitter.com/demonslay335/status/1339975671817318400\r\nSource: http://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nhttp://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/\r\nPage 25 of 25\n\n  http://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/    \nFigure 23: Writing the encrypted random ChaCha8 key, mark, and size to file (sub_57E4B0)  \nFigure 24: The key at the end of an encrypted file    \n1. Small File      \nSmall files are files that are potentially less than 1MB in size. Conti looks for all files that is smaller than 1MB or\nby checking for these extensions below.    \n.4dd, .4dl, .accdb, .accdc, .accde, .accdr, .accdt, .accft, .adb, .ade, .adf, .adp, .arc, .ora,\n.alf, .ask, .btr, .bdf, .cat, .cdb, .ckp, .cma, .cpd, .dacpac, .dad, .dadiagrams, .daschema, .db,\n.db-shm, .db-wal, .db3, .dbc, .dbf, .dbs, .dbt, .dbv, .dbx, .dcb, .dct, .dcx, .ddl, .dlis, .dp1,\n.dqy, .dsk, .dsn, .dtsx, .dxl, .eco, .ecx, .edb, .epim, .exb, .fcd, .fdb, .fic, .fmp, .fmp12, .fmpsl,\n.fol, .fp3, .fp4, .fp5, .fp7, .fpt, .frm, .gdb, .grdb, .gwi, .hdb, .his, .ib, .idb, .ihx, .itdb, .itw,\n   Page 17 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"http://chuongdong.com/reverse%20engineering/2020/12/15/ContiRansomware/"
	],
	"report_names": [
		"ContiRansomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434614,
	"ts_updated_at": 1775791277,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7a95992210e534fda9e7cf3195dd1bb6990e7ce2.pdf",
		"text": "https://archive.orkl.eu/7a95992210e534fda9e7cf3195dd1bb6990e7ce2.txt",
		"img": "https://archive.orkl.eu/7a95992210e534fda9e7cf3195dd1bb6990e7ce2.jpg"
	}
}