@t03r1cht the only idea I have is to deploy it in a separated container/VM, I think this would be quite enough, and I don't really think that much more can be done.
I guess that by "hiding" the Beats what you look for is:
- Protecting/hiding the credentials and configuration used by Beats
- Sending out of the machine all the information of attack attempts (what could be seen in logs or metrics) asap
The credentials should be protected by having beats in a separated container/VM (unless the virtualization layer is also compromised).
Log files and metrics will be shipped asap for attack attempts, but once the honeypot is compromised you probably cannot trust the ones created from this point in time. About that, something you can do from logstash or an ingest pipeline is to add another timestamp to every event sent by Beats, so you can detect if the attacker is altering logs.
I don't see how "hiding" the process can improve any of this, do you have any reference of similar practices?