3/ For example, the following text in the picture below was sent from an external SOC to a customer. According to Windows Defender, among other things, Mimikatz was detected.
On a DC.
But Defender can handle it on its own.
Please run a full scan.
4/ OK.
5/ If the alert occurs on a server (or DC!) under a path that is also relevant (according to the cheat sheet), I tell my customers not to think twice and call an IR company for a deeper analysis (if they don't have the in-house resources).
6/ Another example: These alerts stem from a client - but the client was restaged without a forensic investigation.
7/ But if CS is detected on a computer, at least in my opinion, a deeper analysis is necessary to see if a lateral movement originating from this computer has already taken place, if credentials or other data have been stolen, collect further IOCs and check them in the network...
8/ The quick re-installation of a computer destroys significant traces that are enormously important for forensics or hunting in the network.
AV alarms, in particular, can be a warning sign that a TA is active inside the network, as we repeatedly see in our IR cases.
π
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
1/ Sin #5: No in-depth analysis after a (security) incident
Time and again, we see that security incidents are not dealt with in sufficient depth, which can lead to further security problems, even more serious ones. π§΅
2/ A good example I always mention is the leak of the Fortinet VPN credentials.
Although many companies knew they were vulnerable at the time of this breach and patched their systems, many neglected to change the passwords.
3/ Even this year, we had IR cases where we found the user's credentials for the initial entry into the network in the leaked VPN passwords.
This is a classic example where a security incident was not dealt with sufficiently, and the critical password change was not carried out.
Service accounts should never be part of the Domain Admins group.
Check and clean the DA group regularly because a TA could try to "Kerberoast" the service account, which is primarily a problem if the service account use a weak password (next point).
1/ We continue our path down the seven sins. Today's sin #2: Lack of MFA.
The slide below is almost an evergreen, and I sometimes joke during presentations that I should print it out and hand it out to clients.
But the importance of this point cannot be overemphasized.
π§΅
2/ Among other things, we also investigate many BEC cases, which according to the FBI's Internet Crime Report, cause billions of dollars of damage yearly.
Nevertheless, in our IR cases, we repeatedly find OWA and Exchange Online accesses that are single-factor protected.
3/ Especially with Exchange Online, the legacy protocols must be switched off, as they cannot be protected with MFA. Attackers often use this "trick" to use the phished credentials despite MFA.
2/ Let's start with sin #1: Lack of patch management.
Lack of patch management is bad enough on internal systems (i.e., unpatched DCs), but on systems accessible from the Internet, not applying (security) patches can become an easy gateway into the internal network.
3/ The screenshot of the mailbox left is from a real IR case, taken in February this year (2022).
Creating these draft emails is a typical step in the ProxyShell exploitation, where a module for Metasploit alone was released on 18 August 2021!
In a recent IR case, the TA created persistences with #QakBot on almost every system in the network.
If only individual systems in the network were forensically examined, one or more infected systems would undoubtedly be missed.
π§΅
2/ By examing the network connections made by the clients & servers with a forensic agent, it is apparent that QakBot has made a process injection into the following two processes:
3/ The analysis of the network connections gives us active C2 addresses that we can use for additional hunting inside the network (and in the FW logs).