Lynx Ransomware Analysis; An Advanced Post-Exploitation Ransomware

  • ChatGPT paged: Each PDF page to text, then ChatGPT 4o (detailed)
  • Gemini 2.0: Full PDF with gemini-2.0-flash (8k output token limit)
  • Gemini 2.5: Full PDF with gemini-2.5-flash-preview-05-20 (65k output tokens limit)
  • Original: All text extracted from PDF

Original Text

Lynx Ransomware Analysis; An Advanced Post-Exploitation Ransomware - thetrueartist By xande What is Lynx Ransomware? Lynx ransomware is a “fork” of another popular ransomware called “INC”, its source code was supposedly sold on an onion site at some point in the last year. This “fork” is largely based on it. Lynx uses some strong encryption (AES-128), good secret handling (Curve22519), and an efficient IO pipeline for fast encryption of files.However I believe certain features of this ransomware have been falsified (double extortion), as well as what I believe is the likely infection chain of this ransomware. This is all based on a couple of samples that I have reversed, and at least for the double extortion feature, it is not there, and has no imports that would enable this directly. In recent months it has gotten quite “popular”, and the group has supposedly ransomed several UK/USA/Aus companies. Surface Level Analysis Metadata from the original PeEXE: It is a 32 bit binary: SHA-256: 0315dbb793f855f154aa8d227151f1098bd9b580a4f85064648b85bac1321663 Compilation time: 2024-12-21 11:37:45 UTC Processes Graph: (any.run) Initial Triage Upon starting to reverse this malware, I soon realized that it was not packed or obfuscated in any way. This is pretty uncommon for most intermediate and up malware, however I think there is a reason for this that I will detail later. Reversing Lynx Ransomware I will structure the following analysis starting with what is basically the entry, “InitializeRansomwareOperation”, then reversing everything that it calls. Command Prefixes One of the first things that I noticed about this ransomware is that it appears to take in command prefixes. This is an oddity. When using the –help command it gives you a nice manpage. Argument Description –file Encrypt only specified file(s) –dir Encrypt only specified directory –help Print this message –verbose Enable verbosity –stop-processes Try to stop processes via RestartManager –encrypt-network Encrypt network shares –load-drives Load hidden drives –hide-cmd Hide console window –no-background Don’t change background image –no-print Don’t print note on printers –kill Kill processes/services –safe-mode Enter safe-mode This is pretty odd for ransomware or malware in general, as no victim would know to look for these when trying to use an ordinary .exe. This suggests to me that it is a post exploitation ransomware, but I’ll advance on this point later. Depending on what prefixes are used they store a value in local_14 which accumulates flag states etc. For an example of how the command prefixes work, if –kill is used a specific byte is stored into local_14. It then enumerates these processes (using Process32FirstW/Process32NextW) and, for each process, uses an internal pointer to an array of string pointers. This array holds the target substrings (such as “veeam”, “backup”, “exchange”, etc.) to check against each process name. If a process name contains one of these substrings, that process is terminated. Decoding The Ransomnote After setting up sufficient buffer sizes and allocating memory the ransomware decrypts its base64 note(s). After this it calls a function I’ve named “ReplaceIDInRansomNote”, which takes the %id% string from the decoded note and replaces it with a hardcoded victim ID. This takes it from this: To this: Encryption of Files After decrypting the ransomware note, it likely calculates the amount of threads or cores available for before spawning them in. The ransomware uses the winAPI CreateIoCompletionPort to asynchronously ensure that the files are encrypted within multiple threads of a function I’ve named “ProcessEncryptionTasks”. From there “ProcessEncryptionTasks” deals with IO and block level encryption, it has many switch and case statements that do different things in stages, for instance ReadFile: Then it encrypts the files with case 1: This appears to use a combination of AES-128 as well as potentially XOR to aid in additional obfuscation. Case 2 then writes the file. Case 3 appears to check if the file has a “LYNX” signature, if not it encrypts the file. Cases 4-5 then cleans the metadata up. File Handling and Path Building After this other functions get called from the main “InitializeRansomwareOperation”. It attempts to use the winAPI SHEmptyRecycleBinA to empty the recycle bin. The ransomware then calls a function I’ve named “drivePathBuilder” This function basically finds all drives on the system, even if they are hidden, and attempts to mount them. It does this with these global variables and local_480, which given there are 26 of them and there are 26 letters in the alphabet, these are likely letters that it uses to enumerate all possible drives. After this it attempts to mount drives found. Delete Shadow Copy(s) (VSS) Then another function gets called, “scanDrivesandDeleteShadowCopies”. It attempts to find drives, check the drive type, open them, then delete shadow copies, all before encrypting them. It calls a handler function (“EncryptionExclusionsThreadProc”) that calls “createRansomnoteExcludeFiles”. Ransomnote Propagation, File Exclusions and File Encryption Processing The function I have renamed “createRansomnoteExcludeFiles” is quite self descriptive, but it basically copies the decrypted ransomnote from a global variable and saves it to “README.txt” in every directory if not already written. It also deals with file exclusions and which files to encrypt. First, if silent mode is disabled it populates the decoded ransomnote in every directory. It then enumerates files and directories while skipping several hardcoded file types and directories.. It ends up skipping these file types/attributes: .exe .msi .dll .lynx LYNX README.txt As well as sys files: symlinksF FILE_ATTRIBUTE_SYSTEM It also skips these directories: windows program files program files (x86) $RECYCLE.BIN appdata Additionally it appears that it might specifically look for these DB engines: Processing File Encryption Then for files that pass the “filter” it waits until fewer than 100 encryption threads are running before creating file processing encryption thread(s) for the file(s). This is where the files start to be processed for encryption. “FileEncryptionWorker” calls “SetupFileEncryption”. This is the function that deals with the AES key expansion as well as deriving the session keys and secrets, using Curve25519. “SetupFileEncryption” first uses the winAPI “GetFileAttributesW”, which gets the files attributes :P. It then removes the read only flag from all files processed by it with “SetFileAttributesW”. This makes sure that the files can be modified. It then uses the API “CreateFileW” to read the file. If it cant read the file, it then optionally calls “TerminateResourcesUsingProcesses(RM)”, if –stop-processes is enabled, it then calls “TakeFileOwnershipAndSetPermissions”. “TerminateResourcesUsingProcesses(RM)” uses the RestartManager APIs to shutdown processes unless they are critical. “TakeFileOwnershipAndSetPermissions” attempts to allow the ransomware to take ownership of files, as well as changes the current user to be the file owner. From there it checks to see if the file is empty with “GetFileSizeEx” before continuing. Lynx then creates buffers for dealing with AES keys before decoding the attackers hardcoded base64 public key. It logs almost everything it does, it makes reversing a bit easier: From there it calls “derive_session_keys”, which acquires cryptographic context, before generating 32 random bytes for the AES session key. “derive_session_key” then derives a shared secret using Curve25519, and in the context of being called by “SetupFileEncryption” it uses the attackers public key to compute the shared secret. It then hashes the derived keys with the hashing algo SHA-256. Back in “SetupFileEncryption” it uses “aes_key_expansion” to expand the AES session key into round keys for encryption. It then appends “.” + “LYNX” to the original filename to mark it as encrypted. From there it then ensures that the file’s time are left unaffected. It then deals with the encryption task queue before exiting. Post Encryption Lynx then changes the users desktop background with “changeBackgroundimage”. It takes the decoded ransomnote, saves it to temp as “background-image.jpg” and creates a desktop background with the text against a black background. It then sets the wallpaper registry to point to the newly generated “background-image.jpg”. Print Ransomnote From there the ransomware attempts to print the ransom note to all printers before exiting. It uses the function “printRansomNote” to do this. It is quite simple, it enumerates printers on the local network, and prints copies of the decoded ransomnote to all of them, but it excludes printers such as “Microsoft Print to PDF” and “Microsoft XPS Document Writer”. Conclusion and Hypothesis This ransomware is pretty advanced at what I think it is used for. Because it lacks any obfuscation, or packing techniques as well as having CLI prefixes, and lots of logging, in my mind it is very clear that this family is intended to be used as post-exploitation ransomware. It is possible to attempt to position this ransomware for user execution, but given the cmd.exe window that it shows by default, it is unlikely that it is intended to be used this way. The user is likely to instantly close the cmd.exe window, as most applications with differing levels of legitimacy usually never open it, so it would be a big red flag. Even more so that when closing the window in the first few seconds it completely kills the ransomware. Additionally with it not using any obfuscation, packing, or other obfuscation and exploit techniques, most AV/EDR engines detect this ransomware at runtime, making it unfeasible to execute the ransomware unless you have already have access to the machine and have compromised its security. “Double Extortion” Claim Secondly from reports from authorities such as Paloalto Networks’ Unit 42 and sandboxes cataloging the ransomware, it is most likely falsely reported as double extortion ransomware, as none of the libraries used or files dropped have any internet capabilities. I have looked at 2-3 samples, even one Paloalto listed, and none of them have any sign of exfiltration capabilities. Paloalto Networks – https://unit42.paloaltonetworks.com/inc-ransomware-rebrand-to-lynx/ — MIRROR — Lynx Ransomware: A Rebranding of INC Ransomware It is also possible that it is delivered in the ways that they reference, but I personally doubt it is the main way it is intended to be used or delivered, and that it is far more likely it is post exploitation intended. It is however a pretty flawless analysis other than this. Indicators of Compromise (IoCs) SHA-256 0315dbb793f855f154aa8d227151f1098bd9b580a4f85064648b85bac1321663 URL(s) https[:]//lynxblog[.]net https[:]//lynxblogco7r37jt7p5wrmfxzqze7ghxw6rihzkqc455qluacwotciyd[.]onion https[:]//lynxblogijy4jfoblgix2klxmkbgee4leoeuge7qt4fpfkj4zbi2sjyd[.]onion https[:]//lynxblogmx3rbiwg3rpj4nds25hjsnrwkpxt5gaznetfikz4gz2csyad[.]onion https[:]//lynxblogoxllth4b46cfwlop5pfj4s7dyv37yuy7qn2ftan6gd72hsad[.]onion https[:]//lynxblogtwatfsrwj3oatpejwxk5bngqcd5f7s26iskagfu7ouaomjad[.]onion https[:]//lynxblogxstgzsarfyk2pvhdv45igghb4zmthnzmsipzeoduruz3xwqd[.]onion https[:]//lynxblogxutufossaeawlij3j3uikaloll5ko6grzhkwdclrjngrfoid[.]onion Attacker’s Base64 Encoded Public Key Gq70ERycjoW7SmLxAcnbWs+sCiFoaw+RMQ2VG3EvFho= Hardcoded Victim ID 67af691361c2d9c619f08a76 Base64 Encoded Ransom Note(s) WW91ciBkYXRhIGlzIHN0b2xlbiBhbmQgZW5jcnlwdGVkLg0KRG93bmxvYWQgVE9SIEJyb3dzZXIgdG8gY29udGFjdCB3aXRoIHVzLg0KDQpJRA0KIH4gJWlkJQ0KDQpDaGF0IHNpdGU6DQogfiBUT1IgTmV0d29yazogaHR0cDovL2x5bnhjaGF0bHk0emx1ZG1obWk3NWpyd2h5Y25vcXZreGI0cHJvaHhteXpmNGV1ZjVnanhyb2FkLm9uaW9uL2xvZ2luDQogfiBUT1IgTWlycm9yICMxOiBodHRwOi8vbHlueGNoYXRmdzRyZ3NjbHA0NTY3aTRsbGtxanIya2x0YXVtd3dvYnhkaWszcWEyb29ycmtuYWQub25pb24vbG — TTA ▸ For questions, collaboration, or to report vulnerabilities, feel free to reach out: Post navigation

