Article: Cybersecurity or Security Theatre? How OSINT and SocEng should be key in your approach
Author: Kieren Niĉolas Lovell TalTech Centre for Digital Forensics and Cyber Security project manager
Cybersecurity is all the rage at the moment. We all agree that securing our data is important, and the impact that it can have if we have a breach on personal, organisational, national and international levels, and have a huge emotional, financial or social impact on our lives. In some cases, all three.
However, the mode of attack that is most common and has the most effect, for the least amount of technical skill required, we practice the least. In this regard, we are talking about OSINT and SocEng, Open Source Intelligence gathering and then using this information to launch Social Engineering attacks.
First things first, Social Engineering is not new. Let’s look at it at what it is - scams. Establishing a level to trust to manipulate the person to unknowingly leak information, credentials, or run malware on your system or device. The first recorded case of Social Engineering goes back to the 17th Century, called the “Spanish Prisoner” scam. This was when you were contacted to say you have a long lost Cousin who has been captured by the Spanish. He is a very rich cousin, and if you pay his small bail, he will be released and you will be rewarded ten-fold on the return of your hero cousin. Of course, this was all social engineering and OSINT. At the time, they were collecting data from local village halls about your family tree, working out who was deployed to Spain during their conflict and then taking advantage of the poor communication channels to establish a level of trust that can be used to exploit the target. This is remarkably similar to the Nigerian Lottery scam, but on this occasion, we are talking about completely targeted attacks.
First of all, we must remove this myth that we have developed in the cybersecurity industry. That users click links because a) they are stupid and b) because they have not been trained. That is simply not the case.
In our research of existing incident data, and in the Tallinn University of Technologies OSINT and SocEng exercises, one simple conclusion has come out of our exercises, which we are presenting to Oxford and Cambridge College IT Conference and presented last year at the TalTech ICR. Every single person we have targeted in this fashion, of whom a) Ethically have been informed on the days that they will be targetted spearphishing communications and b) are told: “do not click the link” in our Exercise Neptune and Exercise Mercury projects, have clicked the link. 100%. Well trained cybersecurity professionals, have all done complied or fell for this. Why? Well, let’s break it down:
Cybersecurity advice #1: Never click links in emails
Unless if you are completely anti-social living without the internet, or don’t like to do any work whatsoever, this is impossible. Email has become central to everything that we do. We click links for Office 365, Google Docs, Mailchimp, Marketing emails, for company invoices, the idea that “you can’t click links in emails” whilst also at the same time getting login alerts from these services to “click this link to review your security information” kind of nulls the advice.
“Do as I say, not as I do” has never worked for bringing up teenagers, it definitely doesn’t work against the population
Cybersecurity advice #2: Two Factor Authentication will mitigate the problem
2FA mitigates it, it doesn’t stop it. Introducing the whole 2FA process within your attack profile is common, and can actually provide an approach to get the user to click the link, or to provide information.
Cybersecurity advice #3: Always check the originating email address for spelling mistakes
This, of course, works for general spam. This does not work for targeted attacks. In a recent challenge, we managed to spoof the email addresses of Jesus@God.com, Bill.Gates@Microsoft.com, your own email address, LinkedIn and Google Support. Since email is such an old technology, unless if you have set up DMARC, SPF, and DKIM correctly on your email solution, and everyone in your supply chain and friends and family network, this approach can be utilized and is highly unlikely everyone will do this anytime soon. A good example of how security protocols can be utilised in the attack vector can be seen with sending an email with a PGP Digital Signature. Outlook cannot decode and verify the digital signature in any way by default, but it does display a nice medal logo next to the email to say “it has been digitally signed”. Processes, procedures, and policies can be used against you on a targetted attack.
So, it is all hopeless?
No. Two areas need to be focused on though that we ignore. One is that we do this OSINT gathering ourselves. As individuals, as families, as organisations, we should check what we have publicly exposed online against us. Breached usernames and passwords, systems that are out of date and publicly exposed to the internet, personal data that can be used to craft a customised attack profile against you. Even the smallest amount of data can expose weaknesses in your armour. Is the goal to become completely cyber secure? No. On this occasion, you want to make it more difficult to exploit you than the person or organisation next to you. It isn’t a nice way of thinking, but it is the best thing you can do.
Remember all of your key services. It isn’t just the IT you. Facebook admin rights? Linkedin? Google Drive? If you are using free slack, for example, if a disgruntled employee has left your organization, do you have a process to make sure those rights are terminated before you terminate their contract? Do you google yourself to see what information there is about you? Do you stress test your processes and public policies to see how the information contained within could be used to find a way to break you?
So, how is a good mindset to use when conducting these exercises? Well, think from a disgruntled employee. From a very annoyed ex-partner that wants to hurt you. You cannot protect against state action anyway, but there is more chance of someone compromising your network or information from someone that really wants to hurt you. Remember, I can teach hacking, I cannot teach motivation. There is a wealth of information online, guides, processes, database breaches, malware as a service… However, it requires effort. Time. Knowledge of the target. Make that data collection harder, so only the most motivated could even attempt it.
And Finally, when it happens, don’t panic. Make sure you know how to report an incident just like you would know how to report a fire, a break-in, or a medical problem. The quicker it is reported to the right people, the quicker it can be identified and stopped. Most small incidents become large incidents not because they were intended to be, but because they weren’t noticed.
So, what can I do?
- Conduct OSINT checks against yourself. Regularly Google yourself, check haveIbeenpwned.com to see if you have any breaches.
- Utilize Shodan.io (an opensource vulnerability scanner) against your domain to see what is exposed, and see if you have out of date services running and ask the questions. Sometimes they can be false positives. Remember, that is good news.
- Make sure you have a security.txt on your website or an RFC 2350 (A document that has the security contact information and reporting procedure). This is a small text document that has the email address of your security contact, a telephone number, and a PGP encryption key to transmit any breach or supporting information from a fellow CSIRT/CERT or security professional. Make sure all of your supply chains also have a security.txt as well, or an RFC 2350. If they don’t, question it. As stated previously, the most important thing is getting the incident reported as quickly as possible to the right people at the right time for the right response. This basic .txt document has saved many an organization. The alternative is using your whois data against your website, which a) most likely hasn’t been updated since you got it and b) you have made it private with GDPR. So much delay happens in waiting in holding queues on telephones or conducting services desks, where on this occasion you want any security breach to go straight to the people that need it and to deal with it quickly. If they don’t have it, request it.
- Practice OSINT against yourself. Practice targetted email campaigns. Do not blame users when they do click it. Practice your response routine, and make sure you actually use your routine when it happens for real. Most organizations have great playbooks for incidents. The only time they never see the light of day is during an incident, and then you miss the obvious.
- When requesting penetration tests for your organization, don’t limit the scope. Hackers won’t. Nor should you when you check your defences.
- Read the CERT.ee and NCSC newsletters. Check for the latest trends.
- Check your logs. Most incidents end up checking their logs after the exploit and end up going around in circles because they don’t know what normal is. During all of our exercises, we have not been detected once. IDS, Firewalls, Apache Logging, Single Sign-on services, Syslogs are very effective… if you know where they are, if you know how to read them, and have the tools to do so. SpectX have just released a free desktop version. Work our what is your “normal”, then you can spot the problems. Trying to find the compromise afterwards when you don’t know what your network or system looks like puts you on the back foot, and will have you going down rabbit runs.
If you treat the problem as an organisational problem, and not an IT one, you will realise the “whole-ship” approach including all aspects provides a much better way of providing a security baseline. Remember, you have to protect everything in your organisation, a threat actor just needs to find one compromise, and they aren’t limited by scope, by law, or by time. Just their own determination.
This article was published in Edasi.org.