💡 [REQUEST] - Remote Command Execution - Support for SSH

[d3sch41n]

Implementation PR

No response

Reference Issues

No response

Summary

Dedicated yaml syntax for ssh remote command execution:

Basic Example

It could look like this:

steps:
  - name: establish_ssh_session 
    create_remote_session:
      name: my_session 
      ssh_cmd: ssh -i ${MY_KEYFILE} ${MY_USER}@${MY_HOST_ARG} 
  - name: execute_remote_commands
    remote_session: my_session
    inline: | 
      hostname
      whoami

We can support this natively in golang with the appropriate package:

https://stackoverflow.com/a/41528181

Although we may want to just pipe stdin to a real ssh process - that's "hacky" but
would create more realistic telemetry of attacker activity so hacky might be significantly better in this instance.

Later, We can extend the create_remote_session architecture to support connecting to a remote C2 implant, use WinRM, etc

Drawbacks

No response

Unresolved questions

• Is there a way we could design this to support nested pivots (SSH chains)?
• is there extra glue we need to do to make the telemetry look more real (like making ssh think it's attached to a real tty)

[CrimsonK1ng]

For SSH and other protocols, it will be best to break them up into their own little blocks. This would effectively allow you to create a keyword like:

ssh: username@netaddr:port
key1:
key2:

But you also get to leverage the same logic as the subttp block. So this network protocol can have a list of basic steps which can then be used over the connection. This could be applied across all network protocols essentially.

As for realistic options, just have to expose those as values for the block.

[l50]

This is a very good idea that I'd be super psyched to see. I started to ideate on this problem a few weeks ago and figured I'd share some of what I found/was planning to use if I got the SSH task:

I forked this since it covered most of the stuff I had started to write for in my own client (that I abandoned after). It may be worth forking the original and building on that.

One of the reasons I chose it was that it had an exceptionally compatible license.

---

• Is there a way we could design this to support nested pivots (SSH chains)?

PR for proxy support

---

• is there extra glue we need to do to make the telemetry look more real (like making ssh think it's attached to a real tty)

I think the quickest way we can determine that is to enlist one of our partners for some testing to see how our output sizes up against the real thing. There were several TTPs that could be used from Ouroboros for testing purposes.

[l50]

For SSH and other protocols, it will be best to break them up into their own little blocks. This would effectively allow you to create a keyword like:

ssh: username@netaddr:port
key1:
key2:

But you also get to leverage the same logic as the subttp block. So this network protocol can have a list of basic steps which can then be used over the connection. This could be applied across all network protocols essentially.

As for realistic options, just have to expose those as values for the block.

Agreed, this approach will provide the best foundation to handle whatever params we need to support over time.

[l50]

Blocked by work required for the C2 functionality.

[d3sch41n]

Will revisit once impl for #49 lands - top-level args code structure may influence this design substantially

[l50]

Will revisit once impl for #49 lands - top-level args code structure may influence this design substantially

@d3sch41n Now that #49 landed, should we continue to track this or close and rescope later?