
Hiding malware in Windows: The basics of code injection - buba
https://prdeving.wordpress.com/2018/09/21/hiding-malware-in-windows-code-injection/
======
Someone1234
This 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...](https://en.wikipedia.org/wiki/Windows_10_editions#Comparison_chart)

~~~
rasz
The second best thing you can do is Egress whitelisting. This can be done on
stock W10 after disabling dnsmasq (dnsmasq acts as a hole thru windows
firewall).

~~~
atesti
Do you have more information about this dnsmasq? Is it really a part of
windows?

~~~
rasz
eh, I meant dnscache service.

------
cryogenic_soul
Bit off topic, but in some sense, I really miss old DOS/Windows virus scene. A
lot of people was writing viruses just for fun, and they were inventing very
clever technics, such as polymorphic/metamorphic code or advanced anti
debugging/disassembling tricks (which nowdays you can find in Denuvo :D ).
Nowdays most of the malware are just money grabbers without any art in them,
as a proof of my words - till now nobody were able to beat Z0mbie's "Zmist"
from 2002

[https://en.wikipedia.org/wiki/Zmist](https://en.wikipedia.org/wiki/Zmist)

~~~
stevekemp
Reading that reminds me of "The Whale":

> The Whale virus is a computer virus discovered on July 1, 1990. The file
> size, at 9,216 bytes, was for its time the largest virus ever discovered. It
> is known for using several advanced "stealth" methods.

From:

[https://en.wikipedia.org/wiki/Whale_(computer_virus)](https://en.wikipedia.org/wiki/Whale_\(computer_virus\))

At the time, as the wikipedia page says, I was amazed at the size of the
thing! I got a couple of my own (academic) creations included in various
lists, and at the time I was completely amused that they often had such gems
as "Origins: Romania".

I was never terribly invested in the scene, but I did read a lot of the zines,
40hex, and similar, and because I was interested in low-level coding I would
often decompile virus-samples and experiment with similar techniques,
especially when the polymorphic engines started to appear.

------
rossdavidh
"Hiding"

~~~
saagarjha
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.

~~~
jermaustin1
They were referencing the misspelled title of the post.

~~~
saagarjha
Ah. It seems like the title has been changed, so I didn't catch that.

------
sebazzz
Aren't administrator permissions necessary to write in the other process
memory?

~~~
blincoln
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.

~~~
saagarjha
> 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.

~~~
blincoln
> Xcode works just fine on non-root accounts

Are you sure that attaching to a process (for debugging/memory-modification)
in general does on modern versions of Mac OS?

"In order to guarantee support for debugging on the Mac, you need to log in on
the Developer Tools Access dialog box using the administrator or root user
password" [1]

"DTrace requires admin privileges" [2]

[1]
[http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Acquiring_...](http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Acquiring_Permission_to_Support_Debugging_on_a_Mac)

[2] [http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-
scr...](http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-scripts-for-
mac-os-x/)

~~~
saagarjha
That's consistent with I'm saying. You do not need to be root to attach to a
process on macOS; you merely need to be part of the _developer group. I
believe admins are added to this group by default, but you can do it manually
if you wish. If you don't, you'll need to type the password of an admin user
before you can debug anything.

~~~
blincoln
Unfortunately, I don't have access to a machine to test with - my statement
was based on a lengthy discussion from a few months ago at a previous job -
but I'll assume you're correct, and amend my original statement to "Mac OS is
the only mainstream OS I know of that disallows debugging by non-privileged
user accounts entirely." Thanks :).

------
autokad
Does anyone got any ideas (or know any posts) on how machine learning can be
used to detect these types of attacks?

