Updated README for detailed report explanation.

README.md

@@ -63,3 +63,97 @@ They are paired online while running the script. KHDB does not contain usernames
 It should! If you have EDR installed on the host machine, this tool should be exceptioned.
 ### Would our monitoring tool detect this activity?
 It should, as it is extremely sensitive operation that should never happen outside of this (or similar) procedure. Running this tool should be cleared with your SOC beforehand (or used as a test case).
+
+---
+
+## Weak password report
+1. Reversible Encryption:
+    * ****Explanation:**** Accounts have passwords stored in a reversible format that can be decrypted.
+    * **Risk Assessment:** High. Decrypted passwords can be misused easily.
+    * **Possible Cause:** Legacy applications requiring plaintext password equivalents.
+    * **Use:** Compatibility with older applications.
+    * **Remediation:** Disable reversible encryption through Group Policy ("Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy > Store passwords using reversible encryption").
+2. LM Hashes Present:
+   * **Explanation:** Use of outdated LAN Manager (LM) hashes for storing passwords.
+   * **Risk Assessment:** Very High. LM hashes are easily cracked.
+   * **Possible Cause:** Historical default settings for older Windows systems.
+   * **Use:** Compatibility with legacy clients or systems.
+   * **Remediation:** Disable LM hash storage via Group Policy ("Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Do not store LAN Manager hash value on next password change").
+3. Accounts with No Password:
+   * **Explanation:** Accounts are configured without a password.
+   * **Risk Assessment:** Extremely High. Accounts are accessible without authentication.
+   * **Possible Cause:** Oversight or initial setup convenience.
+   * **Use:** Automated scripts or systems needing easy access.
+   * **Remediation:** Ensure all accounts have strong passwords. Disable unnecessary accounts.
+4. Passwords Found in Dictionary:
+    * **Explanation:** Accounts use weak passwords found in common dictionaries.
+    * **Risk Assessment:** High. Dictionary attacks can easily guess these passwords.
+    * **Possible Cause:** Lack of strong password policies.
+    * **Use:** User convenience and easy recall.
+    * **Remediation:** Implement and enforce strong password policies, use password filter DLLs.
+5. Same Passwords for Multiple Accounts:
+    * **Explanation:** Multiple accounts share the same password.
+    * **Risk Assessment:** High. Compromise of one account leads to multiple breaches.
+    * **Possible Cause:** Administrative convenience.
+    * **Use:** Simplified management across services.
+    * **Remediation:** Establish unique passwords for each account, audit for password uniqueness.
+6. SamAccountName as Password:
+   * **Explanation:** Usernames are used as passwords.
+   * **Risk Assessment:** High. Easy to guess and compromise.
+   * **Possible Cause:** Rudimentary security setup.
+   * **Use:** Lowering barriers for user access.
+   * **Remediation:** Prohibit this practice through user education and strict password policies.
+7. Computer Accounts with Default Passwords:
+   * **Explanation:** Computer accounts use default passwords.
+   * **Risk Assessment:** High. Default passwords are widely known.
+   * **Possible Cause:** Incomplete setup or bulk deployments.
+   * **Use:** Streamlined initial setup.
+   * **Remediation:** Reset all default passwords to strong, unique ones.
+8. Missing Kerberos AES Keys:
+   * **Explanation:** Accounts lack AES keys for Kerberos, falling back to weaker encryption.
+   * **Risk Assessment:** Moderate to High. Weakens Kerberos authentication.
+   * **Possible Cause:** Incomplete updates or migrations.
+   * **Use:** Compatibility with older systems.
+   * **Remediation:** Enable AES encryption for Kerberos in account properties and domain policies.
+9. No Kerberos Pre-Authentication Required:
+   * **Explanation:** Accounts can request authentication data without pre-authentication.
+   * **Risk Assessment:** High. Facilitates offline brute-force attacks.
+   * **Possible Cause:** Troubleshooting or legacy system compatibility.
+   * **Use:** Avoiding issues with older clients.
+   * **Remediation:** Enable Kerberos pre-authentication for all accounts via account properties.
+10. Only DES Encryption Allowed:
+   * **Explanation:** Accounts are restricted to using DES encryption.
+   * **Risk Assessment:** Very High. DES is weak and easily compromised.
+   * **Possible Cause:** Retained settings from when DES was standard.
+   * **Use:** Ensuring functionality of older applications.
+   * **Remediation:** Configure accounts to use stronger encryption types like AES in Group Policy.
+11. Susceptible to Kerberoasting:
+    * **Explanation:** Service accounts have SPNs and weak passwords, making them vulnerable.
+    * **Risk Assessment:** High. Enables offline password cracking.
+    * **Possible Cause:** Lack of awareness about service account security.
+    * **Use:** Service accounts needing elevated privileges.
+    * **Remediation:** Implement strong password policies for service accounts, rotate passwords regularly, use Managed Service Accounts (MSA).
+12. Administrative Accounts Allowed for Delegation:
+    * **Explanation:** Admin accounts configured to allow delegation.
+    * **Risk Assessment:** High. Can be misused to escalate privileges.
+    * **Possible Cause:** Misunderstanding or overly permissive security culture.
+    * **Use:** Facilitating administrative processes.
+    * **Remediation:** Restrict delegation rights, use Constrained Delegation.
+13. Passwords Will Never Expire:
+    * **Explanation:** Accounts are configured to never require password changes.
+    * **Risk Assessment:** Moderate to High. Increases risk of undetected breaches.
+    * **Possible Cause:** Minimizing administrative burden.
+    * **Use:** Reducing disruption from frequent password updates.
+    * **Remediation:** Configure policies to require periodic password changes.
+14. Accounts Not Required to Have a Password:
+    * **Explanation:** Accounts do not require passwords for authentication.
+    * **Risk Assessment:** Extremely High. Allows unrestricted access.
+    * **Possible Cause:** Configuration error or setup for automated systems.
+    * **Use:** Automating processes without manual authentication.
+    * **Remediation:** Enforce password requirements for all accounts.
+15. Smart Card Accounts with a Password:
+    * **Explanation:** Smart card-required accounts also have passwords set.
+    * **Risk Assessment:** Moderate to High. Bypasses smart card security.
+    * **Possible Cause:** Hybrid authentication setup or legacy fallback.
+    * **Use:** Providing a fallback in case of smart card issues.
+    * **Remediation:** Require smart card for login, disable password fallback.