Intelligence Gathering – from Reconnaissance to Exploitation
Back in the days as a security consultant, I was in charge of conducting various tasks such as security audits, security controls integration and more. The ones I enjoyed the most were penetration tests which demonstrate if and how can an attacker breach a target customer. Long story short, I was getting paid to break things so what is not to like?
Most of the attacks have an upper limit in the form of time limitation. This limitation affects its scale and scope, and the technical implications are that in most cases the attacker chooses to exploit known vulnerabilities and use known tools (eventually it’s a game of ROI).
Now, let’s go through the reconnaissance phase (usually the first step of an attack) - information gathering. One approach that worked rather well for me was to gather publicly available information from websites the target customer operates. The incentive was to get documents and analyze their Metadata to get the information I’ll need in the exploitation phase (while I’ve automated the procedure, at first I used FOCA after enumerated all domains of the target).
To simplify things, this approach allowed me to extract valuable information from these files such as OS versions, network shares, users (a couple of usernames can disclose this organization naming convention later to be used in a phishing campaign) and 3rd party application versions.
While this post won’t cover all of the steps involved during an attack (you can read more here and here). By now I know what environment I'm targeting, and what are the tools and exploits I can use against the target customer. After setting a foothold, my malicious malware runs on the target device. From now on, it’s rather easy to get an indication of compromise - passwords, pictures, files or keystrokes - which are usually set to be my goals.
Several days after, the targeted customer gets his penetration test report with all the vulnerabilities and the flow of the attack. Finding the right mitigation was sometimes of a challenge - yeah, these vulnerabilities are known and let’s assume this customer is exceptional and makes sure to update every application whenever there is a new update.
What can the customer do if there is no patch? If the vendor is aware but still there is no mitigation? What happens if there will never be one? And even worse, once inside the organization how the customer can prevent one of the biggest challenges - abusing the built-in features of the installed applications?
At Vicarius, we recognized that the vulnerability assessment regulation is not up to date with the risks out there. Yes, the vulnerability scanners will tell you what updates you need to deploy, the better ones will try to prioritize, but hardly anyone offers mitigation and no one address the gap of abusing software features.
It’s time for a change.