Karma’s development has been fairly rapid and regular with updated variants and improvements, oftentimes building multiple versions on the same day.
Basic configuration between samples is similar, though there are some slight differences such as PDB paths.
In one of samples one can see more of the core features appear, including the writing of the ransom note. Upon execution, these payloads would enumerate all local drives (A to Z), and encrypt files where possible. Further hunting revealed a number of other related samples all compiled within a few days of each other.
Also, the list of excluded extensions is somewhat larger in first sample, then in others.
The malware calls CreateIoCompletionPort, which is used for communication between the main thread and a sub thread(s) handling the encryption process.
This specific call is key in managing efficiency of the encryption process (parallelization in this case).
Individual files are encrypted by way of a random Chacha20 key. Once files are encrypted, the malware will encrypt the random Chacha20 key with the public ECC key and embed it in the encrypted file.
In advanced samples the author removed the CreateIoCompletionPort call, instead opting to create a new thread to manage enumeration and encryption per drive.
Analysts also note the “KARMA” mutex created to prevent the malware from running more than once.
Ransom note names have also been updated to “KARMA-ENCRYPTED.txt”.
Each sample observed offers three contact emails, one for each of the mail providers onionmail, tutanota, and protonmail.
In each sample, the contact emails are unique, suggesting they are specific communication channels per victim.
The notes contain no other unique ID or victim identifier as sometimes seen in notes used by other ransomware groups.
In common with other operators, however, the Karma ransom demand threatens to leak victim data if the victim does not pay.