Original Text ChatGPT 4o Paged

Lynx Ransomware Analysis; An Advanced Post-Exploitation Ransomware - thetrueartist By xande What is Lynx Ransomware? Lynx ransomware is a “fork” of another popular ransomware called “INC”, its source code was supposedly sold on an onion site at some point in the last year. This “fork” is largely based on it. Lynx uses some strong encryption (AES-128), good secret handling (Curve22519), and an efficient IO pipeline for fast encryption of files.However I believe certain features of this ransomware have been falsified (double extortion), as well as what I believe is the likely infection chain of this ransomware. This is all based on a couple of samples that I have reversed, and at least for the double extortion feature, it is not there, and has no imports that would enable this directly. In recent months it has gotten quite “popular”, and the group has supposedly ransomed several UK/USA/Aus companies. Surface Level Analysis Metadata from the original PeEXE: It is a 32 bit binary: SHA-256: 0315dbb793f855f154aa8d227151f1098bd9b580a4f85064648b85bac1321663 Compilation time: 2024-12-21 11:37:45 UTC Processes Graph: (any.run) Initial Triage Upon starting to reverse this malware, I soon realized that it was not packed or obfuscated in any way. This is pretty uncommon for most intermediate and up malware, however I think there is a reason for this that I will detail later. Reversing Lynx Ransomware I will structure the following analysis starting with what is basically the entry, “InitializeRansomwareOperation”, then reversing everything that it calls. Command Prefixes One of the first things that I noticed about this ransomware is that it appears to take in command prefixes. This is an oddity. When using the –help command it gives you a nice manpage. Argument Description –file Encrypt only specified file(s) –dir Encrypt only specified directory –help Print this message –verbose Enable verbosity –stop-processes Try to stop processes via RestartManager –encrypt-network Encrypt network shares –load-drives Load hidden drives –hide-cmd Hide console window –no-background Don’t change background image –no-print Don’t print note on printers –kill Kill processes/services –safe-mode Enter safe-mode This is pretty odd for ransomware or malware in general, as no victim would know to look for these when trying to use an ordinary .exe. This suggests to me that it is a post exploitation ransomware, but I’ll advance on this point later. Depending on what prefixes are used they store a value in local_14 which accumulates flag states etc. For an example of how the command prefixes work, if –kill is used a specific byte is stored into local_14. It then enumerates these processes (using Process32FirstW/Process32NextW) and, for each process, uses an internal pointer to an array of string pointers. This array holds the target substrings (such as “veeam”, “backup”, “exchange”, etc.) to check against each process name. If a process name contains one of these substrings, that process is terminated.

