So I’ve been doing some recon on SuperALTS, mostly starting from the outside and seeing what was actually exposed to the internet. What started as a simple subdomain enumeration ended up becoming a much more interesting chain involving an exposed file manager, directory listing, application artifacts, and eventually reverse engineering an encrypted file to understand how a sensitive bot credential was protected.

I’m intentionally leaving out the actual token, private files, encryption material, and anything that could be directly reused against the target. The issues were reported to the affected party and have since been fixed.

The point of this write-up is the methodology and the chain, not the secrets.

Step 1: Enumerating the domains

I started with basic subdomain enumeration and then checked which hosts were actually alive.

The result was:

https://www.superalts.dev
https://cdn.superalts.dev
https://status.superalts.dev
https://superalts.dev
https://client.superalts.dev
https://docs.superalts.dev

Nothing here looked particularly crazy yet. We had the main site, a CDN, a status page, a client application, and the docs. Pretty normal stuff.

The cdn host was the one I wanted to poke at a little more.

A CDN hostname usually makes me curious because it can sometimes expose more than just static assets. If an application, upload system, or administrative tool has been placed behind the same hostname, it can become an entirely different attack surface.

So I started looking at what was actually being served there.

Step 2: Finding Veno File Manager

Right away I found something that caught my attention: a Veno File Manager installation sitting directly under the CDN:

https://cdn.superalts.dev/vfm-admin/

The application identified itself as Veno File Manager 4.3.0.

This was the first point where the recon became more interesting.

A publicly reachable file-management application is already something worth looking at. It isn’t just another frontend route — it potentially has access to files, uploads, shares, and other server-side resources.

So instead of immediately trying random payloads, I started mapping what the application exposed and what version was actually running.

Step 3: Fingerprinting the stack

While going through the exposed infrastructure, I also picked up several pieces of information about the underlying stack.

The server disclosed:

PHP/8.1.33
LiteSpeed

Neither of these findings is particularly exciting by itself. Version disclosure generally isn’t the thing that wins an assessment.

What it does give us is context.

Now we know what kind of server-side environment we’re looking at, what application stack is involved, and which public vulnerabilities might be worth checking.

I also found that the main application exposed a Next.js build manifest.

The manifest contained information about application routes and helped reveal parts of the structure that weren’t immediately obvious from the normal navigation.

Again, this isn’t automatically a vulnerability. Build manifests exist for a reason. The interesting part is when they reveal routes or functionality that shouldn’t be publicly discoverable or accessible.

Step 4: Looking at the upload directory

The Veno File Manager installation also exposed its upload directory:

https://cdn.superalts.dev/vfm-admin/_content/uploads/

and directory listing was enabled.

This is where the file exposure became more interesting.

An upload directory isn’t necessarily sensitive just because it exists. The problem is what ends up inside it and whether those files are supposed to be publicly retrievable.

Upload directories can contain much more than images.

Depending on how an application is built, they can end up containing:

• application-generated files
• shared files
• exports
• temporary files
• backups
• configuration artifacts
• source files
• files uploaded by internal services

So once I saw that the directory was indexable, I started treating it as a potential source of application artifacts rather than just another web directory.

Step 5: Checking the known Veno File Manager history

Since the application and version were now known, I checked public vulnerability databases for issues affecting Veno File Manager.

One interesting result was Exploit-DB entry 38880, titled:

Veno File Manager - 'q' Arbitrary File Download

The vulnerability is documented as an arbitrary file download issue caused by insufficient handling of user-controlled input.

I want to make one thing clear here:

I did not treat the existence of an exploit as proof that the deployed installation was vulnerable.

Version matching is not enough.

Applications can be patched without changing the visible version, modified by the operator, deployed behind additional controls, or otherwise behave differently from the original vulnerable release.

So I recorded this as a potential lead rather than claiming a confirmed exploitation.

Step 6: Following the files instead of stopping at the application

