How hackers prepare attacks on banks

[RedX]

There is an opinion that attackers are using increasingly sophisticated techniques to break into financial institutions, including state-of-the-art viruses, exploits from the arsenal of special services, and well-targeted phishing.

Step 1: Define your Goals
In the offline world, it can be difficult to find out which services and networks belong to a particular organization.

1. Search engines (Google, Yandex, Shodan).
2. Industry websites for the financial sector — banki.ru, rbc.ru.
3. Whois services 2ip.ru; nic.ru.
4. Search engines for databases of Internet registrars - Hurricane Electric BGP Toolkit, RIPE.
5. Services for visualizing data based on the site's domain name - Robtex.
6. Domain zone analysis service dnsdumpster, which contains historical data on domain zones (IP changes), which greatly helps to collect data. There are a lot of similar services, one of the most well-known analogues - domaintools.com.

This study did not consider such methods as active scanning, determining firewall versions and the presence of IPS, determining the antivirus and other security tools used, and social engineering. There are several other techniques that we have not used for ethical and other reasons, but they are often used by hackers:

1. Search for projects on GitHub. It often happens that a test project, backup, or working code is posted on GitHub, but access to it is forgotten or incorrectly restricted. Research of such projects requires high qualification, but it gives you almost a 100% chance to get into the network using errors of the investigated application or embedded credentials.
2. Online vulnerability testing services, such as HeartBleed, Poodle, DROWN, and others. These services are highly likely to detect specific vulnerabilities, if any, but these checks take a very long time.
3. Bruteforce DNS. This technique is an active intervention. It allows you to iterate through the DNS names of systems, determining the available ones. This happens via DNS requests to the target DNS server. Traffic can be routed, for example, through Google DNS, and from the point of view of the attacked organization, these requests will look legitimate. To implement such techniques, you usually use the KaliLinux toolkit or a similar build. Unfortunately, in practice, DNS logs do not look at or even keep them until something happens.

So, first of all, we define the list of organizations that we are going to"put under control". To do this, you can use search engines, profile sites, and other aggregators of profile information. For example, if we want to collect statistics on financial institutions, go to banki.ru and we take the ready-made top banks and insurance companies. Collecting the list takes almost no time. We have identified the following categories of organizations:

• Banks (from 1 to 25)
• Banks (from 26 to 50)
• Banks (from 51 to 75)
• Banks (from 76 to 100)
• Micro-credit organizations
• Payment systems
• Insurance companies (from 1 to 50)
• Insurance companies (from 51 to 100)

Now we define the networks that organizations own. We find websites of organizations in the search engine, and use the whois web service to determine their addresses . This resource allows you to find out the site's domain name, IP address, and other important data for network search. In this paper, important data include:

1. Netname (network name, very useful when searching through the Ripe database);
2. Descr (the description can be used for a fancy search);
3. Address (search for networks registered to the same physical address);
4. Contact (it is possible to search in the Ripe database for people who could also register networks);
5. Other information that can be used to identify the organization.

All this information can also be obtained via the unix whois command. What to use is a matter of taste. In order not to compromise specific banks, we will show this search using the example of our company:

Using the collected information about organizations, we searched for their address ranges in the Ripe registrar's database. The Ripe service provides a free search option for all registered networks. You should also pay attention to the Country field – we chose only the Russian network segment.

This stage of work required a lot of manual labor, because some addresses may be given to a partner, rented out, or not belong to the organization you are looking for. Therefore, to improve the accuracy of the results, we had to perform additional checks to select only the necessary networks or hosts with the highest possible level of confidence. To verify the networks, we used the publicly available online service of the American telecom operator Hurricane Electric, which can provide information about the network in which it is located at the IP address (for example, at the site address).

As already mentioned, identifying the right networks is the least automated, since it requires manual selection of relevant results. However, it took us only 2 days to collect information about financial sector networks. After completing this stage, we received a list of the "organizations-networks" type.

Step 2. Identify available services
To do this, you can use one of the two most well-known tools designed to make the Internet safer: Shodan or Censys. They have similar features, support working with the API, and can also complement each other. Both services require registration for a full-fledged search. Censys is more demanding: to remove restrictions on the output of search results, you will have to write to developers, convince them of the ethics of research and responsible use of the data obtained. The argument in this case will be a CEH certificate or detailed information about the study.

