Hi,
I am currently deploying the Elastic Stack inside a honeynet for log data analysis of different honeypots. I'm using Beats to ship data directly from the honeypots to Logstash and Elasticsearch, however, I've found that there seems no documented way of hiding Beats from an attacker that possibly breaks into one of the honeypots (which is the intended goal).
Are there official/unofficial tips or alternatives to Beats or is it generally not designed for such tasks?
Best regards,
Marc
Hi @t03r1cht,
Interesting use case. As you mentioned we don't have documentation about an official or recommended way to "hide beats".
Are you deploying your honeypots in containers or virtual machines? If that is the case you can run filebeat in the physical host (or in a different container or VM) and share the log files using shared volumes. This way an attacker would need to break the virtualization/containerization layer (apart of the honeypot) in order to see the beats.
I am deploying Beats on virtual machines. I've had the same idea to "pipe" data through the virtualization layer to the virtual host containing the ELK components. However, I'm not quite sure if that's such a good idea to share folders from the host with honeypots that may potentially be compromised by hackers.
I've thought about forking Filebeat and somehow try to hide it at runtime, but I don't have any experience in Go plus there's not enough time for it, since my thesis submission is due in a couple of days.
How would you hide the process at runtime?
My first guess would be to think like a hacker and maybe hide it in another application, a code cave maybe?
@jsoriano, could you think of some other way how to make Beats "honeypot-proof"?
@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:
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?
The credentials should be protected by having beats in a separated container/VM (unless the virtualization layer is also compromised).
I like that idea. So just to be on the same page, you mean sharing the log files on the honeypot with the Beats VM through a shared folder?
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.
Could you elaborate how that would enable me to detect alterations?
Yes, I think that sharing the log files using a shared volume would be an option, so Beats processes are not visible from the honeypot VM/container, but Beats can see the files.
Regarding log alterations I mean that if an attacker compromises the honeypot, they may delete or alter the logs to hide their attack, you don't care about deleted logs because you are collecting them out of the machine asap, but if the attacker generates logs with altered timestamps they can make difficult to study the attack. By adding an additional timestamp in a trusted place you can detect this kind of alterations, at least you will know when these logs were really shipped.
Oh, so you mean instead of working with the timestamps created by Beats I should generate them in Logstash and use that field for evaluation in Kibana? If the attacker modifies the timestamp of the Beats result JSON document and subtracts, for example, 20 seconds (resulting in e.g. 14.20) but this document is processed inside Logstash at 14.40, this would indicate manipulation since Beats sends it logs ASAP and doesn't take 20 seconds just for sending?
I have totally forgotten about the keystore for Filebeat and Metricbeat and will probably use it for now. Is this what the keystore was originally meant for? How are values stored? Can an attacker somehow retrieve them in plaintext?
Thanks a lot for the help so far, Jaime. I really appreciate it.
In your case I'd pay attention to both timestamps. Beats timestamp will be set to the time when the information is generated, this is more precise and valuable in general, but in your case it can be compromised. The timestamp injected from logstash will be set to the time when this event is processed, what will be slightly later, so this one is less accurate, but from a trusted source. The attacker could be generating logs with any timestamp, what would trick Beats, but with the timestamp added in logstash you know more or less when they really happened.
Current implementation of the keystore is useful in scenarios where you have different security requirements for credentials and for the rest of configuration. For example if you use one system to provide configuration, and another one to provide the credentials. But it only obfuscates the information stored, it is not securely encrypted, so if an attacker gets the store, it can obtain the passwords. We plan to add more security layers to the keystore in the future.
I will definitely try your suggestion with the timestamps, I like it.
How exactly is the keystore storing its values? I'm not using it to store credentials but rather for the storage of log paths, so potential attackers may have a hard time finding out what is being logged.
You can find the keystore implementation for 6.2.4 here: https://github.com/elastic/beats/tree/v6.2.4/libbeat/keystore
Thanks @jsoriano,
unfortunately I was not able to discern the used encryption of this keystore. Is there any documentation
for it?
It uses encryption, but with a known key (the empty string), this is why I mentioned that this can only be considered as obfuscated by now. We plan to allow setting a password in the future.
You can also read about this in the release notes of 6.2.0, where the keystore was released: https://www.elastic.co/blog/beats-6-2-0-released
Now I get what you meant with that! Thanks a ton.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.