Cybersecurity analysts have noted that small to medium-sized business attack traffic has been increasing throughout 2019, unusually reaching higher levels than Telnet & SSH attack traffic. It isn't clear who is causing this as no files are uploaded, just connections from multiple countries being the root cause.
How do we know this? The same reason we are aware of most global cyber threats, the techniques, timings and tools used, and even an idea of who they are - Honeypots.
A honeypot is an information systems resource whose value lies in unauthorised or illicit use of that resource, meaning that it only proves its worth when a hacker tries to interact with it. A typical honeypot resource is disguised as a network server, it may look and feel like a server but its actually a trap laid to bait unauthorised intruders.
How did analysts discover EternalRocks? That would be the honeypot.
A creative cat and mouse game of laying wily traps, the adversary either springing traps or suspecting something fishy, and avoiding them, or in some cases, defacing them. One researcher recently tweeted "To the person who figured out my honeypot is a honeypot, could you please stop putting the picture of Pooh bear on it" to the amusement of many.
Check out the HoneyDB resource for real-time attacker analytics, generated by honeypots and harvested data from honeypot sensors deployed on the internet globally.
Uniquely quirky within network monitoring and intelligence, rich in returns and justifications for organisations small and large, the tools and techniques have puzzlingly been largely ignored by the main Information Security Standards, seemingly unworthy of inclusion on most of the most popular governing standards SANS/NIST/PCI/DSS/ISO.
Our customers rarely request a honeypot system, or as a requirement in an RFP. which is for me is puzzling, considering its importance and value. What other cyber techniques would provide the CISO with confidence that the network isn't breached, details of the host or ports used in the attack, particularly for immature/exposed networks?
Usually, this is the purview of the SIEM team and months of cultivated use case development work. This article is an attempt to set the record straight, stopping the honeypot blind spot here. Below I have listed some creditable honeypot examples worthy of inclusion in anyone's cyber defence large or small.
Host-Based: The simplest and most well-known kind of honeypot. The challenge is blending in with the existing infrastructure, not too hot to be obvious, not too cold to be unnoticed. The hostname and operating system should conform to existing conventions, with a slight tweak of the bait enticing an attacker to explore the system further.
Exactly what kind of bait' depends entirely on your organisation. In addition, the authentication requests should respond in exactly the same way as other hosts on the network, but with the exception of being configured with additional monitoring to generate an alert any time activity such as attempted log on is detected.
The open-source project Artillery from Binary defence is one option to help configure and monitor a stand-alone Linux or Windows honeypot instance. This can be used in tandem with a variety of low-or medium-interaction honeypot programs that simulate a system or service. For example, Cowrie simulates the ssh service which allows authentication by an attacker and monitors attacker activity with the honeypot generating detailed logging and alerting.
Credentials Based: Assuming the adversary is within the network, being alerted to some of the usual lateral techniques is crucial. So extending the concept of honeypots to honey hashes can help. Honey hashes are the insertion of dummy credentials into the memory of a running system. Completely unknown to the system or system user of its presence, unless an attacker uses a tool such as Mimikatz to steal credentials and reuse them within the environment. If an attacker attempts to use the planted honey hash credentials, an alert is triggered on the attempt and an investigation can be launched.
In order to implement honey hashes, there should be a created privileged honey account that will never be used in production, such as a member of the domain administrators group. Thus the privileged account presents an attractive target for attackers. The account should be configured with a very long, randomized password to prevent any realistic exposure from password guessing.
In tandem, a use case is configured on the SIEM to alert on any attempts to log on with this account. Once the baited privileged account in place, the honey hashes on systems in the environment are able to be planted using the New-HoneyHash.ps1 script from the EmpireProject. The PowerShell script takes a domain, account name and account password parameters. It then stores the associated credentials and the provided information in the memory of the Local Security Authority Subsystem Service process.
By placing the decoy domain administrator account (but with an incorrect password) credential in memory it will appear very tempting to any adversary engaged in password memory scraping. Any dump of the credentials stored in memory and subsequent attempt to reuse the account username and password will result in a failed login attempt and an alert can be sent to the SOC for further investigation. Startup scripts, pushed out through group policy, to place honey hashes on multiple systems throughout the environment can be made if you wish to automate the process throughout your system.
File-Based: Further down the cyber kill chain, assuming the worst case has occurred, data has managed to find itself outside the organisation, there's honey to detect this scenario too. Business files which have no legitimate business purpose are able to be deployed on any production server and configured with detailed auditing to alert on any interaction if opened or used. The files should have names which are both interesting but entirely in line with organisational naming conventions. Embedding active content in the documents which will automatically attempt to contact a URL or otherwise reveal the IP address of the system from which the documents are opened, exposing the attacker.
These types of activities have a number of legal as well as logistical challenges to create disinformation that is believable. One example is Canarytokens by Thinkst when an MS Word or PDF document is opened it is able to generate and send an email to a preconfigured email address. If the file is opened, the resulting email sent is unseen by the file opener. The sent email also includes other metadata such as the IP Address of opener and the specific token CanaryToken used. Allowing sufficient data for further investigation by SOC teams.
Cloud-Based: Lastly, a developing field. To understand malicious activity within cloud workloads I recommend the following honey baits across the AWS portfolio of services like SpaceCrab, HoneyBuckets, HoneyLambda, or CanaryTokensDocker. Whilst honeypots are relatively old technology (see C.Stoll 'The Cuckoos Egg: Tracking a spy through the maze of espionage') Taking one, or a mixture of these low cost, easy to configure toolsets will provide an extra dimension to any security monitoring capability and prove to be extremely beneficial for defenders to better understand the risks and possibility of a live attack. In this context, honeypots are a very sweet prospect indeed.