Cybersecurity professionals will likely draw upon the Akira ransomware attack as a key learning example for years to come. The attackers encrypted an organization’s computers by hacking a surveillance camera. While counterintuitive at first glance, the sequence of events follows a logic that can be easily applied to a different organization and different devices within its infrastructure.
Anatomy of the attack
Attackers exploited a vulnerability in a public-facing application to penetrate the network and execute commands on an infected host. Following the initial breach, they launched the popular remote access tool AnyDesk and initiated an RDP session with the organization’s file server. Accessing the server, they attempted to run ransomware, but the company’s EDR system detected and quarantined it. Alas, this didn’t stop the attackers.
Unable to deploy the ransomware on servers or workstations, which were protected by EDR, the attackers ran a LAN scan and found a network video camera. Despite repeated references to a “webcam” in the incident investigation report, we believe it wasn’t the built-in camera of a laptop or smartphone, but a standalone networked device for video surveillance.
There were several reasons why the camera was an ideal target for the attackers:
- Due to its severely outdated firmware, the device was vulnerable to remote exploitation, which granted attackers shell access and the ability to execute commands.
- The camera ran a lightweight Linux build capable of executing standard binaries for this operating system. Coincidentally, Akira’s arsenal contained a Linux-based encryption tool.
- This specialized device lacked — and likely was incapable of supporting — an EDR agent or any other security controls to detect malicious activity.
The attackers were able to install their malware on the camera, and used the device as the foothold for encrypting the organization’s servers.
How to avoid being next victim
The IP camera incident vividly illustrates certain principles of targeted cyberattacks, and provides insight into effective countermeasures. Here’s a ranking of the countermeasures, from the easiest to the most complex:
- Limit access to specialized network devices and their permissions. A major factor in this attack was the IP camera’s overly permissive access to the file servers. These devices should reside within an isolated subnet. If that’s not feasible, they should be given the fewest possible permissions to communicate with other computers. For example, write-access should be restricted to a single folder on a single specific server where video recordings are stored. And access to the camera and this folder should be restricted to workstations used only by security and other authorized personnel. While implementing these restrictions may be more challenging for other specialized devices (such as printers), it’s readily achievable with cameras.
- Deactivate non-essential services and default accounts on smart devices, and change default passwords.
- Use an EDR solution across all servers, workstations, and other compatible devices. The selected solution must be capable of detecting anomalous server activity, such as remote encryption attempts via SMB.
- Extend vulnerability and patch management programs to include all smart devices and server software. Start by conducting a detailed inventory of such devices.
- Where feasible, implement monitoring, such as telemetry forwarding to a SIEM system, even on specialized devices where EDR deployment isn’t possible: routers, firewalls, printers, video surveillance cameras, and similar devices.
- Consider transition to XDR-class solution, which combines network and host monitoring with anomaly-detection technologies, and tools for manual and automatic incident response.
Kaspersky official blog –
