Hiding malware in Windows: The basics of code injection
prdeving.wordpress.com
Hiding malware in Windows: The basics of code injection
1–10 of 24 posts
Re: Hiding malware in Windows: The basics of code injection
#2Aren't administrator permissions necessary to write in the other process memory?
Re: Hiding malware in Windows: The basics of code injection
#3Aren't administrator permissions necessary to write in the other process memory?
This is mentioned as one of the mitigation techniques.
>don’t give admin permissions to random applications
Re: Hiding malware in Windows: The basics of code injection
#4"Hiding"
Re: Hiding malware in Windows: The basics of code injection
#5This might be the wrong venue but with the popularity of randomware and more complex malware attacks, I'm saddened that one of Microsoft's premiere safety technologies, AppLocker, is license restricted.
AppLocker is system-wide whitelisting for those unaware. You can restrict which executables can execute based on a number of criteria of your choosing.
At work I have access to AppLocker thanks to our Enterprise editions. But at home, when I'm setting up relative's PCs (or even my own) I am lacking one of the most powerful tools in my arsenal.
Microsoft should CONSIDER putting AppLocker in retail editions, Enterprise still has a huge number of benefits beyond that[0], and you'd still not be able to centrally manage it. It would make the world better/safer place.
Keep in mind that BitLocker used to be Enterprise edition only too, but Microsoft came around to realizing that it had huge benefits for all users. AppLocker is the same way.
[0] https://en.wikipedia.org/wiki/Windows_10_editions#Comparison...
Re: Hiding malware in Windows: The basics of code injection
#6Aren't administrator permissions necessary to write in the other process memory?
Only if one is writing to a process running under a different user ID. Non-privileged users can write to the memory of their own processes.
Linux used to be similar (and I think some distributions still are), but is now slightly more restrictive, in that processes running as non-root user accounts can only debug child processes they've launched, as opposed to other processes running under the same user account. It can still be used for hiding extra code, of course.
Mac OS is the only mainstream OS I know of that disallows debugging by non-root user accounts entirely.
Think of it this way - on a shared system (e.g. a Linux server) how would developers debug their code in e.g. gdb if they couldn't attach to a process that they'd launched, and interact with it at a low level? Apple can avoid supporting that scenario because they no longer sell systems intended for use my multiple people at the same time, and a developer on a Mac will have sudo permissions as root.
Re: Hiding malware in Windows: The basics of code injection
#7This might be the wrong venue but with the popularity of randomware and more complex malware attacks, I'm saddened that one of Microsoft's premiere safety technologies, AppLocker, is license restricted. AppLocker is system-wide whitelisting for those unaware. You can restrict which executables can execute based on a number of criteria of your choosing. At work I have access to AppLocker thanks to our Enterprise editi…
Doesn't BitLocker only come with the more expensive pro release?
Re: Hiding malware in Windows: The basics of code injection
#8Aren't administrator permissions necessary to write in the other process memory?
Only if one is writing to a process running under a different user ID. Non-privileged users can write to the memory of their own processes. Linux used to be similar (and I think some distributions still are), but is now slightly more restrictive, in that processes running as non-root user accounts can only debug child processes they've launched, as opposed to other processes running under the same user account. It ca…
> Mac OS is the only mainstream OS I know of that disallows debugging by non-root user accounts entirely.
This isn't true; Xcode works just fine on non-root accounts. You will need to get permission to debug anything from an admin user, or add yourself to the developers group. And if you want to debug a system binary you'll need to disable SIP.
Re: Hiding malware in Windows: The basics of code injection
#9"Hiding"
This is probably enough so that the majority of users would not be able to find it. I probably wouldn't, unless the process ended up using excessive resources and I sampled it.