1

I'm working on a tool that exploits SearchIndexer.exe on Windows 7 x86 and connects back to a metasploit multi/handler, using standard metasploit reverse TCP stagers.

The exploit seems to function as intended in the debugger, and works for other processes such as calc.exe.

However, when exploiting SearchIndexer.exe, the TCP connections back to my metasploit instance fails (no traffic sent), and on the victim I can see the following in events in procmon (http://i.stack.imgur.com/Or2L6.png):

http://i.stack.imgur.com/Or2L6.png

Two questions:

  • Are there processes in Windows 7 that are not allowed to make TCP connections?
  • If not, how can I debug why the TCP connection (call) fails?
Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • 3
    If you are able to pop a calc, it means the shellcode is executed successfully. This means that it won't make any difference for any other type of shell code as well. If the connection is getting dropped, check that port 4444 is allowed between the two machines and that the AV is not blocking the connection. A lot of AV's blacklist the TCP stagger of Metasploit. – void_in Jan 18 '14 at 18:50
  • Thanks - I know that my shell code executes successfully, but somehow the shell code works when it is executed in the calc.exe process, but not in the SearchIndexer.exe process. – Carsten Maartmann-Moe Jan 19 '14 at 12:35
  • You mean when you execute the reverse tcp shell code inside calc.exe, it connects back to the handler but when you execute it inside the SearchIndexer.exe process space, it fails? What I fail to understand is how you manage to execute your shell code inside calc.exe? You are exploiting some other vuln and then migrating your shell code to calc.exe process space? – void_in Jan 19 '14 at 13:27
  • I think he's trying to say that launching calc.exe is succesful, but once trying to start a reverse TCP shellcode it fails. – Lucas Kauffman Jan 20 '14 at 11:35
  • @void_in: It is a somewhat special exploitation case - I can exploit any process with Firewire DMA (see https://github.com/carmaa/inception) - I can inject shellcode (in this case, the meterpreter reverse TCP stager) into any process. Somehow injecting the reverse stager works when executing in the calc.exe process, but not in SearchIndexer.exe. I may add that other payloads (such as adding a user, etc.) works - but not network-related payloads (I've also tried opening a bind port. The port opens, but seems filtered when scanning with nmap even though there is no firewall on the target). – Carsten Maartmann-Moe Jan 21 '14 at 09:09
  • Have you tried intentionally mitigating a program that opens a port into SearchIndexer.exe just on your local computer? That would seem to answer your first question. – KnightOfNi Jan 27 '14 at 16:55

1 Answers1

1

Allright, answering my own question. SearchIndexer and other services are protected by Windows Service Hardening. A part of WSH functionality is firewall rules for the service based on the way the service is supposed to communicate. So if the service is not supposed to communicate over the network, the developers may restrict it's ability to connect/receive data on the network.

The WSH firewall rules are checked before and independently of the Windows firewall, so even if you turn that off, they will be in effect.

The effect of this is that SearchIndexer.exe is not allowed to make outbound connections.

Fortunately, the WSH firewall rules are set in a registry key, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable. Deleting the SearchIndexer subkey makes the exploit work flawlessly:

enter image description here