Hello,
There is only one answer to the question you are asking, and the answer is that what you are asking for is literally impossible. You cannot "completely" secure any system even with programs let alone without any security software, because absolutely nothing in this world is perfect and full-proof.
Malware is evolving constantly and therefore the layered protection mechanisms we have in place today may not be good enough to prevent a new attack tomorrow or next week, therefore security vendors are forever rushed around constantly to alter their behavioral protection engine to be adapted towards protecting against both the old and newer attack vectors, alongside the other static-based engines which are responsible for picking up a detection for already existent and known malware which was previously in the wild.
The first thing you can do is attempt to use a standard user account (which is therefore restricted in terms of what it can do, therefore the running programs also become limited), however this does not automatically mean you can no longer be infected... At the end of the day, it really depends what the malware is actually trying to do, and how sophisticated the sample really is; you can find samples out there which will only function if granted administrative privileges, however there are also samples which do not need to perform activities which are usually restricted (and therefore will function fine on a standard user account). Therefore, if you do happen to use a standard account, don't go around thinking you're full-proof because you'll be far from it in reality.
The second thing you can do is make sure that User Account Control is enabled, since if this feature which has been built-in to Windows since the start of Windows Vista is used correctly, then it can be very effective at keeping your OS software cool from a malware infection. The problem is that many people out there are misguided on how to use the feature correctly, and believe that it should just "magically" prevent malware infections... This was not how it was designed to work, ever, period. It was designed to prevent programs which were running which did not need additional permissions from doing things that they do not have the rights to do, and in count this also better protects your system even if the program is indeed trusted, since it lowers the risk of malware being able to exploit it (e.g. hijack it) to perform activities from an elevated process which should not be done (bypassing a UAC prompt as well, sneakily in the background).
The third thing you can do is make sure that SmartScreen is enabled for system-wide usage (if you're on Windows 8 or above), since this is also another great feature built-in to Windows... It works via a cloud reputation network to the Microsoft servers, therefore unknown programs can be blocked from running at the first launch attempt without further user interaction, and it will also be capable of blocking programs without proper verification of a digital signature (code signing authentication) - this is important because people can release malware which claims to be from a specific vendor, however you can check the digital signature to make sure it comes from who they claim it comes from (e.g. Avast, Piriform, McAfee, Adobe, Google, Microsoft, etc.). More richer and popular companies will tend to make sure they are protected with code signing authentication, which helps provide better trust of using their software to the users and prevents infringement attempts on their identity (identity theft).
Blocking all non-digitally-signed programs might work, however this isn't really a reasonable thing to do because there are many pieces of software out there which are genuine and really helpful, but fail to have a digital signature. Many developers (especially now) are at school/University, or at least undergoing some form of education, and may not even work... Therefore, to them a digital signature can seem quite expensive, even if it really is only around £100-£150 for 1 year code signing authentication.
However, you cannot really block only this without using any software, because you won't be able to make use of Anti-Virus signature-based detection to block already known malware from the wild, or make use of any of their behavioral zero-day protection mechanisms to catch out new threats based on heuristic identification methods.
Once again, you won't be able to make use of signature-based detection from vendors with countless stacks of millions of checksum signatures for detection, or their zero-day protection mechanisms.
If browser extensions are allowed then you can make use of uBlock Origin and an independent malicious web filter extension (e.g. from Avira or Bitdefender) for extended protection. Blocking advertisements is highly beneficial since this will reduce your risk of being a victim of malvertising.
Malvertising is the practice of placing malicious advertisements on the web-page; these malicious advertisements can cause a drive-by-download attack, an exploit attack, or just redirect you to another malicious URL (which may also attempt to perform such attacks).
In more serious cases of malvertising, the attacker (hacker) will hijack a perfectly known and "trusted" website to replace advertisements with their own malicious ones, guaranteeing that many innocent users will fall into the attackers trap by having those malicious advertisements loaded before an AV company can add the host domain to their filters... Or they will hijack the server owned by an advertisement service and replace advertisements there with their own, causing a number of websites which are making use of dynamic linking to load the advertisement (instead of static loading) to become compromised.
That being said, most mainstream browsers like Google Chrome have decent mechanisms in place in the scenario of a web-based exploit attack already; an example would be the sandbox container, and they tend to run with standard rights, therefore in the case of an remote code execution exploit, the malicious code won't be able to do as much damage as it could do from an elevated process, and probably won't even be able to escape the sandbox container. On Google Chrome I believe it's called AppContainer. Other browsers like Microsoft Edge, Opera and Firefox also have some sort of sandbox container also I believe, feel free to correct me if I'm wrong. Therefore, stay away from new and unknown browser software without doing proper research, because the chances are that those small-time projects are not very secure at all.
Anyway, the point of an exploit is to use an vulnerability as an advantage, therefore if you cannot block the exploit based on the behavior of the program being affected (e.g. HitmanPro.Alert might be able to do this) or based on signatures (most anti-exploit just get hold of exploits or potentially even purchase them themselves so they can create byte-detection for identification), then there isn't much you can do once it starts apart from shutdown your system very quickly (hold down the power button). But, by then it'd have been to late, as you won't know when it hits you... They're meant to be concealed as much as possible, and exploits come at a very expensive price depending on the scenario on the dark web for example.
You can change protection settings to stop writing to the USB device, and you can also block AutoRuns from them... However, by default without any additional software, if you plug-in a USB affected by an exploit like BadUSB then it's game over. This is why software like HitmanPro.Alert is useful, because they are capable of blocking exploits like BadUSB based on the behavior on-going without relying on signatures.
BadUSB is a firmware infection just so you know, which causes malicious code to execute once a USB is plugged into another system without relying on AutoRun functionality.
No. However it really depends on what you expect to do... If you expect to improve the system security a bit, then the answer is yes, but if you expect to block anything sophisticated then the answer is no, period.
The Windows folder is protected with DACL and therefore you cannot drop programs to it, or overwrite the bytes of any PE files within it (e.g. for patching attempts) if the process is not elevated, however malware doesn't really need to copy itself across to the Windows area at all. This is all just a misconception and I used to be misunderstood by it also... People only attack these areas to hide their malicious samples when they've been dropped after downloading them from a server or after extracting them from resources (for example) because it's good for concealment (there are so many files within the Windows folder that an innocent user will definitely not be capable of going through them all and identifying is a program is not supposed to be there or not, and even if they had a trigger of suspicion they most likely won't go looking there).
Some malicious software will also claim to be a Windows process, by setting it's PE name to "explorer.exe", "lsass.exe", "winlogon.exe", or even more common, "svchost.exe". However, in this scenario, the malware cannot be copied to System32 because there would already be a program there with that name (and executing as a critical process - except explorer.exe which is not a critical process since it can be restarted for obvious reasons - preventing you from terminating to replace the PE in that system location, even if you did have administrative rights). You'd have to patch the Windows program at boot before they've been started otherwise you'd trigger a BugCheck CRITICAL_PROCESS_DIED BSOD crash, which is still good for causing an instant and unexpected BSOD if you needed the system to restart for your malware to function.
Malware won't need to drop to the Windows areas to add to start-up either, and adding to start-up via an AutoRun modification for the current user won't even require administrative rights. As well as this, the Task Scheduler can be abused to cause a program to start-up at boot when the user signs in (even bypassing the UAC alert, which is exactly how Piriform did it for CCleaner).
It really depends on what version of Windows is being used, and this is exactly why it's important to stay up-to-date with the latest version of Windows (e.g. upgrade to Windows 10). I understand why not everyone may necessarily upgrade: Windows 7 is the best as usual, blah blah... Simply because it's more lightweight and provides more freedom in terms of privacy, however the truth is that it's not as secure as Windows 10, no matter how many security patches you do. Those security patches will not replace existent features embedded within the actual OS kernel to the latest versions to strengthen you against rogue attacks such as rogue device drivers from rootkits, and I cannot stress enough how important it is for these things to stay updated. For example... PatchGuard!
For starters, on Windows XP it is possible to actually hook the System Service Dispatch Table entirely from user-mode, I believe though memory-related attacks. This alone is deadly, and the same thing could originally be replicated on Windows Vista with slight changes to the method, however I believe it was fixed through security patches. I remember reading a very old paper on it a few years ago which was written probably in 2009 I believe, I'll see if I can find it to resource it here for you to read on, it was very interesting - I did try to re-implement the functionality myself however it did not work as expected and with limited time to do it I had to stop trying to do that.
See, this is what you would expect! The truth is that you can load device drivers without being registered through the Service Control Manager, meaning you won't have to even call OpenSCManager, CreateServiceA/W and then StartServiceA/W to load a device driver on the system.
One rootkit method to load a device driver without having to use the service manager directly would be through NtLoadDriver, which is exported by the NTDLL.DLL module (which is a system call wrapper for Native API functions, which are used by the stubs of Win32 API functions). The way it works is you perform some registry modifications at "Registry\\Machine\\System\\CurrentControlSet\\Services\\" and then you call NtLoadDriver passing in the name of your service which you registered at the registry. It'll find the newly stored information in the registry and use it to load the system file at the target from the information left in the registry, preventing you from needing to work the service manager yourself.
The second rootkit method (which may not even necessarily work depending on the OS version) would be through NtSetSystemInformation, which is actually used by the system itself to load a device driver (on previous OS versions at least). In the end, it'll leave a trail to even lower functions in the kernel (Ke* functions for example). I originally learnt about this from CodeProject a couple years ago, and from a book I read a few years ago... You can probably find some resources on this one from a Google search. Comodo LeakTest won't test for this one, but it will definitely test the NtLoadDriver method because it triggered by BB/HIPS project during testing since I covered this rootkit device driver load attempt.
If we go even further backwards in time, on Windows 98 there's a function called NtKernLoadDriver - that's a quick fact you probably didn't know.
There are other methods of loading device drivers, and with DKOM manipulation you can conceal evidence of a device driver being loaded by causing user-mode software (and even kernel-mode code) to believe it's not even running. This can be done through SSDT hooking and DKOM (Direct Kernel Object Manipulation), two very famous methods related to kernel-mode rootkits on x86 systems.
You can hide a service just by hooking a function like EnumServicesStatusEx anyway.
To be honest with you, even though me and you might say they normally use IAT hooking, most malware authors trying to do this sort of thing nowadays are mostly beginner in the topic area of API hooking and are just copying off forum example code to do it... Most of the time they don't even alter the Import Address Table also, but just get the address of the target function and perform a hotpatch (overwrite the first instructions to form a JMP <addr>, and on x64 processes you can: MOV RAX, <addr of callback> and then call JMP RAX).
However, in terms of rootkit development, I would recommend hooking the Export Address Table if you are injecting code into processes as they start-up; this will cause programs to get your address anyway. You can also hook the IAT too if you need too... Or just mix and match for specific functions depending on what you're trying to do. Just watch out for custom wrappers of GetProcAddress, because they aren't difficult to write and will bypass things.
You can also enumerate through all the modules within the process, or hook LdrLoadDll to identify when new modules are being loaded (hooking LoadLibraryA/W would not be sufficient since it can be bypassed with a custom wrapper once again), and then you can hook for those modules also. Since, if you hook for NTDLL when you have injected your code into the process, all it'll take is the process to map ntdll.dll into memory and copy across the functions from memory to a byte array with memcpy and then execute that for system call attempt, or just call the functions from the ntdll.dll copy (renamed of course) if you don't hook for the other modules too... Most rootkits forget this, leaving open a gap to stop them or bypass their control. As well as this, samples can hard-code in the bytes for a system call attempt to a specific function without worrying about future changes, because important and critical functions like NtOpenProcess won't be changed in future versions of Windows; programs on previous OS versions are already too dependent on them, therefore Microsoft would never change the NTAPI stub to it... They'd just create a new function with the Ex* prefix as seen in the past, so static hard-coded system calls would work perfectly fine and would do the job. That's another barrier to cross in rootkit development, as you'll want full control, which is why kernel-mode rootkits are more suited for the job.
Normally the launcher will gain debugging rights from lsass.exe (Debugging Rights), however lsass.exe is not a critical process I do not believe since programs need to allocate memory into it and write to it for some sort of IPC mechanism I believe for transitioning of new privileges (could be wrong with this one), therefore it is a vulnerable and potential attack vector for exploitation to gain privileges which should not be granted without permission.
With debugging rights, you can open a handle to processes running under SYSTEM. However, as I was saying earlier, newer versions of Windows are much more secure against malware attacks alone just based on the improvements to the actual built-in system processes and functionality...
For example, csrss.exe can be used on Windows Vista and Windows 7 to shutdown Anti-Virus software by injecting code into it to scan all opened handles, and then find the handle to the AV product and call TerminateProcess against it (or another function). To do this, all you'll need is debugging rights... Whereas, since Windows 8, system processes like csrss.exe have become protected processes and therefore you cannot open a handle to these protected processes from user-mode (not from opening a handle nor duplication attempts, since NtDuplicateHandle used to be a work around to counter the ObRegisterCallbacks protection before AV vendors realized you could use it to block handle duplication as well... And yes, some vendors did forget about that haha).
It's just the little details do count a lot, and things like protected processes really improves the system and keeps it better protected against attacks like rootkits. Imagine if I could inject my code into csrss.exe, I can think of a lot I could do: hook CsrCreateProcess to obtain a handle to all newly executed programs -> inject code. Wouldn't even need to use a device driver with PsSetCreateProcessNotifyRoutineEx, even better!
You can use AppInit_DLLs to force any program which loads User32.dll to load your DLL (only if it's the same architecture as the DLL set to be loaded), and you can also use SetWindowsHookEx to inject code from a remote DLL into any program which loads User32.dll also. The only way to block this would be to: hook LdrLoadDll (local hook) prevent the AppInit_DLLs (I believe) or a kernel-mode callback to PsSetLoadImageNotifyRoutine (and then deal with the module being loaded into your process); patch GDI functions in win32k.sys or work with the hyper-visor to block SetWindowsHookEx attacks. You can't just hook SetWindowsHookEx since it's used for built-in Windows functionality (when you drag the window and move it around that it causes other programs to minimize, this is thanks to SetWindowsHookEx being called in the background for example, so by hooking and preventing it entirely you'd be losing out on Windows functionality for user experience).
-----------------------------------------------------
Moving on from the above, by using a x64 version of Windows alone you'd be staying better protected as well, since most kernel-mode rootkits are adapted for x86 versions of Windows (they usually work with SSDT hooking and DKOM which are prevented by PatchGuard on x64 systems thanks to PatchGuard/Kernel Patch Protection).
As well as this, on x64 versions of Windows you're better protected against the loading of rogue unsigned drivers... However, the counter to this would be obtaining administrative privileges and then running bcdedit.exe -TESTSIGNING ON (and then calling NtRaiseHardError to cause a BSOD crash so the system restarts -> now at boot load your unsigned device driver).
As for administrative privileges, if you're dealing with a user who doesn't know what they are doing, just trick them into believing the alert is for something like Adobe Flash Player or work with other social engineering tricks to cause them to run it. Let's be honest, a lot of infections are done to using UAC incorrectly, and even after all this time people just never seem to learn.
-----------------------------------------------------
I recon one of the most powerful things a rootkit could do to support both x86 and x64 would be to gain administrative privileges via social engineering factors (or an exploit, and on previous versions of Windows like Windows 7 it is much easier to exploit features like UAC as have others done many times in the past, remember UACME from the kernel-mode forums?) and then install a device driver, and then from within this device driver just work with the hyper-visor to virtualize all the running programs. Since the hyper-visor would be being used, you'd then have access to perform kernel-mode hooking (e.g. MSR hooks) without worrying about PatchGuard/Kernel Patch Protection, even on x64 systems!
And that is exactly how Kaspersky protect the system via the hyper-visor, they don't need to worry about Windows kernel-based protection mechanisms since they use real virtualization, and Comodo do this for their auto-sandbox also.
You can be even more powerful... Why use files? Use a driverless driver, don't use anything that isn't necessary. If you don't go around setting hooks then these hooks won't be detected, and if you need to use specific functions not available by default in kernel-mode then find the address or scan SSDT to get the target function (without setting hooks). Just keep everything concealed.
------------------------------------------------------
TLDR; there's nothing you can do to stay fully protected but doing it without any real security software is even stupider... However, if you know what you are doing and are careful and watch what websites you visit and what you download and what devices you plug-into your system then you can not become infected without any protection. However, even if you decide not to use a security product like an AV, it'd be wise to at least use an adblocker on your browser at-least.
Enjoy the read,
Wave.
