Skip to content

Getting started with ROADrecon

Dirk-jan edited this page Nov 23, 2022 · 4 revisions

ROADrecon is a tool for exploring Azure AD environments. To allow for full flexibility, the tool uses 3 simple steps to do this:

  1. Authentication
  2. Data gathering
  3. Data exploration or conversion
usage: roadrecon [-h] {auth,gather,dump,gui,plugin} ...

ROADrecon - The Azure AD exploration tool.
By @_dirkjan - dirkjanm.io

To get started, use one of the subcommands. Each command has a help feature (roadrecon <command> -h).

1. Authenticate to Azure AD
roadrecon auth <options>

2. Gather all information
roadrecon gather <options>

3. Explore the data or export it to a specific format using a plugin
roadrecon gui
roadrecon plugin -h

Authentication

The first step is authentication. There are several authentication methods supported by ROADrecon, which are technically offered by roadlib, the library component of ROADtools.

Username and password

The simplest form of authentication is with only a username and password. To use this, supply both the username and password on the command line.

roadrecon auth -u user@mytenant.onmicrosoft.com -p Passwordhere

The downside of this method is that it uses the legacy password authentication grant to authenticate, which does not support Multi Factor Authentication. Thus if the account requires MFA, or a Conditional Access policy requires MFA, this will fail. If you have legitimate possession of an account, the easiest way to satisfy this is the device code flow.

Device code flow

The Device Code flow gives you a code that can be used on the Microsoft login page in your webbrowser to sign in interactively. This will prompt you for MFA if applicable. To start this flow, you only need to specify the --device-code parameter. You can then provide your credentials in the browser.

roadrecon auth --device-code
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXXX to authenticate.

After you successfully logged in, the authentication flow in the app is complete.

Using a PRT cookie

If you have code execution on a target (or maybe even your own laptop) that is Azure AD joined/registered or Hybrid joined, you can use Single Sign On to authenticate. The reasoning behind this is described in this blog. First you need to initialize the SSO flow with roadrecon and the --prt-init flag. This will provide you with a nonce:

roadrecon auth --prt-init
Requested nonce from server to use with ROADtoken: AQABAAAAAAB2UyzwtQEKR7-rWbgdcBZIJ3LUNT8vP0ZW8dI8AB3zTVy1r1rTFR35qK3ds4Kfcv7FQFMTcHiL6cSofh1eODwInaebcwNsnrrQQr8n-xCFaSAA

This nonce can be provided to ROADtoken to request a PRT cookie. Once you have the PRT cookie, you can complete the sign-in with roadrecon:

roadrecon auth --prt-cookie COOKIE_FROM_ROADTOKEN_GOES_HERE

Using a stolen PRT from mimikatz

You can also use a stolen PRT that you extracted from LSASS memory using mimikatz. The background is described in this blog. You can get the PRT itself with sekurlsa::cloudap, and then decrypt the encrypted session key (ProofOfPossesionKey) with dpapi::cloudapkd /keyvalue:KeyValue_of_ProofOfPossesionKey /unprotect in SYSTEM context, which will give you the plain session key (called Clear key in mimikatz) if there is no TPM protection present. If there is TPM protection you cannot steal the PRT but only derive keys on-demand (use the SSO flow above for the PRT cookie). To use the PRT with roadrecon, you can use the authentication module with the --prt and --prt-sessionkey:

roadrecon auth --prt 0.AXQAj_KHYn9PIkOW<snip>EZVMTmYw8MfeZ7pc --prt-sessionkey 22d31fd0117cbb6a7de<snip>beb0c5cf029a7f63

Direct access/refresh token

If you want to authenticate with an access token or a refresh token of the Azure AD Graph directly, you can supply those with the --access-token or --refresh-token manually. You should take care using this method that the tokens belong to the correct application. Additionally, Access Tokens are by default only valid for one hour. This means that if you will collect data later on in a larger tenant, there is a good chance the token will already be expired before data collection is complete.

Data gathering

After the authentication is complete, the resulting access and refresh tokens will be written to .roadtools_auth. You can now run the roadrecon gather command which will collect all the data. This may take a while in larger environments. Sometimes messages may pop up regarding references it cannot find. This does not mean that data collection was unsuccessful, it simply means that not all references could be resolved so some object relationships may be incomplete.

If you want to collect MFA information, make sure you have an account with a privileged Azure AD role (such as Global Reader / Security Reader or above) and use the --mfa flag. In smaller tenants it may work without this flag.

Using the data

After the data has been collected, it all resides in the database (file) that was created. By default this will be roadrecon.db. To explore this data, you can launch the GUI with roadrecon gui. Alternatively you can launch a plugin to process the data, you can list the plugins and request their options with the -h switch:

roadrecon plugin -h
usage: roadrecon plugin [-h] {policies,bloodhound} ...

positional arguments:
  {policies,bloodhound}
    policies            Parse conditional access policies
    bloodhound          Export Azure AD data to a custom BloodHound version
roadrecon plugin policies -h
usage: roadrecon plugin policies [-h] [-d DATABASE] [-f FILE] [-p]

Parse Conditional Access policies and export those to a file called caps.html

optional arguments:
  -h, --help            show this help message and exit
  -d DATABASE, --database DATABASE
                        Database file. Can be the local database name for SQLite, or an SQLAlchemy compatible URL such
                        as postgresql+psycopg2://dirkjan@/roadtools
  -f FILE, --file FILE  Output file (default: caps.html)
  -p, --print           Also print details to the console