1/ #ThreatHunting: @Avast has blogged how Roshtyak checks the VBAWarnings registry value.
If the value is 1 ("Enable all macros"), then the code will not be executed because it is assumed that this setting is only enabled in a sandbox (or by courageous users). 🧵 #CyberSecurity
2/ "Interestingly, this means that users, who for whatever reason have lowered their security this way, are immune to Roshtyak." [1]
3/ However, this "Enable all macros" value can also be explicitly set for Outlook
If this value is set to 1 in a user context, a nifty persistence within Outlook may have been set up by a TA.
4/ @MDSecLabs published a very readable article about an Outlook persistence technique almost two years ago. [2]
I could easily recreate this persistence in my lab, which still works up to this date. On the one hand, we could now hunt in our network if this registry key is set.
5/ Or we could check in which user directories the file VbaProject.OTM is present, which contains the macro code that would be executed when certain criteria are met (see MDSec's blog post [2])
Path on disk:
C:\Users\<user>\AppData\Roaming\Microsoft\Outlook\VbaProject.OTM).
6/ In our customer networks, we found very few VbaProject.OTM files in user directories, wich makes a manual analysis of the VBA code or monitoring for a creation of this file feasible.
1/ @rootsecdev published a blog post where common misconfigurations inside the Conditional Access Policies in Azure are discussed.
In an Azure Tenant from a customer, the following CA policy was implemented: Require MFA for administrative users.
🧵
2/ However, within the Directory roles checkbox, not all the roles were selected (see the picture below).
In Azure Assessments, I use, among others, the script Get-MsolRolesAndMembers.ps1 to find users which are part of such different roles. [2]
3/ The users or roles found with the mentioned script must be cross-checked with the CA (the checked roles from the menu above) to find possible users which could log in without MFA, resulting in a security gap. 🔎
/1 Repeat after me: AV scans and password change is not enough after a full AD compromise.
A company has already been encrypted twice and asked us for a second opinion. The responders did a password change with an AV scan of the machines...
What could possibly go wrong? 🧵
2/ @UK_Daniel_Card has compiled a good checklist that gives an insight into the many different tasks that are part of a proper IR engagement or clean-up (list not exhaustive):
3/ Another point missing on the checklist is the hunting for "legitimate" remote desktop solutions installed by the TA, which could be used as a backdoor for re-entry (Atera, Splashot, AnyDesk..).
1/ While analyzing AutoRuns entries in a Compromise Assessment, my teammate @newtt42 found four executables with different names but with the same hash (in the C:\Windows directory).
The binaries were ran as services with the following names: JXds, vdEp, JXmM, PTLt. 🧵
2/ @Synacktiv has published a blog post recently where our observations are described:
"The SysInternals PsExec starts a service that is named PsExeSvc by default whereas Impacket's psexec.py tool spawns a process with a randomly generated 4-characters name." [1]
3/ We can hunt for such binary and service names using this sigma rule [2]:
Monitoring or creating a baseline (which users are using Python) could be helpful here, or just monitoring from which paths Python is started (like in our example from the Music directory).
This scanner is trendy among ransomware groups and has been mentioned in reports by @TheDFIRReport, among others. [1] 🧵
2/ This HTTP request can now be used very well for an alert.
Or better, collect and monitor all your DNS logs, because a DNS request will still go out if the Advanced IP Scanner is run without an installation (portable version).
An excellent opportunity for detection.
3/ You can see the DNS request for the domain www.advanced-ip-scanner[.]com below.