Active Directory (Part 6)

By Ashwin Venugopal -

 






Basics

Authentication Methods

There are many authentication methods in an AD environment to verify the identity of a user or a computer. The most common method is password authentication method and every penetration tester must have knowledge of them to take advantage of their features and pivot through the network.

Kerberos authentication is a default protocol in the latest Windows versions. If a user logs in to a service via Kerberos, they get a ticket as a proof of their previous authentication. After that, the tickets can be shown to a service, as an authentication proof, to allow further access. Hence, the tester can attack Kerberos to gain unauthorized access. Some of the most common types of attacks are:

  • Brute force attack- Here, the attacker tries to guess the password of a user account or a service account in the AD domain and use it to authenticate to the domain using Kerberos. It can be done with the help of an automatic tool that allows the trying of different password combinations.

  • Ticket forging- An attacker can also try to forge a Kerberos ticket, in order to gain access the AD domain resources. It can be achieved by either modifying a ticket or using a tool to generate a fake ticket.

  • Golden ticket attack- A stolen Kerberos ticket-granting ticket (TGT) can be used to create a "golden ticket." This ticket will allow them to authenticate many users in AD domain. This thing can achieved via tools like Mimikatz. 

  • Kerberoasting- The attacker may try to exploit weak or default passwords of the service accounts in AD domain. It is done to obtain the service account's Kerberos ticket-granting service (TGS) ticket. This helps in gaining access to the resources or services that the service account has access to. 

NTLM is another way of gaining access in an AD domain. However, it supports different but equally devastating types of attacks, in regard to Kerberos. Penetration tester can attempt following NTLM attacks:

  • Brute force attack- Same as Kerberos.

  • Pass-the-hash attack- A stolen NTLM hash is a cryptographic representation of a password that can be used for authentication in AD domain without knowing the actual password. An attacker can use it with the help of tools like Mimikatz. 

  • NTLM relay attack- A compromised system in the AD domain can be exploited by an attacker to relay NTLM authentication requests to other systems, allowing potential access to the attacker in those systems. Tools like Responder can be used to achieve this.

  • NTLM downgrade attack- A system can be forced to use NTLM instead of a more secure authentication method, such as Kerberos, by manipulating the system's network configuration or using a tool like Mimikatz.

It is highly important to properly secure and manage both Kerberos and NTLM authentication protocols in an AD domain to prevent such attacks. This can be done setting strong passwords for all accounts, regularly rotating and reviewing passwords, and monitoring suspicious activities for Kerberos. For NTLM, administrators should disable it completely when not in use and monitor suspicious activities. However, using more secure authentication protocol, like Kerberos, is strongly recommended. 

Conclusion

This part concludes the basics of Active directory and talks about various authentication methods, attacks, and prevention methods. 






















Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more