Reverse Deception: Organized Cyber Threat Counter-Exploitation (93 page)

Michael walked down to Todd’s desk to see if he was still having problems. Todd said everything seemed to be fine now, but Sam had the same problem last night.

It was still early, and today was the day they were scheduled to install their new networking equipment. They had been planning the upgrade for months, so the slow machines quickly vanished from Michael’s mind as he focused his efforts on bigger tasks.

Discovery

A week had gone by, the upgrade went off exactly as planned, and Michael was now ready to plot out the next major project with Ryan. Just when they were getting ready to plan the needed server upgrade, the phone rang. Todd’s system was acting weird again. Michael had completely forgotten about Todd’s problem, and decided to head down to Todd’s desk again to finally figure out what was happening. He told Ryan to do the daily log check while he was gone, since they were a week behind.

Michael spent about 30 minutes looking at Todd’s machine, but couldn’t figure out the problem. He decided to just replace Todd’s machine with one of the new ones in the back, already loaded with the image of the operating system and approved applications. The entire process for replacing Todd’s machine took only about an hour. When Michael got back to his office, Ryan knocked on the door and said he needed some help. When they got to Ryan’s office, he showed Michael some of the network logs he had been scanning. There was some weird traffic that he had never seen before.

They spent the next couple of hours combing through the logs for the past week. It appeared that two machines on their network were communicating with some strange places they had never seen before. At first, they thought it might have to do with their newfound relationship with a big contractor. Maybe the programmers were exchanging information with some of the other company’s programmers to ensure a smooth integration. Michael had always liked the security side of things and did as much reading as possible, but given the pace at which he and Ryan had been working, there was never much of a chance to implement any of the things he read about. Well, there was no time like the present.

The next morning, Michael showed up with the box of security books he had read over the past year and told Ryan it was past time for ensuring their network was tight. They spent the rest of the day setting up Snort, an IDS, for use on their network. They didn’t want to impact the users by trying to stop any traffic, but they did want to be alerted to anything weird traveling to and from their network. They downloaded the latest rule set and installed it that night. They both decided to call it quits for the night, once they were sure the system was running properly, and looked forward to seeing what it produced after it ran through the weekend.

Before Michael left for the weekend, he had copied the suspicious logs that initially concerned them to his laptop. He decided to spend part of the weekend going through them, irritated at the thought that something was wrong with his network. After two days, and too much pizza and caffeinated drinks, he felt like he had a better understanding of the traffic. It looked like a couple of machines were engaged in two-way communication with several different IP addresses. After a little digging, Michael discovered these IP addresses were located in Nebraska, Texas, California, Brazil, and the Philippines. Why in the world would one of the users go to a website hosted in the Philippines?

Monday morning brought news for which Michael was just not prepared. Ryan told him that the Snort IDS had alerted them to a lot of malicious traffic over the weekend. It looked like the traffic was destined for one machine: Sam’s. However, Michael remembered that the logs from last week showed at least two machines were throwing out weird traffic. If two machines were involved earlier, why was only one affected this weekend?

For most of their network, they used DHCP to dynamically assign IP addresses to the network. However, for many of the programmers, they used the DHCP server to assign static IP addresses because of some of the work they did. He searched the configuration file for the other IP address. That was Todd’s machine. Then it all started to come together. Todd’s and Sam’s machines had been running slow. He replaced Todd’s machine. Sam’s machine was still on the network. Now other machines might be affected. Then he remembered that Todd’s old machine was in the closet. He wondered if there was something on it causing the unwanted traffic.

Michael yelled at Ryan in the other office and told him it was going to be a late night. Michael grabbed Todd’s machine from the closet, while Ryan swapped out Sam’s machine. They put both machines in an empty office and readied themselves for a night of examination. They decided not to plug the machines into the network, because they didn’t want to add to any suspicious traffic on their network. The antivirus software was up to date. The latest operating system patches were installed. Nothing stood out to them. So they stopped, took a breath, and worked out a timeline of the activity. All signs pointed to Todd and Sam as ground zero.

Michael and Ryan were still at work when Sam arrived in the morning. They asked him if there was anything that stood out to him that might have happened when his machine started acting weird. He said that all he could think of from that day was that he found a thumb drive in the bathroom and plugged it into his computer to see if he could identify its owner. Sam said he looked at the file and thought it might be Todd’s, so he sent it to him as an e-mail attachment. Sam still had the thumb drive, so Michael and Ryan took it and hustled back to their office, knowing that this could be the root of their problems.

Malware

Ryan and Michael knew they were going to face some difficulties figuring out what the file on the thumb drive did, since they were not well versed in reverse engineering. Michael remembered meeting Brittany at a local computer security users group meeting two months ago. She worked at a larger company specializing in malicious software (malware) threat analysis. He pulled her card from his desk and gave her a call. He told Brittany that he had a problem and ran down the list of anomalies they had found over the past week. She told him to send her the file and the hard drives, along with the logs, so she could investigate. In the meantime, Brittany asked Michael to keep monitoring the traffic on his company’s network.

