Today’s cautionary tale comes from Verizon’s sneak peek (pdf) of the 2017 Data Breach Digest scenario. It involves an unnamed university, seafood searches, and an IoT botnet; hackers used the university’s own vending machines and other IoT devices to attack the university’s network.
Since the university’s help desk had previously blown off student complaints about slow or inaccessible network connectivity, it was a mess by the time a senior member of the IT security team was notified. The incident is given from that team member’s perspective; he or she suspected something fishy after detecting a sudden big interest in seafood-related domains.
The “incident commander” noticed “the name servers, responsible for Domain Name Service (DNS) lookups, were producing high-volume alerts and showed an abnormal number of sub-domains related to seafood. As the servers struggled to keep up, legitimate lookups were being dropped—preventing access to the majority of the internet.” That explained the “slow network” issues, but not much else.
The university then contacted the Verizon RISK (Research, Investigations, Solutions and Knowledge) Team and handed over DNS and firewall logs. The RISK team discovered the university’s hijacked vending machines and 5,000 other IoT devices were making seafood-related DNS requests every 15 minutes.
The incident commander explained:
The firewall analysis identified over 5,000 discrete systems making hundreds of DNS lookups every 15 minutes. Of these, nearly all systems were found to be living on the segment of the network dedicated to our IoT infrastructure. With a massive campus to monitor and manage, everything from light bulbs to vending machines had been connected to the network for ease of management and improved efficiencies. While these IoT systems were supposed to be isolated from the rest of the network, it was clear that they were all configured to use DNS servers in a different subnet.
After reading the RISK Team’s report, the senior IT security team member said:
Of the thousands of domains requested, only 15 distinct IP addresses were returned. Four of these IP addresses and close to 100 of the domains appeared in recent indicator lists for an emergent IoT botnet. This botnet spread from device to device by brute forcing default and weak passwords. Once the password was known, the malware had full control of the device and would check in with command infrastructure for updates and change the device’s password—locking us out of the 5,000 systems.
At first, the incident commander thought the only way out of trouble was to replace all the IoT devices, such as “every soda machine and lamp post.” Yet the RISK Team’s report explained that “the botnet spread from device to device by brute forcing default and weak passwords,” so the university used a packet sniffer to intercept a clear-text malware password for a compromised IoT device.
With the packet capture device operational, it was only a matter of hours before we had a complete listing of new passwords assigned to devices. With these passwords, one of our developers was able to write a script, which allowed us to log in, update the password, and remove the infection across all devices at once.
Verizon’s sneak peek report includes mitigation and response tips, such as change default credentials on IoT devices. It also advises, “Don’t keep all your eggs in one basket, create separate network zones for IoT systems and air-gap them from other critical networks where possible.”
Verizon’s upcoming second annual Data Breach Digest will cover 16 cybercrime case studies. If the “Panda Monium” sneak peek is any indication, the report should be a great and eye-opening read.