Phase: Initial Access

  • Technique: Post-Exploitation Deployment
  • Procedure: Lynx ransomware is designed to be deployed after gaining access through other means, suggesting it is used post-exploitation.

Phase: Execution

  • Technique: Command Line Interface with Custom Arguments
  • Procedure: The ransomware can be executed with various command-line arguments to control its behavior.
  • Commands:
  • lynx.exe --file <filePath>: Encrypts only specified file(s).
  • lynx.exe --dir <dirPath>: Encrypts only specified directory.
  • lynx.exe --verbose: Enables verbosity.
  • lynx.exe --kill: Kills specific processes and services.
  • lynx.exe --safe-mode: Enters safe mode.

Phase: Impact

  • Technique: Data Encryption for Impact
  • Procedure: Utilizes AES-128 encryption to encrypt files.
  • Technique: Terminating Processes
  • Procedure: Enumerates and terminates processes with specific substrings (“veeam”, “backup”, “exchange”) using Process32FirstW/Process32NextW.

Additional Capabilities

  • Encrypt Network Shares: lynx.exe --encrypt-network
  • Load Hidden Drives: lynx.exe --load-drives
  • Hide Console Window: lynx.exe --hide-cmd
  • No Background Change: lynx.exe --no-background
  • No Print Note: lynx.exe --no-print
  • Stop Processes via RestartManager: lynx.exe --stop-processes

