Attack through a supplier or contractor through the eyes of a penetration tester

The attack on Solar Winds in 2020 has drawn particular attention to the supply chain topic. Briefly about the attack (well, suddenly someone does not know): Attackers gained access to the SolarWinds Orion build system and added a “bookmark” to one of the DLL files. This DLL was then distributed to SolarWinds customers through an automatic update platform. After downloading, the “bookmark” connected to the command and control server (C2) in order to receive “tasks” for execution on the infected computer

The attack itself is nothing new. So, in 2016, Linux Mint was hacked and a malicious tab was installed in the distribution kit. Then they did not pay much attention to this. However, in the case of Solar Winds, many companies and organizations have suffered. In general, attacks through a supplier or through a contractor are becoming more and more popular. So, it makes sense to think about countermeasures in advance.

It is quite possible to become a victim of such an attack when installing unlicensed, hacked software. Attackers often include a bookmark in the distribution kit that will provide them with remote access to the computer, and place such a distribution kit on the Internet at sites full of such unlicensed software, or through torrents.

Vendor attacks – where a contractor is first hacked and then an associated target organization is attacked – can be divided into two types:

Supply chain – through the supply chain (in the classification of MITER ATT & CK – ID: 1195);

Trusted relationship – through a trust relationship (in the MITER ATT & CK classification – ID: 1199).

These attacks are very similar, but they are implemented in different ways.

A supply chain attack is carried out using firmware. An implant is inserted into the firmware itself or part of the update, which provides direct access to the server, or establishes communication with the control center (Command & Control, C2). Such an attack, as a rule, is not targeted – after all, there is no guarantee that a) the target organization will install the required update and b) that the server on which the update is installed does not have Internet access and is updated manually. If the server receives the update automatically and the firewall rules restrict access only to the update server, then this does not provide security guarantees: attackers can control this update server and redirect traffic from the implant to C2.

Trust attacks involve compromising trusted channels (such as VPN). Many organizations use the services of contractors, including small organizations that work remotely (and in the vast majority of cases are weakly protected). Attackers can attack one of the contractors and get into its network and in the future can quite easily penetrate the target infrastructure and, remaining unnoticed, develop their attack – after all, no one is waiting for a trick from a trusted partner (for this reason, great success can be, for example, “Internal” phishing). At the same time, the internal infrastructure is usually less secure, which also plays into the hands of hackers.

How can you protect yourself?

Detecting such attacks is not easy. Analyzing updates for the presence of “bookmarks” is a laborious and expensive task. You can use behavioral analysis to identify anomalies. Segmentation of the network (which in general should be the norm) will also help reduce the risks of negative consequences of such attacks.

With regard to penetration testing, it will be quite difficult to agree between the three parties to carry out such work. Similar projects can be carried out by the parent and subsidiary companies, but what to do with different companies?

Assumed Breach testing can partially solve the problem. In this case, the legend implies that the contractor has been compromised and the attackers are targeting the company. In other words, it is assumed that the attackers already have access to the organization’s internal network. This type of testing is able to demonstrate what can happen in the event of a real attack.

How to organize Assumed Breach testing

The first thing that needs to be done to carry out such work is to determine the type of threat that will be simulated. To attack through the supply chain, the customer needs to run a kind of “implant” on the server where the developer’s software is installed, which, according to the testing legend, was compromised. This “implant” establishes a channel of communication with the C2 of the penetration tester. Many companies use test environments to test for updates before they install them on production servers. These same test environments can be used for presumptive testing if their network configuration matches the operational one.

With simulated trusted attacks, things are easier: the customer needs to provide VPN access to the same network segment that contractors have access to. The customer may also need to provide credentials with the same privileges as contractors.

The second step is setting goals. For example, gaining access to a database or a server located in a closed network segment.

Several testing options are possible, depending on the model of the potential attacker:


May be in the office

There is access to the infrastructure

Works can be performed remotely

The customer provides credentials to access the company’s network

Service staff

May be in the office

Doesn’t have access to infrastructure

Works are performed on the territory of the company without providing access to the network

Performer can use wall outlets and wireless network


No access to the office

There is remote access to the company network

Works are performed remotely

The customer provides access to the company’s network


No access to the office

Access to the internal network obtained as a result of a phishing attack

Works are performed remotely

The customer opens the phishing email and takes the necessary actions

After gaining initial access, performers try to penetrate the public internal network and conduct internal penetration testing to demonstrate what vulnerabilities and weaknesses are there and how alleged attackers can use them to achieve their goals. Moreover, such work can be carried out both with opposition from the information security service (a kind of short version of the Red Team), and without – in the routine internal penetration testing.

In general, in conditions when outsourcing interactions are becoming more and more, and control over the protection of contractors is not regulated by law and is hardly possible in practice, Assumed Breach is perhaps one of the few relatively affordable tools that give companies an understanding of: 1) what will happen in in the case of an attack through a supplier 2) how much information security specialists are ready to repel it 3) where is it worth “to spread the straw”.

Dmitry Neverov, head of the security analysis group, Rostelecom-Solar

Similar Posts

Leave a Reply Cancel reply