Hey everyone,

I've been stuck on the final flag for this "Easy" rated box for 2 days now, and I'm genuinely confused why this lab is marked as easy. I got the user flag via Cacti exploitation without too much trouble, but finding the root flag has been a nightmare.

The Problem:
I successfully gained root access in a Docker container using CVE-2025-9074 (Docker API exploitation). However, I can't locate the root flag. The writeups I've found don't clearly explain where the flag actually is, they just end after getting root access.

I've searched:

• /root/root.txt - doesn't exist
• /mnt/host/root/ - nothing
• /home/ directories - empty
• Various Docker logs - no clear output

Question:
Where exactly is the root flag located, and what's the correct way to retrieve it from the Docker container logs?

Any help would be appreciated. I just want to understand this and finally sleep! 😅

Chaining 3 CVEs to exfiltrate sensitive ERP data.

I recently investigated a compromise of a WordPress website hosted for one of our projects. What made the incident interesting was that the obvious suspect — a file manager plugin installed by the attacker — was not the initial entry point.

The server logs gave us a fairly clear timeline:

• 06:20:08 UTC: a remote IP submitted a successful POST /wp-login.php
• 06:20:11 UTC: the same source accessed /wp-admin/
• 06:20:35 UTC: the attacker installed “FileOrganizer – WordPress File Manager”
• 06:21:18 UTC: the plugin was activated
• 06:21:39 UTC: its file management interface was opened
• 06:22:32–06:22:33 UTC: authenticated admin AJAX requests uploaded executable PHP files into another plugin directory

The important distinction is this:

The evidence does not show that FileOrganizer caused the initial compromise.
The attacker already had a valid administrator session before the plugin was installed.

The plugin was instead used as a post-authentication tool. Once the attacker had administrator privileges, it provided a convenient way to place executable PHP files inside the WordPress installation.

That distinction matters because it is easy to blame the last visible tool instead of investigating how the attacker obtained the valid administrator session.

What we did

• Put the affected site into a short controlled maintenance window
• Preserved access logs, timestamps, file hashes and suspicious files
• Removed an unauthorized WordPress administrator
• Invalidated existing WordPress sessions and application passwords
• Rotated relevant WordPress credentials and salts
• Reviewed plugins, themes, cron hooks and administrator accounts
• Scanned the installation with ClamAV and YARA rules
• Verified WordPress core files against official checksums
• Checked upload directories and plugin directories for executable PHP
• Reviewed redirects, canonical tags and injected external scripts
• Restricted PHP execution in upload directories
• Removed file manager functionality that was not operationally required
• Kept the evidence separate instead of immediately deleting suspicious files

The most important lesson

A successful WordPress admin login should be treated as a full application compromise.

Once an attacker has administrator access, simply deleting the uploaded webshell or uninstalling the file manager plugin is not enough. An administrator may be able to:

• install or modify plugins and themes
• create additional administrators
• add application passwords
• change scheduled tasks
• modify redirects or SEO metadata
• upload executable code
• establish persistence outside the obvious plugin directory

The investigation therefore has to begin with the authentication event, not with the later webshell upload.

What is still unknown

We could prove when the attacker logged in and what happened afterwards. We could not prove from the available evidence alone how the valid administrator session or credentials were initially obtained.

Possible causes include credential reuse, stolen browser sessions, phishing, an exposed password, compromised email access or another vulnerability — but naming one without evidence would be speculation.

Defensive changes we are applying across our hosting platform

We are now adding central monitoring for:

• newly created WordPress administrators
• new application passwords
• plugin installations and activations
• PHP files appearing in upload directories
• WordPress core checksum changes
• unexpected cron and systemd changes
• suspicious login activity
• file integrity changes through AIDE
• ClamAV and YARA results
• offsite backups with tested restores

We are also separating each customer application by system user and database account, keeping databases private and retaining the old server as a rollback source during migrations.

I am sharing this because incident reports are much more useful when they separate confirmed evidence from assumptions. “The attacker used plugin X” is not automatically the same as “plugin X was the initial vulnerability.”

If anyone has investigated similar cases involving a valid WordPress admin session followed by installation of a file manager plugin, I would be interested in the forensic indicators you found most useful — especially for tracing the original session theft without retaining sensitive user data.

>