{
	"id": "9e3260d3-43ef-4708-95ba-57b1cf91c2d0",
	"created_at": "2026-04-06T00:15:15.585285Z",
	"updated_at": "2026-04-10T03:33:41.887727Z",
	"deleted_at": null,
	"sha1_hash": "7577c7503af88534da469adf09044640597db384",
	"title": "Diving into the Sun — SunCrypt: A new neighbour in the ransomware mafia",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6975244,
	"plain_text": "Diving into the Sun — SunCrypt: A new neighbour in the\r\nransomware mafia\r\nBy Sapphire\r\nPublished: 2021-02-01 · Archived: 2026-04-05 15:13:45 UTC\r\nThe first time I heard about SunCrypt I was just enjoying my time off preparing some stuff to get dinner ready.\r\nMy colleagues sent me over some weird samples that were flagged as SunCrypt that were also beaconing to\r\nMaze C2 infrastructure, however they weren’t Maze but shared some similarities and that’s basically why they\r\ndid it as they know my interest in ransomware and my personal fascination with Maze.\r\nAs I was checking a couple of hashes, I saw very interesting things that made me go hands-on to investigate\r\nfurther and I ended up spending a lot of time not only analysing but also hunting and creating some detections for\r\nthis malware.\r\nInitial Open Source Intelligence shows that SunCrypt made its first appearance around October 2019 and it has\r\nbeen active since then. The SunCrypt team is active on underground forums where they look for affiliates for\r\ntheir program just like the rest of ransomware operating under the RaaS model.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 1 of 21\n\nIn their advertisement in a popular forum, shared in Twitter by ShadowIntelligence, can be observed some of the\r\nfeatures they offer for their product such as crypto independency from the Windows CryptoAPI, “bypass” of 70%\r\nof the AV engines, which is not a lot..but I guess at least they didn’t lie selling it as FUD as other threat actors,\r\nasynchronous search and encryption, speed etc.\r\nAdditionally to the lock service, the SunCrypt team provides DDoS if they consider it as part of the extortion to\r\nget the ransom paid.\r\nPress enter or click to view image in full size\r\nSunCrypt shaming site where they expose victims, status and data dumps\r\nFor some journalists and websites related to infosec, they are part of what they call “The Maze Cartel” and they\r\nalso drew some shy lines associating this team with Maze.\r\nMy personal opinion: I don’t believe such thing as a Cartel exists but sounds fancy. This would imply a high\r\ndegree of collaboration, potential relationships and involvement in the money-laundry circuit, extortion and\r\naffiliation methodology… this is very different from a good or neutral relationship with potential collaborations to\r\nshare resources and infrastructure. I wanted to see with my own eyes the degree of relationship and sophistication\r\nof this ransomware family.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 2 of 21\n\nThat said, to start the analysis I grabbed two samples that are available not only in VT but also in AnyRun and\r\nfrom there I started the analysis to figure out how it works and hunting more samples for code comparison.\r\nThis was fundamental to me to construct a solid opinion and conclusions that I may share publicly with the\r\ncommunity.\r\nSunCrypt PowerShell loader analysis\r\nSunCrypt ransomware has been spotted in many cases using PowerShell loaders for delivery and deploy\r\nfollowing the tendency marked by other groups offering ransomware service.\r\nAfter the analysis of some of these loaders, I could observe that share some similarities or reminds to me the\r\nstructure and functionality of other loaders such a Netwalker PowerShell Loader scripts. The SunCrypt loaders\r\ncontains an embedded resource in plain text with two export functions that are called by the script after the\r\ncompilation of the C# code, heavy obfuscation and a lot of junk code and useless data to harden the analysis and\r\ndetection.\r\nThe obfuscation of the script includes arithmetical operations, encoding and string manipulation not only for\r\nanti-analysis but probably to avoid detection by segmenting the base64 strings.\r\nPoweShell Loader script obfuscation\r\nJumping to the analysis, the sample md5 c171bcd34151cbcd48edbce13796e0ed is a PowerShell loader\r\ncontaining the heavy obfuscation mentioned above and contains an embedded small PE file md5\r\n479712042d7ad6600cbe2d1e5bc2fa88 coded in C# that is compiled in runtime and dropped to disk.\r\nThis DLL is used to assist with Process Injection of the payload by adding a class with obfuscated names for the\r\nexported functions to call the functions VirtualAlloc and EnumDesktopW. These are used to allocate memory\r\nand enumerate desktops associated with the process.\r\nThe PowerShell script spawns an additional process instance of Powershell which is directly invoked with the\r\nfollowing arguments after the deobfuscation on the fly of the parameters:\r\nC:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe -ep bypass -file \u003cfilepath of the\r\nscript\u003e\r\nThe main structure of script contains two heavily obfuscated payloads base64 encoded in multiple strings that are\r\nsubsequently deobfuscated by multiple operations and then decoded.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 3 of 21\n\nPowerShell uses the dropped .NET DLL to allocate memory space and copies the resultant buffers to the newly\r\ncreated PowerShell process. The injected bytes are consistent with shellcode and a PE32 file that are injected into\r\nPowerShell’s memory address space.\r\nTo analyze the payload the buffer containing the deobfuscated payload was dumped to disk to carve the bytes.\r\nA basic triage of the shellcode showed that it contains functions related to process injection such as VirtualAlloc\r\nand VirtualProtect, likely indicating that the shellcode is assisting the PowerShell script to leverage the injection\r\nof the payload.\r\nSunCrypt payload Analysis\r\nMost analyzed samples share the same code structure and characteristics but one of them had a simpler structure\r\nthat facilitated the analysis as the only major modification that most samples contain was the addition of more\r\nobfuscation layers.\r\nIn this case I will jump directly to the analysis of the code shared between multiple samples followed by a\r\nsummarisation and conclusion.\r\nFrom the PowerShell loader md5 c171bcd34151cbcd48edbce13796e0ed, the payload md5\r\n0a0882b8da225406cc838991b5f67d11 was dumped and the bytes carved for analysis. This PE file is consistent\r\nwith an executable file likely to be coded in C and contains capabilities to encrypt the filesystem, delete\r\nbackups and to gather and exfiltrate user and host information.\r\nOne of the first noticeable difference of the sample md5 0a0882b8da225406cc838991b5f67d11 is that it does not\r\ncontain commandline arguments unlike other analyzed samples like md5 3d756f9715a65def4a302f5008b03809\r\n(payload carved from the PowerShell loader with MD5 d87fcd8d2bf450b0056a151e9a116f72) which contains\r\nmultiple arguments .\r\nMost samples contain these command line arguments just like the one I just mentioned above that are intended to\r\nmodify the behaviour of the ransomware. One of the key characteristics of SunCrypt is that contain an embedded\r\nconfiguration that is likely to be inserted and then encoded by the builder.\r\nThese command line arguments seen for example in md5 0a0882b8da225406cc838991b5f67d11 that are\r\nexpected share some similarities with the ones seen in other malware like Maze ransomware.\r\nSunCrypt commandline arguments are:\r\n-noshares\r\n-noreport\r\n-nomutex\r\n-log\r\n-path\r\nThe triaged samples that expect command line arguments contain obfuscated parameters and SunCrypt uses FNV\r\nhashing to obfuscate these parameters.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 4 of 21\n\nPress enter or click to view image in full size\r\nIDA flow with each hash value and parameter\r\nFNV (Fowler–Noll–Vo) is a non-cryptographic hash function created by Glenn Fowler, Landon Curt Noll,\r\nand Kiem-Phong Vo. FNV functions contains two primary operations: XOR and multiplication. These can be\r\nspotted also by identifying the hash values for FNV Prime (0x01000193) and the FNV offset basis (0x811c9dc5).\r\nIn this case the identified version that SunCrypt is using is FNV-1a hashing.\r\nAbove the FNV hashing can be observed to obfuscate the commandline arguments, however the\r\nvalue for “-noreport” is not hashed.\r\nThe next step the ransomware takes is to decode the configuration.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 5 of 21\n\nThis configuration added and encoded by the builder contains the following parameters:\r\nMutex/implant ID\r\nC2 address/addresses\r\nRansom note\r\nIdentifier\r\nThe whole section containing the configuration is decoded in multiple steps to save some of its values for its use\r\nin different routines, however the whole configuration is decoded by multiple loops that decode the data with a\r\nsingle-byte xor key 0x11.\r\nPress enter or click to view image in full size\r\nDecoded data containing the HTML code for the ransom note.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 6 of 21\n\nOne of the most noticeable things on the ransom note is that is written in multiple languages including\r\nSpanish(Latin American Spanish), German, French and English. This note contains an hardcoded identifier in\r\nhex format that is intended to be used to start negotiating the payment of the ransom along with the TOR Hidden\r\nService URL where SunCrypt hosts its webpage and Shaming list containing the victim names, proofs and data\r\ndumps.\r\nPress enter or click to view image in full size\r\nSunCrypt ransom note\r\nAfter the initial analysis of the configuration its data showed that both the offset of the ransom note containing the\r\nindividual key in hex format and other values that are used later are not generated on the fly indicating that they\r\nare likely to be added by the builder during the construction process.\r\nOne of the decoded details is a string in hex format that is re-encoded at a later stage and sent within the POST\r\ndata that is likely to be an implant identifier for the attackers.\r\nThe fact that all the data is precomputed or hardcoded is not always typical in ransomware and popped up some\r\nquestions in my head about the crypto used that I had to figure out later.\r\nOnce the C2 are decoded the malware looks for multiple addresses in order to save them for its use later or just\r\ncontinues if only one is used.\r\nThe image below shows that after the configuration decoding and extraction, the next step taken by SunCrypt is a\r\nquick system check to delete the Shadow Copy Volumes. Microsoft’s shadow copy technology allows Windows\r\nsystems to create snapshots-backups of files and volumes. This step ensures no possible recovery.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 7 of 21\n\nAfter decoding the embedded configuration, it saves the C2 addresses for its use\r\nIn most samples all the data such a function names, DLL names and other data are dynamically loaded and\r\nobfuscated using xor, sub or add operations with random values likely to be inserted by the builder combined\r\nwith the use of StackStrings for anti-analysis and evasion.\r\nThe function in charge of deleting the Shadow Copy Volumes works in the same way and all its steps are\r\nobfuscated. SunCrypt retrieves the system version to look for its architecture to handle this via WMI query\r\nexecuting the query “select * from Win32_ShadowCopy” to then delete all the available volumes.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 8 of 21\n\nobfuscated flow to decode strings used to retrieve system architecture and to handle the task via\r\nWMI\r\nOne of the most interesting things I noticed is the fact that so far most samples create a mutex but not all of them.\r\nIn this case, the below screenshot of the sample 3d756f9715a65def4a302f5008b03809 creates it using this hex\r\nstring that was mentioned above and that is decoded during the configuration extraction.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 9 of 21\n\nAfter the config decoding, gets the System Version and creates the mutex\r\nOnce SunCrypt deletes the Shadow Volumes, it scans for available drives following the keyboard scheme from\r\nQ: to M:. In the case of the sample md5 0a0882b8da225406cc838991b5f67d11 it directly contains the hardcoded\r\nvolume letters instead of using other techniques to harden detection such a incrementing loops. However most\r\nsamples like md5 3d756f9715a65def4a302f5008b03809 contains a different technique using FNV-hashing again\r\nto obfuscate this phase, indicating that the developer team modified this to make its detection more complicated.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 10 of 21\n\nIn most samples, drive scanning phase is obfuscated using FNV hashing, funnily enough,\r\n0a0882b8da225406cc838991b5f67d11 contains the strings.\r\nFile encryption and Crypto walkthrough\r\nSunCrypt uses a particular way to encrypt the filesystem and this is somehow reflected in their advertisement\r\nwhere they specify that SunCrypt uses a completely independent cryptography from the system API. Well,\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 11 of 21\n\nthis is true and stepping through the crypto made it complicated as there’s only a few visible calls and it does\r\ncompletely rely on itself instead of the Windows CryptoAPI to generate the keys because the implementation is\r\nalmost completely manual.\r\nAnother interesting feature observed during the crypto walkthrough is that skips files that are empty or less the\r\n512 bytes size to skip potential garbage files. The Crypto is basically identical in all the samples and it consists on\r\na first loop to scan all the directories ensuring the drive C: is present and is encrypted. However SunCrypt scans\r\nall the available network drives such as Windows SMB File Shares in order to encrypted them if they are\r\nconnected and available.\r\nThe malware in most cases contains two lists:\r\nWhitelist of directories: SunCrypt contains a list of directories that skips from the encryption process to\r\nensure its recovery. These directories are: “Windows”, “Program Files”, “Program Files (x86)”,\r\n“$Recycle.bin”, “System Volume Information”.\r\nBlacklist of file extensions: A huge list of file extensions are used to ensure only vital files are maintained\r\nintact.\r\nPress enter or click to view image in full size\r\nnote again the use of FNV hashing and the FNV prime hash above. The number 13:19:00\r\ncorresponds to the end of the array containing the file extensions.\r\nThese two arrays of lists are used with the FNV hashing technique again to ensure obfuscation, however md5\r\n0a0882b8da225406cc838991b5f67d11 again saves the day containing all this information in plain text. The\r\ndirectories and file extensions don’t change between samples and versions.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 12 of 21\n\nPress enter or click to view image in full size\r\nAnother file extension that is skipped is if the filename contains “YOUR_FILES_ARE_ENCRYPTED.HTML”\r\nwhich is used for the ransom note to ensure its delivery to the victim, however there is a problem that is not\r\nresolved.\r\nIf the ransomware is executed twice, it would re-encrypt the filesystem as the file extension of the encrypted\r\nfiles is generated on the fly. This embarrassing scenario indicates that if a previous instance of SunCrypt\r\nencrypts the filesystem, another execution would re-encrypt all the encrypted files, making this very hard to solve.\r\nOnce the directory is picked for encryption SunCrypt decodes the DLL name “advapi32.dll” and a function to be\r\nloaded and used. The malware executes a GetProcAddress to use the function\r\nSystemFunction036(RtlGenRandom), this will be our RNG to generate 32 random bytes without using\r\nCryptGenRandom function call or an insecure generator.\r\nPress enter or click to view image in full size\r\nAfter decoding the DLL and the function that will be called, SunCrypt uses SystemFunction036 to\r\ncreate 32 byte keys.\r\nThis 32-byte buffer is validated after it’s generation to create a secure private key for the Elliptic Curve\r\nalgorithm Curve25519. Curve25519 is a Diffie-Hellman function suitable for a wide variety of applications and\r\nis used by many software applications.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 13 of 21\n\nGet Sapphire’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nCurve25519 works as follows according to the official documentation: “given a user’s 32-byte secret key,\r\nCurve25519 computes the user’s 32-byte public key. Given the user’s 32-byte secret key and another user’s 32-\r\nbyte public key, Curve25519 computes a 32-byte secret shared by the two users. This secret can then be used to\r\nauthenticate and encrypt messages between the two users”.\r\nAfter the generation of this private session key, SunCrypt jumps to the curve function to compute its session\r\npublic key where this session private key is passed to the function along with a basepoint constant of 9 followed\r\nby all zeros. This session public key will be converted to hex format and used as file extension for the\r\nencrypted file to allow the recovery as each time a file is encrypted the session private key is destroyed. Next\r\nstep of SunCrypt is to load its embedded Curve25519 public key to compute a shared secret.\r\nThe analyzed sample md5 0a0882b8da225406cc838991b5f67d11 contains the following public key in hex\r\nformat:\r\nc75d83161c3768477c859b15cfe3f6c7bf707976bfed511af7015d04f7066558\r\nThe other analyzed sample used in the blog to compare SunCrypt versions\r\n(MD5:3d756f9715a65def4a302f5008b03809) containing the improvement and obfuscation shared with most of\r\nthe observed SunCrypt samples contains the public key:\r\n695c567285a5b331dcf1d61bb291ce850e92c57111678fe79a2e5c2e399c9310\r\nThe implementation of Curve25519 looks manual and it’s likely to be using code from any of the multiple open\r\nsource implementation of Curve25519,\r\nThe shared secret is computed by calling the curve function and passing the attacker’s public key, the\r\ngenerated private key and the basepoint as parameters. This shared secret is used by another algorithm to\r\nencrypt the file, allowing its recovery with the attacker’s Curve25519 private key hosted in the SunCrypt C2\r\nservers and the session public key that is the file extension of each file.\r\nSummarising, each time a file is selected for encryption after the aforementioned checks, SunCrypt creates\r\nCurve25519 session keys, stores each public key as file extension and destroys the session private key.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 14 of 21\n\nsession public key is formatted and used as extension, then the shared key is computed with the\r\nsession private key and the attacker’s public key\r\nOnce the session keys are created and the shared key is computed for a given file, the required data is sent via\r\ncompletion I/O port to the encryption thread which takes a pointer to the file and its new generated extension.\r\nTo handle encryption threading, SunCrypt gets the number of processors and the maximum number of available\r\nthreads that the operating system can allow to process I/O completion packets for I/O completion port.\r\nThis provide an efficient threading for multiple asynchronous I/O requests for encryption. Again, this was\r\nreferenced in their forum ad.\r\nPress enter or click to view image in full size\r\nCreateIOCompletionPort initialisation\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 15 of 21\n\nFor the file encryption SunCrypt uses a very fast and secure algorithm which in this case is ChaCha. The\r\nimplementation of ChaCha20 stream cipher is also manual and makes sense its use, because it does not rely on\r\nstatically linked libraries or the CryptoAPI avoiding suspicious calls and it’s very fast and secure. This cipher is\r\nused by other popular ransomware like Maze. Again another similarity.\r\nThe actual file encryption happens after the above steps. The malware calls ReadFile function to get the content\r\nof the file and pushes a pointer to the buffer with the file content, the file extension and the computed shared key\r\nfor that file to ChaCha20 function that encrypts the file partially. This limitation is intended to speed up a bit\r\nmore the encryption as is enough to make the file useless.\r\nAfter reading the file, the flow redirects the data containing the computed shared key and the file to\r\nthe ChaCha20 encryption routine\r\nC2 communications\r\nSunCrypt contains a network module unlike many other ransomware and in my opinion this is also influenced by\r\nMaze. The ransomware uses the IP addresses that are embedded in the configuration and attempts to push\r\ndifferent information from the compromised host.\r\nIt’s worth noting that the observed IP addresses in SunCrypt are in many cases consistent with previous\r\nassociated Maze infrastructure’s subnet, reinforcing the idea of some sort of collaboration between ransomware\r\ndev groups.\r\nSunCrypt gathers information from the Windows system gathering the Minor Version, Major Version and\r\nBuildnumber of the compromised system. The system survey also consists of gathering username and hostname\r\ninformation by calling GetUserNameA and GetComputerA functions.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 16 of 21\n\nThe network module gathers the information and creates a buffer that is later encoded with a\r\nhardcoded key\r\nIn the above image can be observed the information mentioned plus the fact of the use of this offset containing the\r\nbytes used for the mutex or implant id.\r\nOne of the things that raised my attention is that this step is identical between versions, meaning that these bytes\r\nare always used and intended to be sent in the network traffic, however, they are also used as mutex if the sample\r\ngenerates one, which is not always the case. That’s why I’m naming it implant-id and mutex at the same time. Is\r\nsome sort of identifier that they may find useful.\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 17 of 21\n\nAdditionally, SunCrypt adds to this information (Versions and implant/mutex) the victim’s information as\r\nmentioned above.\r\nThe network buffer contains the following example structure:\r\n4 bytes: 0x50120108\r\nImplant ID/Mutex\r\nMinorVersion\r\nMajorVersion\r\nBuildNumber\r\n3 bytes: 0x3a0130\r\nLength of username\r\nUsername\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 18 of 21\n\n1 byte: 0x4a\r\nLength of hostname\r\nHostname\r\nThe above mentioned bytes are likely to be related to a manually implemented library used by the network routine\r\nto create the network buffer, however the library was not identified. Below an example of the network buffer prior\r\nto it’s encoding using an hardcoded single-byte xor key 0x11.\r\nAfterwards the C2 address that was stored during the configuration decoding is loaded and pushed into the stack\r\nto send all this information to the routine handling the HTTP request.\r\nPress enter or click to view image in full size\r\nSunCrypt network buffer entering the encoding loop stage\r\nBelow an example of what SunCrypt HTTP traffic looks like in WireShark, containing the encoded data in the\r\nPOST data.\r\nPress enter or click to view image in full size\r\nSunCrypt network traffic\r\nAnother interesting detail that was mentioned before was the use of C2 infrastructure associated to the Maze\r\nteam, reinforcing the idea of collaboration between ransomware teams which may indicate not only an stable\r\nrelationship between threat actors but also a potential cooperation to share infrastructure, resources and\r\ntechniques.\r\nSummary\r\nAfter the analysis of the samples, can be appreciated some but not a lot of evolution and changes. So far only one\r\nsample was found using clear-text strings (md5:0a0882b8da225406cc838991b5f67d11) which contains vital\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 19 of 21\n\nstrings such as the user-agent and the drive letter whereas the rest of the identified samples contains some of the\r\nfollowing modifications:\r\nUse of StackStrings and more obfuscation hiding all the relevant data\r\nFNV hashing implementation\r\nMutex\r\nFrom all the observed samples, most of them has been spotted using PowerShell as initial vector to obfuscate the\r\npayload and to load the binary into memory and “honours” all the functionalities that the developer team\r\nannounce in their forum post like the non-use of the CryptoAPI for file encryption and thread features. By\r\nlooking at the PowerShell loaders I personally found it similar to Netwalker PowerShell loaders, which makes\r\nme think that the SunCrypt team got some inspiration from them.\r\nSunCrypt contains multiple manual implementations on the source code to avoid detections but despite the\r\nnotable differences, it can be noticed that the team got a lot of inspiration from Maze. SunCrypt copied part of its\r\ncryptoscheme like the use of ChaCha20 stream-cipher and modified its session key implementation by\r\nreplacing RSA for the Curve25519 algorithm probably for two main reasons:\r\nKey generation is way faster and uses smaller keys than RSA, which allows a very fast key generation\r\nand operation.\r\nNon dependant of the Windows CryptoAPI. This allows SunCrypt to hide function calls and hardens\r\nthe analysis. RSA could be implemented manually, but I guess they considered that it wasn’t probably\r\nworth.\r\nAdditionally, to increase the encryption speed the SunCrypt team sends file data via completion I/O port to the\r\nencryption thread.\r\nOverall I have to say SunCrypt is not a very sophisticated ransomware unlike some of its competitors like Maze,\r\nEgregor, Ragnar or Wastedlocker and the main motivation I have to say this, is due to the evolution,\r\ntechniques, language(C over OOP like C++) and obfuscation techniques point to this direction but they got a lot\r\nof inspiration to make something similar to Maze. In fact when I saw SunCrypt for the first time I thought:\r\n“someone from the team just left and started its own project(?)” but after diving into it and checking more samples\r\nI could notice that the level of sophistication and experience, tooling and techniques used are not the same, but I\r\nfeel confident saying that they were a source of inspiration for sure.\r\nHowever, what has in common with Maze? It shares some of the command line arguments , the use of a\r\nnetwork module for data exfiltration, algorithm for file encryption and other references, however the main\r\ndifferences with Maze are:\r\nDifferent implementation of key generation, algorithms and session keys.\r\nNo storage of any temporary data. Maze drops a file in %PROGRAMDATA% to store session keys.\r\nNo anti-disassembly\r\nC instead of C++\r\nNo Anti-Analysis and different evasion techniques\r\nMaze contains a complex network module and URI scheme whereas SunCrypt’s is simple\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 20 of 21\n\nDifferent Shadow Copy deletion technique\r\nNo CIS country protection check.\r\nIt will be interesting to keep an eye on this malware to see its evolution and modifications to survive as the RaaS\r\nmodel service is a fast paced ecosystem full of very capable competitors.\r\nMITRE ATT\u0026CK\r\nT0127-Evasion: Obfuscated Files or Information\r\nT1497-Evasion: Virtualization/Sandbox Evasion::System Checks\r\nT1083-Discovery: File and Directory Discovery\r\nT1082-Discovery: System Information Discovery\r\nT1033-Discovery: System Owner/User Discovery\r\nT1129-Execution: Shared Modules\r\nSamples\r\nmd5 3d756f9715a65def4a302f5008b03809 (SunCrypt)\r\nmd5 b3ac4c0e5b64991f0a8c0add8cd6654c (SunCrypt)\r\nmd5 0a0882b8da225406cc838991b5f67d11 (SunCrypt)\r\nmd5 c171bcd34151cbcd48edbce13796e0ed (PowerShell Loader)\r\nmd5 d87fcd8d2bf450b0056a151e9a116f72 (PowerShell Loader)\r\nC2\r\nhxxp://91[.]218[.]114[.]31\r\nhxxp://91[.]218[.]114[.]30\r\nSource: https://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nhttps://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://medium.com/@sapphirex00/diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83"
	],
	"report_names": [
		"diving-into-the-sun-suncrypt-a-new-neighbour-in-the-ransomware-mafia-d89010c9df83"
	],
	"threat_actors": [
		{
			"id": "e9f85280-337c-4321-b872-0919f8ef64a6",
			"created_at": "2022-10-25T16:07:24.261761Z",
			"updated_at": "2026-04-10T02:00:04.914455Z",
			"deleted_at": null,
			"main_name": "TA2101",
			"aliases": [
				"Gold Village",
				"Maze Team",
				"TA2101",
				"Twisted Spider"
			],
			"source_name": "ETDA:TA2101",
			"tools": [
				"7-Zip",
				"Agentemis",
				"BokBot",
				"Buran",
				"ChaCha",
				"Cobalt Strike",
				"CobaltStrike",
				"Egregor",
				"IceID",
				"IcedID",
				"Mimikatz",
				"PsExec",
				"SharpHound",
				"VegaLocker",
				"WinSCP",
				"cobeacon",
				"nmap"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "c3c864b3-fac9-4d56-8500-7c06c829fbf8",
			"created_at": "2023-01-06T13:46:39.071873Z",
			"updated_at": "2026-04-10T02:00:03.203749Z",
			"deleted_at": null,
			"main_name": "TA2101",
			"aliases": [
				"GOLD VILLAGE",
				"Storm-0216",
				"DEV-0216",
				"UNC2198",
				"TUNNEL SPIDER",
				"Maze Team",
				"TWISTED SPIDER"
			],
			"source_name": "MISPGALAXY:TA2101",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434515,
	"ts_updated_at": 1775792021,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7577c7503af88534da469adf09044640597db384.pdf",
		"text": "https://archive.orkl.eu/7577c7503af88534da469adf09044640597db384.txt",
		"img": "https://archive.orkl.eu/7577c7503af88534da469adf09044640597db384.jpg"
	}
}