You can download the Free Script from here .

Note: You will need to extract the .ps1 after downloading the zip file, please review the help file.

The CionADChecks.ps1 is a PowerShell scripts gathers basic data from AD Domain/forest that we believe enterprises must review on a regular basis and take necessary actions to remediate any weakness. You can further use CionSystems’ Free AD reporter for detailed AD assessment.

The PowerShell script requires the following:

• PowerShell 5.0 (minimum)
• Windows 7+ or Windows Server 2008 (or newer)
• Active Directory PowerShell Module
• Group Policy PowerShell Module

The PowerShell script gathers domain data using the Active Directory PowerShell & Group Policy modules and displays some results on the screen. The data shown on the screen is also saved to a transcript log file and all captured data is also saved to csv/text files in c:\temp\ADMustcheckReports.

The ADMustcheckReports PowerShell script gathers data for key AD security items in a domain:

• User Account Issues
• Groups
• Trusts
• Duplicate SPNs
• Group Policies
• AD Administration & Privileged Accounts
• KRBTGT Account
• Kerberos Delegation
• Group Policy Object Owners
• Much more…
  

  #	What is it?	Recommendations
  1	User Account Issues There are several potential issues that Active Directory domain user accounts may have because these accounts can be configured in many different ways. Further they can be in different states with different user access control settings. The script shows the state of all users along with User accounts flags.	Disable and eventually delete inactive accounts. You must look at all domain controllers to figure out the inactive users as last login attributes are not replicated between dcs. Remove the following from accounts: ·         Reversible Encryption ·         Password Not Required ·         Password Never Expires ·         DES Kerberos Encryption Enabled ·         Do not require Kerberos Pre-Authentication ·         Review accounts configured with SID History and clean up SIDs in SID History for accounts from domains that no longer have trusts configured with them.
  2	Domain Password Policy The Domain Password policy determines how passwords are created and how often they need to be changed, etc. The AD default password minimum is 7 characters. Most AD environments we see have this set to between 8 and 10. Some are set to 0 or 3 or 5. Password Spray attacks are effective against Active Directory due to bad passwords (often with short minimum requirements).Increasing password length can limit Password Spray effectiveness. Fine-Grained Password Policies (FGPP) provides additional flexibility, especially for admin and service accounts.	You can use CionSystems ADGuardian password protection to audit all passwords, enhance default AD password policies, remove duplicate passwords, force all users to change passwords if they are using passwords that has been breached
  3	Tombstone Lifetime The AD Tombstone Lifetime determines how long deleted items exist in AD before they are purged. The default value is 180 days starting with new AD forests created with Windows 2003 SP1. While the tombstone lifetime directly affects deleted items, it also has an impact on Domain Controllers. If a DC hasn’t replicated within the tombstone lifetime with another DC, it is effectively orphaned from the domain. Additionally, DC backups are only useful for restoring AD data within this tombstone lifetime – a backup that is 181 days old is no longer useful when the tombstone lifetime is 180 days.	Systems state DC backups are only useful for restoring AD data within this tombstone lifetime – a backup that is 181 days old is no longer useful when the tombstone lifetime is 180 days.
  3	Active Directory Backups Microsoft supported backups update a partition attribute to identify the last backup date for that partition.	Unlike CionSystems ADGuardian plus, not all backup solutions of Active Directory set this attribute since they are likely not using a Microsoft supported method.
  4	Trusts An Active Directory trust extends the security boundary and include other the systems that may not be in the domain yet they can access resources within the domain, thereby extending the authentication boundary.	Review trust configuration & ensure that trusts are appropriate at least once every month. Review bidirectional trusts. Check if trusts is needed with DMZ environments otherwise remove. See if Selective Authentication works for your need.
  5	Active Directory Duplicate Service Principal Names (SPNs)	Make sure there are no duplicates!
  6	Group Policy Preference Passwords Group Policy Preferences was released in the 2008 time-frame and included capability to provide and update credentials. These credentials were encrypted using AES256 which sounds good until you realize that a static key is used to encrypt them. The cpassword value in the GPP xml files is the encrypted password. Using a PowerShell function from PowerSploit, we can reverse this encryption and get the plain-text value. Since authenticated users have read access to Group Policies in the SYSVOL share on all DCs, anyone can view this information and get the passwords stored in GPP xml files, even across trusts.	Ensure there are no Group Policy Preference passwords in SYSVOL.
  7	Active Directory Admin Account Checks During standard Active Directory Security Assessment, the focus must be on identifying “AD Admins” which includes members of the domain Administrators group, Domain Admins, Enterprise Admins, and other builtin groups etc. These accounts have full AD rights and require careful protection. Note, there may be other accounts with privilege access that may not show up in this list, if the access was granted using ACL’s modification	Ensure passwords change regularly (every year) Disable inactive account Remove disabled accounts Ensure no SPNs on accounts associated with people Remove any computer accounts Scrutinize Service Accounts What do they do? Where do they run? What computers do they authenticate to? What rights are actually required?
  8	AD Admin Accounts Not Member of Protected Users Protected Users is a new group created when the domain PDC Emulator is running Windows Server 2012 R2. Full Domain protection is only available when the domain functional level is 2012 R2. Protected Users group provides additional protections:	Kerberos AES authentication only (No Kerberos DSE/RC4 or NTLM) No Kerberos delegation (constrained or unconstrained) Kerberos TGT set to 4 hours Credential delegation (CredSSP) will not cache the user’s plain text credentials NTLM will not cache the user’s plain text credentials or NT one-way function Offline sign-in is not supported
  9	AD Admins with Old Passwords AD Admin accounts with old passwords, especially those older than 3 months, are vulnerable to password spraying (and password guessing).	Ensure privileged account passwords change regularly. Use CionSystems password protection enhancer! Older passwords are typically poor and easier to guess. Password Spraying & Kerberoasting are popular attack methods for compromising accounts lacking strong passwords.
  10	AD Admins with Kerberos Service Principal Names (SPNs) Kerberos Service Principal Name or SPN is effectively the signpost that points to the service account for a service on a server that supports Kerberos authentication. When the client needs to connect to a service, it must request a Kerberos service ticket from a DC and in order to do this it needs to provide a SPN for that service. The DC looks up the account in the AD forest that has that SPN, identifies the account, and uses the account’s password data to encrypt the ticket. Once the service ticket is delivered to the service, it attempts to open the service ticket and if it can, it can assume the DC provided it, so it validates access for the user.	Ensure that no AD Admin accounts associated with people have SPNs. Limit service account membership in privileged Active Directory groups and ensure these service account passwords are longer than 25 characters Enhance password policies using CionSystems Password protection solution
  11	Check Default Domain Administrator Account for Issues	The account password should change at least every month (and when an AD Admin leaves the organization). Ensure the account has no SPNs. Account should be rarely used which is not the case in most enterprises The account can be enabled or disabled.
  12	Review AD Default/Built-In Group Membership Reviewing the default privileged groups in Active Directory is important to identify accounts with high-level privileges.	Leave only accounts that must require full AD rights are members of these groups. Use CionSystems ADGuardian to reduce the privilege accounts.
  13	Default AD Groups: Administrators	Default Rights: Active Directory admin rights (for the domain) Domain Controller admin rights (for the domain) Reference: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-admins
  14	Default AD Groups: Domain Admins	Default Rights: Membership in the domain Administrators group which provides most rights. Active Directory admin rights (for the domain) Domain Controller admin rights (for the domain) Default rights on all domain Group Policies Default local Administrator on all domain-joined computers Reference: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-domainadmins
  15	Default AD Groups: Enterprise Admins	Default Rights: Membership in every domain Administrators group which provides most rights. Active Directory admin rights (in every forest domain) Domain Controller admin rights (in every forest domain) Default rights on all domain Group Policies This group should remain empty in a single domain forest and membership very limited in a multi-domain forest. Reference: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-entadmins
  16	Default AD Groups: Server Operators	This group is effectively “Domain Controller Admins” and members of this group should be scrutinized at a similar level to Domain Admins. This group has no default members. Default Rights: Default rights on Domain Controllers: ·         Log on locally ·         create and delete shared resources ·         start and stop some services ·         backup and restore files ·         format the hard disk ·         shut down the computer Reference: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-serveroperators
  17	Default AD Groups: Account Operators	This group has no default members. This group should remain empty. Default Rights: This group has rights to most objects in the domain (users, groups, computers, etc). Microsoft recommends this group remain empty. PowerShell Sample Code & Results: Get-ADGroupMember ‘Account Operators’ Reference https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-accountoperators
  18	Privileged Group: VMWare Admins	Many enterprises have “VMWare Admins” or other such groups.   Ensure that “admin” groups only contain admin accounts. Ensure that VMWare Admins follow privileged account best practices: ·         Use separate admin accounts ·         Use admin workstations ·         Passwords change about once a year
  19	Krbtgt Password Not Changed Recently The krbtgt account is the domain service account. This account is disabled but used for Kerberos Tickets. The password set when created & practically never changes. DC/AD backups contains the KRBTGT account password. If an attacker gains knowledge of this password, they can create Golden Tickets!	Change this password every year (DoD STIG requirement) Change after AD admins leave Reference: Krbtgt Account https://adsecurity.org/?p=483 Golden Ticket Attack https://adsecurity.org/?tag=goldenticket
  20	Kerberos Delegation Kerberos Delegation Types: Unconstrained: Impersonate users connecting to service to ANY Kerberos service. Constrained: Impersonate authenticated users connecting to service to SPECIFIC Kerberos services on servers. Constrained with Protocol Transition: Impersonate any user to SPECIFIC Kerberos services on servers. (aka “Kerberos Magic”) Resource-based Constrained Delegation: Enables delegation configured on the resource instead of the account	Set all AD Admin accounts to: “Account is sensitive and cannot be delegated” Add all AD Admin accounts to the “Protected Users” group (Windows 2012 R2 DCs). Ensure service accounts with Kerberos delegation have long, complex passwords (preferably group Managed Service Accounts). Remove delegation from accounts that don’t require it. Don’t use Domain Controller SPNs when delegating. Work to shift accounts with unconstrained delegation to constrained. Restrict & monitor who has the ability to configure Kerberos delegation.
  21	GPO Permissions: Review Owners Group Policy Objects (GPO) has owners which are able to change permissions. Typically when an account creates a GPO, the account that created has delegate modify rights and it is configured as the owner.	Ensure all GPO owners are set to Domain Admins or Enterprise Admins, especially GPOs linked to the domain root and Domain Controllers OU.
  22	Review Domain Permissions Domain permissions should be reviewed to ensure that configuration is appropriate. Security of the domain often depends on proper domain permissions.	Review domain root permissions with special attention paid to any non-default admin groups (Domain Admins, domain Administrators, Enterprise Admins, etc) with GenericAll (Full Control), WriteDACL (change permissions), write property (modify), and ExtendedRights. Ensure that the domain root owner is configured to Domain Admins or Enterprise Admins.
  23	Domain Controllers Running Old Versions Domain Controllers must be running Microsoft supported Windows versions. You can run all Windows Server 2012 R2 DCs even with older Windows Server versions in the domain (note that some testing to ensure Windows 2003/XP works with the new DCs, especially for SMB shares).   All DCs should be running a minimum of Windows Server 2012 R2, preferably 2016/2019. If all DCs are not running 2012 R2 with 2012R2 DFL, Protected Users group doesn’t have full domain protection.	All DCs should be running a minimum of Windows Server 2012 R2, preferably 2016/2019
  24	AD Forest Functional Level / Domain Functional Level Older than Domain Controller Operating System	Ensure all Domain Controllers are updated to Windows Server 2012 R2 (or newer) and set DFL/FFL to 2012 R2 (or newer). Change the domain level only after understanding all the implications!

