4/ Ensure to periodically check the properties of the AD objects, which could include passwords, left in the Description.
5/ "LAPS is the Microsoft solution to automatically manage the password for the built-in Administrator account on Windows devices. When machines are built or imaged, they often have the same password for the built-in Administrator account.
6/ If this is never changed, a single password can give local administrative rights to all machines and may provide opportunities for lateral movement. LAPS solves this problem by ensuring each device has a unique local administrator password and rotates it regularly." [1]
7/ In our incident response cases, we regularly see local administrators or accounts that are part of the local administrator's group in combination with a weak password - an ideal target for lateral movement.
2/ Strictly speaking not part of a guide about hardening AD, but I must stress once again the importance of logging executed PowerShell code on clients and servers:
3/ There are other opinions about PowerShell Script Block logging because, potentially, passwords or other sensitive data could end up in event logs, and authenticated users on the workstation or server could read these logs, thus giving away the sensitive data. [1]
2/ In our AD assessments or IR cases, we repeatedly see that service accounts are highly privileged, often also part of the domain administrators group.
This can be disastrous, especially with a weak password for the service account:
3/ @Synacktiv took a closer look at the detection capabilities of Defender for Identity, including whether and how Kerberoasting could be detected. [1]
3/ The whitepaper Certified Pre-Owned: Abusing Active Directory Certificate Services by Will Schroeder and Lee Christensen showcased new possibilities and attack vectors to gain domain administrative rights as an attacker. [1]
A TA brute-forced the password of the domain admin.
The customer first suspected an internal compromise, but upon a deeper investigation of this incident, we quickly realized that the IP address was the internal address of a Cisco ASA VPN box.
2/ The customer disabled the login mask a long time ago on the public internet-facing IP address of the Cisco ASA, as depicted in the image below.
3/ But, if we take a closer look at the @metasploit module 'Cisco SSL VPN Bruteforce Login Utility', we see that the URL "+CSCOE+/logon.htm" is used for the password guessing, at least in this module. [1]
2/ When I saw this for the first time I was quite confused and scratched my head, because I always look for suspicious user agents or deviating user agents of the compromised user.
It took a moment to realise that the phishing kit spoofed the UA from the user's browser. 👉😏
3/ This behavior of Evilginx2 makes it harder to find outliers in the recorded login information, because as nicely described in the blog the user agent from the user performs the login as if the user would log in himself.
2/ The screenshot above depicts the content of the config.json file, which is located in the installation directory of DWservice, and could be interesting for LEA purposes (the key could be linked to an account).
Below is another screenshot with various features of the service.
3/ In our case, the path to the binary was C:\Programdata\DWAgent\native\dwagsvc.exe, but the path can be changed during installation.