Protecting Internet-facing Systems

Every organization in this world that operates online, has Internet-facing systems. These are services which are necessary to deliver to customers, clients or guests. These operations are non-negotiable, and a must-have.

Security-minded organizations apply better practices, such as diligently keeping all services patched, as well as using additional protection services such as Web Application Firewalls (WAF), frontend proxies that can detect and block known attacks, and maybe even anti-DDoS systems from the likes of Akamai and CloudFlare. Organizations that utilize these practices are generally protected from known threats of the past. We liken it to driving forward by using the rearview mirror.

Unfortunately, the rearview mirror approach does nothing for protection of a host that has been compromised through some yet-unknown vulnerability, literally a zero-day threat. Zero-day threats which are used in the wild are becoming more and more common. This isn’t a surprise, considering that vulnerabilities are now on the path to commoditization with marketplace-driving organizations like Zerodium.

Now that we have established the very real - but unknown - level of vulnerability we all face, even with fully-protected, fully-patched, fully-secured internet-facing systems, let’s consider this:

##A sensible approach to protecting vulnerability abuse##

If we start with the presumption that a system is already infected, the sensible thing to do is to prevent damage. Considering that nearly all modern attacks rely on multiple stages of vulnerability scanning, privilege escalation, lateral movement, c2 communications, there are many opportunities to spot potentially-maliciouis behaviour.

Our focus today will be on egress control, and where that is exhibited and prevents damage.

When an internet-facing host has no ability to reach out, except to respond to public-facing services, it turns out, nearly all modern attacks are stopped dead in their tracks. When this is extended to other network hosts that support the internet-facing host, the approach is extremely effective to contain any would-be attack.

We thought a good way to illustrate this in the real world would be to place an unpatched Exchange Server 2019 on the Internet as a honeypot and observe behaviour and share our findings.

Exchange 2019 Honeypot protected by adam:ONE®

The only protection it is enjoying is Zero Trust Network Access powered by adam:ONE, by enabling DTTS® (Don’t Talk To Strangers) and leak-proof DNS filtering that allows it to obtain Windows updates, IT remote control, and that’s it. This approach protects from the following malicious activities:

  • Unauthorized Remote Access
  • C2 (Command&Control) connections that use any IP protocol
  • Downloads of additional payloads
  • Exfiltration via legacy DNS
  • Exfiltration or C2 via DoH or DoT

Further technical details will be maintained at https://adamnet.io/exchange2019honeypot - feel free to check back and interact with us there.