Cloud Postgres honeypots breached within seconds -- and your IP filter is unlikely to save you
IP-blocking won't do much...
The time to breach a honeypot? Blink and you'll miss that you've just got compromised.
Security researchers who set up 320 cloud honeypots globally to learn how quickly threat actors would target exposed cloud services found that 80% of them were breached in under 24 hours -- with a single threat actor compromising 96% of 80 Postgres honeypots globally within a blistering 30 seconds.
Palo Alto Network’s Unit 42 evenly deployed four types of honeypots, with with remote desktop protocol (RDP), secure shell protocol (SSH), server message block (SMB), and Postgres database services publicly exposed. These were kept live for a month to gather intelligence between July and August 2021.
Its researchers intentionally configured a few accounts with weak credentials that granted limited access to the application in a sandboxed environment, with each honeypot reset and redeployed when a threat actor successfully authenticated via one of the credentials and gained access to the application.
The time to breach a honeypot varied, but all of the 320 honeypots werer breached within a week. (Interestingly, 85% of the attacker IPs were observed only on a single day, a number that indicates that Layer 3 IP-inspecting firewalls are increasingly ineffective as attackers rarely reuse the same IPs to launch attacks.)
See also: Hackers are exfiltrating stolen data using the Slack API
An earlier network scanning activity project by the group identified over 700,000 scanner IPs daily that that enumerated (the process of extracting user names, machine names, network resources, and other services from a system) more than 9,500 different ports every day and Unit 42 used that research to inform the experiment.
“We were curious whether proactively blocking the network scanning traffic could prevent attackers from discovering the honeypots and reduce the number of attacks” Unit42 noted.
“To test the hypothesis, we created an experimental group of 48 honeypots and applied firewall policies to block IPs from known network scanners. The firewall policy blocks the IPs that have been scanning a specific application daily in the past 30 days. Figure 6 compares the number of attacks observed on each honeypot between the control group (no firewall) and the experimental group (with firewall). We could not see a significant difference between the two groups, meaning blocking known scanner IPs is ineffective in mitigating attacks…”
Palo Alto Networks said it recommends all cloud service users:
- Create a guardrail to prevent privileged ports from being open.
- Create audit rules to monitor all the open ports and exposed services.
- Create automated response and remediation rules to fix misconfigurations automatically.
- Deploy next-generation firewalls in front of the applications to block malicious traffic.
Honeypots can be a vital and low cost way of gaining intelligence into what's likely to hit you.
As security researcher Jason Schoor earlier told us: "Public-facing honeypots can provide a wealth of insight into active reconnaissance campaigns against your network: the types of attacks, origination, and more, all in (almost) real time. Placed within a network, honeypots can produce high fidelity detection alerts.
"As these systems should have no actual production value, any attempted accesses whatsoever should be considered malicious and trigger incident response activity, including detection rule tuning and security control effectiveness review for the real production systems you’re trying to protect."
One highly regarded honeypot-type security tool (not actually a honeypot as you'd know it) that can be actively deployed throughout your internal network (hardware, virtual or cloud-based) is Thinkst Canaries, which are deployed inside your network and communicate with the hosted console through DNS; i.e. the only network access they need is a DNS server that's capable of external queries. They come recommended.
