Active Directory ACL Visualizer and Explorer

Active Directory security is notoriously difficult. Small organizations generally have no idea what they're doing, and way too many people are just added to Domain Admins. In large organizations you have a huge number of people with different needs, and they are delegated access to varying degrees of power in the AD. At some point in time, someone makes a mistake, and that can cost you dearly.

Adalanche is an all-in-one binary - it collects information from Active Directory or from local Windows machines and can the analyze the collected data. If you're only doing AD analysis, just grab the binary for your preferred platform. Later you can deploy the dedicated collector .exe for your Windows member machines via a GPO or other orchestration and get even more insight.

You have three options to get Adalanche up and running on your system:

Download either the latest release or recent development build. Usually running with the latest development build is fine, but there might be a problem here and there. Releases are considered stable and are for the less adventurous.

If you prefer full control, you can roll your own on any supported platform (Windows, MacOS, Linux):

• Prerequisites: Go 1.23, PowerShell 7, git
• git clone https://github.com/lkarlslund/Adalanche Adalanche
• cd Adalanche
• ./build.ps1

Resulting binaries are available in the 'binaries' subfolder.

You can also purchase a commercial version of Adalanche from NetSection which is a signed binary on the Windows platform.

You can either use some sample data to just play around, or you can collect data from a real Active Directory domain.

If you're not keen on running foreign tools against your Active Directory, there are sample data available in this repository.

If you're running Adalanche on a Windows domain joined machine should just work without any parameters, as Adalanche tries to autodetect as much as it can. Under this scenario, and with parameters given, you will run in a collect-analyze mode (collect from Active Directory, then analyze).

For more advanced use (recommended) first collect, with proper options. All your data files (are belong to us), and will end up in the data subfolder (or use --datapath dir to use an alternative folder).

See program options for other possibilities (help or command --help).

Some options are global options (they need to come before the command) and other are command specific (and need to come after the command). Logging, profiling, setting the datapath etc. are global options. Use "--help" to figure it out :-)

The primary source of data is from Active Directory, and is intiated with this command:

adalanche collect activedirectory [--options ...]

Windows versions of Adalanche will default to using the native Windows LDAP library to connect to Active Directory, while non Windows version will use the multiplatform LDAP library. You can force Adalanche on Windows to use the multiplatform library with the --nativeldap=false option - this allows you to use a hash as a password and also to use a kerberos cache file for authentication.

If you're on a non-domain joined Windows machine or another OS, you'll need at least the --domain parameter, as well as username and password (you'll be prompted for password if Adalanche needs it and you didn't provide it on command line - beware of SysMon or other command line logging tools that might capture your password).

LDAP (unencrypted port 389) is default. You can switch to TLS (port 636) with --tlsmode tls option.

Example to create data files file for contoso.local coming from your Linux pwnage box using TLS port 636, ignoring certs and using NTLM auth:

adalanche collect activedirectory --tlsmode tls --ignorecert --domain contoso.local --authdomain CONTOSO --username joe --password Hunter42

From domain joined Windows member using current user:

adalanche collect activedirectory

From domain joined Windows machine using other credentials than logged in:

adalanche collect activedirectory --authmode ntlm --username joe --password Hunter42

There are more options available, for instance on what LDAP contexts to collect, whether to collect GPOs or not etc. Please be aware that you can collect GPOs from Linux by mounting sysvol locally and pointing Adalanche to this path for GPO collection - but you will lose ACL analysis for the individual files.

• Wrong credentials (username/password) "LDAP Result Code 49 "Invalid Credentials": 8009030C: LdapErr: DSID-0C0906B5, comment: AcceptSecurityContext error, data 52e, v4563" You've entered wrong credentials or the account is blocked.

• Channel binding requirements "LDAP Result Code 49 "Invalid Credentials": 80090346: LdapErr: DSID-0C0906B5, comment: AcceptSecurityContext error, data 80090346, v4563" This is a "Channel Binding" requirement for SSL enabled connections over LDAP, as part of Microsofts hardening efforts on making LDAP more secure. This is currently unsupported by Adalanche on non Windows platforms due to LDAP library limitations - try running the collection from a Windows machine.

The SysInternals AD Explorer (adexplorer64.exe) is an enhanced GUI application that allows you to poke around in all objects and see all attributes. It also leverages the Windows LDAP library (just like Users & Computers etc.), and might be an option if you're not allowed to run Adalanche directly due to security concerns. By utilizing the "snapshot" feature, it allows you do dump the entire AD into a proprietary file, which Adalanche can ingest as an alternative to talking directly to LDAP.

The procedure for using AD Explorer as a data source is:

• Launch 'adexplorer64.exe'
• Connect to your domain, for simple setups you can just leave all fields blank and press connect
• Choose File | Create snapshot ... and save the file somewhere. There is no progress indicator, so just have patience
• Run Adalanche to collect Active Directory object and GPO data: adalanche collect activedirectory --adexplorerfile=yoursavedfile.bin