The above details provide a structured framework for red team emulation of Lynx ransomware's deployment and functionality.

Decoding The Ransomnote After setting up sufficient buffer sizes and allocating memory the ransomware decrypts its base64 note(s). After this it calls a function I’ve named “ReplaceIDInRansomNote”, which takes the %id% string from the decoded note and replaces it with a hardcoded victim ID. This takes it from this: To this: Encryption of Files After decrypting the ransomware note, it likely calculates the amount of threads or cores available for before spawning them in. The ransomware uses the winAPI CreateIoCompletionPort to asynchronously ensure that the files are encrypted within multiple threads of a function I’ve named “ProcessEncryptionTasks”. From there “ProcessEncryptionTasks” deals with IO and block level encryption, it has many switch and case statements that do different things in stages, for instance ReadFile: Then it encrypts the files with case 1:

Phase: Impact

  • Technique: Ransom Note Customization
  • Procedure: The ransomware decrypts base64-encoded ransom notes and uses a function (ReplaceIDInRansomNote) to replace a placeholder string %id% with a hardcoded victim ID in the note.

  • Technique: Multi-threaded File Encryption

  • Procedure 1: The ransomware calculates the number of available CPU cores or threads.
  • Procedure 2: It uses the Windows API CreateIoCompletionPort to set up asynchronous file encryption across multiple threads.
  • Procedure 3: The function "ProcessEncryptionTasks" manages the I/O operations and block-level encryption. It utilizes switch-case logic to perform various encryption stages.
  • Likely Command: Would include creating multiple threads for processing file encryption tasks and handling I/O operations using API calls like ReadFile followed by encryption logic in case 1.

This appears to use a combination of AES-128 as well as potentially XOR to aid in additional obfuscation. Case 2 then writes the file. Case 3 appears to check if the file has a “LYNX” signature, if not it encrypts the file. Cases 4-5 then cleans the metadata up. File Handling and Path Building After this other functions get called from the main “InitializeRansomwareOperation”. It attempts to use the winAPI SHEmptyRecycleBinA to empty the recycle bin. The ransomware then calls a function I’ve named “drivePathBuilder” This function basically finds all drives on the system, even if they are hidden, and attempts to mount them. It does this with these global variables and local_480, which given there are 26 of them and there are 26 letters in the alphabet, these are likely letters that it uses to enumerate all possible drives. After this it attempts to mount drives found. Delete Shadow Copy(s) (VSS) Then another function gets called, “scanDrivesandDeleteShadowCopies”. It attempts to find drives, check the drive type, open them, then delete shadow copies, all before encrypting them.

Phase: Initial Setup

  • Technique: File Encryption Preparation
  • Procedure: Use a combination of AES-128 and potential XOR for obfuscation. Check files for a "LYNX" signature to decide if encryption is necessary. Clean up file metadata.

Phase: Execution

  • Technique: Recycle Bin Cleansing
  • Procedure: Use WinAPI SHEmptyRecycleBinA to empty the recycle bin.

Phase: Discovery

  • Technique: Drive Enumeration
  • Procedure: Function "drivePathBuilder" is used to find all system drives, including hidden ones, and attempt to mount them using possible drive letters.

Phase: Impact

  • Technique: Shadow Copy Deletion
  • Procedure: Function "scanDrivesandDeleteShadowCopies" checks drive types and deletes shadow copies to prevent recovery before encryption.

