proxy or additional gateway support

[Viss]

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

[0x27]

We could do this with the HTTP_PROXY/HTTPS_PROXY/FTP_PROXY environmental variables, would just have to double check that all the downloaders we support will consistently respect these.

Might be a good idea to have a "connectivity check" function that alerts the user that they should set these.

[Viss]

Those are both excellent ideas!
Both would work for my immediate use case scenario.
My next use case scenario is "linux boxes in tightly controlled datacenters, where dns exfil and other clever exfil methods still get caught because 'why the shit is the production jira server talking to gmail? what the fuck is going on alarm sounds' "

setting up something like a reverse port forward to a socks proxy so outbound traffic from orc goes 'back out the same way we came in, over ssh' seems sneaky enough to eek by unnoticed :D

[UlrichBerntien]

Now all downloader should consider http_proxy and https_proxy shell variables or environment variables. Shell variable setting is sufficent because the exports to environment are included in the functions.

Now the two script load and run functions (getsuspect and getexploit) checks the TCP connection to github if no https_proxy is defined.

[0x27]

@Viss - for the reverse port forward, running something like 3proxy or another SOCKS proxy on localhost (on the "attacking host"), and doing something like "ssh -R 1337:127.0.0.1:1337 -l root -i key.rsa victim.tld" would forward the local port 1337 (assuming that is where your 3proxy/SOCKS proxy is listening) to the remote hosts port 1337. You could then (on the victim side) use that as your SOCKS proxy.

Given a lot of the things require the env vars to be HTTP proxies though, maybe using Squid or something and forwarding that is the way to go. You can certainly forward multiple ports using "-R" arguments too.

Given we have added proxy awareness, I guess this will have to go in the wiki for the tool as a usage case/instruction once I've done some testing on it. Will update this issue once that is done :)

[0x27]

Just going to add this here, but an OPSEC note for if you are forwarding remote ports back to local ports to do proxying (and acting as a gateway). If your proxy is exiting via your attack-boxes IP, you could end up with a catastrophic OPSEC failure, where someone else on the pwned box does a request for some IP checker over your proxy, leaking your IP. So it will be heavily suggested to use a local Tor instance for the SOCKS proxy you forward (meaning, "exit IP's" of the tunnel are Tor exits), and a Privoxy -> Tor setup for HTTP/HTTPS.

Other OPSEC considerations/risks are also being looked at here, will note them down as stuff gets tested and all that.

[Viss]

So there are several really awesome projects on github that are either go or python proxies that are "one script with no dependencies that run on python 2.7", so you don't have to try to install stuff on the box you've gained access to. One of those is called "almondrocks", and I've had decent success with it in the past: https://github.com/klustic/AlmondRocks

but it turns out there's somewhat of a market for this sort of thing (shady, one-file, zero-deps proxies for socks or http) and there are a few of them floating around.

Ideally, this project shouldnt have to rely too much on the specifics of the proxy, just that "the operator understands the requirements, and that this tool is part of a larger toolset". :D

[Viss]

also as far as opsec is concerned, what I have noticed lately is that blueteamers are becoming lazy and complacent with the BILLIONS AND BILLIONS OF DOLLARS IN TOOLS they have available to them, so they tend not to go hunting anymore, and only investigate leads that bloop their siem or logging tool or dashboard. So basically unless you hit a tripwire or something, they wont come looking - and GENERALLY that boils down to "is a host trying to talk to the internet that doesnt normally talk to the internet".

[zMarch]

I'd like to imagine that orc won't bloop too much, but then I have seen carbon black on *nix hosts before. That said, opsec should still be a concern, I think - even if they don't care right now (and nobody seems to care too much about *nix from either colour), they might in the future. Should get things right/add warnings from the start.
that said, vpn/proxyery is nice to have, and we do have options for pulling down other tools...