If you can't reach GPOs from where you're importing, you can either disable GPO imports --gpos=false or copy the Group Policy folder from SYSVOL and point to that with --gpopath=your-copied-GPO-folder, but you'll lose ACL analysis for the individual GPO files.

You will then have compressed AD data (and potentially GPO data) in your datapath like a normal collection run. You can delete the AD Explorer data file now, as this is converted into Adalanche native format, and you can now run analysis mode.

For Windows systems that are members of your Active Directory domain (or standalone) you can collect more information from the local machines. This can be done using the Windows versions of the Adalanche binaries, or by using the stripped down versions that only provide the ability to collect from local machines, but not do anything else.

The 32-bit Windows version of the collector works transparently also on 64-bit systems.

The idea is that you orchestrate it centraliy with a Scheduled Task via a GPO or whatever means you see fit (psexec, login script etc). The collector will get more information if it is run with elevated privileges, but can provide parital information when run as an unpriviliged user.

adalanche-collector --datapath \\some\share\where\youcanwrite\butnotread collect localmachine

You can run the local machine collector from the full Adalanche binary too, the commands are identical.

Please remember to secure your collection repository UNC path, so member machines can only create/write/modify files, but not read from them. Only you - the analyst - should be able to do so.

The files will automatically be imported into Adalanche when you run it, if they're part of your datapath (in a subfolder or just copied in - whatever works for you)

This will give you insight into who uses what systems, service accounts that are domain users, autoadminlogins, who are local admins, who can RDP into systems and more fun stuff later on :-)

This is dead simple - everything you've collected should be in the data directory, either in the main folder or in subfolders.

Whatever resides there and Adalanche understands is automatically loaded, correlated and used. It's totally magic.

IMPORTANT: If you're doing multi domain analysis, place all AD object and GPO files for each domain in their own subfolder, so Adalanche can figure out what to merge and what NOT to merge. When dumping just point to a new --datapath for collection run (example: adalanche --datapath=data/domain1 collect activedirectory --domain=domain1)

These extensions are recognized:

• .localmachine.json - Windows collector data
• .gpodata.json - Active Directory GPO data
• .objects.msgp.lz4 - Active Directory object/schema data in MsgPack format (LZ4 compressed)

Highly advanced command line to analyze and launch your browser:

adalanche analyze

There are some options here as well - try adalanche analyze --help

When launched, you'll see some statistics on what's loaded into memory and how many edges are detected between objects. Don't worry, Adalanche can handle millions of objects and edges, if you have enough RAM ;)

The pre-loaded query allows you to see who can pwn "Administrators", "Domain Admins" and "Enterprise Admins". Query target nodes are marked with RED.

Press the "analyze" button in the query interface to get the results displayed. If you get a lot of objects on this one, congratz, you're running a pwnshop.

Depending on whether you're over or underwhelmed by the results, you can do adjustments or other searches.

To ease the learning experience, there are a number of sample queries built into Adalanche. You access these by pressing the "Sample queries" button, and choosing one. This should give you some idea of how to do queries.

Query direction:

• In "incoming" mode you select target nodes, and Adalanche figures out who can reach these target nodes (most common search)
• In "outgoing" mode you select target nodes, and Adalanche figures out what impact they have (like what can "Domain Users" do?)

If your query returns more than 2500 objects (default), Adalanche will limit the output and give you the results that fit within the limit. This limitation is because it has the potential to crash your browser, and is not an Adalanche restriction - feel free to adjust as needed.

Remember, you might get too many results. Limit the selection of target nodes with (&(attribute=something)(_limit<10)) to just get the first 10 target nodes (see LDAP queries below)

The "Prune island nodes" option removes nodes that have no edges from the results.

Analysis depth allows you do limit how many edges from the target selection is returned. Setting this to 0 will only result in the query targets (don't prune islands here, otherwise you'll get nothing), setting it to 1 results on only neighbouring edges to be returned. Quite useful if you get too much data back, blank is no restrictions.

Max outgoing edges limits how many outgoing edges are allowed from an object, and can help limit results for groups and objects that have many assignments. Adalanche tries it best to limit this in a logical way.

Each edge has a probability of success, and you can limit the graph by choosing the minimum probability per edge or overall/accumulated probability of current edge.

Press the "Edges" tab to allow you to do edge based filtering.

FML is not the usual abbreviation, but represents First, Middle and Last. Disabling the "Middle" selector, will also prevent "Last" in the results, unless it's picked up as the "First" due to the way the search is done.

This works the same way as the "Edges" limiter above.

When you press the "LDAP Query" tab on the bottom portion of the page, and you get the search interface:

You enter a query for things you want to search for, with the "start query" setting your targets. Optionally you can also add a secondary query the following nodes must match. If you put a filter in the "end query" then nodes not matching this will be removed from the outer objects (end of graph).

Adalanche works a bit differently than other tools, as it dumps everything it can from an Active Directory server, which it then saves to a highly compressed binary cache files for later use. This dump can be done by any unprivileged user, unless the Active Directory has been hardened to prevent this (rare).

If you collect GPOs I recommend using a Domain Admin account, as GPOs are often restricted to apply only to certain computers, and regular users can't read the files. This will limit the results that could have been gathered from GPOs.

The analysis phase is done on all collected data files, so you do not have to be connected to the systems when doing analysis. This way you can explore different scenarios, and ask questions not easily answered otherwise.

The tool works like an interactive map in your browser, and defaults to a ldap search query that shows you how to become "Domain Admin" or "Enterprise Admin" (i.e. member of said group or takeover of an account which is either a direct or indirect member of these groups).

The tool has its own LDAP query parser, and makes it easy to search for other objects to take over, by using a familiar search language.

The queries support:

• case insensitive matching for all attribute names
• checking whether an attribute exists using asterisk syntax (member=*)
• case insensitive matching for string values using equality (=)
• integer comparison using <, <=, > and >= operators
• glob search using equality if search value includes ? or *
• case sensitive regexp search using equality if search value is enclosed in forward slashes: (name=/^Sir.*Mix.*lot$/ (can be made case insensitive with /(?i)pattern/ flags, see https://github.com/google/re2/wiki/Syntax)
• extensible match: 1.2.840.113556.1.4.803 (you can also use :and:) LDAP_MATCHING_RULE_BIT_AND
• extensible match: 1.2.840.113556.1.4.804 (you can also use :or:) LDAP_MATCHING_RULE_BIT_OR
• extensible match: 1.2.840.113556.1.4.1941 (you can also use :dnchain:) LDAP_MATCHING_RULE_IN_CHAIN
• custom extensible match: count - returns number of attribute values (member:count:>20 gives groups with more members than 20)
• custom extensible match: length - matches on length of attribute values (name:length:>20 gives you objects with long names)
• custom extensible match: since - parses the attribute as a timestamp and your value as a duration - pwdLastSet:since:<-6Y5M4D3h2m1s (pawLastSet is less than the time 6 years, 5 months, 4 days, 3 hours, 2 minutes and 1 second ago - or just pass an integer that represents seconds directly)
• synthetic attribute: _limit (_limit=10) returns true on the first 10 hits, false on the rest giving you a max output of 10 items
• synthetic attribute: _random100 (_random100<10) allows you to return a random percentage of results (&(type=Person)(_random100<1)) gives you 1% of users
• synthetic attribute: out - allows you to select objects based on what they can pwn directly (&(type=Group)(_canpwn=ResetPassword)) gives you all groups that are assigned the reset password right
• synthetic attribute: in - allows you to select objects based on how they can be pwned directly (&(type=Person)(_pwnable=ResetPassword)) gives you all users that can have their password reset
• glob matching on the attribute name - searching for (*name=something) is possible - also just * to search all attributes
• custom extensible match: timediff - allows you to search for accounts not in use or password changes relative to other attributes - e.g. lastLogonTimestamp:timediff(pwdLastSet):>6M finds all objects where the lastLogonTimestamp is 6 months or more recent than pwdLastSet
• custom extensible match: caseExactMatch - switches text searches (exact, glob) to case sensitive mode

This list is not exhaustive.

There is a right click menu on objects, so you can to searches in the displayed graph. First right click a target:

Then find a source to trace from:

If there's a connection from source to target, you'll get the entire attack path presented like this:

You can also pick any object on the graph, and perform an inbound or outbound search from it.

• A large AD with 500.000 objects results in a file approximately 250MB in size, but much larger ADs work fine too, just add more hardware
• Adalanche requires a reasonable amount of memory - loading and analyzing the above AD will use about 2.5GB RAM - but RAM is cheap, getting pwned is not
• There are probably mistakes, false positives and stuff I've overlooked. Feedback is welcome!
• There is an unsolved challenge with services that require multiple ACLs to pass (for instance Cert servers only lets members of "Users that can enroll" group use enrollment, while the Certificate Template lets "Domain Users" enroll - this looks like "Domain Users" can enroll to Adalanche). The same problem arises with fileshares, so this analysis is not done yet.

If you need inspiration on how to use a detected attack path I can highly recommend that you take a look at both the PayloadsAllTheThings Active Directory and HackTricks Active Directory Methodology sites.

Commercial editions with improved functionality are available for purchase from NetSection. This is what funds the open source edition.

Feedback is welcome -> Mastodon @lkarlslund / Twitter @lkarlslund / LinkedIn Lars Karlslund