The post Performing Active Directory Security Review appeared first on ADSploit.

When security and core infrastructure is involved, this is a dangerous space to take shortcuts. For example, consider a Windows centric environment. Most companies recognize the install base and huge potential customer base. But some companies lack the domain expertise. Not knowing the Microsoft ecosystem, and basically in the “fake it before you make it” phase, they may simply wrap a Linux tool with a UI. All’s good, right? Looks like a Windows app, but no need to invest in the cross training and support a new development platform. (An example of this is Manage Engine’s AD Tools).
For example, one might build an Active Directory management tool using Linux as the deployment platform. Simply run the application in a Linux VM supporting Windows workloads. But, while the products look like a Windows solution, from a security standpoint, it is a Linux solution, with Linux vulnerabilities, hiding this from management tools.
For most almost all enterprises, Active Directory holds the keys to the kingdom. As such, It will be highly telemetered and monitored. But, if these tools are not secure, neither is the Active Directory instance.

Recently, an exploit leveraging Log4J – an integral component to Apache – appeared as a zero day. This m Meanings if any product utilizing Log4J on your network has elevated permissions then – your core infrastructure, identities, credentials and defenses are potentially compromised.

If the product in question is a management tool, holds elevated credentials, or can control configuration and monitoring – immediate action is required. This requires going to the AD logs and log aggregators to perform the a thorough forensic investigation. Examine network logs and event logs. DO NOT USE ANY SUCH PRODUCT TO PERFORM THESE TASKS. Having a product that provides real time alerts of all changes to the Active Directory is essential for security, for instance CionSystems Active Directory Change alerter/notifier that has the ability trap ‘all’ changes and send real time alerts.
Once an intruder can access Active Directory at this level, the impact is potentially catastrophic. Via Accounts in Active Directory, and the products service accounts, the threat actor will likely have access to credentials used by network tools, intrusion detection, log aggregators, and other core infrastructure. They will also be able to cover their trail and inject hacking tools, such as MimiKatz, into the environment. A recent example of CVE-2021-44228 which pertains to vulnerabilities in Apache Log4j. This is something any customer using a vendor supplied VM should investigate, thoroughly.
Lastly, do not assume applying a vendor fix is all that is required. These attacks are usually tools used to potentiate APT’s (Advanced Persistent Threats). This means a fix needs to be combined with ongoing forensics, removal of problematic products, and retrospective log analysis.

