Systemd-timesync used in ransomware attack

Ask Fedora Ask in English
1

Hi all,

I’m running Fedora 35, and have docker installed that provides an apache, php an mysql server locally. The docker related services are not accessible from the internet to the best of my knowledge. I also have the Fedora firewall enabled.

This morning I noticed the database in mysql provided by docker no longer existed. While docker is running mysql as virtual machine, the actual mysql raw data is stored on my machine, the host machine. Looking at the directory that held my docker mysql data, I can see a new database was created yesterday, named Z_README_TO_RESTORE. Looking inside the database it’s a ransomware attack asking for bitcoin. Also if you google the database name, you’ll see similar reports, but usually just on online web servers, no local docker reports.

I’ve ran chkrootkit and found nothing. I’ve also looked at the last logins and no one logged into my machine around the time these files were created.

Interestingly, the files are created by the systemd-timesync user. There is no way the systemd-timesync user should be creating or editing these files, the correct user is usern.

[usern@localhost workingdir]$ sudo ls -ls mysql/Z_README_TO_RECOVER/
total 112
 4 -rw-rw----. 1 systemd-timesync input    65 May 31 13:08 db.opt
12 -rw-rw----. 1 systemd-timesync input  8560 May 31 13:08 RECOVER_YOUR_DATA.frm
96 -rw-rw----. 1 systemd-timesync input 98304 May 31 13:08 RECOVER_YOUR_DATA.ibd

I’ve looked for other files created around this time but can’t find anything obvious, mostly just packagekit and snap updates files, hundreds of them.

However, 3 related files were modified by the systemd_timesync user at the same time:

   2510027       4 -rw-rw----    1 systemd-timesync input                       484 May 31 13:08 ./home/usern/workingdir/mysql/mysql/user.MYD
   2510093     128 -rw-rw----    1 systemd-timesync input                    131072 May 31 13:08 ./home/usern/workingdir/mysql/mysql/innodb_table_stats.ibd
   2510095     256 -rw-rw----    1 systemd-timesync input                    262144 May 31 13:08 ./home/usern/workingdir/mysql/mysql/innodb_index_stats.ibd

Interesting, I also have mysql installed on my host machine outside of docker… it wasn’t running at the time of the ransomware attack. The non docker mysql install puts the mysql data in a different folder, the default mysql folder, where as the docker mysql data directory is within a sub folder within specific user account. The non docker mysql data is all intact.

I’m not interested in getting my data back, but I am interested in finding the root cause so I can prevent it.

Many thanks

2 Likes
2

Please note that any privileged process can create files that are owned by the systemd-timesync user; that is not restricted to the systemd-timesync process itself.

3

Just supposing. Maybe the uid number used inside the docker container incidentally match the systemd-timesync uid number on the host?
In addition. Maybe you didn’t use the official mysql image, but some malicious one?

4

@happy did you ever get to the bottom of this? I’m curious. TY!

1 Like
5

Do you have any ports accessible from the internet?
Do you have any services that connect to or maintain a link to a server on the internet?

Even something as simple as IoT devices such as a thermostat, camera, security system, media server, Alexa, etc. could allow someone to access your local LAN and trigger some malware. Opening a web page or email could do so as well.

Finding out how it happened could involve time with forensic examination of system logs to see what vector was used for the attack.

Why would anything be creating “hundreds” of files at about the same time?
The find command can be used to identify the times when files were accessed/created.

6

@storagefelt, I didn’t exactly pin it down 100%, but it is as Jeff mentioned, I had a dmz on open on my router, so all internet traffic was allowed in, so you could reach my local mysql directly, and the root password was basic enough to crack, so I guess it was that…

Although the systemd-timesync user issue I did not ever get to the bottom of… the uid didn’t match anything (didnt exist) in the vagrant machine.

2 Likes