Listen to this Post
Introduction:
The recent AWS policy update explicitly prohibiting pentesting activities through its API Gateway has sent shockwaves through the offensive security community, rendering tools like the popular TeamFiltration utility temporarily obsolete. In response, security researchers have swiftly forked the project, creating a modified version that bypasses the defunct FireProx method, ensuring red teams can continue to assess the resilience of M365 and Azure AD environments against password spray and credential stuffing attacks. This evolution highlights the perpetual cat-and-mouse game between cloud providers and security professionals, demanding constant adaptation of tools and techniques.
Learning Objectives:
- Understand the impact of AWS’s API Gateway policy change on offensive security tooling.
- Learn how to configure and use the forked TeamFiltration version with alternative proxy providers.
- Master the commands and methodologies for executing effective password spray attacks while maintaining operational stealth.
You Should Know:
- The Death of FireProx and the Rise of Alternative Proxies
The original TeamFiltration tool relied on FireProx, a tool that programmatically created AWS API Gateways to generate a rotating pool of IP addresses for evading detection. With AWS now blocking this activity, the forked version removes FireProx entirely, allowing operators to specify any HTTP proxy in the configuration file.
Step-by-Step Guide:
First, clone the forked repository and install its dependencies.
git clone https://github.com/S3cur3Th1sSh1t/TeamFiltration cd TeamFiltration pip3 install -r requirements.txt
Next, you must edit the `config.json` file. Locate the `proxy` section and replace it with your preferred proxy service. For example, using a static proxy:
"proxy": {
"url": "http://your-proxy-ip:8080",
"username": "your_username",
"password": "your_password"
}
This configuration directs all of TeamFiltration’s web requests through your specified proxy, masking the source IP and bypassing the need for AWS’s API Gateway.
2. Configuring TeamFiltration for a Stealthy Password Spray
A password spray attack tests a few common passwords against a large number of usernames, a technique that is effective but easily blocked without proper obfuscation.
Step-by-Step Guide:
Prepare a list of target usernames (usernames.txt) and a shortlist of common passwords (passwords.txt). The key is to use a long delay between authentication attempts to avoid triggering account lockout policies.
Run the spray using the following command:
python3 teamfiltration.py spray -u usernames.txt -p passwords.txt --delay 1200 -d yourdomain.com --proxy
– spray: Invokes the password spray module.
– -u usernames.txt: Specifies the file containing target usernames.
– -p passwords.txt: Specifies the file containing passwords to spray.
– --delay 1200: Sets a 20-minute (1200-second) delay between each login attempt per IP to evade lockout thresholds.
– -d yourdomain.com: Defines the target domain.
– --proxy: Ensures the tool uses the proxy defined in your `config.json` file.
3. Enumerating Valid Usernames with OData
Before spraying, you often need to enumerate valid usernames. TeamFiltration can leverage Microsoft’s OData API for this purpose.
Step-by-Step Guide:
The tool can query endpoints like https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/@.onmicrosoft.com?Protocol=Autodiscoverv1` to validate email addresses. Use the enumerate module:
python3 teamfiltration.py enumerate -d yourdomain.com -o enumerated_users.txt --proxy
This command will probe a list of potential usernames against various Microsoft services, outputting a list of valid accounts toenumerated_users.txt`. The `–proxy` flag is crucial here to avoid having your reconnaissance IP blocked by Microsoft’s security systems.
4. Windows Command for Proxy Configuration Validation
Before running TeamFiltration, ensure your proxy is working correctly from your operational machine. You can use a simple cURL command in Windows or Linux to verify.
Step-by-Step Guide:
Open a command prompt or terminal and run:
curl -x http://your-proxy-ip:8080 -U your_username:your_password http://ifconfig.me
– -x http://your-proxy-ip:8080`: Specifies the proxy server.-U your_username:your_password
-: Provides proxy authentication credentials.http://ifconfig.me`: A service that returns the external IP address making the request.
-
This command should return the IP address of your proxy, not your local machine’s IP, confirming that your traffic is being routed correctly.
- Hardening Your Linux Server to Host a Proxy
If you are deploying your own proxy server, hardening the underlying Linux OS is a critical first step.
Step-by-Step Guide:
Update the system and install a minimal proxy server like Squid.
sudo apt update && sudo apt upgrade -y sudo apt install squid -y
Configure the firewall to allow only necessary traffic and block everything else.
sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow ssh sudo ufw allow 3128/tcp Squid proxy default port sudo ufw --force enable
Edit the Squid configuration file `/etc/squid/squid.conf` to set up authentication and restrict access to your IP only, significantly reducing the attack surface.
6. Exploiting Weak MFA Policies
TeamFiltration can also be used in scenarios where Multi-Factor Authentication (MFA) is not enforced or is poorly implemented, such as with “MFA Fatigue” attacks.
Step-by-Step Guide:
If you discover an account with a weak MFA policy (e.g., push notifications without number matching), you can combine the spray with a high volume of attempts. A custom script could be used to automate this, but the core principle remains: target accounts without conditional access policies that require strong MFA. The command is the same as a standard spray, but the success rate hinges on the target’s MFA configuration being vulnerable to spamming approval requests.
7. Analyzing Logs for Incident Response
From a blue team perspective, understanding this attack vector is key to defense. The following KQL query for Azure Sentinel can help identify potential password spray activities originating from a single IP against multiple user accounts.
Step-by-Step Guide:
SigninLogs | where ResultType == "50057" // User account is disabled or ResultType == "50126" // Invalid username or password | summarize AttemptCount = count(), DistinctUsers = dcount(UserPrincipalName) by IPAddress, bin(TimeGenerated, 1h) | where DistinctUsers > 5 and AttemptCount > 10 | project TimeGenerated, IPAddress, AttemptCount, DistinctUsers
This query looks for a high number of failed sign-in attempts (ResultType 50126) from a single IP address across a large number of distinct users within a one-hour window, which is a classic signature of a password spray attack.
What Undercode Say:
- The agility of the offensive security community is its greatest asset, as demonstrated by the rapid fork and adaptation of TeamFiltration within hours of the AWS policy change.
- Cloud providers are increasingly acting as security gatekeepers, actively monitoring and shutting down infrastructure used for pentesting within their terms of service, forcing a re-evaluation of operational infrastructure.
This swift adaptation signifies a broader trend in cybersecurity: the democratization of advanced tradecraft. When a major tool is neutered by a platform policy, the community collaboratively finds a path forward, often within days. This fork is not just a patch; it’s a statement. It proves that reliance on a single cloud provider’s specific service (FireProx/AWS API Gateway) was a single point of failure. The new model—supporting any configurable proxy—is more resilient and versatile, allowing operators to use a multitude of proxy-as-a-service providers or their own infrastructure. This event forces both red and blue teams to think more critically about the underlying infrastructure of their tools and the log artifacts they leave behind. For defenders, the takeaway is that the absence of FireProx-related indicators does not mean the absence of a TeamFiltration-style attack; they must now look for anomalies related to a wider array of proxy services.
Prediction:
The forced pivot from FireProx will accelerate the development and adoption of more decentralized, resilient proxy networks for offensive security, potentially leveraging peer-to-peer technologies, blockchain-based anonymization layers, or a rotating pool of residential IPs. This will make attacks harder to attribute and block based on simple IP reputation, pushing defenders to rely more heavily on behavioral analytics and strict conditional access policies that enforce MFA universally, rather than trying to blacklist the ever-changing infrastructure of attackers. The cat-and-mouse game is entering a new, more complex phase.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Activity 7386681631589281793 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