Brittany called her team together and provided them with a rundown of the situation. They rapidly began analyzing the data from the logs and the malware. One of them fired up IDA Pro, launched Wireshark to view any communications resulting from the malware, and began to analyze the file from the original thumb drive. In a virtualized environment, the seemingly innocent PDF file was launched, and IDA Pro allowed the malware analyst to step through it line by line. Everything looked fine at first, and then it happened. The PDF file dropped another file in one of the system directories, which then beaconed out to some of the same IP addresses originally seen by Michael. The PDF document was innocent enough, but behind the scenes, it had installed another program, which allowed remote access to the machine.

In the meantime, Michael and Ryan were busy analyzing the traffic on their network. They still had Snort running, alerting them to any more activity, as well as Wireshark watching traffic ingress and egress. They were capturing live packets on their network, saving them for later analysis. Michael had already realized that some of the machines on their network were being remotely controlled as part of a botnet. Ryan started taking a deeper look at the information, and was surprised to see that some of it was not encrypted. As they started to piece together what they were seeing, it looked like some of the design documents for their data collection analyzer. They had gained a much better grasp on what looked right and what didn’t, so they felt much better about running Snort inline so it could also act as an IPS. This had proved very beneficial in stopping the malicious traffic on their network.

While Michael and Ryan were making progress, Brittany and her team were wrapping up their portion of the investigation. Log analysis from the previous weeks revealed that several machines on Michael’s network had been communicating with several CnC servers used by criminal networks to steal information from unsuspecting victims. They correlated that information with the forensic analysis of the two hard drives he sent. Dates and times matched from the timeline that Michael sent and the infection seen on the initial two systems.

Aftermath

Brittany and her team passed their information back to Michael as well as to the FBI. She knew the FBI investigators were interested in cases such as this, because they had seen a tremendous uptick in this kind of activity, especially associated with various contractors. When they correlated this information with what Brittany’s team sent and with the analysis that Michael had completed, they decided to dig a little deeper. After several months, they traced the activity back to a criminal element who appeared to have stolen the information for another contractor, in the same town as Michael’s, no less. It turns out that the competitor had been working on the same type of project and wanted to get a leg up on Michael’s company. Luckily, Michael and Ryan had caught the initial infection fast enough and called in for outside help when they did.

Did all of this sound familiar? It should. It happens almost every day.

Real-World Tactics

Now let’s turn to the real world. We’ll show you an approach some of the authors took to track down the infamous developer behind the SpyEye botnet, an Eastern European “semifunctional” programmer better known as Gribodemon (also affiliated with Harderman, Hiro, Roman, ep0xe1, Bx1, and others). This demonstrates a method of analysis and legal infiltration of a global criminal infrastructure.

For the cyber counterintelligence operation we’ll walk through in this section, the discovery of the enabling vulnerability was crafted and refined by Lance James while he worked at Damballa, Inc. In order to properly tell this tale, we first need to give credit where credit is due, and this time it goes to Lance for all of his amazing work in the field of cyber counterintelligence and CCI operations. His technical caliber should worry the bad guys. (He’s also an amazing singer, but that is neither here nor there.)

Engaging an Active Threat

In late December 2009, a new Trojan (known as SpyEye), which has properties that compare and compete with the Zeus Trojan, appeared in the Russian underground market. Similar to other theft-based malware, it has a web-based CnC back end that collects and sorts the stolen data and its statistics. This tool died early in 2012, due to pressure on the author team from numerous angles, ranging from private industry, law enforcement, and infiltration of their circle of trust by security professionals seeking to take the author team down.

The following is a breakdown of the analysis performed on more than 30 SpyEye CnC servers using an information disclosure exploitable vulnerability in the session management mechanics of the back-end control panel managing a SpyEye botnet. The analysis performed through this exploitable vulnerability provided the analysis team with the ability to read all server-side files. With this technique it is not possible to write or alter any of the information on the criminals’ CnC server, which was important to us because it meant that we would not be responsible for editing, damaging, or overwriting any of the data stored on the criminals’ servers.

We have chosen not to disclose the exploitable vulnerability to protect the innocent and the guilty. However, we will walk you through the process step by step. This will give you an idea of how we were able to accomplish this feat and circumvent the criminals’ security posture and exploit the laziness of crimeware developers (who are just as lazy as industry software engineers). In
Chapter 13
, another technique that has been used to circumvent the stupidity of criminals will be disclosed, along with repeatable code so you can play yourself.

To re-create our environment, you need a Linux-based server running the SpyEye main administrative control panel (main CP). This is the primary server that manages multiple collectors, which are servers that are put out on the Internet or locally on the same server as the main CP. The SpyEye collectors are responsible for communicating with infected victims running the SpyEye bot (Trojan). If you approach one of the members of the analysis team, you could be provided with the SpyEye server distribution image. Surprisingly, this a Linux VM guest operating system image, which has been custom configured by the SpyEye author team. The following shows the desktop of this image, which has the humorous depiction of the nationality of the lead author, Gribodemon.