I recently did a (sort-of) Purple Team engagement. I sat in a room with the client's head of IT, looking at their SIEM (Security Incident and Event Management) dashboard while I was performing attacks of increasing severity (and later detectability). The client's SOC (Security Operations Center) team was not informed of the engagement during the first days, so that their initial reaction could be as realistic as possible. This was not meant as some sort "gotcha" towards the SOC team, mind you. Approaches like that would be highly counterproductive and just create a hostile work environment. It was only meant to better identify gaps in existing processes.
The client provided me with initial access to their Active Directory domain (a newly created account), following an "assumed breach" scenario, meaning it was meant to test the security posture after the perimeter was breached. The account was configured exactly like it would have been for a new employee, name, description, group memberships and permissions included. The laptop I was provided with came with CrowdStrike Falcon, and while an AMSI bypass proved to be successful quickly, some of the recon tools I used were immediately picked up by the behavioral detection. However, most of these were only displayed as "info" elements without severity in the central CrowdStrike console. These elicited no reaction from the SOC. Somewhat understandable, given that they probably get tons of these "info" events every day. Nevertheless:
This adage should be printed on a sign and hung on the wall in every Blue Team office.
After initial silent recon, I created a snapshot of the entire Active Directory domain using ADExplorer. This was picked up by CrowdStrike as a "medium" severity event and elicited a reaction from the SOC team. Regretfully, they immediately closed the automatically created issue as a "False Positive". While ADExplorer can be used for legitimate purposes by legitimate system administrators, this event should still trigger at least a surface level investigations. Even more so when the executing user seems to be on his first day on the job. Especially if for almost half a day, CrowdStrike already reported "info" events related to domain reconaissance from the same system and user. This was regrettable, since client's SIEM configuration did not allow for much more detection opportunities afterwards.
The SIEM's data only consisted of CrowdStrike events and some Windows event logs (and those only from the domain controllers). This was far from sufficient. In my opinion, a good SIEM / IDS should make use of all the existing Windows event logs of all systems in the domain and preferably also use additional logs such as those generated by Sysmon, which I highly recommend to use whereever and whenever possible. After the initial recon steps mentioned above, none of the further steps for lateral movement and privilege escalation were picked up anywhere.
So, after the detections and defenses had been overcome, it was time to throw the SOC team a little bone. So I executed Rubeus on the laptop an tried to get the tickets of all domain users with an SPN. The process was immediately killed and resulted in a "high" severity event. Minutes later, I got a Microsoft Teams message on the laptop from a member of the client's cybersecurity team. The message contained something along the lines of:
Which, given the context, was sort of hilarious to me.
After waiting almost two hours, the staff member wrote me another message, urging me to reply soon.
In the meantime, I was wreaking havoc in the network, unbothered moisturized, in my lane.
While I understand the wish from the cybersecurity team to maintain a friendly relationship with the rest of the staff,
being so lenient when someone's account or system is potentially compromised is a risk for the entire company.
Slightly more decisive actions would have been preferable in this case.
Examples for this could be quarantining the system on a network-level and temporarily disabling the user until the situation has been resolved.
Sure, this might cause a little bit of inconvenience in the case of a false positive, but could do wonders in the case of an actual attack.
In addition to the subpar reaction from the SOC, one other thing that really piqued my interest was a lack of alerts on rather obvious reconnaissance techniques commonly used by attackers. And that was because of the lack of data the SIEM was receiving. If they had evaluated all Windows events and Sysmon information AND if they had configured proper alerts for common TTPs, the SIEM would have painted a much clearer picture of an attack much earlier during the process. So, just as a well-intentioned heads-up: EDR and SIEM programs are great tools to enhance security and catch attackers red-handed. But just having these systems in place is far from enough. They also need to be configured properly. And, very often, properly collecting and evaluating the logs that are generated by the operating systems in your network can help you detect a lot of attackers before an EDR can intervene can even catch wind of them.