On May 24, 2022, Cisco became aware of a potential breach in their corporate network after an employee’s personal Google account was compromised – an act a ransomware gang named Yanluowang has now claimed as its work.
Cisco disclosed the months-old compromise after a list of files accessed during the incident appeared on the dark web.
“Cisco experienced a security incident on our corporate network in late May 2022, and we immediately took action to contain and eradicate the bad actors. Cisco did not identify any impact to our business as a result of this incident, including Cisco products or services, sensitive customer data or sensitive employee information, intellectual property, or supply chain operations. On August 10 the bad actors published a list of files from this security incident to the dark web. We have also implemented additional measures to safeguard our systems and are sharing technical details to help protect the wider security community.”Cisco
During an investigation by Cisco Security Incident Response (CSIRT) and Cisco Talos, it was determined that a Cisco employee’s credentials were compromised after an attacker gained control of a personal Google account where credentials saved in the victim’s browser were being synchronized.
The attacker conducted a series of sophisticated voice phishing attacks under the guise of various trusted organizations attempting to convince the victim to accept multi-factor authentication (MFA) push notifications initiated by the attacker. The attacker ultimately succeeded in achieving an MFA push acceptance, granting them access to VPN in the context of the targeted user.
After establishing access to the VPN, the attacker then began to use the compromised user account to logon to a large number of systems before beginning to pivot further into the environment. They moved into the Citrix environment, compromising a series of Citrix servers and eventually obtained privileged access to domain controllers.
After obtaining access to credential databases, the attacker was observed leveraging machine accounts for privileged authentication and lateral movement across the environment.
Throughout the attack, Cisco observed attempts to exfiltrate information from the network. Cisco confirmed that the only successful data exfiltration that occurred during the attack included the contents of a Box folder that was associated with a compromised employee’s account and employee authentication data from active directory. The Box data obtained by the adversary in this case was not sensitive. The threat actor claimed to have stolen 2.75GB of data, consisting of approximately 3,100 files.
The threat actor was successfully removed from the environment and displayed persistence, repeatedly attempting to regain access in the weeks following the attack; however, these attempts were unsuccessful.
The threat actor dropped a series of payloads onto systems. The first payload is a simple backdoor that takes commands from a command and control (C2) server and executes them on the end system via the Windows Command Processor.
Commands are retrieved by making HTTP GET requests to the C2 server. The malware also communicates with the C2 server via HTTP GET requests.
The following Command and Control specific TTPs were observed during this attack.
Although this particular attack did not specifically target an ICS, OT or SCADA network, the worlds of IT and OT are converging. The benefits of hyper connectivity are clear for industrial systems. Initiatives like Industry 4.0 set out the vision for future industrial control systems based on IT/OT integration, pushing Internet technology as far towards the physical devices as possible.
With this in mind, we can apply the same tools, techniques, and procedures (TTPs) used in the Cisco attack to a conventional IT/OT network.
For example, an employee may sign into a compromised Google account on an office workstation, which in turn synchronises their locally stored browser passwords to their Google Account, which the attackers have access to.
The attackers can then use these credentials to gain access to the corporate VPN and subsequently logon to a large number of systems before beginning to pivot further into the environment.
After obtaining access to credential databases, an attacker may leverage machine accounts for privileged authentication and lateral movement across the environment into the OT network.
After pivoting into the OT network, an attacker may deploy a backdoor on a compromised engineering workstation that takes commands from a command and control (C2) server and executes them on the end system.
Now, an attacker can launch further attacks on SCADA workstations, PLCs or HMI devices.
Looking at the above example, the engineering workstation does not even need to have direct access to the internet to be compromised, an attacker can still move laterally through the network from the IT side to the OT side.
Blueskytec have resolved all of these threats for the ICS/OT environment by providing a solution that harnesses all of the benefits of IT hyper connectivity, but ensures all of the cyber security issues of IT do not penetrate the ICS/OT networks allowing complete protection of the ICS/OT domain.
Even if the enterprise IT network is attacked, Blueskytec’s technology still protects the operation of devices and control systems in real time just as the system was originally designed.
The Blueskytec technology works by isolating the manufacturers physical device from the internet using encryption and authentication.
Once the Blueskytec technology is in place on the network, it provides an isolated “island” or “group” of activity that only users of the same key space can access – a “circle of trust”, thus, a cyber-attack from outside the group this simply cannot happen because every transaction is encrypted and authenticated using a new key from the Key Space.
At the centre of the system is an encrypted space – called the Key Space. This enables connections between the computing points. At the entrance point to the Key Space (Ingress) is a Key Space Gateway device and at the exit point (Egress) is an ICSProtect device.
As you can see from the example network diagram above, the SCADA workstation (Windows, Linux, MacOS etc.) is isolated and protected from the rest of the network via a Key Space Gateway (KSG). This takes the IP connection from the SCADA workstation, which is unencrypted, and converts this into an encrypted connection for mapping onto the Key Space Technology.
Any connection that the SCADA workstation opens will be encrypted onto the Key Space. Encrypted data can ONLY be decoded by a Key Space recipient – not just anyone. In this example, an ICS Protect acts as a Key Space recipient.
The KSG and ICS Protects are within the same Key Space, isolated from the internet via a cryptographic method that only allows communication between known trusted items. Any communications outside the trusted group will not be understood by any other computer (including Quantum Computers).
If we look back at our original scenario, an attacker may attempt to pivot into the OT network and deploy a backdoor on a compromised engineering / SCADA workstation that takes commands from a command and control (C2) server. With the Blueskytec technology in place, this wouldn’t be possible as any command and control traffic would have originated from outside of the encrypted Key Space, and any traffic from outside of the Key Space is rejected by the KSG or ICS Protect device.
Even if an engineering / SCADA workstation is compromised from the inside (i.e insider threat) the engineering / SCADA workstation does not believe it is connected to any external network and therefore cannot establish any connection to a command and control (C2) server. However, SCADA software that is running on the engineering / SCADA machine continues to function and communicate to the PLC’s on the network within the Key Space.
Although packets may well exit the engineering / SCADA workstation, be passed onto the BST Key Space and exit into the wider world, they will be on the wrong port, be encrypted and will have the incorrect length for the type of service that is requested in the header.
Written by James Mockford – James.Mockford@blueskytec.com