1/ We recently had an interesting #Azure case where the TA, instead of creating a new Inbox Rule, added email addresses of interest to the list of blocked senders and domains.
The incoming emails will get flagged as spam and moved to the Junk email folder. 📂
🧵
2/ Here is a screenshot from Outlook web access
(the view might differ, as, for example, here on the screenshot from the theitbros [1])
3/ And here from an Outlook client:
4/ This is a sneaky way to circumvent monitoring of audit logs which looks for specific keywords like "New-InboxRule".
Check out the excellent Business Email Compromise (BEC) guide from PwC for more keywords and background. [2]
5/ Plus, such a rule will not appear when extracting mailbox rules from the compromised account (or for all accounts for threat-hunting reasons) with the cmdlet Get-InboxRule.
6/ But we see this action in the Unified Audit Log tracked with the Operation "Set-MailboxJunkEmailConfiguration"
7/ Or we can read out the active list of blocked senders and domains with PowerShell (might return a long list of domains and addresses):
8/ I tweeted about the "Set-MailboxJunkEmailConfiguration" operation before, but last time, the attackers entered a whole list of mail addresses as trusted senders to facilitate receiving spam mail.
10/ Nevertheless, the TA must log into the compromised account to read the "interesting" emails received and move to the Junk-Folder (because of the Blocked Senders rule).
Thus we still have a good chance to catch the TA with the traces inside the Sign-In Logs 🎉
1/ Customer receives an email from a network monitoring device that a host is supposedly infected with a #CoinMiner. The Task Manager on the said system shows the following screenshot 🤕.
A story of an unpatched system, incorrect scoping, and 🍀. 🧵
1/ I used #AutoRuns v14.09 (GUI) in my lab setup but noticed that it failed to find (or display) the malware in the Startup folder, although the file is there (screenshot below).
I checked back and forth, searched manually for the file, and restarted the OS and AutoRuns.
🧵
2/ With #Velociraptor, I ran the hunt Sysinternals.Autoruns, and with the CLI version of AutoRuns, the malware is found in the Startup folder.
3/ The same for the #Velociraptor hunt Sys.StartupItems.
1/ Real-World #PingCastle Finding #13: Allow log on locally
➡️ Domain Users are eligible to log into DC's 🤯🙈
"When you grant an account the Allow logon locally right, you are allowing that account to log on locally to all domain controllers in the domain." [1]
"If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges." [1]
3/ I encountered this finding several times in our AD assessments, so you better check your settings in your domain right now (better safe than sorry 🔒).
2/ @threatpunter wrote a detailed blog about WMI persistences and how to remove them.
"The simplest method to remove the entry from the WMI database is to use Autoruns. Launch Autoruns as an administrator and select the WMI tab to review WMI-related persistence." ✂️
3/ "Alternatively, you can remove the WMI event subscriptions from the command line." [2]