Operations Security (OPSEC)

Sometimes when you follow cybersecurity experts on social media or look at cybersecurity presentations, you may come across phrases like “OPSEC FAIL.” These usually refer to significant operational errors made by APT groups and/or malware developers. For those who are curious about what operasyon güvenliği (OPSEC) is, it stands for Operational Security, which is a process of protecting critical information about an operation to prevent it from being acquired by opposing intelligence units.

At the Virus Bulletin event held in London from October 2-4, 2019, I participated in a presentation entitled “Who is SandCat: an unveiling of a lesser-known threat actor” by Kaspersky. The presentation covered the OPSEC errors made by the SandCat group, believed to be a unit of Uzbekistan intelligence. One of the errors was that the group used a command and control center with the address registered under the name of a military unit (Military Unit 02616) when testing 0-day exploit codes on systems with Kaspersky Antivirus software that had telemetry feature enabled. This showed that the group did not take OPSEC very seriously. Kaspersky researchers were able to take advantage of the opportunity and collect the 0-day exploit codes used by the group from systems with Kaspersky Antivirus software and analyze them.

As a cyber security researcher who takes advantage of opportunities to hunt for threats on VirusTotal, I recently encountered a malicious software developer who was not paying attention to the topic of OPSEC (Operations Security) in the past months.

When I ran the malware named “fatura1.exe” on my analysis system, a fake phone bill and warning message appeared. When I examined the “fatura1.exe” file with the RDG Packer Detector tool, I learned that it was developed with the C# programming language. When I briefly looked at the code with the ILSpy source code translator, I saw that the code was obscured (obfuscated). To make the source code readable, I used the de4dot tool.

When I looked at the source code, the function s_method2() which decrypted the data encrypted with AES caught my attention. After a short time of analyzing the Main() function step by step with the dnSpy debugger, I noticed that the s_method0() function decrypted the encrypted data and saved it in the variable byte_0 and then saves it to a file and runs it. After I learned this, I decided to save the data in the byte_0 variable to disk and analyze it.

After analyzing this file with dnSpy and also the ANY.RUN sandbox system, I found that it was a cracked version of a password and crypto wallet stealer called Project Evrial.

After the analysis, I found the command and control center’s address (http://zmcoin.tk) and decided to visit it. With the directory browsing feature enabled, I was able to view the files stolen by the malware in a folder. When I sorted the files by date and downloaded the oldest file to examine it, I saw that the malicious person had first tested this malware on their own test system. Of course, this test system was not only used to test the malware but also for personal business, which resulted in a failure of OPSEC (Operations Security) as the malware had also stolen personal information such as name, surname, email address, etc. from the system. The malicious person fell into the well he dug himself. :)

As it can be seen, it is possible to obtain important information about cyber operations and the people who carry them out, thanks to malicious actors who do not pay attention to operational security.

Hope to see you in the following articles.