In this example we obtained local admin on the box, but wanted domain admin instead. Craig quickly spotted that a scheduled task runs as domain admin (ntbackup). We hoped to simply change the backup params to give us a shell but this was hopeless, and if you try replacing the the ntbackup executable with a simple cmd.exe windows file protection stops us. The simple solution was to let the scheduled task run, debug the process and insert our cmd process in its memory space. (if your attacker already has local admin.. you have issues..)
This video shows the attack under the debugger.. (post 2 probably does more of the explaining)








I`m really glad to see you've finally decided to leak more :)
About this post , this is really cool trick to jump from local-admin to domain-privileged accounts , but probebly it`s not the best nor something stealth in a real-world case. I`m sure you know much more effective tricks but I just share my personal comments.
In such case ( need to obtain domain-privileged credentials without wasting time on cracking hashes ) dll-injection tricks usually do the best. dll injection is now reliable,stealth and remotely possible. As always custom codes would be the most effective ones but there are tons of good tools out there to do it. Meterpreter payload(of Metasploit) is my favorite for this case. here is 1,2,3 :
1-Run meterpreter payload by exploiting a flaw or by simply running generated .exe payload
2-List and identify target process (which runs under a domain-privileged account)
3-Inject new instance of Meterpreter,or cmd.exe into it , or simply migrate current session of meterpreter into target process. note that migration is not reliable always.
Recent BlackHat talks , reveal even more tools/tricks/ways about the case :)
>About this post , this is really cool trick to
>jump from local-admin to domain-privileged
>accounts , but probebly it`s not the best nor
>something stealth in a real-world case.
I thought this was a real world example. It works on the target, doesn't that make it real-world?
By real-world , I mean tricks which can be used
in a real pen-test. Yes this trick works like a charm but , moving a debugger package (which is not common in a production network!) to compromised host make any admin catch something is wrong (maybe too late but...).
The second post about this topic how ever,
makes everything much more better, but it`s not
still ideal . why ? because it`s replacing a noticeable change in process,changing the way application should behave , and as this change generate a failed-backup warning,and...