u/CyberMasterV

I think it depends on the malware author's skills. You're right, it would be more difficult to analyze a malicious sample that doesn't have a lot of imports in the IAT (import address table), however, it's doable and requires more steps to potentially recover the IAT. For ransomware actors in particular, I don't think they care too much about stealthy (as opposed to spyware, some RATs, and others). For example, someone would need to implement a hashing mechanism and compare these hashes with pre-defined values to determine the required functions/DLLs at runtime. Custom obfuscation and packers are also pretty common if you want to have a low number of symbols/functions in the payload.

Hey OP, I have a lot of malware analysis step-by-step posts on my blog https://cybergeeks.tech/ . I also recommend reading the Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software book and completing the labs. Let me know if you have any questions.

Short analysis: The ransomware checks if a file is encrypted by comparing the first 4 bytes with a specific 4-byte value. The files were encrypted using the ChaCha20 algorithm (symmetric cipher from Crypto++ library), and the ChaCha20 key was encrypted using a public key and stored in the encrypted file. In order to decrypt files, you need to have that fullKey file corresponding to your specific ID (8 bytes), which is different from the other that successfully decrypted the files. That's why you can't decrypt your files using the same key file.

Hey OP,

Ransomware encrypts files using AES and then the AES key is encrypted using the RSA public key embedded in the malware. When the TA gives you the decryptor, it contains the RSA private key corresponding to the public key that can be used to decrypt the AES key corresponding to a file. TA usually changes the RSA public key because otherwise everybody can decrypt their files if a single payment is made and the private key is shared. I can take a look at this and I'll update the post in a few days.

Hey, they've called it differently but I usually give them a generic name such as "malware.exe" during my analysis.

I have a few step-by-step analysis articles of Linux malware on my blog: https://cybergeeks.tech/how-to-analyze-linux-malware-a-case-study-of-symbiote/.

Yeah

"The malicious activity is implemented using the Heaven’s Gate technique. The segment
selector 0x33 is utilized to transition to x64 mode and execute 64-bit code." It uses NTAPI undocumented functions to perform most of the malicious activity.

Yes https://www.bleepingcomputer.com/news/security/linux-version-of-royal-ransomware-targets-vmware-esxi-servers/

It works for me.

What about download this PDF and let's read about analyzing malware in PDF files? :D Maybe it will be my next project.

Hi, what error do you get?

When you're in doubt, VirusTotal helps!

"data consisted of public information, such as Twitter IDs, names, login names, locations, and verified status, it also included private information, such as phone numbers and email addresses."

I would say they prefer .IMG, .ISO, and .lnk files rather than PDFs now. You can check the reputation of the domain on VirusTotal, DomainTools, etc. if you want to be extra careful.

Hi, I'm not sure about Signal because I didn't study it's encryption of messages, but I can tell you that if you have a stealer on Windows that wants to steal the browser credentials for example, it can decrypt the creds using the key stored on the machine. I think Signal is useful to avoid Man-in-the-middle attacks, but if a TA has access to your phone with root privileges, it's game over.

Dissect - a proprietary enterprise investigation framework. Dissect is the collective name of the many different projects that live in the dissect.* namespace. Many of these projects are parsers or implementations for various file formats, such as dissect.ntfs for parsing NTFS filesystems or dissect.hypervisor for parsing many virtual disk formats. However, when we’re talking about “dissect”, we usually refer to one project in particular: dissect.target.

dissect.target is a host investigation framework made for enterprise forensics. It works on targets, which is basically any type of source data you may encounter in an investigation. You don’t have to worry anymore about how you’re going to get something like a registry hive out of an image, instead you’re able to immediately get usable artefacts and investigation information out of any source data. This allows you to spend more time on doing the fun and interesting work of an investigation, and less time on the boring stuff, like extracting files and running a bunch of different tools on them.

(https://docs.dissect.tools/en/latest/overview/index.html)

Dissect - a proprietary enterprise investigation framework. Dissect is the collective name of the many different projects that live in the dissect.* namespace. Many of these projects are parsers or implementations for various file formats, such as dissect.ntfs for parsing NTFS filesystems or dissect.hypervisor for parsing many virtual disk formats. However, when we’re talking about “dissect”, we usually refer to one project in particular: dissect.target.

dissect.target is a host investigation framework made for enterprise forensics. It works on targets, which is basically any type of source data you may encounter in an investigation. You don’t have to worry anymore about how you’re going to get something like a registry hive out of an image, instead you’re able to immediately get usable artefacts and investigation information out of any source data. This allows you to spend more time on doing the fun and interesting work of an investigation, and less time on the boring stuff, like extracting files and running a bunch of different tools on them.

(https://docs.dissect.tools/en/latest/overview/index.html)

Microsoft Customer Guidance: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

This is Kevin Beaumont's blog post regarding the vulnerability: https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9

No versions were mentioned, but I suspect all of them are vulnerable. They didn't give details about the POC though. They just mentioned a request that is similar with the format of the ProxyShell vulnerability.

Indeed! The third/final part will be published next month. This project was challenging but I learnt a lot along the way. I would like to analyze a more recent version of Pegasus but I didn't find one in open sources.

That was also a surprise for me because I didn't see other actors that dropped PEView on an infected host. My honest answer is Idk because they didn't ran it, however, I've included all tools that were dropped/installed for completeness even if the TA didn't use them. PEView can be used for basic analysis of a PE and you can extract information such as DOS header, sections hex dump, and others.

Thanks a lot for your feedback!

Well, thanks. I was just curious and requested some feedback, that's it. Have a good one.