July 27, 2020

Cyber exploitation at scale: don't become a victim of remote access exploitation

By

Theta

Cyber exploitation at scale: don't become a victim of remote access exploitation

Let’s face it – it’s been a tough period for remote access solutions, especially when we’re so dependent upon it. First, we had the myriad of SSL-VPN’s from the likes of Cisco, F5, Palo Alto, Cisco, Fortinet and Pulse Secure – going from being an enterprise security product to the worst nightmare for a security team overnight.

Then we had mass exploitation of Remote Desktop Protocol followed shortly after by another kicker from Citrix’s ADC. All of these self-hosted, Internet-exposed services share an unfortunate tale over the past 12 months. They’ve all provided at least one way for an attacker to easily gain remote access without authentication into your corporate network, and all were rapidly exploited at scale.

Looks like someone’s server has had a visit from China who took advantage of an exposed RDP port

The remote access vulnerabilities we’ve witnessed

Earlier this year we observed a vulnerability allowing an attacker to turn any stolen Exchange user account into a complete system compromise, with identification and exploitation following shortly after.

Last week Network vendor F5 released an advisory regarding customers of a critical vulnerability. It allowed an attacker to execute arbitrary commands without authentication, essentially RCE on a common load-balancing solution for enterprises through a management console that is exposed to the public Internet by default. Read that again – not just a remote code execution vulnerability but on the management console. This vulnerability was not widely acknowledged by the security community until Friday when F5 took to Twitter to re-announce the CVE.

This week we now see another critical vulnerability in DNS – the telephone directory of the Internet – and how it can be exploited. By their nature, DNS servers are often co-hosted with Domain Controllers and (currently) require unencrypted communications with other DNS servers on the Internet, so a compromise of one DNS machine can lead to the compromise of an entire domain.

Our Theta Cyber Security team observed several compromised systems (due to previous gateway vulnerabilities noted above) and had seen first-hand the impact these had on businesses. Here are the actions that we took:

  1. Our first objective was to leverage Internet scan data from Shodan to identify a number of New Zealand organisations with this software running within their environment.
  2. We worked with industry peers to ensure easily discoverable New Zealand organisations were notified and encouraged to remediate this vulnerability immediately over the weekend. Reducing the risk for a number of New Zealand organisations was a step in the right direction, but with over 8,500 F5 devices identified worldwide, we knew this was just the start.
  3. Theta positioned a honeypot, essentially emulating a vulnerable F5 device to lure attackers, gaining insight into the scanning and exploitation of the vulnerability from Saturday (4th July) NZST. Our honeypot was present in Shodan to ensure opportunistic attackers would be able to identify our host with relatively little effort. We immediately observed discovery scans, as attackers and researchers started to trawl the Internet looking to validate that our host was indeed an F5 Big-IP.

Interface for our honeypot – designed to respond as if it were a vulnerable F5 host

The honeypot attacks

Within record time, we observed the first attempted attack against our honeypot. Here’s the timeline of events:

Sunday – First attempted attack at 12 PM on Sunday. From that point, we saw 12 other opportunistic attacks, each using Tor as a relay before communicating with our honeypot.

Monday - As we reached Monday, the exploitation attempts skyrocketed. We had 50 attempts at exploitation from 15 different locations.

Tuesday – By Tuesday afternoon, our honeypot had 150 exploitation attempts, 25 unique attacks, 37 attack vectors, 7 vulnerability scans, countless port scans and over 215 visitors in two days.

By the end of the week - Our honeypot had 213 attacks with 43 unique payloads from 65 different locations with 58% routed through Tor.

Attacks don’t always come from unusual countries, so IP whitelisting is becoming less effective as a control, especially when hosted in a legitimate provider like AWS or Azure

The questions you need to be asking:

  • How fast could you respond to a critical software update for an Internet-facing device within your organisation?
  • Do you have a process to understand and act on such intelligence in a matter of hours?
  • How would you handle a migration to a new remote access technology?

If a vulnerability were released on a Friday, you can’t afford to wait until Monday to think about it and then take action. You could be ransomed before the end of the weekend. It’s another timely reminder that your front-line of defense must be able to self-heal and repair in a state of vulnerability. This means a heightened sense of situational awareness, automatic updates, multiple lines of defense and dedicated internal ownership around vulnerabilities is required.

From vulnerability release to exploitation can be measured in hours – don’t wait until Monday morning