Disclaimer: The content in this post in no way reflects the opinions or expressed statements on behalf of my employer. It is my own personal tinkering and meant for educational purposes only in red and blue team security operations. Any abuse or unauthorized use of the knowledge and tools listed below is on you.
Recently, Cloudflare released a non-account required trial edition of their service: Argos Tunneling in a recent blog posting. To keep it simple, Argos Tunnels essentially put a reverse call back agent on your local webserver and will tunnel your service to their cloud. The intended use case is that you no longer have to ‘directly’ expose your self-hosted services to the Internet anymore in a typical reverse proxy or forward PAT. Their trial allows for non-account members to test services with dynamically generated DNS records automatically created and pushed throughout their CDN routes to any service port hosted locally. The kicker is that not only is this nearly instantly available; it even wraps your original content in a proper TLS session without any certificate errors!
Why is this a perfect use or test case for Red Teams? Now, in a post-compromise scenario of an endpoint; we can now reverse shell to a known and trusted CDN and the other ‘side’ of the connections is handled, routed, forwarded with dynamically generated DNS names created for us. This is more than likely going to bypass edge perimeter monitoring inspection.
From a blue team defensive perspective, this presents lots of problematic indicators of compromise to contend with:
- Properly inspecting content including webshell payload before egress through the cloudflare daemon proxy and to the CDN cloud service
- The argos tunnel daemon supports multiple architectures including: 32/64 bit desktops on Windows, Linux, Mac, and even 32/64 bit editions of ARM
- The argos tunnel daemon will not be natively flagged by anti-malware solutions and potentially by user behavior analytics solutions either
- Potential for a variation of rapid FQDN’s through cloudflare to have to track down for any given at-scale infection or compromise
From a red team perspective, this an additional vector and tool for us to continue trying to egress shell activity in the on-going cat and mouse game of stealth vs. detection. In my example below you can see that I am able to run a simple emulated web service using Nmap’s ncat package and properly formatted ‘HTTP 1.1/200 OK’ response with a carriage return followed by my payload. Notice Cloudflare does not complain or stop if there aren’t things like secure headers or non-triggering specific content.
As you can see, results of a shell code can be displayed easily. Using the Nmap LUA HTTP script in Windows you could provide a LUA based webshell that has been modified to perform in Linux or Windows. There’s also self contained http server that performs OS based shell commands called shell2http made for Windows, Linux, and Mac compatibility. Alternatively if the compromised host is Linux or Mac, you are more than likely going to have Python or Tomcat related packages built in that could be potentially leveraged for other webshells. An example use might be to run shell2http -cgi /shell “webshell.php” and then attach a simple PHP form based webshell.
Note for defenders: During our testing, we do discover that at least in the free non-registered agent does utilize alternative specific alternative port 7844 when establishing to the CloudFlare Argos cloud mesh. This may however change or there may be other ports for registered users. Good perimeter egress port security or strict proxy port enforcement (not just transparent mode) can go a long way to blocking these initial tunnels out. Don’t just rely on an IPS or basic URL/DNS inspection.
I hope you’ve found this simple yet very effective use case of Argos Tunneling enlightening. If you’re looking for blue or red team operation services and or consulting; please feel free to drop me a line at www.scissecurity.com