More fun with WordPress as a honeypot
An story about intentionally bad secured WordPress instances
I applied some updates to my honeypress project. For deployment in docker, I added new scripts to deploy, receive logs and remove the honeypot instances. Every step is focused on automation, so no stdin is required to interact with them. At a later point, env variables will be allowed to control input variables.
The deployment creates a new WordPress blog from the latest WordPress version, with a generated admin account inside it. You can use this admin account to prepare the instance, if needed.
The project is a playground. Please note the disclaimer on https://github.com/cmllr/honeypress#obvious-disclaimer
The WordPress instance is now ready to be utilized. Based on the configuration, e. g. bruteforce logins can be allowed to monitor further activities inside of the dashboard. For an attacker, it's just an another badly secured WordPress instance. The real admin user has an generated username, so the attacker can also attempt logins on "admin:admin", for example.
The new takeout.sh command will pull the log out of the running container, and if any uploads are present, they will be copied out of the container aswell. All informations will be stored in the takeouts folder for further analysis.
To clean up the most likely infected Wordpress instances can be removed all together with cleanup.sh. After that, new instances can be spawned to monitor further infections. The logfiles will persist of course to allow further research.
There is still some work to do (especially to bind the instances to domains), but base work can be already done with it. It will be interesting to see what the honeypot will monitor.
Photo by Georg Eiermann on Unsplash