Note: Since the initial writing of this paper in early December, the scope and impact of CVE-2021-44228 has become apparent. Threat actors are using this vulnerability to potentiate attacks, and it is proving surprisingly damaging. In particular, ZD has noted:

“The FBI’s cyber division has issued an alert warning enterprises using Zoho-owned ManageEngine’s Desktop Central that advanced attackers have been exploiting a flaw to install malware since late October.”
From: https://www.ic3.gov/Media/News/2021/211220.pdf

The post The dangers of vendor shortcuts! appeared first on ADSploit.

CionSystems’ Enterprise Identity and Governance Portal supports multiple, back-end, repositories:

• Active Directory
• AzureActive Directory
• Office 365
• Google Apps
• Sales Force

This facilitates a variety of use cases, including migration, credential synchronization, provisioning, self-service of users, mergers and federation. Enterprise Identity and Governance Portal can also interoperate with multiple Active Directory instances.

The post Enterprise Identity and Governance Suite appeared first on ADSploit.

Once the CSV file is ready. Now login to ADM pro as a administrator, go to AD Management menu, click on Group in left side menu and then click on Create Groups using CSV – Bulk in right side pane, Now follow the below screen shots to do the rest.

After importing the CSV file Check Create Exchange E-Mail address option, select the container and click on Create Group button

