favicon.ico handler & meterpreter reverse_tcp encoder problems

[jlbrown1980 at comcast.net (jlbrown1980 at comcast.net)]

Ahh that makes sense, did not realize that it regenerated the shell code.
I cant for the life of me figure out why the stdapi extension for meterpreter is not loading then.  

So for a single connection to the URL the exploit is being hosted on (eg. http://192.168.1.105:4444/zWejak) , it will 
keep trying to re-encode the payload?  I'm trying to figure out how to explain what i'm thinking about.... for example, 
I setup the exploit get it running on my linux computer, then I run across the hall to my windows xp computer.  Paste 
in the exploited URL to IE7.  Then I just let it sit there with the few lines of giberish, no hitting refresh or 
anything like that.   Under those circumstances should it keep trying to encode, or should it successfully encode the 
payload,  upload it, then discontinue encoding if no other sessions/connections are present?  For some reason when I am 
having the windows xp computer connect to the SRVPORT (using meterpreter/reverse_tcp) I cannot get the target computer 
to connect back to the linux comp via open LPORT.  In the MSFCONSOLE display it will display nothing (no uploading DLL 
or anything like that) when the target computer con
nects to it via SRVPORT.  When I use the LPORT, I immediately see text on the MSFCONSOLE.  DLL uploads, then a 
meterpreter session is opened by the target PC.  When they connect through the SRVPORT, it seems useless though as the 
extension will not load (stdapi).  Thats all I can think of so far.  

If my understanding of this is correct, shouldn't the target computer connect to the exploited URL using the SRVPORT.  
Then code is loaded and computer redirects to the LPORT, and open up a meterpreter session?

If that is the case, it would appear the problem I'm having lies somewhere in the redirection process.

Thanks

 -------------- Original message ----------------------
From: Kurt Grutzmacher <grutz at jingojango.net>
> Ah, I hadn't even realized that IE7 started doing favicon. It's still
> not a problem because the http server code is recognizing that the URI
> being passed (/favicon.ico) isn't mapped to any expoit so it's just
> dropping the request.
>
> Part of the exploit routine regenerates shellcode on every connection to
> reduce the likelihood that two machines will receive the same set of
> strings, throwing off (H,N)IDS.
>
> In on_request_uri the line:
>
>   # Re-generate the payload, using the explicit target
>   return if ((p = regenerate_payload(cli, nil, nil, target)) == nil)
>
> does this. It's just before the send_response function. If you use curl
> to send multiple requests they payload should be changing on each one.
>
>
> -- 
>                  ..:[ grutz at jingojango dot net ]:..
>      GPG fingerprint: 5FD6 A27D 63DB 3319 140F  B3FB EC95 2A03 8CB3 ECB4
>       "There's just no amusing way to say, 'I have a CISSP'."