User Controls
How To Integrate a Backdoor Into a Windows OS As a Shell of the OS Itself
-
2016-09-10 at 6:44 PM UTCWhat you'd want to do is wrap a malicious shell around a critical operating system component, in such a way that Windows is unable to operate without it.
Method: Wrap the malicious executable around the executable function itself
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\exefile\shell\open\command]
Key Value:
1.exe "%1" %*
Note: If 1.exe is removed or renamed from the system path, executable files will no longer be able to be executed
-
2016-09-10 at 11:37 PM UTC
What you'd want to do is wrap a malicious shell around a critical operating system component, in such a way that Windows is unable to operate without it.
Method: Wrap the malicious executable around the executable function itself
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\exefile\shell\open\command]
@=""1.exe %1" %*"
Note: If 1.exe is removed or renamed from the system path, executable files will no longer be able to be executed
For one you're throwing together a bunch of terminology here that really doesn't describe what you are proposing to do. Secondly if you set the key for
[HKEY_CLASSES_ROOT\exefile\shell\open\command] to ""1.exe %1" %*" all you are doing is running your 1.exe whenever any other executable is called. Fixing the problem here is trivial, you just open regedit.exe and set the value back to "%1 %*". Like it's supposed to be, there, problem solved.
-
2016-09-11 at 1:15 AM UTCListen, molester, like I said, if the 1.exe file is removed from the system path, no executables will be able to execute. The key not only runs 1.exe when an executable is started, it also makes it mandatory that 1.exe be in the system path to execute any executables. As for the key itself, not many people could even find it to change it back.
-
2016-09-11 at 1:20 AM UTC
Listen, molester,.
-
2016-09-11 at 1:43 AM UTCdidn't ADS get deprecated after windows XP?
-
2016-09-11 at 2:38 AM UTC
didn't ADS get deprecated after windows XP?
I could use a symbolic link to run the executable in ADS in Windows versions above WinXP. -
2016-09-11 at 1:16 PM UTC
Listen, molester, like I said, if the 1.exe file is removed from the system path, no executables will be able to execute. The key not only runs 1.exe when an executable is started, it also makes it mandatory that 1.exe be in the system path to execute any executables. As for the key itself, not many people could even find it to change it back.
I don't think changing the key for [HKEY_CLASSES_ROOT\exefile\shell\open\command] affects the environment variables. Also at aldra:
[greentext]> didn't ADS get deprecated after windows XP[/greentext]
Where was ADS mentioned in the thread.
-
2016-09-12 at 3:49 AM UTCI was under the impression he was trying to create an ADS bind on launch because the syntax is similar (though it's been a long time since I've looked at it)
""1.exe %1" %*"
if you're just doing shell execution I'm pretty sure that won't actually work; you'd want to do "1.exe && %*"
what your line translates to is
"1.exe firstparameter" actualprogram.exe firstparameter
you'd also want to use the absolute path unless 1.exe is in the windows folder or some other $path
^the registry shell handlers are separate to environment variables. for example if you double-click a .pdf, it checks the shell handler list in the registry to see what normally opens a pdf document and runs that command. you'd probably expect to find something like the following:
"c:/path/to/pdfreader %*"
what he's doing is adding a handler to exe files, so any time you try to run an executable, windows uses another program to try to open it, in this case something malicious
dunno what the practical utility here is though to be honest considering you need local admin to get into the registry in the first place -
2016-09-12 at 4:59 AM UTCThe value is:
1.exe "%1" %*
Anything else and it won't work.
The purpose is to force the target machine to keep 1.exe in place on the system.
The registry automatically looks for the file in %WIN% and %SYSTEM%. You don't have to specify a PATH.
If 1.exe is removed from the system or renamed, the system will be unable to execute any EXE files at all. That means starting a random executable not only starts 1.exe, but also, the starting of that random .exe is dependent on having 1.exe in the %WIN% or %SYSTEM% or root of the drive, or the specified PATH if desired. Remove the 1.exe and you can no longer start any executable.
Try it for yourself. Copy regedit.exe and rename in regedit.com, start regedit.com, add the key, take calc.exe and rename it 1.exe and put it in the Windows system folder. Now start mspaint.exe. You will see 1.exe will also start. Now delete 1.exe. Try and start mspaint.exe again. Can't. Put 1.exe back in the system folder. Now mspaint.exe starts normally. -
2016-09-12 at 5:27 AM UTCOk, now instead of describing a persistence technique. Tell me a scenario where you would actually be able to do this remotely, and how you personally would employ this method.
-
2016-09-12 at 6:03 AM UTCMost trojan front ends have remote registry read/write capability, so it's simply a matter of pressing a couple of buttons and the target machine's registry is right there. For example, after port scanning IP ranges for open known trojan ports, finding a few dozen that aren't honey pots, logging into them with the corresponding front ends after cracking the passwords, whatever, upload server with registry access, lock the r00tkit executable file into place using the registry key... most users would probably try and delete the file, then undelete it and restore it when they found out it broke everything. This provides the intruder more time to use the connection for various nefarious purposes, before the key is finally discovered.
-
2016-09-12 at 1:41 PM UTC
Most trojan front ends have remote registry read/write capability, so it's simply a matter of pressing a couple of buttons and the target machine's registry is right there.
Using a trojan that you did not write yourself and controlling it with a GUI instead of a terminal is skid tier.For example, after port scanning IP ranges for open known trojan ports, finding a few dozen that aren't honey pots, logging into them with the corresponding front ends after cracking the passwords, whatever
Malware usually has a hardcoded IP address or domain for their C&C. One does not simply 'scan for common trojan ports' and expect to takeover individual boxes that have been infected. Ever heard of this principle called whitelisting?upload server with registry access
It's not wrong but it's uncommon to call it a server in the context you're talking about.lock the r00tkit executable file into place using the registry key… most users would probably try and delete the file, then undelete it and restore it when they found out it broke everything.
Rootkits, traditionally, have other persistence mechanisms than the registry.
-
2016-09-12 at 2:04 PM UTC
Most trojan front ends have remote registry read/write capability, so it's simply a matter of pressing a couple of buttons and the target machine's registry is right there. For example, after port scanning IP ranges for open known trojan ports, finding a few dozen that aren't honey pots, logging into them with the corresponding front ends after cracking the passwords, whatever, upload server with registry access, lock the r00tkit executable file into place using the registry key… most users would probably try and delete the file, then undelete it and restore it when they found out it broke everything. This provides the intruder more time to use the connection for various nefarious purposes, before the key is finally discovered.
This is so 2009, man. Right now it's all about 0day java/extension/applet driveby installs. Sure, there's probably thousands of machines with subseven on them (probably old XP boxes running in hydroelectric dams or factories), but this is really old.
Also, one technique that probably never fails is to email a small group of people an email with "boobs.jpeg.exe" attached. Ok, it'll be a bit more complicated than that due to gmail not even allowing exe to go through, but if you invest like, 30 more minutes into building a phishing site and stuff, you'll get better results.
-
2016-09-12 at 7:06 PM UTC
Sure, there's probably thousands of machines with subseven on them (probably old XP boxes running in hydroelectric dams or factories), but this is really old.
Not thousands. Millions. New trojans still come out every day, operating on new port numbers, and they still work perfectly on Windows versions above WinXP, right up to the most recent version. Nothing has changed since the '90's. If you were to scan IP ranges right now for modern known trojans on their corresponding ports, you would still get hundreds of hits in just a few hours, especially if you use an ultra-highspeed "half-open" port scanner.
