ACCDFISA – RansomWare
Well, we have now had our first run-in with Ransomware. We received a call from a client stating that they were having issues accessing a remote application server. Sure enough, we were unable to access the remote application server through the VPN connection. Once on site, I was greeted with a screen stating that the server had been used to access illegal content on the internet and was shut down by the ACCDFISA, an acronym for the Anti Cyber Crime Department of Federal Internet Security Agency. The screen gave instructions for unlocking the system by paying $100 using Moneypak, Paysafecard, or Ukash. This looked to be a standard scamware application so I decided to attempt removal.
Hmm, nothing I could do would allow me around this screen. Pressing CTRL-ALT-DEL would bring up the menu allowing me to choose Task Manager but nothing would show up. I shutdown the server and was able to see Task Manager running in the background as the malicious application shutdown. The application relaunched after the reboot so I decided to restart to safe mode.
I was able to start the system in Safe Mode to the Command Prompt only. I was now able to start an analysis of the system. My first task was to export the system log files for review on a different PC. Next, I began tracking down how the Ransomware was loading. I found it in one of the remote users’ appdata folder. I now know who was logged on (or so I thought) when the application was downloaded. At this point, I created a backup of the files that I felt were causing the issues. I also found 1433 files that had been encrypted with an AES algorithm. Uh oh, not good!
Files from c:\programdata\local\ – (hidden)
Files from c:\decrypt — (hidden)
File downloaded from remote website
File from user desktop
- “how to decrypt aes files.lnk” points to c:\decrypt\decrypt.exe
I also found that the IP address had been changed to a 172.x.x.x address and default gateway was removed.
I launched the registry editor and found all references to the above files. The process loading the ransomware is the svchost.exe that was created in the user profile folder. Renaming the files remedied the issue with the application loading. However, nothing I could do would let me change the IP address. It’s at this point that I decided to test out the decrypt.exe file. When launched I received the following screen where I could put in the “purchased” recovery key should I have decided to fall to the ransom. This wasn’t going to happen as you’re not guaranteed that you’ll receive your code!
I decided to reload the server, but I still wanted to know “how did this load?” I know the username that the application was loaded from so started by looking through the user’s IE history. There it was, a single entry in the history to an .exe on a webserver somewhere. Unfortunately, I didn’t write this URL down. I found the file in the internet cache and was able to make a copy. Nice! Now, why did she go to this….. Oh no. I realized at this point that her account had to have been compromised. I began digging through the security log on the server and there it was, right there. There was a logon entry for the user just two minutes before the AES encryption was began. The next log entry provided what I feared!! The successful logon was from an IP address from 18.104.22.168, or wimax-client.yota.ru!! The account had been compromised. The password was complex and was something that could not have been acquired through a dictionary attack. Furthermore, there was NO failed logon attempts from this account in the event logs. Someone was able to get the password and get it right the first time!!!
I notified the IT support for this employee’s home office and the computer was put offline for analysis. I’m putting my chips on the guess that there is a key logging Trojan on this employee’s PC.
Now, back to the server. I decided to reload the server as it only hosts two applications for remote users. The AES encrypted files were random files on the server that the compromised user account had rights to. Everything was easily recoverable once the system was reloaded. We spent four hours on the reload and made changes to the firewall so that the published applications were accessible to specific addresses only.
What can you do with the AES files? Well, I’m gonna say that there’s nothing you can do without the encryption key. Hopefully, you have a good backup!
It looks like it’s now being detected by F-Secure, BitDefender, and GData as Gen:Trojan.Heur.TP.bqW@b4F!vWj. Symantec is detecting it as Suspicious.Cloud.5!!
UPDATE 2/23/2012 – 8:13PM
Microsoft is now detecting it. Microsoft Malware Protection Center