USB is probably the easiest way it could've been done.  Drop a USB in a parking lot, or near an employee area.  What would you do if you found a USB on the ground?  Plug it in and see what's on it so you can keep it or return it.  Employee finds it, plugs it in, and its over before he even knows what just happened.  There were rumors that that's how the US shutdown some foreign nuclear facilities.  It caused part of the machines to start and stop very abruptly, eventually breaking each piece and rendering the facility worthless.  (very large and expensive pieces. Im not a nuclear physicist, I don't know what they were) it wasn't traceable once in the system, not even noticeable really.  It appeared to be just faulty machinery.
Anyways, I have no proof to support it, just word of mouth.  Its a neat little hackers bed time story. 

I appreciate the links.  Very useful reading.  And I agree about making it yourself.  Its always the best way to do anything.    im just working on basics until summer.  Then im gonna hit this stuff hard before I start my network security classes next fall.  Im also trying to work through my transition from windows to Linux.

No worries.  That makes sense that it would be left in a "funky state" haha.  It feels like that's what has been happening.  And leaving another backdoor is smart and definitely something I'll keep in mind on more serious tasks.

So the restarting sessions problem arose as I was on the forums, so I posted it immediately, but it turns out it was an easy fix.  The task was scheduled to only run when the computer was plugged in (and it wasn't).  It's working kind of hit and miss now.  Looks like it will just be an issue in the task properties that I will play around with.

Thanks for the quick reply.

Got the file to open on the target PC with encoding.  It doesn't avoid the AV I want it to, but that isn't a big deal right now.  The major problem I have now is reestablishing a connection after I close a session.  I added a schedule for it to run every minute via "scheduleme", but that doesn't work, and I even tried manually running the .exe on the target PC, but that doesn't work either.  Here is my schedule code:


Any thoughts?

PS:  hayabusa, you posted while I was typing this, but you're correct, bad characters were most likely the problem and that issue was solved.

EDIT:  Ok, apparently now it will start a new session when I manually execute the file on the target...(wasn't doing it before)...but I'd still like it to automatically make a new connection, so my code is above that i tried to do that with...

I could play around with encode more I suppose.  But I don't think its the AV stopping it.  Normally an AV will notify or at least have record of whats been flagged, but it doesn't with these files.  Thanks for a reply, hopefully looking for some more help if anyone can offer it.

Problem: 
I'm creating a payload, encoding it, moving to a Windows 7 machine, and Windows will not open the exe I've created.

Process:
I started with a simple payload, here is the what I used...
It works.  It gets made, sent, and I get a meterpreter connection.  My problem with it, however, is that it lights up pretty much every AV it could run into.  So I decided to try encoding it to see what happens...
This works fine up to the point where windows tries to open it.  It says that the file isn't compatible with windows and it refuses to use it.  I've also tried hiding it in a legit windows exe, but that hasn't worked either.  And if I'm doing this part wrong please point that out too...
The "windows-software.exe" is the legit windows exe.  And hiding it within that file did not work either.  Same problem with it not opening.

I'm fairly confused about it.  I've spent a LOT of time checking out tutorials, reading forums, and watching videos, and everyone seems to follow the same steps, except NONE of them had this problem.

What I'm working with:
   My Machine:  HP Pavillion DM3Z with BackTrack 5R1
   Target:  HP Laptop... but it's running Windows 7

PS:  Both machines are mine on my network.