2/ Yes, an attacker might find clues about other hosts in the network elsewhere (logs/history files), and yes, a TA can probably crack the hashes relatively quickly with hashcat. [1]
3/ But I would probably vote to enable this setting at the end of the day. You?
2/ I have been mentioning this topic in one of my presentations for quite some time (see slide above).
When DNS logs are recorded, analyzed, and evaluated, the use of DoH can lead to a blind spot. I assume that more TAs and malware authors will use this technique in the future.
3/ If possible, block the DoH resolvers on the proxy or firewall.
1/ Perhaps a lesser known "feature" of Microsoft Authenticator, but the diagnostic data can be very helpful in investigating a compromised #Azure account where MFA is enabled but the user claims not to have confirmed the MFA Consent Prompt. 🧵
2/ You will find the diagnostic data here:
Authenticator App
▪️ Burger Menu
▪️ Send feedback
▪️ Having trouble?
▪️ View diagnostic data
Click "Copy all" and send the text via mail or other ways to your analysis device.
3/ When logging into an MFA protected (the second factor is the Consent Prompt) account, we see the following entries (abbreviated) in the Authenticator diagnostic data:
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/ #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
/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]: