{
	"id": "5fd3dc18-3a5a-4617-be26-7b31a6fa67cf",
	"created_at": "2026-04-06T01:30:29.833467Z",
	"updated_at": "2026-04-10T03:38:09.649915Z",
	"deleted_at": null,
	"sha1_hash": "65f63554395ee76623d4d50ba0cc49672480df85",
	"title": "In-Depth Analysis of Lynx Ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 903115,
	"plain_text": "In-Depth Analysis of Lynx Ransomware\r\nBy Nextron Threat Research Team\r\nPublished: 2026-03-30 · Archived: 2026-04-06 00:13:40 UTC\r\nIntroduction\r\nLynx ransomware is a newly emerged and sophisticated malware threat that has been active since mid-2024. Lynx\r\nransomware has claimed over 20 victims across a range of industries. Once it infiltrates a system, it encrypts\r\ncritical files, appending a ‘.lynx’ extension, and deletes backup files like shadow copies to hinder recovery.\r\nUniquely, it also sends the ransom note to available printers, adding an unexpected element to its attack strategy.\r\nThis malware shares similarities with previous INC ransomware, indicating that they bought INC ransomware\r\nsource code.\r\nThe first sample was identified by rivitna2, checking VT showed it had only 26 detections which is a low\r\ndetection rate for a ransomware sample,so we decided to dive deeper.\r\nNote: Rapid7 wrote a quick analysis on a Lynx ransomware sample highlighting some of its functionalities, check\r\nthe blog here.\r\nOverview\r\nLynx ransomware employs a variety of techniques such as:\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 1 of 34\n\nTerminating processes and services.\r\nDirectory enumeration.\r\nPrivilege escalation.\r\nDeleting shadow copies.\r\nEncrypting all mounted drives and shared folders.\r\nChanging the background image.\r\nPrinting the ransomware note.\r\nBy default when executed the ransomware will encrypt every file on the system but in addition to that it also\r\nallows the attacker to customize the ransomware behaviour via command line flags which are highlighted below :\r\n–file Encrypt specified file\r\n–dir Encrypt specified directory\r\n–help Print every argument and it`s usage\r\n–verbose Enable verbosity\r\n–stop-processes stop processes via RestartManager\r\n–encrypt-network Encrypt network shares\r\n–load-drives Mount available volumes\r\n–hide-cmd Hide console window (not used)\r\n–no-background Don’t change background image\r\n–no-print Don’t print note on printers\r\n–kill Kill processes \u0026 services\r\n–safe-mode Enter safe-mode (not used)\r\nA comprehensive list of Indicators of Compromise (IOCs) is available at the end of this article.\r\nIn the next section, we will take a closer look at Lynx ransomware and analyze its inner workings, including key\r\naspects such as its encryption implementation and file processing methods.\r\nFull Ransomware Analysis\r\nThe ransomware starts by calling main function and assigning flags based on the parameters passed to the\r\nransomware.\r\nTerminate Process\r\nPassing the kill flag, the malware begins by enumerating all running processes and terminates any process whose\r\nname contains any of the following words:\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 2 of 34\n\nsql\r\nveeam\r\nbackup\r\nexchange\r\njava\r\nnotepad\r\nFirst, CreateToolhelp32Snapshot is called with the TH32CS_SNAPPROCESS flag to capture a snapshot of all\r\nprocesses in the system. Passing 0 indicates that all processes are included.\r\nNext, Process32FirstW retrieves information about the first process in the snapshot and stores it in the pe\r\nstructure.\r\nFor each process, the code compares its name (pe.szExeFile) with the target process names array using a case-insensitive search function.\r\nIf a process name matches, OpenProcess is called with the PROCESS_TERMINATE flag to obtain a handle to the\r\nprocess.\r\nFinally, TerminateProcess is called to terminate the matched process.\r\nEnumerate Services Function\r\nThe function enumerates and terminates services along with its dependent services, if the display name or service\r\nname contains any of the words mentioned above.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 3 of 34\n\nOpenSCManagerW is used to obtain a handle to the service control manager database with full access\r\npermissions.\r\nThe services are enumerated and stored in lpServices.\r\nA loop processes each service in the list, checking if it matches any of the target service names.\r\nIf a match is found, stop_services is called to stop the service along with its dependent services.\r\nStop Services Function\r\nThe function attempts to stop a specified service along with its dependent services.\r\nOpenSCManagerW is used to obtain a handle to the Service Control Manager with full access permissions.\r\nOpenServiceW is used to open the specified service with the required access rights\r\n(SERVICE_QUERY_STATUS, SERVICE_ENUMERATE_DEPENDENTS, and SERVICE_STOP).\r\nQueryServiceStatusEx is used to query the current status of the service.\r\nThe dependent services are enumerated and stopped recursively by calling stop_services for each dependent\r\nservice.\r\nControlService is called to send a stop command to the service.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 4 of 34\n\nThe ransome note is base64 decoded then it’s passed to a function to\r\nreplace every occurrence of %id% with the victim ID 66a204aee7861ae72f21b4e0\r\nYour data is stolen and encrypted.\r\nYour unique identificator is %id%\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 5 of 34\n\nUse this TOR site to contact with us:\r\nhttp://lynxch2k5xi35j7hlbmwl7d6u2oz4vp2wqp6qkwol624cod3d6iqiyqd.onion/login\r\nUse this email to contact with us:\r\nmartina.lestariid1898@proton.me\r\nOur blog\r\n ~ TOR Network: http://lynxbllrfr5262yvbgtqoyq76s7mpztcqkv6tjjxgpilpma7nyoeohyd.onion/disclosures\r\n ~ Mirror #1: http://lynxblog.net/\r\nThe malware begins setting up a multi-threaded environment for the encryption operation using the Windows I/O\r\nCompletion Port mechanism.\r\nFirst, the function call populates the SystemInfo structure with information about the current system, such as the\r\nnumber of processors.\r\nThe number of threads to be used is set to four times the number of processors in the system. This aims to\r\nleverage multi-threading to speed up disk encryption.\r\nAn I/O Completion Port is then created to manage asynchronous I/O operations.\r\n0xffffffff: This parameter indicates that no file handle is associated with the completion port initially.\r\n0: This parameter specifies that the completion port is not associated with an existing port.\r\n0: The completion key is set to zero, and the last parameter specifies the maximum number of threads that can run\r\nconcurrently. If it’s zero, it defaults to the number of processors.\r\nIt Creates a thread for each processor to handle I/O completion.\r\nEach thread runs the Encryption function and uses the CompletionPort for synchronization.\r\nThe encryption function will be discussed later.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 6 of 34\n\nEnumerate Directory Function\r\nThe function attempts to create a README.txt file in a specified directory, it uses the FindFirstFileW function in\r\norder to find the first file in the directory.\r\nA loop iterates over each file and directory, special directories notations like ‘.’ and ‘..’ , as well as reparse points,\r\nare skipped.\r\nFor each file, the function checks if it is a system file or has certain extensions such as ‘.exe’, ‘.msi’, ‘.dll’, ‘.lynx’,\r\nif the file does not match these criteria and is not named LYNX or README.txt, it is queued for encryption by\r\ncreating a new thread.\r\nFor each subdirectory, a recursive call to ‘enum_dir’ is made.\r\nSpecial directories like ‘windows’, ‘program files’, and others are skipped to avoid processing system directories.\r\nIt Handles “Program Files” and “Program Files (x86)” separately, for each subdirectory within, a recursive call to\r\n‘enum_dir’ searching for “microsoft sql server” directory to be encrypted.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 7 of 34\n\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 8 of 34\n\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 9 of 34\n\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 10 of 34\n\nPrepare Encryption Function\r\nThis function performs several tasks:\r\nIt checks if it has write access to the file that is to be encrypted.\r\nIf it does not, it attempts privilege escalation and checks again for write access.\r\nIf a ‘stop_processes_flag’ flag is passed, the function attempts to terminate every process that has an open handle\r\nto the file at that moment.\r\nIf all these attempts fail, the file will not be encrypted.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 11 of 34\n\nCheck Write Access Function\r\nThis function essentially checks if the malware has write access to the file being encrypted.\r\nIt does this by writing a dummy data of 36 bytes of the character “2” at the end of the file.\r\nIt then verifies if the written data is indeed 36 bytes.\r\nIf so then the data was written successfully, indicating that the malware has write access to the file.\r\nSetFilePointerEx moves the file pointer to the end of the file.\r\nAfter writing the data, the file pointer is moved back to its original position.\r\nFinally, SetEndOfFile truncates the file, effectively removing the written data.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 12 of 34\n\nPrivilege Escalation function\r\nIf the write check fails the ransomware will call priv_escalation which tries to enable ‘SeTakeOwnershipPrivilege’\r\non the current process token.\r\nThis privilege will allow the process to take ownership of an object without being granted discretionary access,\r\nWith this privilege, the user can take ownership of any securable object in the system effectively granting the\r\nransomware write access.\r\nFrom a code perspective the following is how write access is granted:\r\n1- The function starts by taking ownership of a file or directory and sets its security descriptor to grant full control\r\nto a specified group.\r\n2- AllocateAndInitializeSid is called to create a SID for the specified group.\r\n3- The EXPLICIT_ACCESS structure is set up to define the permissions (full control) for the new ACL.\r\n4- SetEntriesInAclW is called to create a new ACL that grants these permissions.\r\n5- SetNamedSecurityInfoW is used to set the DACL for the file or directory.\r\n6- A handle to the current process token is opened using OpenProcessToken.\r\n7- LookupPrivilegeValueW is used to get the LUID for the SeTakeOwnershipPrivilege.\r\n9- The LUID is needed to adjust the token’s privileges.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 13 of 34\n\n10- AdjustTokenPrivileges is called to enable the SeTakeOwnershipPrivilege for the current process access token,\r\nthis privilege is required to change the owner of the file or directory.\r\n11- SetNamedSecurityInfoW is used again to set the ownership of the file or directory to the specified SID, this\r\nstep changes the owner of the file or directory to the specified SID, the OWNER_SECURITY_INFORMATION\r\nflag is used to specify that the owner is being set.\r\n12- LookupPrivilegeValueW is used to retrieve the LUID for SeTakeOwnershipPrivilege again, which is needed to\r\ndisable the privilege in the next step\r\n13- AdjustTokenPrivileges is used to disable the SeTakeOwnershipPrivilege privilege in the current process’s\r\naccess token, returning the token to its original state.\r\n14- SetNamedSecurityInfoW is used to re-apply the DACL to ensure that the permissions are set correctly.\r\nTerminate Process Using Restart Manager Function\r\nThe function terminates every process that has an open handle to the file to be encrypted, it leverages the Restart\r\nManager (RM) API to identify these processes and then terminates them, while avoiding the termination of\r\n‘Windows Explorer’, ‘critical system processes’, and processes that the current user does not have permission to\r\nshut down.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 14 of 34\n\nRmStartSession initiates a new Restart Manager session.\r\nRmRegisterResources registers the specified file as a resource to be managed within this session.\r\nRmGetList retrieves the list of processes currently using the specified file.\r\nThe function then iterates through this list of processes. It ensures that it avoids terminating Windows Explorer\r\n(RmExplorer) and critical system processes (RmCritical). For each process, it verifies that the process is not the\r\ncurrent one and opens it with PROCESS_TERMINATE access.\r\nIt then calls TerminateProcess to terminate the process and waits for the termination to complete using\r\nWaitForSingleObject.\r\nAdditionally, the function decodes the ECC public key and passes it to generate_aes_key. It uses the ECC\r\ncurve25519 to create a shared secret, which is then hashed with SHA512. This hashed value is used as the AES\r\nkey and is passed to AESKeyExpansion to generate the round keys.\r\nThe marker contains the following data of a total of 116 byte that will be appended at the end of the encrypted file:\r\nECC public key (32 bytes)\r\nSHA512(ECC public key) (64 bytes)\r\n\"LYNX\"\r\n00 00 00 00 (unknown purpose)\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 15 of 34\n\n40 42 0F 00 (representing 1,000,000 – 1MB – encryption block size)\r\n05 00 00 00 (possibly the encryption block step – will be explained later )\r\n01 00 00 00 (number of skipped blocks a block is 5MB)\r\nand it sets switch_value to equal 2.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 16 of 34\n\nAfter setting up the necessary structures and starting the asynchronous read operation, the function calls\r\nCreateIoCompletionPort to associate the file handle with the completion port.\r\nAs the function performs operations like reading the file, it uses the OVERLAPPED structure to manage\r\nasynchronous operations. When an operation completes, it posts a completion packet to the I/O completion port\r\nindicating that the file is ready for encryption.\r\nThe Encryption function waits for these completion packets using GetQueuedCompletionStatus. When it receives\r\na completion packet, it processes the operation based on the switch_value set in the OVERLAPPED structure by\r\nprepare_encryption.\r\nThe Encryption function receives this packet and transitions to encrypting the file data.\r\nEncryption Function\r\nThe Encryption function starts by setting up the environment and parameters it needs to operate.\r\nIt waits for I/O completion packets using the GetQueuedCompletionStatus function.\r\nWaiting for I/O Completion:\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 17 of 34\n\nThe function continuously waits for an I/O completion packet. When a packet is received, it processes the\r\noperation based on the switch_value.\r\nthe switch block handles 4 cases:\r\ncase 0\r\ncase 1\r\ncase 2\r\ncase 3\r\nas mentioned above the switch_value is set to 2, so we start explaning case 2.\r\nCase 2 :\r\nThe function checks if the read_counter is equal to 0.\r\nread_counter is used to count how many blocks are read/encrypted.\r\nwhich leaves us with 2 cases:\r\n1 – read_counter = 0 indicates that this is our first block to read/encrypt.\r\nIt doesn’t evaluate next_enc_block_offset.\r\n2 – read_counter != 0 indicates that it’s not the first block to read/encrypt.\r\nif it’s not the first block to be encrypt, next_enc_block_offset is evaluated, next_enc_block_offset is used to\r\nindicate where the next block to be encrypted .\r\nExample:\r\nthe malware encrypt 1MB at the start of the file and then encrypt 1MB starting at 6MB , so it skips 5MB every\r\ntime.\r\nIt also write the marker at the end of the file.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 18 of 34\n\nCase 0 :\r\nThe function checks if the next_enc_block_offset is bigger than the filesize which means there is no more data to\r\nencrypt, and that the read_counter not equal to 0 and that means it’s not our first encryption block.\r\nif so it then sets switch_code to 3 ( case 3 – ends the encryption – no more data to encrypt).\r\nif not then there are more data to be encrypt.\r\nCase 1 :\r\nthe condition aims to determine how many bytes will be read/encrypted.\r\nlet’s break it down with example.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 19 of 34\n\nlet’s assume we have 6.5 MB of data to be encrypted, remember that there is a marker written at the end of the file\r\n(case 2 )so it will be 6.5MB + 0x74 bytes.\r\nThe first 1MB will be encrypted normally, and then it start encrypting starting from 6MB which is only the last\r\n0.5MB but the malware reads 1MB each time so it will read 0.5 MB + 0x74 byteS (which we don’t want it to be\r\nencrypted).\r\nThe condition is trying to know how to get the right size of data to be written.\r\nit’s doing a simple math: lpNumberOfBytesRead + next_enc_block_offset – filesize which for the given example\r\nwould be:\r\nlpNumberOfBytesRead = 0.5MB + 0x74 bytes\r\nnext_enc_block_offset = 6MB\r\nfilesize = 6.5 MB\r\nso the result is 0x74 , if the the result is equal to 0x74 it will basically subtract the marker size from\r\nlpNumberOfBytesRead and assign that to lpNumberOfBytesWritten, lpNumberOfBytesWritten = 0.5 MB which\r\nis what we want.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 20 of 34\n\nIt then increments the read_counter, which tracks how many blocks of data have been read to be encrypted.\r\nThe AES-CTR round keys are prepared to encrypt the data.\r\nCase 3 :\r\nIt renames the encrypted file to its final name and close all open handles.\r\nAES-CTR Encryption resulting keystream is XORed with the plaintext data to produce ciphertext.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 21 of 34\n\nThe nonce is incremented after each block to ensure a unique keystream for each block.\r\nThe encrypted data is written back to the file.\r\nThe function workflow is as the following:\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 22 of 34\n\nDelete Shadow Copies Function\r\nThe enc_del_shadow_copies function attempts to delete shadow copies on all available drives and then proceeds\r\nto enumerate directories and encrypt them , it although encrypt network shares if the encrypt_network_flag is set.\r\nThe function iterates over each possible drive letter (‘A’ to ‘Z’) and uses GetDriveTypeW to determine if the drive\r\nis removable, fixed, or remote.\r\nIt ignores drives that are not of these types, such as CD-ROM drives or non-existent drives.\r\nCreateFileW is called with paths in the format \\\\?\\A:\\ to create file handles for each drive.\r\nThe prefix \\\\?\\ instructs the Windows API to treat the path as a literal string and bypass normal path parsing rules,\r\nallowing the application to work with paths longer than MAX_PATH and to include special characters.\r\nThe string A: specifies the drive letter, and the :\\ following the drive letter indicates the root directory of that drive.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 23 of 34\n\nIt attempts to delete shadow copies using DeviceIoControl with the control code 0x53C028\r\n(IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE), setting the maximum size to 1.\r\nThe function enumerates each available drive to be encrypted.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 24 of 34\n\nEncrypt Shared Folders Function\r\nThis function enumerates network shares, processes each shared folder found, and handles nested resources\r\nrecursively.\r\nWNetOpenEnumW is called to start the enumeration of network resources. It uses RESOURCE_GLOBALNET to\r\nenumerate all network resources, RESOURCETYPE_ANY to include all types of resources, and 0x13u for\r\nadditional options.\r\nWNetEnumResourceW is called in a loop to enumerate network resources. It populates the currentResource buffer\r\nwith resource information and updates cCount with the number of resources.\r\nFor each resource, the loop iterates over the currentResource array.\r\nIf the resource’s display type is RESOURCEDISPLAYTYPE_SHARE, it indicates a shared folder.\r\nenum_dir is called to process the directory corresponding to the shared folder.\r\nIf the resource has a scope indicating it is a container (RESOURCEUSAGE_CONTAINER), enc_shared_folders\r\nis called recursively to enumerate its contents.\r\nRESOURCEUSAGE_CONTAINER means that this resource is a container and can be further enumerated to find\r\nadditional resources inside it.\r\nThis is commonly seen in network domains, servers, or other hierarchical structures in network environments.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 25 of 34\n\nMount Volume Function\r\nThe function mounts all available volumes to specific drive letters, ensuring that no drive letters are already\r\noccupied. It iterates through an array of drive letters, identifying unoccupied ones indicated by the\r\nDRIVE_NO_ROOT_DIR status.\r\nUsing FindFirstVolumeW and FindNextVolumeW, the function iterates through all volumes.\r\nIt then mounts each volume to an available drive letter from the lpszVolumeMountPoint array using\r\nSetVolumeMountPointW.\r\nThis process ensures that every drive is mounted, making it possible for them to be encrypted.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 26 of 34\n\nChange Background Function\r\nIt creates a temporary image file named “background-image.jpg” in the temp folder. This file contains the ransom\r\nnote as an image and sets it as the desktop wallpaper.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 27 of 34\n\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 28 of 34\n\nPrint Ransom Note Function\r\nThe function enumerates every printer connected to the system and sends the ransom note to be printed.\r\nEnumPrintersW is called to retrieve the list of printers.\r\nIt iterates through each printer, skipping “Microsoft Print to PDF” and “Microsoft XPS Document Writer”.\r\nFor each remaining printer, it uses StartDocPrinterW to start the document and StartPagePrinter to start a page.\r\nFinally, it uses WritePrinter to send the ransom note to the printer.\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 29 of 34\n\nIDA IDB\r\nYou can take a look at the IDA IDB for more details here.\r\nIndicators Of Compromise\r\nYou can find all IOCs and links to the latest version of the detection rules here.\r\nLYNX hashes:\r\neaa0e773eb593b0046452f420b6db8a47178c09e6db0fa68f6a2d42c3f48e3bc\r\n571f5de9dd0d509ed7e5242b9b7473c2b2cbb36ba64d38b32122a0a337d6cf8b\r\nb378b7ef0f906358eec595777a50f9bb5cc7bb6635e0f031d65b818a26bdc4ee\r\necbfea3e7869166dd418f15387bc33ce46f2c72168f571071916b5054d7f6e49\r\n85699c7180ad77f2ede0b15862bb7b51ad9df0478ed394866ac7fa9362bf5683\r\nINC hashes:\r\n64b249eb3ab5993e7bcf5c0130e5f31cbd79dabdcad97268042780726e68533f\r\n508a644d552f237615d1504aa1628566fe0e752a5bc0c882fa72b3155c322cef\r\n7f104a3dfda3a7fbdd9b910d00b0169328c5d2facc10dc17b4378612ffa82d51\r\n1754c9973bac8260412e5ec34bf5156f5bb157aa797f95ff4fc905439b74357a\r\nd147b202e98ce73802d7501366a036ea8993c4c06cdfc6921899efdd22d159c6\r\n05e4f234a0f177949f375a56b1a875c9ca3d2bee97a2cb73fc2708914416c5a9\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 30 of 34\n\nfef674fce37d5de43a4d36e86b2c0851d738f110a0d48bae4b2dab4c6a2c373e\r\n36e3c83e50a19ad1048dab7814f3922631990578aab0790401bc67dbcc90a72e\r\n869d6ae8c0568e40086fd817766a503bfe130c805748e7880704985890aca947\r\nee1d8ac9fef147f0751000c38ca5d72feceeaae803049a2cd49dcce15223b720\r\nf96ecd567d9a05a6adb33f07880eebf1d6a8709512302e363377065ca8f98f56\r\n3156ee399296d55e56788b487701eb07fd5c49db04f80f5ab3dc5c4e3c071be0\r\nfcefe50ed02c8d315272a94f860451bfd3d86fa6ffac215e69dfa26a7a5deced\r\n11cfd8e84704194ff9c56780858e9bbb9e82ff1b958149d74c43969d06ea10bd\r\n02472036db9ec498ae565b344f099263f3218ecb785282150e8565d5cac92461\r\ne17c601551dfded76ab99a233957c5c4acf0229b46cd7fc2175ead7fe1e3d261\r\n9ac550187c7c27a52c80e1c61def1d3d5e6dbae0e4eaeacf1a493908ffd3ec7d\r\nca9d2440850b730ba03b3a4f410760961d15eb87e55ec502908d2546cd6f598c\r\n1a7c754ae1933338c740c807ec3dcf5e18e438356990761fdc2e75a2685ebf4a\r\na5925db043e3142e31f21bc18549eb7df289d7c938d56dffe3f5905af11ab97a\r\n7ccea71dcec6042d83692ea9e1348f249b970af2d73c83af3f9d67c4434b2dd0\r\n5a8883ad96a944593103f2f7f3a692ea3cde1ede71cf3de6750eb7a044a61486\r\n1a7c754ae1933338c740c807ec3dcf5e18e438356990761fdc2e75a2685ebf4a\r\n463075274e328bd47d8092f4901e67f7fff6c5d972b5ffcf821d3c988797e8e3\r\nKey Description\r\nRansomware Note Name README.txt\r\nExtension .lynx\r\nECC Curve25519\r\nEncryption AES_CTR\r\nBackground image background-image.jpg\r\nDetection\r\nYara\r\nrule MAL_RANSOM_INC_Aug24 {\r\n meta:\r\n author = \"X__Junior\"\r\n description = \"Detects INC ransomware and it's variants like Lynx\"\r\n reference1 = \"https://x.com/rivitna2/status/1817681737251471471\"\r\n reference2 = \"https://twitter.com/rivitna2/status/1701739812733014313\"\r\n date = \"2024-08-08\"\r\n hash1 = \"eaa0e773eb593b0046452f420b6db8a47178c09e6db0fa68f6a2d42c3f48e3bc\" // LYNX\r\n hash2 = \"1754c9973bac8260412e5ec34bf5156f5bb157aa797f95ff4fc905439b74357a\" // INC\r\n score = 80\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 31 of 34\n\nstrings:\r\n $s1 = \"tarting full encryption in\" wide\r\n $s2 = \"oad hidden drives\" wide\r\n $s3 = \"ending note to printers\" ascii\r\n $s4 = \"uccessfully delete shadow copies from %c:/\" wide\r\n $op1 = { 33 C9 03 C6 83 C0 02 0F 92 C1 F7 D9 0B C8 51 E8 }\r\n $op2 = { 8B 44 24 [1-4] 6A 00 50 FF 35 ?? ?? ?? ?? 50 FF 15}\r\n $op3 = { 57 50 8D 45 ?? C7 45 ?? 00 00 00 00 50 6A 00 6A 00 6A 02 6A 00 6A 02 C7 45 ?? 00 00 00\r\n $op4 = { 6A FF 8D 4? ?? 5? 8D 4? ?? 5? 8D 4? ?? 5? 5? FF 15 ?? ?? ?? ?? 85 C0 }\r\n $op5 = { 56 6A 00 68 01 00 10 00 FF 15 ?? ?? ?? ?? 8B F0 83 FE FF 74 ?? 6A 00 56 FF 15 ?? ?? ??\r\n condition:\r\n uint16(0) == 0x5A4D and\r\n (\r\n 3 of ($s*)\r\n or 3 of ($op*)\r\n or (2 of ($s*) and 2 of ($op*) )\r\n )\r\n}\r\nSigma\r\nPotentially Suspicious Desktop Background Change Via Registry\r\nAppendix A\r\nDifferent encryption modes\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 32 of 34\n\nNextron’s Solutions for Enhanced Cybersecurity\r\nNextron steps in where traditional security measures might miss threats. Our digital forensics tools conduct\r\nthorough analyses of systems that show signs of unusual behavior. They effectively identify risky software and\r\nexpose a range of threats that could go unnoticed by standard methods.\r\nOur signature collection is tailored to detect a variety of security concerns. This includes hacker tools, their\r\nremnants, unusual user activities, hidden configuration settings, and legitimate software that might be misused for\r\nattacks. Our approach is especially useful in detecting the tactics used in supply chain attacks and identifying tools\r\nthat evade Antivirus and EDR systems.\r\nAbout the author:\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 33 of 34\n\nNextron Threat Research Team\r\nThe Nextron Threat Research Team builds the detection logic behind THOR, Aurora, Thunderstorm and the rest of\r\nthe Nextron toolchain. The group analyses intrusions, reverse-engineers malware, tracks supply-chain incidents,\r\nand turns all of that into signatures, heuristics and rules used across our products. The team maintains YARA and\r\nSigma content at scale, develops internal tooling and pipelines, and ships thousands of high-quality detections\r\nevery year that help customers spot real attacker activity instead of noise.\r\nSource: https://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nhttps://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/\r\nPage 34 of 34\n\n  https://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/   \nIt attempts to delete shadow copies using DeviceIoControl with the control code 0x53C028\n(IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE),    setting the maximum size to 1.\nThe function enumerates each available drive to be encrypted.  \n   Page 24 of 34",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.nextron-systems.com/2024/10/11/in-depth-analysis-of-lynx-ransomware/"
	],
	"report_names": [
		"in-depth-analysis-of-lynx-ransomware"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "cf7fc640-acfe-41c4-9f3d-5515d53a3ffb",
			"created_at": "2023-01-06T13:46:38.228042Z",
			"updated_at": "2026-04-10T02:00:02.883048Z",
			"deleted_at": null,
			"main_name": "APT1",
			"aliases": [
				"PLA Unit 61398",
				"Comment Crew",
				"Byzantine Candor",
				"Comment Group",
				"GIF89a",
				"Group 3",
				"TG-8223",
				"Brown Fox",
				"ShadyRAT",
				"G0006",
				"COMMENT PANDA"
			],
			"source_name": "MISPGALAXY:APT1",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3aaf0755-5c9b-4612-9f0e-e266ef1bdb4b",
			"created_at": "2022-10-25T16:07:23.480196Z",
			"updated_at": "2026-04-10T02:00:04.626125Z",
			"deleted_at": null,
			"main_name": "Comment Crew",
			"aliases": [
				"APT 1",
				"BrownFox",
				"Byzantine Candor",
				"Byzantine Hades",
				"Comment Crew",
				"Comment Panda",
				"G0006",
				"GIF89a",
				"Group 3",
				"Operation Oceansalt",
				"Operation Seasalt",
				"Operation Siesta",
				"Shanghai Group",
				"TG-8223"
			],
			"source_name": "ETDA:Comment Crew",
			"tools": [
				"Auriga",
				"Cachedump",
				"Chymine",
				"CookieBag",
				"Darkmoon",
				"GDOCUPLOAD",
				"GLOOXMAIL",
				"GREENCAT",
				"Gen:Trojan.Heur.PT",
				"GetMail",
				"Hackfase",
				"Hacksfase",
				"Helauto",
				"Kurton",
				"LETSGO",
				"LIGHTBOLT",
				"LIGHTDART",
				"LOLBAS",
				"LOLBins",
				"LONGRUN",
				"Living off the Land",
				"Lslsass",
				"MAPIget",
				"ManItsMe",
				"Mimikatz",
				"MiniASP",
				"Oceansalt",
				"Pass-The-Hash Toolkit",
				"Poison Ivy",
				"ProcDump",
				"Riodrv",
				"SPIVY",
				"Seasalt",
				"ShadyRAT",
				"StarsyPound",
				"TROJAN.COOKIES",
				"TROJAN.FOXY",
				"TabMsgSQL",
				"Tarsip",
				"Trojan.GTALK",
				"WebC2",
				"WebC2-AdSpace",
				"WebC2-Ausov",
				"WebC2-Bolid",
				"WebC2-Cson",
				"WebC2-DIV",
				"WebC2-GreenCat",
				"WebC2-Head",
				"WebC2-Kt3",
				"WebC2-Qbp",
				"WebC2-Rave",
				"WebC2-Table",
				"WebC2-UGX",
				"WebC2-Yahoo",
				"Wordpress Bruteforcer",
				"bangat",
				"gsecdump",
				"pivy",
				"poisonivy",
				"pwdump",
				"zxdosml"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439029,
	"ts_updated_at": 1775792289,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/65f63554395ee76623d4d50ba0cc49672480df85.pdf",
		"text": "https://archive.orkl.eu/65f63554395ee76623d4d50ba0cc49672480df85.txt",
		"img": "https://archive.orkl.eu/65f63554395ee76623d4d50ba0cc49672480df85.jpg"
	}
}