We used the Shodan service because it is more convenient for getting data. Shodan also scans in the same way as Nmap scans with the "-sV " flag, which is a plus in our study – it makes it more familiar to process the results. The automation process is probably the most interesting, but there is no point in describing it in detail, because everything, including Python code examples, has already been described by its creator John Matherly, also known as @achilleanin, in shodan. Moreover, there is a repository on GitHub, where you can get acquainted with the official Shodan library for Python.

For more information about requests to Shodan, please follow the link. An example of a request via the web interface looks like this:

The example shows that the address 8.8.8.8 has a 53 UDP port, a DNS service located in the USA and owned by Google, and the version of the operating system used at this IP address. Requests to Shodan can identify much more specific services that you forget to restrict access to from the Internet, although this should have been done. Since you can get different banners and versions of these services, you can also compare the data obtained with different vulnerability databases.
However, it turns out that we need to run every detected IP address through Shodan, and we got, for a second, about 100,000 of them – too much for manual verification… What is it about the API?
We have written our own data collector. We launched the program and after a week of work, we got a picture of the distribution of available services in the financial sector, without interacting with them in any way! It is quite possible to track changes in infrastructures in this way.

From the most "terrible" on the perimeters of financial organizations found:

• DBMS (for the sake of justice, we note that some of the banners contained the entry "is not allowed to connect to this SQL server»);
• directory services (you can find out LDAP by using banners);
• services that provide access to the FS (such as smb and ftp);
• printers (and here, judging by the page load, there is no error!) that may have the most dramatic vulnerabilities and are generally recognized as the least protected devices. Yes, the vulnerabilities are old. But when was the last time you updated your perimeter printers?
• Insecure remote management services such as telnet, RDP;
• RPC Services;
• Virtualization systems;
• Multimedia services.

These services were distributed across organizations as follows.
We were not surprised by the results obtained: the larger the size of the organization, the more services are placed on the network perimeter, and as the number of services increases, the probability of configuration errors increases.

Step 3: Identify vulnerable services
After finding available services, you can determine the degree of their security. Are they vulnerable and, if so, what vulnerabilities do they have? To do this, you need to analyze the feature space that Shodan assigns for each individual host. This information looks like this:

• IP – a unique network address of a node in a computer network built using the IP protocol;
• Port – a digital number that is a parameter of transport protocols (such as TCP and UDP);
• Protocol – a set of logical-level interface conventions that define data exchange between different programs;
• Hostname is a symbolic name assigned to a network device, which can be used to organize access to this device in various ways;
• Service – name of a specific service;
• Product – name of the software used to implement the service;
• Product_version – version of the specific software;
• Banner – welcome information provided by the service when you try to connect to it;
• CPE – (Common Platform Enumeration) a standardized way to name software applications, operating systems, and hardware platforms;
• OS – Version of the operating system.

Shodan may not provide a complete set of information for all open ports, but if it does, the data (in the example, the results that have already been processed in our system are selected) looks like this:

From the entire feature space, we selected fields that can be used to find information about the vulnerability of this host. A bundle of Product + Product_version, or CPE, can be perfect for this. In our case, we decided to use the Product + Product_version bundle, and the search was performed using the internal vulnerability database of Positive Technologies.
There are a considerable number of publicly available sources for finding vulnerabilities on the web, here are some of them:

SecurityLab.ru - this is not only information security news and a forum, it is also a vulnerability database! Example of information output:

• FSTEC database – A database of information security threats that differs from other similar resources by the ability to find vulnerabilities for software and packages of domestic production;
• nvd.nist.gov - The National Vulnerability Database of the US Institute of Standards and Technology, which combines publicly available US government resources for finding and analyzing vulnerabilities;
• vulners.com - large updated database of information security content, allows you to search for vulnerabilities, exploits, patches, bug bounty results;
• cvedetails.com - easy-to-use web interface for viewing vulnerability data. You can view a list of vendors, products, versions, and CVE related vulnerabilities;
• securityfocus.com – one of the top public sources, especially in terms of filling in data on exploits.

All of the above resources allow you to quickly search for vulnerabilities based on various criteria, including CPE. These resources also allow you to automate the search process to some extent. As a result, you can find a lot of useful information: detailed descriptions of vulnerabilities, information about the presence of ROS'ov or recorded facts of exploitation of the vulnerability, and sometimes links to exploits:

We already have a set of services and their banners. All that remains is to run this information through the vulnerability database.
The results were as follows: out of the total number of services found by Shodan, vulnerabilities were found in 5% of services. This figure is small: for comparison, according to statistics from our own automated perimeter scans, vulnerabilities are usually found in 20-50% of services. But theoretically, the percentage of vulnerability detection can be increased. Let's see how this can be done.

For example, for ROSSSH (in the screenshot, the 4th line from the bottom), we can assume that the ROSSSH Remote Preauth Heap Corruption vulnerability is available. Despite the fact that the vulnerability is not new at all, the probability of encountering it in this service is significantly higher than zero. Let's remind you about our previous research, in which we said that about 30% of systems accessible from the Internet contain vulnerabilities older than 5 years. Similar results from Cisco, according to which the average duration of known vulnerabilities is 5.64 years. These results are comparable to our own, and the small difference in numbers is due to different samples and research methods.

Using the example above, we can assume that the RDP service has vulnerabilities CVE-2015-0079, CVE-2015-2373, CVE-2015-2472, and CVE-2016-0019. This is an incomplete list of possible vulnerabilities. In all open sources, these vulnerabilities are linked by CPE to the OS version, ignoring the binding to RDP. The most striking example is the high-profile exploitable vulnerabilities, which we will return to later. For many other services, you can also make similar assumptions about the possible presence of vulnerabilities.

Step 4. Search for exploits
The next step is to look for exploits for specific vulnerabilities. In the vulnerability search engines described above, it is possible to find exploits in a small number, but no one bothers to use special utilities for this, because the Pandora's box is already open. For example, there is a freely distributed utility called PTEE. It is described in great detail in another article. And there is also Metasploit, which, although it does not collect anything, but…

Since our company has its own knowledge base, where vulnerabilities are already mapped to exploits, no additional actions were required at this step. Based on the results of processing, we received:

• Of the 559 high-risk vulnerabilities on the CVSS scale, 88 are vulnerabilities with available exploits. ;
• Out of 733 medium-risk vulnerabilities on the CVSS scale, 178 vulnerabilities with available exploits were identified.;
• Out of 309 low-risk vulnerabilities on the CVSS scale, there are 8 vulnerabilities with available exploits.

One of the old dogmas of information security states: the level of security of a system is equal to the level of security of the weakest link. Indeed, when planning an attack, as practice shows, a potential attacker will choose the most unprotected system. If you look closely at the results, you can see that the probability of finding such systems is high for all categories of organizations:
There is a simple explanation for the results: as the infrastructure grows, it becomes more difficult to monitor it. More hosts – more old software and more vulnerabilities, including exploitable ones. In large companies, the perimeter is extremely dynamic – even within one week, up to several dozen new hosts may appear on the network border, and the same number may leave, as we have shown in our Positive Research. If these changes are only the result of an error, then the probability that one of these nodes will have an "open door to the network" is very high. It is for this reason that periodic monitoring of the perimeter state in a mode as close to real time as possible is very important for ensuring security.
How long will it take to search for vulnerable services if information about the vulnerability has just appeared on the Internet? In our system, the search for specified vulnerabilities takes less than a second. It takes more time to analyze the results obtained, but this is also quite fast: in this study, the analysis of a single vulnerability took no more than 15 minutes.

Step 5. The actual attack
So, an attacker collects data about the target infrastructure and identifies vulnerable services; searches for information about vulnerabilities and selects exploitable ones; then, comparing knowledge about the target infrastructure with data about vulnerabilities, makes assumptions about the presence of these vulnerabilities in the system. At the last step, the attacker conducts an attack on vulnerable systems using the available tools.

In our study, of course, no real attacks were carried out. But we can evaluate the capabilities of hackers at the last stage. Consider, for example, the last part of a well-known exploit pack leaked by The Shadow Brokers group. This package contained a lot of interesting exploits, for example, the SMB hacking kit, which became well-known after analytics WannaCry. In our sample, this exploit was suitable for 36 systems (data on the perimeter under study was collected before the archive with exploits was published). At that time, the exploits contained in the package were applicable to all versions of Windows. Therefore, they were highly likely to be hacked. This is exactly what WannaCry showed. And this is just the tip of the iceberg, there were other interesting exploits in the pack:

1. Esteemaudit (RDP Exploit). We consider placing RDP services on the perimeter without an ACL (access control list) to be a mistake. In our upload, 44 systems were identified with the presence of this service. According to the description, the exploit is only applicable to older versions of Windows Server 2003. For this reason, we excluded 10 addresses with banners of newer versions of Windows – there are still 3 systems for which the exploit could be applied, and 31 without confirmation;
2. A set of exploits for web servers. For 37 systems, an assumption was made about the applicability of exploits aimed at hacking web servers;
3. A set of exploits for mail servers. Mail servers were found on 13 systems that were suitable for operation.

As a result, out of all 3,764 available addresses, 111 with potentially vulnerable services were identified. And with a high probability, they could be hacked using this exploit pack.
At the beginning of the study, the level of danger seemed lower than we received, but then WannaCry came and did not agree with us. The reason for the high level of danger was insufficient control of the external perimeter in organizations. At the same time, even after the publication of warnings and recommendations of information security experts, there was no significant increase in the level of security. This was clearly shown by the epidemic of the next Petya/NotPetya which exploited the same vulnerability (although its propagation vector does not relate to the network perimeter). One vulnerable system is enough to infect the infrastructure, and one vulnerable service is enough for an attacker to overcome the perimeter.

Conclusions and recommendations for protection
Let's sum up the results. If you use a regular network scanner that looks for vulnerabilities, employees of the organization may have suspicions that someone is "watching" them. The facts of such scans can be easily identified using IDS systems and blocked. But who will track the work of a mass search engine? In this article, we demonstrated that:

1. To prepare a targeted attack on the financial sector, no special financial costs are required;
2. The preparation may be invisible to the attacked organizations and to those who protect them;
3. To implement an attack, it is not necessary to have an exploit pack from the NSA, although its components are also publicly available.

Perimeter security is one of the basic protection vectors. But defending without knowing what you are defending is difficult and, frankly, pointless. If you don't know the boundaries of the perimeter you are protecting, you can use the network analysis methods described in this article. And if there are many external subnets (for example, an infrastructure distributed throughout the country with multiple Internet connections) and the perimeter is difficult to inventory, then you can ask for help from specialists. For example, contact Positive Technologies experts [email protected]
All you need is a list of selected networks from the operator and consent to scanning.

After getting an idea of what the perimeter consists of, we'll start protecting it. Achieving the most secure information system configurations is a difficult task, since it is people who are responsible for the software, its configuration and maintenance, and somewhere you have to make assumptions to please the business. Information security always balances between the functionality of the system and its security.

1. Identify assets that can be accessed from the Internet with reasonable grounds;
2. Services without access justification must be removed from the perimeter;
3. Document and implement the process of placing new systems on the external perimeter;
4. Create ACLs and restrict access to administrative interfaces, remote access services, databases, and other critical services to the minimum possible list of persons/addresses;
5. Enter the update installation process and define metrics for the success of the process;
6. Perform security analysis activities, such as scanning with specialized tools in audit mode (from the internal network), as well as scanning for vulnerabilities in pentest mode (scanning from an external site to understand how your infrastructure looks to a potential intruder), with regularity at least once a month;
7. Determine the list of persons responsible for assets (both from the business and IT side). This will reduce labor costs and response time for urgent system updates.;
8. To prioritize the elimination of vulnerabilities, you need to determine the criticality of assets;
9. Create a response plan in case of detection of critical vulnerabilities on systems located on the perimeter. The plan should take into account how to act in case of detection of a critical vulnerability; what actions should be taken by system administrators and information security specialists, and whether these actions are coordinated with the business owners of the systems.

Of course, it should be remembered that to counter threats, it is necessary to use an integrated approach to ensuring information security, and you should start with your "network borders".