We have got intelligence that one our developers at Ack-Me Corp is working on a weekend side-project where he is vibe coding an internal knowledge-base chatbot for our company, where he put all of our customer records and sensitive data inside it.

Your mission, if you choose to accept it - is to track down the website and obtain the secret flag.

Start by investigating ackme-corp.net online presence and dig deep into their infrastructure, this includes going beyond the scope of the shell.

Starting off we need to do initial reconnaissance against the provided domain ackme-corp.net, making note of the phrase online presence to look through specifically either social media or adjacent website. We can eventually find a repository on GitHub where this domain is present using the website's search:

Looking through this GitHub project, theres a few things going on. First, there is a GitHub pages deployment with interesting subdomains. The page itself doesn't have anything interesting currently.

In the version control change history of the CNAME file we can see several previous domains in past versions in this order from older to new:

docs.staging.chase.io

This is not live and no snapshots were found.

sphinxdocs.pyansys.co

This is not live and no snapshots were found.

morpheus-docs.dev.vtg.paramount.tech

In March of this year this hosted the same content as the current GitHub pages deployment. The

testing.internal.hacme-corp.net

First interesting thing I found related to this domain was the subdomains specified in the certificate for the domain:

Specifically we can see the domain vibe.coding.internal.test.hacme-corp.net, which seems related to the challenge description. Unfortunately this is no longer live, but in Recorded Future we can actually see that this webpage snapshot was archived a few days prior that we can look at.

The only pivot I can really find here is vibecodeawebsitetoday.com, which we will talk about shortly. I don't actually think that this was an intended clue in the challenge however, and it highlights the different forms of recon and enumeration we can do with the right tools. I'll ignore this to find the intended solve for now.

testing.internal.ackme-corp.com

This didn't really have anything interesting as well in my research, but it's interesting this has the same subdomains as the current domain hosted in GitLab pages.

Enumerating subdomains

So in this challenge, many of the domains present have wildcard subdomains in their certifications, pointing towards the possibility that the page we are looking for. Looking back in the subdomains present for hacme-corp.net, we observed the URL vibe.coding.internal.test.hacme-corp.net present in the crt.sh output.

Domains within the certificate for `hacme-corp.net`

In the provided domain ackme-corp.net we can see that there are also wildcarded subdomains present in the certificate:

Thankfully though, earlier we saw that the current deployed GitHub pages domain was testing.internal.ackme-corp.net, which gives us a good starting point to enumerate further.

The CTF provided us with a wordlist to enumerate subdomains at /opt/wordlists/subdomain-wordlist.txt, but running wc -l to print the number of lines shows us that it has 5000 entries. I ran fuzzing tool ffuf against the domain with the following command:

ffuf -u http://FUZZ.testing.internal.ackme-corp.net -w /opt/wordlists/subdomain-wordlist.txt -mc 200,301,302 -s

Unfortunately I received no hits. Wondering if there is any pattern matching from the original vibe/coding subdomain we saw earlier, I looked to see if either of those were present in our wordlist.

At this point, I think we're looking for a nested subdomain where one of the two is coding. I really didn't want to have to fuzz for both subdomains given the high number of requests required, so at this point I wanted to go easier paths first. I can then fuzz this with the potentially known domain:

ffuf -u http://FUZZ.REDACTED.testing.internal.ackme-corp.net -w /opt/wordlists/subdomain-wordlist.txt -mc 200,301,302

This resulted in no hits, then:

ffuf -u http://REDACTED.FUZZ.testing.internal.ackme-corp.net -w /opt/wordlists/subdomain-wordlist.txt -mc 200,301,302 -s

We got a hit! Our redacted endpoint is returning a 200 at the time of this post.

Authenticating to the Portal

From here we have some interesting things to investigate:

the vibecodeawebsitetoday.com domain present at the bottom.
the source code of the login portal.
how the login endpoint interacts.

To start with the simple, testing the login page reveals a few specificities:

Attempting to login with an email not ending in @ackme-corp.net results in no web request being sent to the login endpoint. Because there was no request sent, this tells us that the conditional check is being done client-side, and we can see that in the JavaScript of the page:

            // Client-side validation: Only allow @ackme-corp.net emails
            if (!email.toLowerCase().endsWith('@ackme-corp.net')) {
                showError('Access restricted to Ack-Me Corp employees only (@ackme-corp.net emails)');
                return;
            }