Now you can verify these new created group in Exchange Console as below.

The post Creating mailbox enabled distribution group using CSV in ADM Pro appeared first on ADSploit.

The post Enhancing Enterprise Value appeared first on ADSploit.

The post CionSystems – Reporter appeared first on ADSploit.

The post CionSystems – Recovery appeared first on ADSploit.

The post CionSystems – Change Notifier appeared first on ADSploit.

So, the application designer has disclosed that the solution for the web services being designed will involve the (1) need to authenticate; (2) need to determine levels of authorization; and (3) [by the way] need to have some personalized data be carried forward to the application. If you, as a the security architect involved in the security assessment process, are smart, you would have a security framework to meet these requirements. And if you are “lucky” the application designer will have aligned the requirements to the security framework. But, the reality is that even with an architecture supported by standards and guideline, convincing the application developers to follow it is another story.

Rather than take on the “creative conflict”, a discussion should be a convincing proposal that the information is in place to make it easier for the application developer to obtain the information through the use of the “architecture” than creating yet-another database. The proper manner is to bring value to the organization and enable the development process to be easier with the architecture. The key to bringing value is to have the information in the “best” place (here!), at the “best” time (now!) and with the “best” information (right!).

The application developer will be interested in two types of data to drive the application: the identity information and the application’s database. Identity Management as a service deals with the former (discussion of the security requirements and implications of the latter are to be discussed in future posts). Although there are multiple products out in the market that are label to perform identity management, it is more than just technology (the tool), it also involves people and processes. Information about a digital identity that is combed from multiple data sources and stored in other information stores is a result of a set of operational procedures (people, process, and technology) that manage the information flow.

Security for Identity Management involves a lot more than just Confidentiality, Integrity, Availability, so I prefer to use the Parkerian Hexad (elements of information security proposed by Donn B. Parker in his book “Fighting Computer Crime, A New Framework for Protecting Information,” [John Wiley & Sons, 1998].) to proposed how to make “here!”, “now!” and “right!” the feasible end result (goal) of a good identity management procedure. The core elements (six) lay out the parameters that, for the developers, make the choice of the architect’s vision of an identity information store of “digital identity” preferable to that of creating yet-another identity store through yet-another registration process:

1.  Confidentiality – not only will the process protect who has access to the data during the “managing” of the identity data from the data source of record into the identity information store (such as an “LDAP directory) but that the process that created data into the data source of record was also protected.

2.  Possession or control – the process by which the information is delivered from the data source of record to the identity information store is secured, similar to a “chain of custody,” is well understood and controlled.

3.  Integrity – the information itself is not compromised, being consistent with its intended state asserts the validity of the data.

4. Authenticity – the claim that the data is coming from an reliable source is the assertion that the information from the data source of record is valid and truthful is important to document so that the information may not be mis-used under false assumption. The ways that the management process can assert authenticity of the data will be discussed later.

5. Availability – the identity information store needs to be accessible to the application for it to be of any use. But, more importantly, the information that feeds into the identity information store must be accessible, and the rules as to how current the information is should be well understood.

6. Utility – the most important is the agreement that the data is useful and that it will meet all the requirements for authentication, authorization, and personalization without causing an excessive amount of overhead in processing time and development costs.

Contributed By:

Steve Primost CISSP, CISM
Information/Application Security Architect

The post Road Map for an Application/Software Security Architect (Part 6) appeared first on ADSploit.