During our research on the Winnti group we discovered a considerable amount of Winnti samples targeting different gaming companies. Using this sophisticated malicious program cybercriminals gained remote access to infected workstations and then carried out further activity manually.
Naturally, we were keen to find out how the malicious libraries spread across a local network. To do so, we tracked the attackers activity on an infected computer.
1st attempt: virtual machine #1
At the beginning of the investigation we ran the malicious programs on a virtual machine, which worked fairly well – we even spotted some cybercriminal activity. But they quickly realized it wasnt a computer they wanted to net. Once that was the case, the attackers servers stopped responding to requests from bots working on virtual machines.
This is what we managed to learn at this stage of our monitoring.
First of all, the perpetrators looked at what was happening on the victims desktop. After that they enabled the remote command line and used it to browse the root folder of the current disk, searched for the file winmm.dll, and checked the operating system version. The ListFileManager plugin then came into play. It works with the file system and the attackers used it to browse the folders C:Windows and C:Work. Then they tried to restart the computer, but made a mistake in the parameters of the shutdown command, having typed shutdown /t /r 1 (the computer should have been restarted in 1 second), but after a while they shut the computer down completely with the use of the correct command shutdown /s /t 1.
Sequence of events:
|– remote command line module – CmdPlus.dll,|
|– work with file system – ListFileManager.dll, TransPlus.dll)|
When the virtual machine restarted, the malicious users connected to it and downloaded an auxiliary program named ff._exe_ into the folder Config.Msi.
(ff._exe_, MD5: 0xd2d6115a337cf4f40402d15cb9ece2ea, verdict: Trojan.Win32.KillWin.sp)
This program looks for files of the following types on the hard drive:
- HTML (.htm, .html) documents
- MS Excel (.xls, .xlsx) tables
- PowerPoint (.ppt) presentations
- Text files (.txt)
- MS Word (.doc, .docx) documents
- HTMLHelp (.chm) – context help files
- MS Works (.wps) documents
- Adobe Reader (.pdf) documents
Apart from this, ff._exe_ includes destructive functionality: if the disks file system has not been recognized as FAT or NTFS by the program, it initiates a procedure of filling the disk with zeros. Although the virtual machine in question had an NTFS file system on all the disks, ff._exe_ couldnt recognize the file system and started a disk cleanup. By all appearances, the attackers knew about this fault in the program and were trying to prevent an operating system crash by forcing the program to terminate, but they left it too late. As a result the hard drive had been filled with enough zeros and the operating system had died.
Sequence of events:
After that it would have raised suspicions if the state of the virtual machine had been rolled back and it was infected all over again. The intruders would have got a surprise if an infected computer they had just killed was once again working 10 minutes later and a bot was knocking to inform the C&C about itself working on a system with exactly the same configuration. So we decided to use another operating system and, just in case, another bot variant.
2nd attempt: virtual machine #2
We launched the new bot on the new virtual machine and after a while the intruders were active on the infected computer. They downloaded three files wm.bat, ctime.exe and wm3280.dll and executed wm.bat.
Batch file wm.bat:
- copies the latest version of malicious library wm3280.dll to the folder c:windows under the name winmm.dll;
- specifies the time attributes of file that has just been copied (creation time, modification time and last access) so they are the same as those for system library c:windowstwain.dll;
- specifies attributes of the malicious library as hidden, system, read only;
After that another auxiliary program ec.exe was downloaded and executed.
(ec.exe, MD5: 0x14c112794ca492b7a82fa11f94b5b8b3, verdict: Trojan-PSW.Win32.Certif.a)
This program looks for certificates installed in the system containing a private key. If any are found, it drops them as files onto the disk. When the program finished working the intruders used the command dir to check if any certificates had appeared. Since the infected virtual operating system had no certificates of this kind installed the attackers saw nothing and removed the ec.exe program.
They then manually went through the folders on disk C:, came across a folder called Sign that I had created in advance where I had put a certificate with which a certain program was signed. The cybercriminals took a close interest in the folder and a file with the extension .cer and made a copy of the file for themselves.
When the certificate theft had been completed, the attackers used the net view command to see which computers existed in network neighborhood and displayed a listing of all established connections with the netstat an command.
This was all that was of any interest on my virtual machine. After analyzing the data they retrieved, the criminals figured out that this was a fake system, and the C&C server stopped accepting connections from the bot working on that virtual machine.
After that, we didnt risk using any more virtual machines it could frighten off the cybercriminals. Therefore, we decided to continue our observations in a more realistic environment.
3rd attempt: the Marta trap
I had arranged the local network to look like a department at a certain gaming company. The department was made to look like it was involved in compiling game resources. The computer of the imaginary new employee Marta had been infected with Winnti a week after she started work. Everything had to look plausible, which meant there had to be corporate correspondence in place for that week. Thats why we made up several correspondents for Marta to communicate with: a team lead, system administrator, manager and engineers. However, its a time-consuming task thinking up business emails which is why Marta was a new employee in the fabricated company and didnt have many emails in her inbox.
As has already been said, the intruders examined the infected computers manually. We had to wait for a while before we noticed in the network traffic that someone was active on the infected machine. Our main goal was to figure out what methods the attackers would use to infect Martas colleagues computers. We expected the attackers to send emails with a malicious payload to the other employees from Martas machine. However, they used different approaches.
Twice the intruders actively examined the infected computer and its neighborhood. That was in the early stage of observation. After that, if they returned to the infected computer, they apparently did so just to recall what computer it was nothing significant was happening.
The first time the attackers were just getting the lay of the land, observing what was happening on the desktop of the infected computer:
They carefully started gathering useful data from the computer. They had a look at some folders (created in advance to simulate work-related activity by our fictitious new employee):
With the help of the command net use they took a look at what network resources the computer had been connecting to and saw that there was single mapped network disk:
They tried to access disk C: of the remote computer with the use of the command dir and were denied access:
With the use of the net view command they managed to see the other computers on the network:
They then tried to access the file system of one of them – unsuccessfully:
With the help of net user they took a look at what users were registered on the infected computer:
Apparently at this moment the intruders decided to take a break and think over what to do next, since they stopped their reconnaissance and only returned several hours later.
On their second visit to the infected machine the attackers instantly checked with the help of the command net use if new connections to remote network resources had appeared since their last visit. Nothing new was displayed.
The intruders were looking for their malicious library:
They examined the content of the current users documents folder:
The file Default.rdp caught their attention:
For some reason they turned off the following attributes in their malicious library: hidden, system, read onlу (when the intruders operated on the virtual machine they did the opposite and set those attributes in the malicious library using the wm.bat file):
They loaded the program Network Password Recovery by the developer Nir Sofer to the infected machine. This program discovers saved passwords in the operating system linked to:
- accounts used to access remote computers in a local network;
- Outlook 2003 accounts;
- accounts in messengers MSN Messenger / Windows Messenger;
- accounts saved in browsers Internet Explorer 7.x and 8.x;
- Remote Desktop 6 accounts;
The network traffic revealed the program netpass.exe which was stored on the attackers operating system via the path Z:dllpassnetpass.exe.
The intruders executed that program with the parameter /stext a.txt that saves found passwords in a file named a.txt.
When the program finished working the file a.txt appeared and the intruders looked at it:
There were shared folders for Marta on remote computers in the local network allegedly for sharing data between Marta and other employees. Marta had already connected to the computers of users Jonas-448 and KARL-SCH and naturally she saved credentials for accessing the shared folders. Now the intruders had that data as well. They tried using Martas credentials to access the disk C: on Karls computer it didnt work:
They checked if Karl was on the network Karl was on-site:
They then tried to play around with the input data of the command net use it didnt help:
After that the intruders probably lost interest, removed all the files they had created and did nothing more of any significance.
Judging by the results of our observation we can assume that the members of the Winnti group dont bother with complicated work and tend to grab low-hanging fruits. This was also noticed when the group was trying to penetrate one gaming company for a second time. No doubt they wanted to re-infect the company it was notable that they were persistent but used fairly crude approaches, only rarely using more sophisticated methods. This may have worked if the company in question hadnt been prepared for such attacks, but we were waiting for them and their numerous direct attacks failed. In the end they just gave up and, as was the case earlier, they most probably postponed their next attempt for a month or so, possibly switching to another more susceptible victim. Considering how many companies they have already compromised, there is hardly a lack of potential victims. They appear not to waste much time on particularly hard targets, opting instead to make money from the numerous organizations that require less effort to crack.
The Winnti honeypot – luring intruders
Not yet confirmed switching incident through applica-malware injection into Andoroid.