This was the part where the investigation started moving away from normal web recon.

The exposed file infrastructure allowed me to find application-related artifacts that were not supposed to be publicly available.

One of those artifacts turned out to be particularly interesting.

It was related to one of the application’s bots and contained sensitive material, but that material wasn’t sitting there as readable plaintext.

It was encrypted.

At first glance, that sounds like the end of the road.

It wasn’t.

This is where I switched from web enumeration to reverse engineering.

Step 7: Getting the encrypted bot source

The vulnerable file exposure eventually led to an application artifact containing the bot’s source.

The source wasn’t simply sitting there as readable JavaScript or Python.

Parts of it had been packaged/obfuscated and the sensitive data was protected by an encryption routine.

I won’t include the original file here, and I won’t publish the encrypted blob, key material, token, or exact path that led to it.

Instead, the interesting question became:

How is the application itself decrypting this data?

That question matters because encryption doesn’t exist in isolation.

If a program needs to use an encrypted secret, it needs some way of turning that encrypted value back into usable data.

So rather than trying to brute-force the encrypted value, I looked at the program responsible for consuming it.

Step 8: Reverse engineering the encryption logic

I loaded the relevant file into a reverse-engineering workflow and started following the code around the encrypted data.

The goal wasn’t to immediately understand the entire program.

That would be a waste of time.

Instead, I worked backwards from the sensitive value and looked for:

• references to the encrypted data
• cryptographic functions
• constants used by the encryption routine
• transformations applied before decryption
• key/IV derivation
• decoding and encoding operations
• the point where the decrypted result was consumed

This is the same general approach I use when reversing crackmes:

find something interesting, follow the references, understand the surrounding function, then trace backwards until the actual logic becomes obvious.

Step 9: Finding the decryption path

Eventually I found the code responsible for processing the encrypted value.

The important discovery wasn’t simply “this is encrypted.”

It was that the application contained the logic necessary to reproduce the decryption process.

Once the relevant operations were understood, I reconstructed the logic in an isolated environment.

This let me verify that the encrypted value could be transformed back into its original plaintext without needing to attack the encryption itself.

And that distinction is important.

I wasn’t breaking modern cryptography through brute force.

I was reversing the implementation that was already shipped with the application.

The weak point wasn’t necessarily the cryptographic primitive.

The weak point was the overall secret-management design.

Step 10: The secret was the bot token

After reproducing the application’s decryption logic, the resulting plaintext contained a bot authentication credential.

That was the moment the impact of the original file exposure became obvious.

The chain was now:

Publicly reachable infrastructure
        |
        v
Exposed file-management application
        |
        v
Publicly accessible file storage
        |
        v
Application artifact
        |
        v
Encrypted sensitive data
        |
        v
Reverse engineering
        |
        v
Recovered decryption logic
        |
        v
Sensitive bot credential

And this is exactly why I don’t like looking at findings in isolation.

If I had stopped at the PHP version disclosure, the result would have been a boring information disclosure.

If I had stopped at the directory listing, it would have been a file exposure.

If I had stopped at the encrypted source, it would have looked like a dead end.

Following the entire chain produced a completely different impact.

Step 11: Why the encryption didn’t protect the secret

This was probably the biggest lesson from the whole thing: having “encrypted” written next to a secret doesn’t automatically make the secret safe.

There is a huge difference between:

Encrypted data

and:

Encrypted data
+
publicly accessible application
+
decryption implementation
+
everything required to reproduce it

The first can be a strong security boundary.

The second can become little more than obfuscation.

This doesn’t mean encryption is useless. It means encryption has to be part of a proper key-management model.

If the application ships everything an attacker needs to decrypt its own secret, then anyone who obtains the application may be able to recover that secret.

This is especially important for bot tokens, API keys, service credentials, and other long-lived authentication material.

Step 12: Impact

The individual findings can be viewed roughly like this:

---

