Like an exciting adventure story, but real
What is it like to spend your days catching crooks and other villains? Not as the village constable of old (when everything was better, of course), but what does a security analyst's daily life look like? How exciting, or perhaps how dull, is it to use an extensive set of software tools, knowledge, experience and common sense from behind your computer screens to get hackers from all over the world out of your customers' networks and keep them out? And how do you tell the bosses that their own employees can be very creative too?
In this blog, we look at several real scenarios, presented as fictional accounts for privacy and confidentiality reasons.
Note: the images and screenshots are real, but deliberately taken from examples or other events to protect privacy and prevent identification.
As a security organisation licensed as a private investigation agency, my colleagues and I regularly encounter suspicious activity in our customers' networks. How do you provide well-founded 'proof' that an employee is acting maliciously? And how does that translate into a real-world business risk? How does a hacker find a way through all the security layers in place? Most of our customers have an endpoint security solution, such as antivirus, and a 'Next-Gen' or 'UTM' firewall. Unfortunately, we see all too often that these tools are not configured properly or optimally, allowing attackers to act unchecked.
SIEM, or Security Information and Event Management, combined with UBI (User Behaviour Intelligence), is becoming increasingly important in our daily work as security analysts. We enjoy our work and always approach it with the aim of helping our customers. The potentially large number of alerts from traditional SIEM and UBI solutions needs to be kept to a minimum. You do not want to confront your customer four times a day with various 'business-critical' alerts that individually have little or no business impact. That is why we always make sure we know the customer, their IT environment, policies and culture.
We analyse using intelligent tools that focus mainly on behaviour and accumulated events. In most cases, these are combined solutions, such as Rapid7 InsightVM and InsightIDR and/or DTEX Systems.
Use case: how does this work?
Within hours of every new customer engaging SECWATCH, we see various alerts coming in through our tools and reports. In this case, a user account with elevated domain privileges suddenly grants elevated privileges to several other accounts. There is no other suspicious activity apart from these actions.
To find the cause, we examine the audit trail from a forensic perspective and decide to call the responsible IT administrator briefly. After a short explanation, the action proves legitimate: the user had temporarily elevated several accounts for an installation. We give the customer a few tips on privilege management and point out the risks, then close the incident and investigation. We deliberately choose to close and archive only this incident, because we want to be notified again if the same actions recur.
The following day, several incidents occur in the same environment, one after another within a particular timeframe. Most are automated actions that cannot immediately be linked to a specific type of user behaviour or activity. We instruct the tools to add the accounts concerned to the watch list: we will monitor these users closely for the time being.
After a while, the incidents start to accumulate and we investigate further.
The first alert concerns 'leaked accounts', which our pentesters often use in external penetration tests and internal assessments. An alert in the system shows that several accounts appear in leaked user databases from various hacks, including the LinkedIn, Dropbox and Yahoo breaches some time ago.
For each incident, we identify the potentially leaked accounts. These accounts are known from major, well-known breaches. Could any still have an unchanged password? This happens all too often and, some time later, we see several alerts:
The attacker tries to gain access to a single account by brute force, or to obtain a valid login through password spraying. We regard this as 'noisy' behaviour, particularly for a potentially targeted attack. Could a service account have the wrong password? Or are we dealing with a not particularly clever, potentially malicious action?
The answer soon follows:
In the background, we begin communicating with our customer and discussing the possible decisions. Do we let 'them' continue briefly under controlled conditions, or block them immediately? In this specific case, we decide to observe. We might learn something, and we can always intervene immediately if necessary. We see the attacker initiating various actions and assigning permissions, including remote access and possibly a reverse shell. A service account logs in through an external VPN connection.
A new asset, not yet known to us, starts trying to install a dropper on an asset in the environment:
We examine the evidence, but do not yet see suspicious data traffic.
Then we do see a successful transaction (example):
Because our customer's environment is connected to a Vulnerability Management environment (Rapid7 InsightVM), we quickly look up the attacked asset on the dashboard to obtain an immediate overview of exploitable vulnerabilities:
The asset has several vulnerabilities for which public exploits are available. The attacker does, however, need to 'write' these themselves, because no simple Metasploit module is available.
Not much later, lateral movement follows, in this case to a local administrator account. Disabling local administrator accounts is often 'forgotten', and their passwords are frequently never reviewed. This allows an attacker to try to hide and gain system-level access through exploits.
Followed by privilege escalation:
As the business impact and risk are now becoming critical, we agree with our customer to stop the 'experiment'. We immediately bring everything to a halt with mitigating actions to prevent further impact. We know a great deal, but you never know everything. We start working through all the collected events and detailed logs, taking immediate action with the system administrators. All access is stopped and all accounts are reset.
The employees involved are informed, and we discuss with the customer's responsible decision-makers whether they wish to proceed with forensic analysis, an internal investigation and a police report. We involve our compliance auditors to analyse GDPR and notification obligations, even though we have worked in a tightly controlled manner.
While these events unfold at just one of our customers, my colleagues encounter similar, yet always slightly different, developments at other companies and organisations. The creativity of hackers outside an organisation must never be underestimated, nor that of its own employees. Both can seriously disrupt a business, and each requires a different approach. Our days are never the same, and never boring.