Attacking and Defending Active Directory Part I

Introduction

Microsoft Active Directory is one of the most interesting services to attack since we can gather a lot of information just by checking if the server is misconfigured which enables us to enumerate treasure trove of information like Domain Users, Administrative Shares, Password Policies and many more.

In this series, I will be separating this into three parts. The first part will include the introduction of Active Directory and its components.

The second part will include different types of attacks against Active Directory and the demonstration on how to execute these attacks.

And lastly, we’ll be covering different approaches in defending and reducing attack surfaces of Active Directory.

What is Active Directory?

Active Directory or AD is a centralized Windows OS directory service that stores information about objects on the network and automates the management of user data, security, and distributed resources.

Active Directory Components

Just to give you an overview of the different components of Active Directory, the Active Directory consists of:

  • Domains
  • Forests
  • Sites
  • Domain Controllers
  • Organizational Units (OU)

Each of these components has their own purpose that enables Active Directory to function within an organization.

I will just summarize the meanings and functions of these components but you can read more about Active Directory on the official documentation of Microsoft.

Domains

Active Directory domains are where the users and computers are located. Each domain holds a database that contains the information of an object’s identity.

For example, I have an AD domain called internal.anotsodev.org. This domain contains all the information of users and computers joined in this domain.

Forests

Active Directory forests are the topmost logical containers of the hierarchy. The illustration below shows the organizational domain forest model of internal.anotsodev.org.

Sites

Active Directory Domain Sites enables the users to authenticate with the nearest domain controller and provides domain preference either administrative or least privilege to the current logged in user.

Sites are organized by one or more IP subnets based on the geographic location of the domain users joined to a domain.

Domain Controllers

Active Directory Domain Controllers handles authentication requests and verifies users if they have access to domain resources. Domain Users’ preference and permissions are defined via group policy set to the Domain Controller.

Organizational Unit (OU)

An organizational unit (OU) is a subdivision within an Active Directory into which you can place users, groups, computers, and other organizational units. You can create organizational units to mirror your organization’s functional or business structure. Each domain can implement its own organizational unit hierarchy. If your organization contains several domains, you can create organizational unit structures in each domain that are independent of the structures in the other domains.


So that ends the first part of the “Attacking and Defending Active Directory” series.

I will be posting the second part of this series which is the actual attacks that are being used against active directories next week.

Stay tuned and be safe!

References:


Subscribe for more!

To stay up to date with my latest posts and more InfoSec guides, make sure to subscribe to this blog by entering your email address below.

I promise I won’t be spamming your mailbox. Because no one loves spam. AMIRIGHT?

Poor man’s log collection on Windows

Introduction

As your organization grows, a lot more log collectors either commercial or freeware are needed to be installed on your network to get logs from different servers running on Windows or *nix.

Let’s say for example this organization called kyle.biz has implemented Arcsight SmartConnectors deployed on Linux servers to get event logs on Windows. And based on my experience, setting up the SmartConnectors is tedious and maintaining them is sometimes a pain.

The limitations were also realized since SmartConnector only gets logs on the server static IPs configured during the installation so there is no way we’ll get the logs from other machines that have dynamic IPs.

Upon research, our team has stumbled upon this article from Microsoft’s documentation page and saw that Windows has already built-in log forwarding feature which is powerful and easy to configure!

So without further ado, let’s now configure the Source Initiated WEC and WEF on our servers! 

Prerequisites

Windows Event Collector

  • OS: Windows Server 2016 
  • Hostname: WEC01.internal.kyle.biz
  • RAM: 16GB
  • CPU: 4 Cores
  • Storage:
    • Drive C:\ – 50GB
    • Drive D:\ – 60GB (we’ll save our forwarded logs here)
  • Joined in a domain.

Windows Event Source

  • OS: Windows Server 2016
  • Hostname: CONSOLESERVER01.internal.kyle.biz
  • Joined in a domain.

WEC Server Configuration

On the following steps, we’ll be configuring our collector server to receive logs which will be initiated by source computers.

Step 1: Open the Event Viewer and click the Subscription.

Step 2: Right-click the Subscription to create a new Subscription. You can also see other actions on the right pane of the window.

Step 3: Enter the subscription name and select the subscription type as Source computer initiated.

Before we proceed in adding computer groups, let’s first configure the events to collect and advanced settings.

Step 4: Click the Select Events then click the manual edit/XML tab then copy the XML format query here: Appendix E – Annotated baseline subscription event query

Step 5: Click OK

Step 6: Click the Advanced Settings then select Minimize Latency.

Step 7: Click OK

Step 8: We’ll now add our domain computers by clicking Select Computer Groups.

Step 9: Since we are joined in a domain, click Add Domain Computers then search for the hostname of the event source. (Ex: CONSOLESERVER01.internal.kyle.biz)

Step 10: Click OK

Step 11: Right-click the Forwarded Events then click on properties

Step 12: Create folder Winenvt\Logs on drive D:\ then replace the log path by entering D:\Winevt\Logs\ForwardedEvents.evtx or refer to the screenshot below.

Event Source Configuration

On the following steps, we’ll be configuring the source computers to forward logs to our collector server.

Step 1: Let’s now configure our event source server machine to point the SubscriptionManagers to our WEC.

Step 2: Open the Local Group Policy then click the Event Forwarding to see the items under that directory.

Step 3: Click the Configure target Subscription Manager and enter on the value

"Server=http://WEC01.internal.kyle.biz.org:5985/wsman/SubscriptionManager/WEC,Refresh=60"

Step 4: Click OK

Step 5: Open Command Prompt then enter gpudate /force to apply the modification in our local group policy.

Step 6: Press Enter

Step 7: Go back to the WEC server then check if the Baseline events already getting logs from our event source machine.

Step 8: We can already see that the events are already forwarded and ready to use for analysis.

So that’s it! I hope you learned something new today and I hope you’ll be using this example to reduce the gap and have greater visibility on your network.

References:


Subscribe for more!

To stay up to date with my latest posts and more InfoSec guides, make sure to subscribe to this blog by entering your email address below.

I promise I won’t be spamming your mailbox. Because no one loves spam. AMIRIGHT?