Victory at PHDays 9. We share life hacks in three parts. Part 1

Hello! My name is Vitaliy Malkin. I am the head of the security analysis department at Informzashchita and part-time captain of the True0xA3 team. With this article, we begin a cycle of 3 materials dedicated to our performance at PHDays IX Standoff. In this article, we will explain why competent preparation is half the success, why it is so important to pick up “fruits” in time, and how you can organize the interaction of the pentest team within one single project.

TL; DR article contains a huge number of Englishisms and complex technical terms, for which I apologize separately.

I. Input

We had 16 selected pentesters, 4 trainees, 6 servers, our own CUDA station and a great desire to win.

We started the active preparation phase 8 days before the start of StandOff. This was our 3rd attempt as an attacker, and many of us already had enough experience to understand what to look for this year. We saw 5 priority areas for elaboration:

1. Effective coordination;
2. Collection of Low Hanging Fruits;
3. Exploitation of vulnerabilities of atypical (for us) technologies (ACS TP, IoT, GSM);
4. Preparation of external infrastructure and equipment;
5. Development add. persistence and hardening methods.

Let's try to parse these items in order.

1. Effective coordination

It’s easiest for me to talk about this point, because the general decision I was responsible for its implementation. During StandOff, the most common problem for beginners, in my opinion, is poor coordination. The team members solve the same tasks, there is no clear understanding of what has already been watched and what is not. The information received on the task is not transmitted to each other, as a result, the efficiency of work greatly decreases. And the more participants, the more the efficiency drops. Moreover, it is very useful to have a person who understands the general picture of the infrastructure well and can link individual vulnerabilities into a full-fledged attack vector.

This year Discord platform was chosen for team interaction. In general, it is very similar to the good old IRC chat with additional features like file-upload-a and voice communication. We took a description of all the objects from the Agend competitions and created a channel for each of them, into which information was posted. Thus, any person who connected to the task could see everything that came up to him, including the results of launching various tools and manual searches. On all info channels, a limit of one message per minute was set to prevent flooding. And the whole discussion was conducted in separate chats, which were also created for each object.



A number of organizational decisions were also made to improve coordination. In general, it is not customary for us to set tasks with the wording “NECESSARY” in our team. We try to discuss why this or that task is set, what its implementation will lead to, and also how to accomplish it more efficiently. But within the framework of StandOff, such a model can lead to unnecessary bickering, so we decided to entrust the coordinator with complete authority over the process. Within 28 hours of the competition, his decisions were practically not discussed, which certainly saved us a lot of time. Although it may have affected the quality of communications. In addition to this, we decided to very clearly delineate the areas of responsibility: despite the fact that some of the team members got not the most exciting tasks.

2. Collection of Low Hanging Fruits

In my opinion, the main secret of our success was: a huge daily experience of projects and the correct prioritization of tasks. Last year, we were able to capture an entire office and hold it for the entire game simply due to quickly hacked simple vulnerabilities. This year, we approached the problem centrally and compiled a list of such vulnerabilities.

ms17-010; ms08-67; SMBCRY LibSSH RCE; HP DATA Protectoer; HP iLo; ipmi Cisco Smart Install Java RMI JDWP; JBOSS; drupalgeddon2; weblogic heartbleed shellshock; ibm websphere iis-webdav; rservices; vnc; ftp-anon; NFS smb-null; Tomcat

Next, two checker and penetrator services were written, which in an automated mode, using public exploits and metasploit, first checked for vulnerabilities, and then tried to exploit them. The utility received a nmap report at the input, which ultimately accelerated the process.

3. Exploitation of vulnerabilities of atypical (for us) technologies (ACS TP, IoT, GSM)

We most often do projects for banks and other financial organizations. SCADA-systems, if they do, are more likely in the style: “If you were able to get network access to the scada, fix this and count this as one of the criteria for the success of the project.” Therefore, we do not have good applied experience in analyzing the security of process control systems. This in turn led to the fact that a week before StandOff we urgently sat down to study typical vulnerabilities. With IoT and GSM, the situation is even worse: if IoT is sometimes found in projects, then we saw GSM only on previous StandOffs.

Thus, during the preparation, we identified two separate people on the automated process control system, and two more on GSM and IoT. During the preparatory week, the 1st group wrote out typical approaches to the pentest of SCADA systems, and also studied in detail a video on last year’s ICS infrastructure. The guys also pumped out about 200 GB of various HMIs, drivers, and other software that is directly related to the controllers. As for GSM and IoT, here we prepared several pieces of iron, read all available articles on GSM and hoped that this would be enough. (SPOILER: Not really!)

4. Preparation of external infrastructure and equipment

Understanding that our team will be large enough this year, we immediately decided that we needed additional equipment. Next will be a list of suggestions that we have collected inside the team, a “+” sign indicates that we eventually took:

- a coffee machine;
+ - CUDA-server (they didn’t take it with them, but they used it);
+ spare laptop;
+ WIFI router;
+ managed switch;
+ network cables of various lengths (20 pcs);
+ pilot (3 pcs);
+ Wi-fi Alfa (3 pcs);
+ rubber-duck (2 pcs);
- proxmark;
- a camera.

