· unified

How I Hacked a Random Machine

A basic walkthrough of how I hacked a random machine.

hacking random machine

Basic walkthrough of how I hacked a random machine pt1

Welcome to my part one walkthrough on how I got initial access and some level of privilege escalation on a random computer on the internet. Context is I wanted to practice on some real machines in the wild. I’m a total amateur so there is probably going to be a lot of you screaming at your monitor in frustration. Let me know if you think there was something I could have done better or any feedback in general. Anyways, let’s get to it.

Picking a random region and county in the US and using masscan on their IP range, I found a bunch of interesting machines: mostly routers, cameras, and then after the fifth machine I looked at this:

Image of website that displays header 'Upload and Play Video' with a file upload field

At least to me this is begging to be exploited, so I had to try doing it. Unfortunately I didn’t really document this process until much later, but essentially I was looking through Hacktricks section on file uploads (https://hacktricks.wiki/en/pentesting-web/file-upload/index.html) and trying out what tricks they recommended. Eventually I discovered it was as simple as changing out the MIME content to look like an mp4 (video/mp4) instead of a php file. That was rather stupid easy.

Image of successfully launched p0wny shell instance; logged in as www-data@lamp-server

I now have a simple php shell I ripped off of here (https://github.com/flozz/p0wny-shell). Doing a bunch of manually digging through the server I discovered it looks like its running in an XAMPP environment (Apache PHP and what not) and had some other interesting services going. Using some basic tools like linenum and linpeas, I extracted a lot of interesting information including some logins for an admin user on their main login page and a flixtor movie account (while getting a premium movie account was cool, this becomes much more relevant later). It was getting really late, so before hopping off I dumped all of /var/www/html before logging off (thank god I did).

Waking up in the morning and trying to get back into my shell, nothing came up. “Oh shit” is what I thought. I had no clue whether or not a sysadmin detected my shell and plugged up my gateway at the time (later investigation proved this was some automatic cleaning and other shit I didn’t understand) but I was left with just the original login portal.

Image of empty custom login page with fields 'Username or Email' and 'Password'

And luckily enough the admin credentials found earlier worked.

Image of custom login page with fields 'Username or Email' filled in with 'drathnis@gmail.com' and filled 'Password' not shown for privacy reasons

Awesome.

Image of empty custom account register page that is only accessible to the account user; asks for details like first, last name, username, email, and password

Just in case I were to lose the admin account in the future, I added my own user account with phony details to try and blend in with the other existing users.

Anyways… back to trying to get RCE again on the server.

Using the dumps of /var/www/html from earlier, I scanned through a bunch of different php files and found an interesting endpoint: /productCompare.php

Image of low quality web page titled 'Compare Product Data' with some random fields including a file browse and upload button

Looking through the code, I spotted yet another file upload vulnerability (what’s up with this server and not handling uploaded files correctly??)

Image of php code that clearly shows a unchecked file upload vulnerability

After uploading the same shell, I was confused because I didn’t see it in the file dropdown to reread the code and realized it only displays files ending in .xlsx (spreadsheet files). Directly visiting my shell at /uploads/ I’m back in again to my previous www-data environment.

www-data didn’t have a lot of permissions; I couldn’t sudo or run a lot of commands I wanted to and the php shell was getting old real quick. I was too lazy to set up a proper tor reverse shell so I continued using it in the meantime.

While the linux version, snapd, and other software is quite old and had some ready exploitdb scripts to get root; nothing worked. It seemed that www-data had too few permissions to get a lot of the scripts working (this info came from linpeas). Looks like I couldn’t just script kiddy my way to root.

Using pspy64, I found this interesting process

2026/03/12 01:16:27 [35;1mCMD: UID=1000 PID=1014 | /var/www/html/CENSORED/venv/bin/ python flixtor_api.py

UID 1000 refers to the Julian user on the system; apparently they have some flixtor_api (related to the flixtor login I was able to steal earlier; still has over a free year of premium access that isn’t cheap I’m going to enjoy lol). It looked to be the only process being run by Julian so I know any easy attempt at getting any privilege escalation was going to be through this process.

A huge oversight I saw was that the www-data user was in the same permissions group as Julian. While there weren’t a lot of credential files I could access without being Julian, I had the ability to overwrite some files inside of this flixtor_api folder (bingo).

Image of modified flixtor API python program with my own injected route that runs OS commands

I was able to inject my own flask endpoint, but there was a problem. I had no easy way of restarting the python and I didn’t want to risk eliminating this priv esc potential vector by killing the python process.

Image of command output of 'systemctl cat flixtor'; shows details about the systemctl flixtor service

While Restart=always is set in the systemctl config for flixtor; I still have no clue if manually killing the process would actually make it restart with my new endpoint attached (someone let me know if you know the answer to this).

In the meantime ruling out changing and restarting any python files, I targeted files that would have to be read in real time by the flixtor process.

This took my attention to changing out some Javascript wherever I could.

Seeing “playwright” everywhere in the python files of this project (I have no clue what it does, I just saw a lot of mentions of it) I found the packages responsible for it in the python venv.

Image of command output of 'ls' in python flixtor program's playwright package driver directory

Great, everything is writable by people in the julian group, including www-data

Image of contents of default cli.js file

Changed this cli.js file to look like this

Image of new version of cli.js with javascript payload

Payload was generated using duck.ai and I was able to transfer this version of the file over pastebin to send to our target.

Image of catted file output of changed cli.js

Great, we’ve injected our payload

Image of attempted RCE through cli.js failing

Well that was disappointing; trying some other endpoints, nothing happened. Either there was something wrong with the javascript payload or it just isn’t running at all.

Something I had remembered was this debug code snippet from earlier; not sure why it didn’t jump out to me sooner, maybe I’m just a little stupid

Image of earlier flixtor python program showing /debug/ endpoint

We can see in the config that DEBUG_DIR is the folder where they keep some random looking screenshots; not really sure why they’re there but let’s have fun with it

Image of outputted config file contents showing where DEBUG_DIR resolves to

Great, so the endpoint reacts how you would expect it to

Image of curling http://127.0.0.1/debug (works) Well this didn’t really work the way I hoped it to

Image of failed attempt at directory travesal in debug endpoint

This ended up feeling like a deadend; File linking didn’t even work because I don’t have group write access to / debug_screenshots; this was really discouraging and low key wanted to kill myself because I thought I was on to something.

However, thinking more about system file links I kept digging through the source code and found this

Image of /js method in flixtor program

Image of 'ls -la' inside of flixtor app directory (reveals JS filed served by /js endpoint)

We found another endpoint meant to be used by flixtor presumably? that serves the javascript file

After linking the file to passwd and calling the endpoint…

Image of symbolically linking js file to /etc/passwd and curling /js to print contents of /etc/passwd

Halle - fucking - lujah, finally; we could read files as Julian. Previous attempts at priv esc failed, but at least it inspired this new file reading method

Censored image of an anthropic token read through this vulnerability

An anthropic token? don’t mind me yoink

Reading a bunch of other private files we discover more interesting passwords and users

Image of censored output of .mysql_history revealing passwords on the system

This concludes part 1 of my writeup, stay tuned for future updates :-P

I’d love any feedback, harsh or not. Happy hacking.

(PS: Side note I forgot to include but at some point I discovered some MD5 hash to some random php mysql user in the machine after accessing their local MySQL; using hashcat brute force I cracked it in like less than 2 seconds. it was the same as another password discovered earlier plus one extra number like LOL that isn’t a big upgrade of a password)

Image of hashcat cracking MD5 hashes on the system

Image of successful output of the previous command

btw if any FBI is reading this, this is a totally abandoned server with none of my actions actually inflicting any harm to individuals related to this service; to further this point law enforcement even the gemeni and anthropic tokens I found expired like in like August of last year, not really a well maintained server anyone is touching


Some Q/A:

Q: hey brother, So I am too trying for masscan but well no luck aside of some routers lol but nothing serious can you help me with command or like ip block. where did you decide to try?

A: I don’t really plan on further making my opsec worse by telling you exactly where I scanned, but let me correct something I said earlier by scanning some random IP range in a “random region and county.” It actually wasn’t at all random. I asked myself stereotypically where would I find a bunch of higher probability of exploitable machines and then scanned that region. That’s why only like I needed to look at the first 5 or 6 IPs in a big list I had to actually find something I could easily exploit. It’s much easier to curate a higher quality list of items to go through than picking random machines on the internet (think statistics)

a lot of this stuff is just critical thinking; blindly firing hasn’t really worked for me all that well historically

Q: also how did you managed to get reverse shell? like on different network

A: This isn’t a reverse shell in the sense I have some listening service like netcat somewhere waiting for a reverse connection. In this case my picked server had what’s commonly known as a “file upload vulnerability”. I honestly think a lot of these generalizable exploit names like XSS and what not are great, but really understanding what’s happening is key.

  1. I have no code on this target initially so everything I’m doing is just blackbox work, nearly guessing and checking but making the best estimates based on what info I get from the application

a) example info while not much from this example is a feedback message, I get a message saying either file uploaded successfully or not (a standard message like this makes it easy to make a script that bruteforces a lot of configurations, like fuzzing; I didn’t need to do that but it was an option). Also being able to directly access the uploads file was a major plus.

b) from some error messages I know the server is running apache, which means PHP

  1. I find using burp I could just change out the HTTP reported MIME type of the file I was uploading and the server just ate my shit up. That was honestly just a lot of guess work. But because I know the server is running apache, and runs .php files when you open them on the backend, I know that if I create a malicious php file (in this case it was the opensource shell I just ripped from github because I was a lazy ass) and uploaded that then accessed it, I would have RCE on the server.

a) imo it’s better to think of exploits as what they actually are than just some simple term like “file upload vulnerability” because it could mean a lot of things depending on the scenario

  1. While I already answered the question I believe; this isn’t a reverse shell, it’s just a php shell I’m accessing over tor (it’s not reverse because the initial request in the network exchange comes from my machine, not the other machine)

Foot note

In a conversation with @nox he brought up the idea of Honeypots and how even things like API tokens can be wired up to cause some internal behavior to happen (Honeytokens; can find an article here: https://deceptiq.com/blog/whats-in-a-good-honeytoken)

The bottom line is if you decide to do something like break into some random server, think. It’s good form to be suspicious of everything, and even I feel for it too. “At least to me this is begging to be exploited” is something that a lot of honeypots are going to be designed to do, so tread carefully.

Originally authored on 13/03/2026