CHAPTER
9
Attack Characterization Techniques
Wherever he steps, whatever he touches, whatever he leaves, even unconsciously, will serve as a silent witness against him.
—Professor Edmond Locard
You’ve dedicated a significant amount of your valuable time reading about advanced, persistent, and advanced persistent threats before arriving at this chapter. The study of the legal and threat landscape, as well as the various TTPs employed by those who wish you harm, is very important. However, what does it all mean? What happened? When did this all start? Where did they get in, and where did they go? Why did they attack you?
At the core of this discussion is determining who decided to break into your system, who decided to steal your financial information, and who decided to make your life miserable. Discovering the who can help paint a clearer picture of the what, when, where, why, and how, and determine its impact on your business. So, in case you’ve already forgotten the title of this chapter, we’re going to focus on trying to attribute malicious actions to a particular actor or group.
Your journey down this weary path likely started like so many others. It probably began with a small anomaly on your network or system—maybe the system was just running a little slow. You then went through some immediate troubleshooting steps to find out what piece of software or hardware was giving you problems. However, as your problem-solving steps took you deeper down the rabbit hole, you noticed some other anomalies, which required you to follow incident response protocols per your company’s guidelines. Something didn’t feel quite right while you were containing the incident, so you dug a little deeper to find the root of the problem. That’s when you notice it. Your company’s crown jewels—whether financial data, technical specs on the new design, or the CEO’s e-mail messages about a merger—have been exposed, which could derail your company’s reputation and business success. Who did this? What was their end game? And so begins your next journey, from hunted to hunter.
Postincident Characterization
Postincident or forensic adversary characterization refers to a situation where an incident of an undetermined type has occurred, presenting some form of already occurred observable data that was collected after the incident. This data is taken and used in a manner that may help you analyze the attack. There are several primary objectives of this form of characterization, which are limited since the incident has already occurred.
One objective is that the characterization will provide leverage to justify a measured reaction to an incident. It may be that the reaction is to change the design of a production network to a more secure model. You may also realize that the forensic analysis was only the beginning, and it is necessary to define an accurate profile of the adversary to aid in his capture. Most important, you may need to obtain a better understanding of the kinds of people who really want to break into your network, their motivations, and the types of attacks you are likely to see coming from the characterized subset of adversaries.
Because an actual event has occurred, the starting point for the characterization changes from the typical starting point of a theoretical characterization (which are the events that led to the discovery of the occurred events) to the data (from sources like the IDS and firewall logs or other) pertaining to an incident. To this end, one of the applications of theoretical adversary characterization that has attracted substantial interest is the possibility of a technology that can automate the characterization of adversaries from IDS data alone, providing a real-time “score” of the adversary responsible for triggering some rule or mechanism of an IDS. However, such automated mechanisms are currently not as effective as having a human in the loop. An IDS that provides characterization is basing that information on the IDS data alone, which could be bypassed by your attackers if they begin to understand those IDS rules though trial-and-error practices. Administrators can provide keen insights based on inputs from other systems as well as the IDS. Although automated characterization is possible and could be here in the near future, at this point, completely relying on technological solutions is not the route you want to take.
Metrics applied to examine the semantics of an attack could be used to draw conclusions about an adversary from data such as the operating system the attackers are using, the exploit they are using, the operating system of the target, and the difficulty of the hack.
Chapter 2 examined much of the characterization theory alluded to in this chapter, including concepts that can be applied for both theoretical (asset type) and postincident characterizations, giving us a framework through which we can seek attribution.
Attack characterization can have two primary components: events, which refer to what has occurred in the attack, and threats, which are the motives and intent of the attack.
Characterizing an attacker will rely on analyzing what you can see over the network and on the hosts. Generally, session data isn’t available through existing infrastructure or production resources (operational network). The following might provide information:
Web servers retain session logs, which can contain keystrokes.Host security programs, if installed and configured properly, can record user activity and session information.IDSs can monitor session activity.Honeynet technologies, if configured properly, can be deployed to monitor session-level interactions.Another Tall Tale
Michael was the senior network engineer at an up-and-coming software company. He had been with the company since it opened its doors about eight months ago, and had only one other person working with him. Given the small staff, he also served as a jack-of-all-trades, offering technical support when required.
The software company was still a small player on the scene. However, it had just devised a new way to process and analyze very large data collections. This new discovery had garnered the company some press lately, as it was going to partner with a major defense contractor. This could really put the company on the map, and the developers were working all hours to complete the final version of their code.
The day started out like any other. Michael had just arrived at work, still finishing his first cup of coffee. He noticed that the message light was blinking on his phone, and he wasn’t really ready to hear about someone who couldn’t open an e-mail message or some other mundane problem. That’s when Ryan, the other network engineer, came in and told him that his phone had already been ringing off the hook this morning. So, Michael decided he should actually check the voicemail and find out what was going on. It was Todd, one of the junior programmers, informing Michael that he came in last night to work, and his system had been running very slow. He probably hadn’t rebooted his system in forever, and that might be the problem.
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.
SpyEye main CP server desktop
You need to run this VM image locally using an open source or commercial version of a VM manager system, such as Virtual Box or VMware.
We also used BurpSuite, developed by Port Swigger (http://portswigger.net), which is a Java-based application for testing the security of web applications. This is a highly recommended tool when analyzing the security cyber criminal support infrastructures. Download the free version of BurpSuite, and with the SpyEye CP running locally, run the BurpSuite tool and set it with the following settings in the proxy tab under proxy listeners.
Proxy listeners setting to add new listener
Further down on the same tab, set the “match and replace” for the proxy of the session to overwrite the header request with one that would dupe the remote system into communicating openly between the SpyEye collector and the local CP, as shown here:
Request header overwrite between the local and remote server
Once these two settings have been made, all requests that are generated locally are sent to the remote server, and due to the nature of Ajax session management, you will be able to manipulate the remote server into responding to a local request. In practice, the vulnerability works, as Ajax is seeing the request coming in to the server, but it cannot distinguish between a remote and local request. Upon generating a local request, the remote server responds and sends all of the remote server information to the local server, seeing it to be a part of the remote infrastructure.
By using this technique, you are provided with all of the information stored on the remote CnC server, which is transferred seamlessly to the local CP for full inspection by the analysis team. You also have the data related to the victims that is stored in a SpyEye collector and all of the applicable statistics. The remote server then copies the following files to the local root directory of the web server running the SpyEye CP, which provide even more information related to the criminals’ infrastructure and their current campaign.
Debug.log (general traffic)Error.log (possible leaked IP addresses and other information)Tasks.log (what it’s doing)Backup.sh (SQL dump and passwords)Config.ini (settings)Although you may think what we have done is illegal, it actually is not. The analysis team worked with cyber law legal counsel for several weeks to refine the legal explanation and walk through the processes and procedures of this technique. By following the steps and recommendations covered in Chapter 5, we were able to convey the appropriate information for our legal counsel to understand the technique. Per the counsel, we were simply locally requesting remote files on obfuscated directories.
As the local CP in our control was obtained publicly, and the exploitable vulnerability did not affect or alter the state of the remote server, we were provided a legal analysis approving our technique for counter-exploiting criminal servers to learn more about the operators behind the campaigns. You may be surprised that the technique we developed was approved for use by not only our immediate legal counsel, but also by US law enforcement. This being said, we will now dive into the analysis of the data of more than 30 different criminal CnC infrastructures, and examine the habits and practices of the criminal operators to determine the motive, intent, and capability of the criminals behind the campaigns.
About SpyEye
SpyEye is a low-cost and effective do-it-yourself (DIY) Trojan kit with many features. With SpyEye, sorting can be based on infected processes, bot globally unique identifiers (GUIDs), and FTP logins. The configuration requires a standard Linux, Apache, MySQL, and PHP (LAMP) environment. The installation is simple, and the majority of the front-end web code uses Ajax (XML/HTTP) to post the data queries to the viewer.
SpyEye divides itself into two setups: the CnC controller (this houses the statistics and communication with the machines interactively) and the form grabber, which is used to collect the login data and store it in a database for querying. The form grabber and the CnC controller identify themselves to an outside observer via the HTML <title> tag that most browsers render to be displayed in the middle of the top bar of the browser when accessing the page. Figures 9-1 and 9-2 show examples of these <title> tags.
Figure 9-1 CnC identifier within the <title> tag (CN 1)
Figure 9-2 Form grabber identifier within the <title> tag (SYN 1)
To access either CN 1 or SYN 1, a password prompt is displayed to authenticate access, as shown in Figure 9-3.
Figure 9-3 SpyEye password prompt
Latest SpyEye findings reveal certain botnet operators “skinning” their web panel, as shown in Figure 9-4. This demonstrates a level of care for their infrastructure.
Figure 9-4 “Show me the money” skin
Features of the CnC portion of the web panel include FTP back connect, SOCKS5, code insertion, binary uploads, task monitoring, global statistics, and settings, as shown in Figure 9-5.
Figure 9-5 CnC portion of the web panel
Binary Update Function
The binary update function is used to continuously update the bots within the network. Further analysis indicates that this activity happens frequently, at minimum on a daily basis. The purpose of this function is to replace binaries that are unknown to the antivirus community, since the updates are not distributed in the wild via exploits, but internally through the tunnel created between the CnC back end and the operator. Further investigation enables us to identify the new MD5s updated to the bots and reveals how many active bots are receiving updates, as shown in Figure 9-6.
Figure 9-6 Real-time update log identifying the new MD5 and the originating MD5
Figure 9-7 MD5 a3fe1f59d8d72699ad342adb992ba450 with 4.9 percent identification according to VirusTotal
Up Sell
Within the SYN 1 form grabber panel, a few features have been updated for version 1.2, including a private certificate stealer, as shown in Figure 9-8. This feature allows the botnet operator to request certificates from the controlled bots. Also available is a specific Bank of America grabber. Both of these features require the buyers of the malware DIY kit to pay extra if they desire these features.
Figure 9-8 Form grabber panel
Backdoor Access
Within the CN 1 panel, there are FTP back connect and SOCKS5 controls designed for miscellaneous use, such as remote administration and sending spam. For each bot with SOCKS5 availability, the server binds a unique port on the CnC server for the botnet operators to perform a reverse connection with the infected host, as shown in Figure 9-9.
Figure 9-9 SOCKS5 reverse connection status
Statistics and Data Collection
A common trend in many other botnet control panels is the geographical IP address location and version tracking, and SpyEye follows suit, as shown in Figure 9-10.
Figure 9-10 Geographical IP address and version tracking
Other statistics acquired are infected operating system versions, Internet Explorer versions, and user type:
The latest SpyEye malware also enumerates the software information that exists on the victim hosts, as shown in Figure 9-11.
Figure 9-11 Enumerated software on an infected host
In addition, check boxes have been added to the stolen data query page, enabling wildcard lookups with the LIKE? option for bot IDs, as shown in Figure 9-12. These features were likely added to enable granularity for each query.
Figure 9-12 Lookup options
SpyEye’s evolution is progressing rapidly, and the success rate of the malware itself appears to be increasing quietly yet effectively. Combined with impactful distribution campaigns, this malware is an up-and-coming contender in the ongoing threats plaguing the Internet.
Traffic, Targets, and Taxonomy
So far, we’ve discussed many of SpyEye’s specific features and demonstrated its rapid evolution, similar to the infamous Zeus malware that scourges the Internet in a highly aggressive manner. Now we will focus on the following topics:
Traffic analysis of the CnC, including configurations and binary updatesTaxonomy of the separate SpyEye botnet operatorsInfection statisticsTraffic Analysis
Traffic analysis for SpyEye reveals particular information about the specific exploits incurred by the botnet operators, as well as their motives. Acquiring intelligence early on about an increasing threat such as SpyEye is essential in order to gain an upper hand against such malice. Performing traffic analysis is an effective method to obtain information about the intentions and actions of an enemy. In this case, we were investigating an operator of SpyEye using the tool to steal credentials and financial information from unsuspecting computer users.
Unfortunately, the initiation period of this specific operator’s attack remained unreported publicly for eight days, likely enabling an effective infection rate. Supporting this theory, we found that on the first day of this SpyEye campaign, the operator fortuitously exploited 11,678 unique computers (approximately one host was infected every seven seconds on the first day), and then proceeded to update the bots immediately with 94 different binaries. This is usually an attempt to prevent antivirus software from detecting anything that was possibly discovered in the wild, essentially ensuring a longer life cycle and obviously more profit.
Figure 9-13 The general SpyEye botnet configuration
The traffic analysis targeted at this specific malware expedition enables us to gauge the success of this operator’s attacks and, in general, the potential of the threats that exist on the Internet. The following are some observations exhibited through this type of analysis:
Life cycle of malware campaignsApproximated traffic generated between the CnC system and infected hostsType of traffic generated (configuration, binary updates, and geolocation updates)Infection rateCnC time zoneUnique binaries generated (daily)Figures 9-14 and 9-15 provide a general idea of the daily infection rate. These graphs measure total traffic activity based on the types of requests that are made to the hosts. It is interesting to note that at the beginning stages of the CnC activity, the priority seems to be focused on updating the bots with new binaries (naturally a protective measure). Coincidentally, around the same time that this specific site was reported as malicious, we observed that the main type of traffic became focused on updating configurations on the botnets. This continued until the end of the life cycle and ceased abruptly when the site was shut down on September 24. This could suggest that the majority of stability is determined after a week of protecting the infected hosts from detection, and the interactive malicious behavior between the botnet operator starts within the next week of the life cycle (since configuration updates include task loading as well as setting up infected hosts).
Figure 9-14 Infection and binary distribution
Figure 9-15 Traffic analysis tells a story.
Checking Out the Competition
Many other SpyEye campaigns that have lengthier life cycles have not necessarily been as successful when it comes to mass infections. Here are two examples:
Both of these CnC hosts were still live when we performed this traffic analysis, and they reflect the more common infection rate that the SpyEye operators are averaging. What is very noticeable is that with the majority of cases observed, the public discovery and detection rate of the CnC host and its activity is significantly behind compared to the actual date of the initial launch of each unique SpyEye operation. This obviously gives the botnet operators a significant edge at this time.
Targets and Taxonomy
We identify many infected targets when analyzing botnets and their intentions, and we confidentially report our findings to the rightful owners of the data. Here, we are going to focus more on the targeted Internet service providers (ISPs) that are hosting the SpyEye CnC systems and binaries. Some of these ISPs appear to be quite lenient in allowing this malicious behavior on their network, and we have researched an eight-month timeline of SpyEye activity, from January 16, 2010, to October 16, 2010. This period covers the majority of known activity conducted by SpyEye operators.
The Facts Since January 2010, there have been 173 unique domains discovered in the wild and 17 IP addresses hosted on 77 unique ISPs in 24 countries. Many have had a decent life cycle and demonstrated gradual growth over time in use. Figure 9-16 shows a graph of these attacks over the period from January to October.
Figure 9-16 190 attacks over eight months
From this data, it is apparent that the summer months saw significant growth for SpyEye activity. Seeing that there were more than 190 known unique SpyEye assaults over an eight-month period suggests that this specific malicious software is growing in popularity and will likely continue to do so.
Location Within this eight-month period, we observed that the highest density (almost 30 percent) of launches were conducted within Ukrainian (UA) IP address space, as shown in Figure 9-17. The Czech Republic (CZ) held second place at 12 percent, and the United States came in third at 8 percent.
Figure 9-17 Ukraine wins the gold medal.
Figure 9-16 presented unique SpyEye campaigns over the eight-month timeline, which is useful for identifying its traits for growth and preferred seasons. But by taking it a step further, we can organize the campaigns by location over the defined timeline, as shown in Figure 9-18.
Figure 9-18 Countries playing host
An interesting pattern we see is the high density of Ukraine (UA) appearing mostly within July and August, and tapering down in September. But then we see the Czech Republic (CZ) exercise exponential growth just in September alone. Taking a look at a cluster of CZ ISPs, we can combine the registration, and we’ll notice a very obvious pattern:
This makes it easy to recognize that serial patterns and habits are formed, and enables us to trace back preferences such as specific ISP services and locations.
Internet Service Providers Table 9-1 lists the identified ISPs involved and their geographic locations.
Table 9-1 Involved ISPs
Figure 9-19 shows the ISP distribution among these countries graphically. Both the United States and the Ukraine have 16 ISPs, yet the Ukraine’s hosting usage is more than three times that of the United States. The ratio of US hosting during the eight-month period is rather normal, with two specific modest jumps in May and September. Figure 9-20 shows the ranking of the ISP usage.
Figure 9-19 Countries with unique ISPs
Figure 9-20 Ranked ISP usage
SOFTEL (ASN 50134) ranks highest in use by botnet operators (13 times in eight months) followed by COLO-AS (ASN 196954). By taking a look at what months the ISPs were used, we got a history of certain SpyEye activity, as shown in Figure 9-21.
Figure 9-21 ISP usage per month
The graph in Figure 9-21 illustrates how we can use this information to identify significant patterns. An example is that UAIP-AS (a Ukrainian network, ASN 51306) made a significant appearance in August. If we analyze the specific activity for that ISP, we find this information:
In July, we see the same operator displaying the same pattern using ASN 196814, which is PAN-SAM, a network related to UAIP-AS (also run by PAN-SAM). The operator’s URI pattern remains the same, and he utilizes these ISPs for aggressive malware distribution and CnC use.
By following the trail of convenience for operators (known serial ISPs that enable their malicious activities), this type of analysis allows you to trace backward and track distinct operators.
Aftermath
At the end of a 10-month analysis of over 30 SpyEye botnet CnC servers, the analysis team was able to determine which criminals behind each botnet (almost all being run independently) posed the largest threat to enterprise networks. There were several tied back directly to the author of SpyEye, Gribodemon, and his cohorts and direct customers, who at the time went by the online identities Hiro, Bx1, jb00n, and Vasy. The information was collected and used against the criminals to deny, degrade, and deceive their ability to continue to steal from the innocent. The analysis team was able to provide detailed information for each criminal operating each SpyEye botnet, including the following:
Crimeware infrastructure configurationBotnet update proceduresMotive and intent of criminalPersonally identifiable information (of the criminal operator)
Login and password for the botnet domain registrar accountLogin and password for e-mail accounts the criminal used for alertsLogin and password for virtest accounts (which test SpyEye binaries detection rates)Login and password for domain blacklist checkersLogin and password for criminal online bank accountsLogin and password for incoming IP addresses (where is the bad guy?)Although this information does not exactly identify the true physical identity of the criminal (focus) behind the threat, it is useful. It can be sent to law enforcement, used for counterintelligence purposes to counter the threat, or be used in other nefarious ways that would flat out damage the criminals’ ability to do what they desire to do.
Conclusion
Not everyone is capable of generating their own exploits that will pass legal review for use on operational or live networks. However, there are techniques out there that can help you analyze and better understand the actual persons behind the keyboard on the other end analyzing the stolen data from your enterprise.
Threat research requires the ability to adapt and respond to evolutionary technologies from threats such as SpyEye. Through traffic analysis and taxonomy, you can gain a very eye-opening perspective on these types of threats and can begin developing intelligent defense systems that tackle very specific advances conducted by malicious actors on the Internet. This type of research enables development of preemptive defenses, enabling networks to remain protected against these types of attacks. This chapter discussed some of the tactics and tools that can play a role in actively engaging an active threat within your enterprise.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.