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

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).

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

eh, I meant dnscache service.

Do you mean "whitelisting" or is a term I've never heard of?

Thanks, typo fixed.

Doesn't BitLocker only come with the more expensive pro release?

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

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)

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.

"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.

They were referencing the misspelled title of the post.

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

Aren'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.

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

> 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_...

[2] http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-scr...

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.

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 :).

This is mentioned as one of the mitigation techniques. >don’t give admin permissions to random applications

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