It calls a handler function (“EncryptionExclusionsThreadProc”) that calls “createRansomnoteExcludeFiles”. Ransomnote Propagation, File Exclusions and File Encryption Processing The function I have renamed “createRansomnoteExcludeFiles” is quite self descriptive, but it basically copies the decrypted ransomnote from a global variable and saves it to “README.txt” in every directory if not already written. It also deals with file exclusions and which files to encrypt. First, if silent mode is disabled it populates the decoded ransomnote in every directory. It then enumerates files and directories while skipping several hardcoded file types and directories.. It ends up skipping these file types/attributes: .exe .msi .dll .lynx LYNX README.txt As well as sys files: symlinksF FILE_ATTRIBUTE_SYSTEM It also skips these directories: windows program files program files (x86) $RECYCLE.BIN appdata Additionally it appears that it might specifically look for these DB engines: Processing File Encryption Then for files that pass the “filter” it waits until fewer than 100 encryption threads are running before creating file processing encryption thread(s) for the file(s). This is where the files start to be processed for encryption. “FileEncryptionWorker” calls “SetupFileEncryption”. This is the function that deals with the AES key expansion as well as deriving the session keys and secrets, using Curve25519. “SetupFileEncryption” first uses the winAPI “GetFileAttributesW”, which gets the files attributes :P. It then removes the read only flag from all files processed by it with “SetFileAttributesW”. This makes sure that the files can be modified. It then uses the API “CreateFileW” to read the file. If it cant read the file, it then optionally calls “TerminateResourcesUsingProcesses(RM)”, if –stop-processes is enabled, it then calls “TakeFileOwnershipAndSetPermissions”. “TerminateResourcesUsingProcesses(RM)” uses the RestartManager APIs to shutdown processes unless they are critical.

Phase: Ransomnote Propagation and Exclusion Management

  • Technique: File and Directory Enumeration
  • Procedure: Enumerates files and directories, skipping certain file types (.exe, .msi, .dll, .lynx, README.txt) and directories (windows, program files, $RECYCLE.BIN, appdata).

  • Technique: Ransomnote Deployment

  • Procedure: Copies a decrypted ransomnote to "README.txt" in every directory if silent mode is disabled.

Phase: File Encryption

  • Technique: Controlled File Encryption
  • Procedure: Waits for fewer than 100 encryption threads before initiating encryption processes on files that pass exclusion filters.

  • Function: SetupFileEncryption

  • Technique: AES Key and Session Secret Derivation

    • Procedure: Utilizes Curve25519 for key derivation.
  • Technique: Modify File Attributes

  • Command: Calls GetFileAttributesW and SetFileAttributesW to remove read-only attribute from files.

  • Technique: File Access

  • Command: Uses CreateFileW to read files for encryption.

  • Function: TerminateResourcesUsingProcesses(RM)

  • Technique: Process Termination

    • Procedure: Uses RestartManager APIs to shutdown non-critical processes if --stop-processes is enabled.
  • Technique: File Ownership and Permissions

  • Procedure: Calls TakeFileOwnershipAndSetPermissions to adjust permissions if necessary.

“TakeFileOwnershipAndSetPermissions” attempts to allow the ransomware to take ownership of files, as well as changes the current user to be the file owner. From there it checks to see if the file is empty with “GetFileSizeEx” before continuing. Lynx then creates buffers for dealing with AES keys before decoding the attackers hardcoded base64 public key. It logs almost everything it does, it makes reversing a bit easier: From there it calls “derive_session_keys”, which acquires cryptographic context, before generating 32 random bytes for the AES session key. “derive_session_key” then derives a shared secret using Curve25519, and in the context of being called by “SetupFileEncryption” it uses the attackers public key to compute the shared secret. It then hashes the derived keys with the hashing algo SHA-256. Back in “SetupFileEncryption” it uses “aes_key_expansion” to expand the AES session key into round keys for encryption. It then appends “.” + “LYNX” to the original filename to mark it as encrypted. From there it then ensures that the file’s time are left unaffected. It then deals with the encryption task queue before exiting. Post Encryption Lynx then changes the users desktop background with “changeBackgroundimage”. It takes the decoded ransomnote, saves it to temp as “background-image.jpg” and creates a desktop background with the text against a black background.

Phase: Privilege Escalation

  • Technique: File Ownership and Permissions Change
  • Procedure: Executes TakeFileOwnershipAndSetPermissions to transfer file ownership to current user and modify permissions.

Phase: Discovery

  • Technique: File Size Check
  • Procedure: Utilizes GetFileSizeEx to verify if the target file is empty before proceeding.

Phase: Execution

  • Technique: AES Key Preparation and Public Key Decoding
  • Procedure: Prepares buffers for AES keys and decodes the attacker's hardcoded base64 public key.

Phase: Encryption

  • Technique: Session Key Derivation and Encryption Preparation
  • Procedure:
  • Calls derive_session_keys to acquire cryptographic context and generate a 32-byte AES session key.
  • Utilizes Curve25519 to derive a shared secret using the attacker's public key.
  • Hashes the derived keys with SHA-256.
  • Expands the AES session key into round keys with aes_key_expansion.
  • Renames the file with a .LYNX extension to denote encryption.
  • Ensures file timestamps are preserved.

Phase: Impact

  • Technique: Desktop Background Change
  • Procedure: Uses changeBackgroundimage to modify the user's desktop background by saving and applying a decoded ransom note as background-image.jpg.

