One of the most exciting parts about continuous testing is the open door policy that exists with our customers. When a new piece of research comes out, we can verify and explore this issue across all internal and external customer networks simultaneously right away. This keeps our customers aware and protected against trending risk.

A highlight for me at Defcon 2024 Labs was the “Farming n-days with GreyNoise” talk by Andrew Morris (https://x.com/andrew___morris). In it he discussed a GreyNoise beta program called Plasma that allows a user to easily stand-up custom honeypots. Specifically, by running a simple bash script from the cloud provider of your choice, you can turn the VPS into a realistic honeypot (think Sonicwall looking device) with an attached GreyNoise sensor. The sensor does full packet captures and uses GreyNoise to enrich the data.

Setting up a n-day farm

Setting up the honeypot is really simple. The installation process is a one-line command from your VPS of choice, in my case Digital Ocean:

GREYNOISE_API_KEY="XXXX" && curl -H "key: ${GREYNOISE_API_KEY}" -L <https://api.greynoise.io/v1/workspaces/[WORKSPACE_ID]/sensors/bootstrap/script> | sudo bash -s -- -k ${GREYNOISE_API_KEY}

From the GreyNoise side you need to pick out your persona and deploy it to the sensor. For example, in the screenshot below I want my honeypot to appear as an Ivanti SSL VPN:

icon-activity:

Registering a TLS certificate using Let’s Encrypt and the honeypot IP will get the IP onto the Certificate Transparency Lists like crt.sh. As expected, this quickly increases the targeting of our honeypots with a very low lift.





After deploying the persona, I have a semi-legit looking SSL VPN exposed to the Internet:

Farming Wordlists from Greynoise Sensors

To be expected, shortly after being deployed our honeypots started seeing checks for “.env” files. For reference, a .env file can often contain API keys and passwords. Bots scanning for “.env” is well known. In fact, in August 2024, Palo Alto Unit 42 discussed extortion operations with the initial access being from a “.env” file. They even went as far as to say “The most common initial access vectors for [targeting IAM credentials] originate from organizations inadvertently misconfiguring servers, subsequently exposing sensitive files to the public internet, with the most frequently exposed files being .env files.”

Fairly quickly we saw one of our hosts receive 720 unique “.env” checks. For comparison the default nuclei template looks in ~22 locations. This isn’t really an apples to apples comparison as with Nuclei you could add additional paths or different types of env checks, but the point is … it is an easy win to turn the sensor data into custom wordlists and scan all 720 locations across every host on every customer.

Conclusion

That’s it for now. In the next post we will talk about using a Jupyter notebook and the GreyNoise API for better analysis, building more complex wordlists, and touch on pulling pcap’s for n-days.

In the mean time, the following query can be used to find HTTP Request URLs from the Plasma dashboard:

select
 http_request_url,
 http_request_headers,
 http_request_method,
 http_request_body,
 gn_first_seen,
 gn_tags,
 gn_actor,
 gn_classification,
 gn_actor,
 gn_cve,
 http_response_status,
 ipv4_src_ip,
 metadata_region
 from
 sensor_data
 where
 tcp_dst_port = 80
 AND LENGTH (http_request_url) >= 1
 limit
 80