It's probably a good indication of the open door to our system. Note this file /opt/glassfish3/glassfish/domains/domain1/applications/Sarketsdr/gety. usr/share/command-not-found/programs.d/amd64-main.db
usr/share/locale-langpack/en_GB/LC_MESSAGES/util-linux.mo opt/glassfish3/glassfish/domains/domain1/applications/Sarketsdr/gety Let's use this bit of info to scan our system for other files that are probably related to this malicious code: find / -mount -type f -exec sh -c 'grep -q "\.minexmr\.\|wipefs" ""' \ -print In my case the later pointed to an open log file with this content: # head /tmp/mcalogĬMD: /bin/wipefs -B -o stratum+tcp://:8888 -u 49ijJ3HJUg1b2MGnDmnEDJWdphGzWXgtbbBENx43NJiAUZWf8cSGryiZtYVZz3dgRcZH3Leokoqqi8SfRexMW32aFfvoHBp -p x -k
#WIPEFS RASPBIAN CODE#
So we have code for "mining various cryptocoins" here.īefore turning off the machine it's good to have a look at the process with strace (if you're comfortable with it) or look at the files in /proc/ - at least cat cmdline and ls -la fd. Try "xmrminer" -help' for more information. Let's look at the strings in wipefs: strings /bin/wipefs In my case crontab had a line to run /bin/wipefs every 12 minutes. A note of caution here: If dpkg -V reports nothing then don't put your guard down because it's not unlikely that the virus/hacker has taken steps to fool it. Based on the description of the ss and netstat (man ss, man netstat) it's obvious that we have malicious code here that is trying to hide itself. That is surely a sign of compromise for executables (like /bin/ss and netstat). Googling the md5 of the suspicious /bin/wipefs you get results that suggest hacking/virus.ĭpkg -verify lists a few files that have been altered since installation. And it's not at all normal to have an executable in /etc. What follows is the most important parts of my investigation.Ī typical investigation to find out whether this is malicious code # man wipefsĪccording to its description on the man page this executable has no reason running - more so running for a long time and consuming a lot of CPU.
I found out that this system was compromised. In my case wipefs was run by /bin/wipefs and was also using 100% of my CPU. Zfs snapshot -r destroy Storage=persistent > /etc/systemd/journald.I had a similar case in a server running java/glassfish. Systemctl enable start disable rpi-set-sysconf # Last Tuesday of the month, at 2am +/-1h
#WIPEFS RASPBIAN INSTALL#
Zfs create -V 10G -b " $(getconf PAGESIZE ) " -o compression=zle -o logbias=throughput -o sync=always -o primarycache=metadata -o secondarycache=none -o com.sun:auto-snapshot=false rpool/swapĮcho /dev/zvol/rpool/swap none swap discard 0 0 > /etc/fstabĮcho RESUME=none > /etc/initramfs-tools/conf.d/resumeĪpt install -y mosh zfs-auto-snapshot psmisc watchdog curl apt-file As an aside, the dd command is also useful for writing disk images to the.
#WIPEFS RASPBIAN FULL#
This will be much faster than wiping the full SD card. The count parameter will only copy zeroes to that number of sectors and then will quit. # -Įxport RASPI_IMG=20220121_raspi_4_bullseyeīOOT_SIZE= $(sfdisk -d " $ " To only wipe the beginning part of the card, add a parameter to the dd command: dd bs512 count100000 if/dev/zero of/dev/sdb. # Executed as user with sudo rights on some host. # Prepare SD card or USB disk for first boot.
0 kommentar(er)
