This is the last thread in this AD hardening measure series, but there would still be so much to discuss 😅
Here are more points you should focus on to defend your networks even better.
"Administrative accounts should never be enabled for delegation.
You can prevent these privileged accounts from being targeted by enabling the ‘Account is sensitive and cannot be delegated’ flag on them. You can optionally add these accounts to the ‘Protected Users’ group.
This group provides protections over and above just preventing delegation and makes them even more secure; however, it may cause operational issues, so it is worth testing in your environment." [1]
"It is not uncommon for DART to engage with customers where accounts have weak or easy to guess credentials, including those of privileged users such as Domain Admins.
Simple password spray attacks can lead to the compromise of such accounts." [1]
"If you are licensed for Azure Active Directory P1 or higher, you can also deploy Azure Active Directory Password Protection, which can disallow your users from using easy to guess passwords even in on-premises Active Directory."
"An account can be set without a password if it has the flag "PASSWD_NOTREQD" set as "True" in the "useraccountcontrol" attribute. This represents a high security risk as the account is not protected at all without a password".
"Groups such as Account and Server Operators have wide ranging privilege over your Active Directory. For example, by default Server Operators can log on to Domain Controllers, restart services, backup and restore files, and more."
"It is recommended that, where possible, privileged built-in groups not contain any users. Instead, the appropriate privilege should be granted specifically to users that require it." [1]
Thanks for following me through this 10-day journey into hardening AD.
I want to use this thread to thank all the incredible people in our industry who have conducted the research and created the tools I presented in this series 💙
I really stand on the shoulders of giants 🙏
👋
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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])
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 🔒).