It then sets the wallpaper registry to point to the newly generated “background-image.jpg”. Print Ransomnote From there the ransomware attempts to print the ransom note to all printers before exiting. It uses the function “printRansomNote” to do this. It is quite simple, it enumerates printers on the local network, and prints copies of the decoded ransomnote to all of them, but it excludes printers such as “Microsoft Print to PDF” and “Microsoft XPS Document Writer”. Conclusion and Hypothesis This ransomware is pretty advanced at what I think it is used for. Because it lacks any obfuscation, or packing techniques as well as having CLI prefixes, and lots of logging, in my mind it is very clear that this family is intended to be used as post-exploitation ransomware. It is possible to attempt to position this ransomware for user execution, but given the cmd.exe window that it shows by default, it is unlikely that it is intended to be used this way. The user is likely to instantly close the cmd.exe window, as most applications with differing levels of legitimacy usually never open it, so it would be a big red flag. Even more so that when closing the window in the first few seconds it completely kills the ransomware. Additionally with it not using any obfuscation, packing, or other obfuscation and exploit techniques, most AV/EDR engines detect this ransomware at runtime, making it unfeasible to execute the ransomware unless you have already have access to the machine and have compromised its security. “Double Extortion” Claim Secondly from reports from authorities such as Paloalto Networks’ Unit 42 and sandboxes cataloging the ransomware, it is most likely falsely reported as double extortion ransomware, as none of the libraries used or files dropped have any internet capabilities. I have looked at 2-3 samples, even one Paloalto listed, and none of them have any sign of exfiltration capabilities. Paloalto Networks – https://unit42.paloaltonetworks.com/inc-ransomware-rebrand-to-lynx/ — MIRROR — Lynx Ransomware: A Rebranding of INC Ransomware It is also possible that it is delivered in the ways that they reference, but I personally doubt it is the main way it is intended to be used or delivered, and that it is far more likely it is post exploitation intended. It is however a pretty flawless analysis other than this. Indicators of Compromise (IoCs) SHA-256 0315dbb793f855f154aa8d227151f1098bd9b580a4f85064648b85bac1321663 URL(s) https[:]//lynxblog[.]net https[:]//lynxblogco7r37jt7p5wrmfxzqze7ghxw6rihzkqc455qluacwotciyd[.]onion https[:]//lynxblogijy4jfoblgix2klxmkbgee4leoeuge7qt4fpfkj4zbi2sjyd[.]onion https[:]//lynxblogmx3rbiwg3rpj4nds25hjsnrwkpxt5gaznetfikz4gz2csyad[.]onion https[:]//lynxblogoxllth4b46cfwlop5pfj4s7dyv37yuy7qn2ftan6gd72hsad[.]onion https[:]//lynxblogtwatfsrwj3oatpejwxk5bngqcd5f7s26iskagfu7ouaomjad[.]onion https[:]//lynxblogxstgzsarfyk2pvhdv45igghb4zmthnzmsipzeoduruz3xwqd[.]onion https[:]//lynxblogxutufossaeawlij3j3uikaloll5ko6grzhkwdclrjngrfoid[.]onion Attacker’s Base64 Encoded Public Key Gq70ERycjoW7SmLxAcnbWs+sCiFoaw+RMQ2VG3EvFho= Hardcoded Victim ID 67af691361c2d9c619f08a76 Base64 Encoded Ransom Note(s) WW91ciBkYXRhIGlzIHN0b2xlbiBhbmQgZW5jcnlwdGVkLg0KRG93bmxvYWQgVE9SIEJyb3dzZXIgdG8gY29udGFjdCB3aXRoIHVzLg0KDQpJRA0KIH4gJWlkJQ0KDQpDaGF0IHNpdGU6DQogfiBUT1IgTmV0d29yazogaHR0cDovL2x5bnhjaGF0bHk0emx1ZG1obWk3NWpyd2h5Y25vcXZreGI0cHJvaHhteXpmNGV1ZjVnanhyb2FkLm9uaW9uL2xvZ2luDQogfiBUT1IgTWlycm9yICMxOiBodHRwOi8vbHlueGNoYXRmdzRyZ3NjbHA0NTY3aTRsbGtxanIya2x0YXVtd3dvYnhkaWszcWEyb29ycmtuYWQub25pb24vbG — TTA ▸ For questions, collaboration, or to report vulnerabilities, feel free to reach out: Post navigation

Phase: Impact

  • Technique: Modify System Display Settings
  • Procedure: The ransomware sets the wallpaper registry to point to a generated file, "background-image.jpg", as part of its operation.

  • Technique: Ransom Note Distribution via Printers

  • Procedure: The ransomware uses a function called printRansomNote to print the ransom note to all network printers, excluding printers like “Microsoft Print to PDF” and “Microsoft XPS Document Writer”. This process involves enumerating printers on the local network and sending the ransom note to each eligible printer.

