Figure 5 shows a trend of intrusions and targeted network services on Ireland SH.
Shodan scan bots and JSP CMS
Ireland SH received large number of SNMP fingerprinting attempts from 184.108.40.206 (lh26042.voxility.net) owned by Voxility cloud provider, https://www.voxility.com, USA. This intruder was also found to target Sydney SH.
220.127.116.11 that was previously mentioned found to conduct DNS amplification, SNMP and UPNP scanning on the SH. The intruder started with DNS amplification attack and move to SNMP scanning toward end of April and at beginning of May UPNP scanning were conducted concurrently with other intrusions.
Shodan scan bot (http://www.shodanhq.com) were found to probe for uncommon ports such as 32764, 20000, 27017, 9981, 7777, 7071 etc. These ports seem to be related to Internet connected devices (e.g. IPTV, Webcam, etc.).
A number of attempts from 18.104.22.168 (host-122-102.optic-bridge.net) and 22.214.171.124 (lardnerserver.datahop.com) targeting JSP CMSes were observed on Ireland SH (as well as Sydney and Tokyo SHs). In some instances, attackers browsed to known JSP-shell paths on the server (i.e. /cmd/cmd.jsp). A sample list of requested URLs are provided below. The behaviour from both IP addresses were identical showing possibility of a single threat actor behind these reconnaissance activities:
/web-console/ServerInfo.jsp /jmx-console/HtmlAdaptor /dawdwadwaad /zecmd/zecmd.jsp /safe2/index.jsp /manager/html /man/3.jsp /iesvc/iesvc.jsp /cmd/cmd.jsp /DnSjEgA/
Figure 6 shows a trend of intrusions and targeted network services on Sydney SH.
Elcatel a hosting provider in Netherlands behind most intrusions
Probing and connection to RDP (Remote Desktop Protocol) was noticeable on Sydney SH. The majority of attempts sourced from 126.96.36.199 and 188.8.131.52 owned by Chinanet, China, ASN 23650 following by 184.108.40.206 owned by Amazon, US.
220.127.116.11 by Fiberring, Netherlands, 18.104.22.168 by LeaseWeb, Netherlands, and 22.214.171.124 by ScopeHosts, India were top three intruders for SIP scans.
126.96.36.199 and 188.8.131.52 by Ecatel, Netherlands, ASN 29073 following with 184.108.40.206, OVH, France were orchestrated the majority of DNS amplification intrusions not only on Sydney but also on other SHs.
SNMP scan found mainly source from ShadowServer’s scan bots (http://www.shadowserver.org).
Figure 7 shows a trend of intrusions and targeted network services on Sao Paulo SH.
Large number of HTTP proxy requests and intrusive Shodan bots
Sao Paulo SH received large number of HTTP proxy requests. It seems like the IP addresses that was assigned by Amazon to this SH were previously (mis)used as a HTTP proxy server (Providers must quarantine IP addresses for a specific period before assigning them to another customer). A sample list of targeted URLs are listed below where the majority seems to be used for Ad affiliated programs.
Shodan scan bot (http://www.shodanhq.com) were also found very intrusive on this SH looking probing for uncommon ports.
And similar to other SHs, a large number of DNS amplification intrusions sourced from Ecatel, Netherlands, ASN 29073 was observed on Sao Paulo SH.
A considerable increase in the number of SSH brute-forcing attempts toward end of May was prominent on this SH. This was due to two new threat actors i.e. 220.127.116.11 and 18.104.22.168 from South Korea targeting all SHs for root account with guessable password combinations (e.g. qwerty, password, 123456). Both IP addresses sourced from the same ASN 3789. Banner grabbing of the first host advertised the following details:
Port 22: OpenSSH 5.3p1 protocol 1.99 Port 80: Apache httpd 2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.0-fips PHP/5.3.22 mod_jk/1.2.37
ShadowServer scanning bots were observed requesting for determining the DNS version by using version.bind request.
Shodan scan bots were actively probing for DNS Search Discovery (DNS-SD) enabled DNS server.
scanresearch1.syssec.ruhr-uni-bochum.de and openresolve scanning bots were the other ‘legitimate’ source IPs behind DNS scans.
PHP-CGI remote code execution (CVE-2012-1823) was observed on all SHs, deploying variety of malcodes, bitcoin miners, port scanner etc.
Tomcat manager brute-force attempts (e.g. /manager/html) were observed on all SHs. These attempts were mainly sourced from 22.214.171.124 and 126.96.36.199 with a sparse password list (e.g. tomcat, root, admin, manager, s3cret, test, role1, both).
188.8.131.52 (li71-58.members.linode.com) and 184.108.40.206 (li572-57.members.linode.com) both owned by Linode Cloud provider (http://linode.com) targeted all except N.Virgina SHs for Cisco IOS vulnerabilities (http://www.infosecpro.com/penetrationtest/p75.htm). The request URL was /level/99/exec/show/config.
The following domain names were target of DNS amplification attempts and the most intrusive threat actors were 220.127.116.11, 18.104.22.168 from Ecatel Netherlands and 22.214.171.124 owned by OVH (http://ovh.net):
saveroads.ru zing.zong.co.ua www.jrdga.info doc.gov apews.org jong.zong.co.ua shifen.com a3247.com, xboot.net, fkfkfkfc.biz, magas.bslrpg.com. hizbullah.me www.jrdga.info namecheap.com 1x1.cz (targeted by 126.96.36.199, falcon688.dedicatedpanel.com and 188.8.131.52 , hosted-by.reliablesite.net) iorr.ru (tageted by 184.108.40.206 and 220.127.116.11, 77-223-136-170.netdirekt.com.tr)
How to protect my EC2 servers?
Harden your server by applying latest patches and secure configuration Below is a list of few recommendations to protect your network service against each widely exploited vulnerability.
- DNS amplification attack mitigation
- NTP amplification attack mitigation
- Hardening SSH service
- Hardening VoIP(SIP)
- Securing SNMP
- Securing UPNP
Patching and keeping services up to date is a difficult task in a long run, specially when due to existence of legacy applications, it is impossible to immediately apply latest security fixes. So what can you do in this situation?
Well, one way is to use a technique known as virtual patching. However, to do this, you first need a working Intrusion Prevention System in place and you need to write a custom rule that block bad traffic and allow for good.
The other interim solution is by using a custom blocklist/blacklist that prevents intruders at the edge of your network (e.g. firewall). In this case, all the traffic generated from a known intruder is dropped and she does not have ability to access your servers. However, the majority of current blacklist feeds are either generic or tailored toward malware or spam campaigns. At the time of writing there are no widely known blacklist feeds that can block intruders targeting cloud platform such as AWS, Google Cloud, Microsoft Azure etc.
For the first time, we are planing to rule-out a cloud-based custom blacklist service where you can simply use it at your firewall or web server, SSH server, … and this feed will block the intruders before they access your server. Subscribe to our mailing list to get notified and receive trial access to our cloud-based blacklist service (pre-launch).
Do you want to find out more about your environment’s attackers and their tactics? Fill up this form for an invitation to a Smart Honeypot VIP plan.
Discuss this at reddit.