Finding What it exposed

---

PHP version disclosure Server-side technology information

LiteSpeed disclosure Web server information

Next.js build manifest Application route information

Exposed Veno File Manager Administrative/file-management attack surface

Directory listing Public visibility into uploaded files

Potential historical Veno issue Possible arbitrary file access

Application artifact exposure Internal application material

Recoverable encrypted secret Sensitive authentication credential

The real severity came from chaining them.

The most important finding wasn’t “there is a Veno File Manager.”

It was:

A public file exposure ultimately allowed recovery of
a sensitive authentication credential.

Step 13: What I reported

When reporting the issues, I kept the sensitive material out of the report where possible and focused on proving impact without unnecessarily exposing the credential.

The report covered the exposed application, file exposure, affected artifacts, the reverse-engineering result, and the fact that the encrypted secret could be recovered.

I did not publish the actual token in this article.

I also won’t include the exact extraction chain or commands required to obtain the sensitive material from the affected infrastructure.

The goal of a responsible disclosure is to demonstrate the issue strongly enough that it can be fixed — not to turn the report into a ready-made instruction manual for abusing somebody else’s infrastructure.

Step 14: The $500 payout

After the report was submitted, the findings were reviewed and accepted. The research ultimately resulted in a $500 payout.

I think the payout is worth mentioning because the interesting part of this research wasn’t any single scanner finding. Most of the early observations were useful mainly because they gave me somewhere to continue looking.

The actual impact came from chaining those observations together until there was a demonstrable sensitive-data exposure.

That is also why I prefer reporting the complete chain when possible. Saying “directory listing found” doesn’t really communicate what the directory listing led to. Showing that it could ultimately expose a sensitive bot credential gives the triager a much clearer picture of the risk.

I still won’t publish the credential itself or the exact steps required to retrieve it. The affected party already had enough information to reproduce and fix the issue, and there isn’t much value in leaving the sensitive details public after remediation.

Step 15: Remediation

The issues were reported, accepted, and have since been fixed.

The main defensive lessons from this investigation are pretty straightforward.

Don’t expose administrative applications unnecessarily

If a file manager is only needed internally, it shouldn’t be publicly reachable from a CDN hostname.

Put administrative interfaces behind authentication, network restrictions, VPN access, or another appropriate access-control layer.

Disable directory listing where it isn’t required

An upload directory shouldn’t automatically become an index of every file stored underneath it.

Keep sensitive application artifacts out of public storage

Source code, bot packages, backups, configuration files, exports, and internal artifacts should be treated as sensitive unless there is a deliberate reason for them to be public.

Don’t embed recoverable secrets in distributed applications

If a program contains a secret that it can decrypt locally, assume that a determined reverse engineer can eventually inspect that process.

Secrets should instead live in an appropriate server-side secret store or another architecture where the untrusted client doesn’t receive the secret.

Rotate credentials after exposure

Once a bot token or API key has been exposed, removing the file isn’t enough.

The credential itself should be revoked and replaced.

Conclusion

This was one of those investigations where the first finding wasn’t anywhere near the final impact.

It started with:

Subdomain enumeration

Then became:

Exposed CDN application

Then:

Veno File Manager

Then:

Directory listing

Then:

Application artifact

Then:

Encrypted bot source

And finally:

Reverse engineered decryption logic
        |
        v
Recovered bot credential

The biggest lesson for me was the value of following a finding instead of immediately moving on to the next one.

A directory listing can look boring.

An encrypted file can look useless.

A version disclosure can look harmless.

But vulnerabilities don’t always exist independently. Sometimes the real impact only becomes visible after several small pieces are connected.

And in this case, the interesting part wasn’t cracking the encryption itself.

It was realizing that the application had shipped the pieces required to reverse its own protection.

References

• Exploit-DB — Veno File Manager arbitrary file download (EDB-38880)
• SuperALTS
• SuperALTS CDN