Observations

  • Intended Usage: The ransomware exhibits characteristics of being post-exploitation ransomware due to its lack of obfuscation, packing techniques, and visible command-line interface, indicating it is designed for use after gaining access to a compromised machine.
  • Detection Challenges: The absence of obfuscation makes the ransomware detectable by most AV/EDR solutions at runtime.

Use this structured detail for creating emulation scenarios during red team exercises.

Gemini 2.0

Model: gemini-2.0-flash

Okay, I will extract and structure the procedures used by the threat actor in the provided CTI report, focusing on command lines, executed programs, tools, and attack techniques, while excluding passive IOCs.

Lynx Ransomware Attack Procedures

Phase: Command Prefix Usage and Configuration

  • Technique: Command prefix usage
  • Procedure: The ransomware checks for and uses command prefixes such as -file, -directory, -stop-processes, -encrypt-network, -no-console, -no-background, -kill, -safe-mode, and others to modify its behavior. The usage of these prefixes modifies specific states and configurations

Phase: Process Termination

  • Technique: Process Termination via RestartManager
  • Procedure: The ransomware attempts to stop specific processes via RestartManager. The ransomware enumerates processes using Process32FirstW and Process32NextW, comparing process names and calling TerminateProcess to kill them.

Phase: Drive enumeration

  • Technique: Find all drives on the system
  • Procedure: The ransomware discovers drives on the system to enumerate files and directory to encrypt.

Phase: Shadow Copy Deletion

  • Technique: Shadow Copy Deletion (VSS)
  • Procedure: Before encryption, the ransomware attempts to delete shadow copies to prevent easy recovery using the winAPI SHEmptyRecycle BinA.

Phase: File Enumeration and Filtering

  • Technique: File Enumeration and Exclusion
  • Procedure: The ransomware enumerates files in directories but skips specific files and directories based on hardcoded names and extensions.
  • Exclusions include: Windows, program files, program files (x86), $RECYCLE BIN, appdata,
  • File Type Exclusions include: .exe, .lnk, .sys

Phase: File Encryption

  • Technique: AES-128 Encryption with multi-threading
  • Procedure: The ransomware creates multiple threads to encrypt files in parallel. Encryption is achieved via AES-128, leveraging random generated keys.

Phase: Volume Shadow Copy Deletion

  • Technique: Delete Shadow Copies
  • Procedure: The malware deletes volume shadow copies by calling deviceiocontrol. This occurs before encryption.

Phase: Volume Shadow Copy Deletion (Alternative approach)

  • Technique: Process for destroying shadow copies
  • Procedure: The process attempts to find drives, check the drive type, open them, and then delete shadow copies, all before encrypting.

Phase: Ransom Note Creation

  • Technique: Ransom Note Generation
  • Procedure: The ransomware decrypts a base64-encoded ransom note, replaces a placeholder (%id%) with a victim ID, and saves the note in each encrypted directory if silent mode isn't enabled.

Phase: Persistence

  • Technique: Change Background Image
  • Procedure: The ransomware changes the user's desktop background by generating a background image containing the ransom note text and setting the wallpaper registry key. This involves creating a compatible device context, bitmap, drawing the text onto it, and saving as "background-image.jpg" and sets the wallpaper to it.

    • RegSetValueExW HKEY_CURRENT_USER\Control Panel\Desktop Wallpaper [path_to]\background-image.jpg
    • SystemParametersInfoW SPI_SETDESKWALLPAPER 0 [path_to]\background-image.jpg 3

Phase: Resource Termination

  • Technique: RestartManager for Termination
  • Procedure: If the -stop-processes prefix is used, it calls TerminateResourceUsing Processes (RM)() which uses the RestartManager APIs to shutdown applications with associated handles. * RmStartSession * RmRegisterResources * RmGetList * RmShutdown * RmEndSession

Phase: Privilege Escalation

  • Technique: Token adjustment
  • Procedure: The malware tries to allow the process to gain ownership. It uses lookupprivilegevalueW to get a seTakeOwnershipPrivilege, and then calls adjusttokenprivileges.
Gemini 2.5

Model: gemini-2.5-flash-preview-05-20

Here's a structured breakdown of the procedures used by the Lynx ransomware, focusing on command lines, executed programs, tools, and attack techniques, suitable for red team emulation.

Phase: Execution

  • Technique: Command-Line Interface (T1059)
    • Procedure: The ransomware binary is executed with various command-line arguments to control its behavior, including targeting specific files or directories, controlling visibility, and enabling verbose logging.
    • Command (example): lynx.exe -file <path_to_file> -no-console -no-wallpaper -verbose
    • Command (example): lynx.exe -dir <path_to_directory> -encrypt-network -stop-processes -kill
    • Command (example): lynx.exe -safe-mode -verbose
    • Arguments Used:
      • -file: Encrypts only specified file(s).
      • -dir: Encrypts only specified directory(s).
      • -help: Displays help message.
      • -stop-processes: Attempts to stop processes via Windows RestartManager APIs.
      • -encrypt-network: Encrypts network shares.
      • -no-console: Hides the console window.
      • -no-wallpaper: Prevents desktop background image change.
      • -safe-mode: Enters safe-mode (specific operational mode).
      • -kill: Kills specified processes/services.
      • -verbose: Enables verbose logging.

