Introduction
Over the years, as information security teams, we have always been on the defense, forever waiting for the next security event before we can act. Although part of our strategy is to anticipate the adversary, we have not truly started to learn from the trends of the adversary to be prepared for the next attack.
Below is a proposal to use both theoretical and practical solutions applicable to information security deception tactics and elementary threat intelligence methodologies to enhance your security further.
The concepts discussed below require an open mind and one that is receptive to change. Admittedly some security practices may not even fathom that such concepts can be implemented in their environments. However, I believe that if we are going to get ahead of the curve and the blue team, then we need to change some of our practices, or as some sportsmen say… “Step up our game!”
I have broken them up into individual ideas, and each can be applied independently of the others. Thus you can implement one, or you can implement them all. (My suggestion is to start small, pick only one concept and start small and expand the program as you progress, optimize, and see success)
Each of the ideas has a varying impact on resources and investment needed to see the concept to fruition and to maximize the benefits of each.
You may or may not have heard of honeynets. Borrowing from this concept, I have refined the ideas to meet companies whose information security deployments are not yet mature enough for a full-scale honeypot deployment.
Honeytokens
Honeytokens; I define these as deception pieces of information strategically placed in corporate infrastructure and platforms as trapdoors used to detect “maliciousness” and provide the earliest alerts so that Security Operations Centers and Security teams can act on time in responding to the potential security incident. These are unlike honeypots which are computer systems.
Wikipedia provides another but similar definition at à https://en.wikipedia.org/wiki/Honeytoken
Honeytokens should be designed and created to look legitimate and indistinguishable from the rest of the information they share a residence with. However, they have no legitimate use, and thus any action on them should be a red flag for the security team, and incident response processes should be kick-started as a result of this trigger.
Some examples of Honeytokens include but not limited to;
1- Honeytokens for user accounts
2- Honeytokens for admin, privileged and service accounts
3- Honeytokens for emails (with the proper maturity these three could later become online identities for a threat intelligence program)
4- Honeytokens for R&D and mission-critical information repositories
5- Honeytokens for sensitive, PII, HR and finance databases
6- Honeytokens in connectivity/networks
a. Possibly deliberate (benign) open ports
Honeytokens for user accounts
These are benign accounts created and added to active directory that have no legitimate use. No one should be attempting to authenticate with these accounts or using them to gain any level of access.
The Security team in collaboration with the Active Directory team, can share logs, create detection rules, and thus any activity related to these accounts, would be flagged, and a predefined playbook is followed to investigate the alert.
These can even be taken a step further to help to combat phishing. [This will be addressed further below]
Honeytokens for admin, privilege, and service accounts can also be engineered in this manner, as described above, primarily when monitoring critical applications and servers. However, they can have different or more advanced use cases – [I would recommend this for later deployments, though, as the deception program gains traction and matures].
To combat phishing, for example, When a user submits their credentials in a phishing attack, generic incident response processes usually include asking the victimized user to change their credentials. Depending on the efficiency of your helpdesk and how enabled the security team is, this can take as little as an hour or as long as two days (or even more) before the user’s credentials are updated. However, in this time, the security team usually doesn’t know (nor review or they may perform a limited audit) of all the activity related to the user to establish maliciousness, success or failure of attempted compromise as a result of the phish.
However, with a coordinated effort, a set of dubious credentials can be submitted to the phishing website and then the security team in collaboration with the active directory team monitors for activity in the infrastructure for these credentials. Such an alert would allow the security team to understand how successful a particular phishing attack was and where the adversaries are or attempted to gain access to the network.
However, it is important to note that honey token accounts should be indistinguishable from the rest of the accounts in naming. The only way to tell them apart should be only because the creators of these in the honey token program know them and a database of these accounts is stored for reference. For example, the database of phishing honey tokens should include the identity of the honey token, the phishing campaign it was submitted in and if there has been an attempt to use the record or not.
Admittedly, some security practitioners will find difficulty with this specific idea due to the logistics involved and the level of inter-team coordination required to implement it.
Honeytokens for R&D repositories
These are offshoots of research data that are digitally marked and monitored using Windows sys internals tools or using a FIM (file integrity monitoring) solution to detect any activity on these repositories or files. You would be on the lookout for on-access and modified attributes in the logs for these data sets.
Legitimate users who use these repositories would not need to access these dubious repositories or datasets, and thus any activity on these repositories can indicate the first successful step in a data breach or data exfiltration of patented data and research.
Furthermore, the digitally marked datasets can be monitored for their appearance on the open web using free and open-source tools that are readily available. For example; Google alerts can be used to be on the lookout for this (honey token) data on the public web. Of course, by the time you receive a Google alert that this data is in the public domain, it may be a bit too late. However, This is still a preferable scenario to receiving a call from Law enforcement six months after the breach.
Also for added continuous monitoring benefit signatures can be written in the IDS, IDS, and firewalls to look out for these digital marks as they cross the network. Since this is dubious data, you can test its exfiltration to ensure that the alerts put in place will trigger.
This type of honeytoken may present a higher cost in setting up. However, the ongoing monitoring would impose a minuscule cost to maintain.
Again there should be no indication on face value that this data is fictitious.
Honeytokens for sensitive, PII, and customer data databases
The PII and customer data that companies store currently presents a significant risk and is now one of the most exportable datasets when it comes to data breaches. (OPM, Equifax, Adobe, European Central bank, and the list goes on)
However, it is relatively easy to monitor these datasets for maliciousness when you know what to look for among these datasets or databases.
These honeytokens would act as “spring-loaded traps(alerts)” since they would not be accessed using regular applications and thus any read or modification activity of these datasets or records would indicate an anomalous event that needs to be investigated.
The types of threats that can be detected by alerting on these honeytokens in databases range from simple SQL injections via a web application/browser to massive data exports by an insider threat and everything in between.
Honeytokens in connectivity/networking
Networks present one of the most significant challenges for creating Honeytokens due to the nature of the network. However, carefully crafted honeytokens in the network can provide immense value in tracking and locating adversaries in the network.
For example, the port 4444 is used by a sleuth of worms and virus and is a frequent port used for malware propagation and command and control traffic. Thus this can be used to detect potentially infected machines independent of an endpoint solution in place. (That being said the port 4444 is also used by some security appliances such as the Sophos UTM however if none of your appliances use such a port then it would be an ideal candidate)
The idea here is to leave some ports deliberately open (but benign), well aware that your infrastructure does not have any legitimate traffic internally that utilizes these ports, and thus any network traffic in the firewall that goes through these ports is flagged, forensically analyzed and the machine/machines involved analyzed as well.
Network honeytokens preset the highest rate of false positives (when poorly crafted) however they also give real-time updates on the status of your monitoring efforts when carefully created with accurate assumptions or deductions
It is important to mention here that the desire to reduce the false positive rate should not result in a reduction your monitoring efforts and what you are able to detect.
However, I believe there needs to be a shift in how we deal with false positives especially in large-scale corporations and companies dealing with national infrastructure. As Edward. G Amoroso aptly puts in his book Cyber Attacks “Responding to a large number of false positives is necessary to adequately protect national infrastructure.”
It is also important to note that with such a program, the vulnerability risk assessment will indicate more vulnerabilities than there actually are if correctly implemented.
Legal Implications
There should be considerable legal and regulatory concerns that need to be considered before the use Honeytokens.
For example, the placement of honeytoken accounts in a PII database can create integrity issues in the database that only HR or data privacy teams may determine the impact of such actions.
There may be some regulations that limit the use of Honeytokens in production databases and datasets or even storing “honeytoken databases” on the same servers as production databases.
Another consideration is when submitting fake credentials to phishing attacks that target your company. I can only speculate on what type of legal sign off is required to sanction such actions as part of your information security program. For example, how about when you create fake credentials and then we on board someone whose identity matches a previously created Honeytoken?
It is also important to note that if the adversary is competent and they discover that the data in their possession is honeytoken data, they may retaliate against the company. There is little evidence and published research to support this statement, but the possibility still exists.
So the legal team needs to be involved in the decision making if such a program is to be rolled out / sanctioned.
Benefits
Undoubtedly there are numerous benefits associated with using honeytokens. During this reading, you may have come up with some benefits as you read. Below are some of the benefits that a security program can reap from an adequately implemented honeytoken program.
1- Early warning signals to detect maliciousness and adversaries.
Because of the nature of honeytokens, any alerts that are a result of monitoring these tokens, provide signals with a high degree of confidence of suspicious activity. Thus any incident response efforts can be focused on responding to actual potential security incidents and thwart any possible damage before any considerable impact.
2- Combat phishing attacks and detect pivot attacks (when a phishing attack is successful)
This goes directly to phishing attacks and using honeytokens to study and learn of any pivot attacks that may have been a result of a successful phishing attack.
This would, in fact, enhance your phishing attack metrics especially on the potency of phishing attacks that have been directed towards your company.
I must warn against using this solution for attribution as such deductions have been incorrect often.
3- Potential to uncover unknown vulnerabilities
This is a hidden gem when deploying honeytokens. As you study the typical habits of these tokens and implement them, you reveal possible unsecure computing practices within the organization, and in the quest to reduce the false positives, the correction of these computing practices automatically improves the security practices internally.
As an example, you might uncover an application that is communicating on a port that it should not be communicating on due to a misconfiguration or poor application management.
Honeynets, in general, magnify this benefit (and all these benefits) especially when they replicate sections on your infrastructure. However, this proposal is not for a honeynet at this point.
4- Potential to uncover insider threats
Another benefit of using honeytokens is to monitor for and alert on potential insider threats. Arguably, these honeytokens are the most cost-effective solution to monitor and detect insider threats. This is because, since there is no legitimate reason to access honeytokens, anyone accessing these tokens outside of the team running the program, would at least be suspicious and at most malicious.
However, this goes without saying that investigating such cases would have legal and compliance requirements, and preferably a predefined defined playbook. This goes back to the legal implications I raised above.
5- Increased focused visibility into our infrastructure
By design, honeytokens require that we understand what is normal behavior before we can define abnormal behavior. This activity would require documentation of your infrastructure during deployment and this by default, enhances your understanding and visibility into your infrastructure.
Secondly, once monitoring is set up for honeytokens, they can provide a higher assurance on the status of the infrastructure as they would be “spring loaded traps” that haven’t been tripped yet thereby asserting some confidence on the state of your security.
Finally, the more we deploy, the more we monitor and thus the more we see.
Wrap up
As I conclude here are a few items to consider,
a- If this program is to be enacted in any way to be successful, discretion is crucial and necessary for its success. However, there are benefits for openly announcing the use of deployment tactics. Yet, these benefits can only be realized in organizations with mature information security programs. The most significant of these benefits is deterrence of potential insider threat.
b- The success of the program relies on the coordinated effort from various platform owners that are engaged in the honeytoken program.
c- Just like any global program, senior leadership buy-in and on-going support are needed both in terms of organizational support and potential funding where and when required.
d- This program is scalable and could start small (even with only one honeytoken to start) and keep growing as it is optimized.
e- For some honeytokens to appear believable and indistinguishable from the rest of the datasets, there is a need to be kept alive, and this requires a sizable level of effort.
f- This program does not provide a preventative solution but rather an enhanced early warning system. An enhancement to your continuous monitoring program!
Let me know your thoughts and feedback on these concepts, whether positive or negative.