As for infrastructure, this is a separate song. Last year, we realized how useful it is to use a CUDA station, breaking several handshakes, so there was no doubt about the need to use it. It is important that this year, as well as in the past, all the attackers were behind the NATth, which generally rejected the possibility of reverse-connections from DMZ. But absolutely all hosts should have access to the Internet, except for the ICS nodes. In this regard, we decided to raise three listener servers, accessible from the Internet. Also, for simplicity of pivoting and consolidation, we used our own OpenVpn server with client-to-client mode enabled. Unfortunately, it is impossible to automate the process of connecting a gateway, so for about 12 hours out of 28, one of the team members was working with gateways.

5. Development of add. persistence and hardenin methods

Our past experience with StandOff has shown very clearly that it’s not enough to hack a server successfully: it’s important not to let others gain a foothold in it. Therefore, sufficient attention was paid to RAT with new signatures and scripts to strengthen the protection of Windows. We used our standard RAT, slightly changing the obfuscation methods. The rules were a bit more complicated. In general, we determined for ourselves the following set of scripts:

• closing SMB and RPC;
• porting RDP to a non-standard port;
• Disabling reversible encryption, guest accounts and other settings from the security baseline.

For Linux, a special init-script was developed that closed all ports, opened SSH on a non-standard port, and registered the public keys of the command to access SSH.

II. Briefing

On May 17th, 5 days before StandOff, a briefing was held for attackers. In the course of it, a lot of information surfaced that influenced our training.

Firstly, the organizers published a map of the network, and this has become a great help for us. We were able to divide the areas of responsibility in advance, update the network segments, and most importantly, to understand what the network is all the same. In my opinion, the most important statement made at the briefing was the phrase that the ICS network would be accessible from only one segment, and this segment would not be protected. Moreover, the most points will be given for ICS and secure offices, and the organizers directly encourage the struggle for networks between hackers.

We took this information like this: "The one who captures the bigbrogroup is likely to win the game." The thing is that our experience told us: no matter what punishments the organizers would come up with for a simple service, defenders would drop vulnerable services if they could not patch them. After all, it’s much worse when they announce from the stage of the largest information security conference that you have spoiled hackers than if they took away some game points from you. Our theory was confirmed, but we will talk about this in detail in the 2nd article.

As a result, we decided to divide the whole team into 4 parts:

1. Bigbrogroup.This was the task to which we assigned the highest priority. The team involved the people who have the most experience breaking into the internal infrastructure of different customers. In total, this mini-team consisted of 5 people. Their goal was to gain a foothold in the domain as quickly as possible and cut off other teams from access to the ICS.

2. Wireless Network. The team that was responsible for monitoring Wi-Fi, tracked new points, intercepted handshakes and brutalized them. GSM also entered into their tasks, but first of all it was necessary to capture Wi-Fi and cut off other commands from it.

3. Unprotected networks.The team that for the first four hours picked all unprotected networks for vulnerabilities. We understood that in these four hours nothing super-important will happen in the protected segments, and if it does, the defenders will roll it back. Therefore, they focused on what could have irreversibly changed. As it turned out - not in vain. Four hours later, the same group began to analyze protected segments.

4. Scanners group. The organizers directly stated that the networks will change, so we had two people who continuously scanned the network for changes. It was not so easy to automate, because under different networks, different settings were needed at different times. For example, in the first hour on the fe.phd network, nmap worked fine for us in T3 mode, and after 12 hours it barely worked in T1.

Another important vector for us was the list of software and technologies published by the organizers. For each technology, we tried to create our own competence center, which could very quickly help and see typical vulnerabilities.

For some services, we found very interesting vulnerabilities, but there were no public exploits. So it was, for example, with Redis Post-exploitation RCE. We were sure that this vulnerability would appear in the gaming infrastructure, so we decided to write our own 1-day exploit. It was not possible to write 1-day specifically for this vulnerability, but on the whole we had about five non-public exploits on hand that we were ready to use.



Unfortunately, we did not manage to share all the technologies, but it was not so scary. We covered the main set, and this was enough. There was also a list of process controllers, which we also sorted out and tried to prepare for it.

In preparation for the battle, we prepared several tools for seamlessly connecting to the ICS physical network. For example, we implemented a cheap analog of Pineapple-a using raspberry. The module was connected via Ethernet to the industrial network and via GSM to the management service. Next, we could remotely configure the Ethernet connection and distribute it on the spot using the built-in Wi-Fi module. Unfortunately, at the briefing, the organizers clearly made it clear that you can’t physically connect to the ICS, so we left this module until better times.

A lot of information was about the bank, offshore bank and the work of antifraud. But having learned that there is not a lot of money in it, we decided not to prepare for this in advance, but to come up with something along the way.

Summing up, we have done a fairly large amount of work in preparation. It is important to note that in addition to the obvious advantages in the form of a successful performance at StandOff, there were also not obvious ones.

• Such preparation is a great way to get distracted and do something that I have long wanted to try and explore, and there was simply no time in the framework of the project activity.
• We do not have projects that involve the entire team as part of one task, so we got a good team building, pursuing specific goals.
• Much of what we have done can be used in real projects, so in addition to expanding our competencies, we also got ready-made tools.

Now, having described all this in the text, I understand that we didn’t accomplish anything so grandiose as it seemed from before. In general, it seems to me that the correctly organized stage of preparation became the main reason for the victory of our team. And what directly happened during StandOff itself - I will tell in the second article of the cycle.