Phase: Discovery

  • Technique: System Information Discovery (T1082)
    • Procedure: Obtains system information (e.g., number of available processors) to configure parallel encryption threads.
    • Program/Tool: Windows API GetSystemInfo
  • Technique: Process Discovery (T1057)
    • Procedure: Enumerates running processes to identify and potentially terminate specific applications that might interfere with encryption or hold file locks.
    • Program/Tool: Windows API CreateToolhelp32Snapshot, Process32FirstW, Process32NextW
    • Targeted Processes (by string search): Processes related to "backup", "exchange", "sql", "vss" (Volume Shadow Copy).
  • Technique: System Network Configuration Discovery (T1016)
    • Procedure: Identifies and enumerates all logical drives on the system, including hidden drives, and attempts to mount them for encryption.
    • Program/Tool: Windows API GetDriveType, FindFirstVolume, GetVolumeInformation
  • Technique: Peripheral Device Discovery (T1120)
    • Procedure: Enumerates locally connected or network-available printers to print ransom notes.
    • Program/Tool: Windows API EnumPrinters

Phase: Defense Evasion

  • Technique: Process Termination (T1489)
    • Procedure: Terminates specific applications that might be locking files or interfering with encryption, identified through process enumeration.
    • Program/Tool: Windows API TerminateProcess
    • Procedure: Utilizes Windows RestartManager APIs to gracefully shut down applications holding files that the ransomware intends to encrypt.
    • Program/Tool: Windows API RmStartSession, RmRegisterResources, RmGetList, RmShutdown, RmEndSession
  • Technique: Inhibit System Recovery (T1490) - Volume Shadow Copy Deletion
    • Procedure: Deletes Volume Shadow Copies to prevent data recovery by the victim.
    • Program/Tool: Windows API DeviceIoControl (with control code 0x53c028 specific to VSS operations)
  • Technique: Inhibit System Recovery (T1490) - Recycle Bin Emptying
    • Procedure: Empties the Windows Recycle Bin.
    • Program/Tool: Windows API SHEmptyRecycleBinA
  • Technique: File and Directory Permissions Modification (T1222)
    • Procedure: Removes the read-only attribute from files to ensure they can be modified (encrypted).
    • Program/Tool: Windows API SetFileAttributes
    • Procedure: Attempts to take ownership of files and modify Access Control Lists (ACLs) to ensure full write permissions for encryption, by adjusting token privileges (e.g., SeTakeOwnershipPrivilege, SeSecurityPrivilege).
    • Program/Tool: Windows API AllocateAndInitializedAcl, SetEntriesInAcl, SetNamedSecurityInfoW, LookupPrivilegeValueW, AdjustTokenPrivileges

Phase: Impact

  • Technique: Data Encrypted for Impact (T1486)
    • Procedure: Encrypts files on local and network drives using strong encryption algorithms.
    • Encryption Algorithm: AES-128 (symmetric encryption), Curve25519 (key exchange), SHA-256 (hashing)
    • File Renaming: Appends a specific extension (".LYNX") to encrypted filenames.
    • Excluded File Types (Examples): .exe, .dll, .sys, .ini, .bat, .lnk, .README.txt, files with "LYNX" signature, and various other system, temporary, and common non-user files.
    • Excluded Directories (Examples): windows, program files, program files (x86), $RECYCLE.BIN, appdata.
    • Targeted Data (Implicit): Searches for files related to specific database engines (e.g., "microsoft sql server", "postgresql") to ensure their encryption.
  • Technique: Defacement (T1491) - Desktop Wallpaper
    • Procedure: Changes the user's desktop background to display the ransom note, creating a new image file from the decoded note content.
    • Program/Tool: Windows API SystemParametersInfo (to set wallpaper), CreateFile, WriteFile, BitBlt, SelectObject, DeleteObject, ReleaseDC (for image manipulation), and Registry APIs (RegSetValueEx) to modify HKCU\Control Panel\Desktop\Wallpaper.
  • Technique: Ransom Note (T1486) - Disk Propagation
    • Procedure: Drops the ransom note (often README.txt or similar) in every directory where files are encrypted.
    • Content: The note contains the victim ID, onion addresses for the chat site, and blog links for communication and payment instructions.
  • Technique: Ransom Note (T1486) - Print Propagation
    • Procedure: Prints copies of the decoded ransom note to all available physical printers on the local network.
    • Program/Tool: Windows API OpenPrinter, StartDocPrinter, StartPagePrinter, WritePrinter, EndPagePrinter, EndDocPrinter, ClosePrinter
    • Excluded Printers: Excludes virtual printers such as "Microsoft Print to PDF" and "Microsoft XPS Document Writer".