This does mean that if we do have a pair of valid credentials we in theory should be able to use the console in the browser to request the login endpoint directly. We can see that being called later in the following:

            try {
                const response = await fetch('/api/auth/login', {
                    method: 'POST',
                    headers: {
                        'Content-Type': 'application/json',
                    },
                    body: JSON.stringify({
                        email: email,
                        password: password
                    })
                });

Seems clear at this point what use the login page is for. Pivoting towards vibecodeawebsitetoday.com, we land on a clearly vibecoded landing page for a fictional service:

Upon inspecting the source code for the page there is no logic for any sort of API or network connections, and none of the buttons on the page actually do anything. If you type stuff into the prompt and press the Create App button, it renders you an error that is specified in the javascript:

Doing basic research into the domain looking for directory or subdomain relationships didn't come up with anything, so back to the terminal we go. We have the other provided wordlist at our disposal: api-objects.txt. Sounds promising, let fuzz this domain for any directories as well.

ffuf -u https://vibecodeawebsitetoday.com/FUZZ -w /opt/wordlists/api-objects.txt -mc 200,301,302 -s

Okay cool, we have documentation. This page is helpful and gives us a working API we can use for the page we discovered:

Poking around through these endpoints, we get an option to test and execute them, and can see from the health endpoint that this API is still live.

Looking back at the API requests in the documentation, we are most interested in the authentication endpoints. All of them require an app_id to make the request on:

After some digging we can find the app_id for our application of interest in the same source code for the page:

Taking that, I wanted to see if I could register an email with the correct email domain. I got the following response:

{
  "status": "error",
  "message": "Registration failed. Ack-Me Corp employees should use the internal portal for authentication."
}

It seems clear at this point we need to use the register page to create an account using a different email domain, then pass those credentials to the login endpoint while circumventing the client-side restriction. I then register an account using the API docs execute function with the credentials testing@email.net and password testing123, with which I get a success response for.

{
  "status": "success",
  "message": "Registration successful. You can now login with your credentials.",
  "app_id": "REDACTED",
  "verified": true,
  "dev_note": "Account auto-verified for immediate access"
}

Registration Response

There is also a login endpoint there, so I put these credentials in there and submit.

I am returned with a success and a JWT session token that I save just in case.

{
  "status": "success",
  "token": "REDACTED",
  "message": "Login successful!",
  "app_id": "REDACTED"
}

One more thing I notice is that at the top of this page there is a link to /openapi.json:

Turns out our target application also has this page present:

After looking through I can summarize the present options:

Main Endpoints:/ → Home page (redirects to login or chat)./login → Login page./api/auth/login → Authenticate with email/password via VibeCode, create a session./chat → Chat page interface./api/chat → Chatbot endpoint (takes a message in JSON, optional session cookie)./api/auth/logout → Logout, clears session./api/health → Health check.
Schemas:LoginRequest → requires email and password.ChatRequest → requires message.ValidationError & HTTPValidationError → standard error reporting.

We can start in our terminal by assigning variables:

APP='http://coding.pprod.testing.internal.ackme-corp.net'
EMAIL='fakeemail@email.net'
PASS='testing123'

Then we can use the /api/auth/login endpoint to authenticate with our previous credentials:

curl -isS -H 'content-type: application/json' -X POST "$APP/api/auth/login" -d "{\"email\":\"$EMAIL\",\"password\":\"$PASS\"}"

We get a response!

HTTP/1.1 200 OK
Server: nginx/1.29.1
Date: Mon, 29 Sep 2025 21:45:07 GMT
Content-Type: application/json
Content-Length: 39
Connection: keep-alive
set-cookie: session_token=6EEVbQ55QcgsUqRnJDHOWHuKmCg2qYje42dOvHWLad4; HttpOnly; Max-Age=86400; Path=/; SameSite=lax
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block

{"status":"success","redirect":"/chat"}

Cool so we can authenticate. Unfortunately I couldn't get any of the other endpoints to successful act that we had authenticated, so I moved to attempting to do all of this in the console of the browser to interact with the javascript directly.

This is successful again, and this time I have an LLM create me a script to send a series of LLM jailbreak attempts passing along the authenticated session hoping for any responses or flags.

Script to send jailbreak prompts to `/chat`

Output of our chats, many of which contain the flag for the challenge.

I enjoyed this challenge as it was different than the ones we have had to complete previously. Although most did not provide new information, I spent a long time enumerating the various domains present in the completion path and learned several new tools to try and gather information.

After completing the challenges I always look up the author for Wiz research articles written by them, as it seems the challenges themselves are based on previously-published information from them. This challenge is no different, and we can see parallels in this article from challenge author Gal Nagli.

Needle in a Haystack - Wiz Cloud CTF September

Jason Walker

Enumerating subdomains

Authenticating to the Portal