Deny execution from %TEMP% (etc) directories.

[Garacesh]

We're seeing a spate of kids downloading emulators recently. Obviously this is a massive breach of copyright laws and we'd like to have no part in it. We can play whack-a-mole with blocking websites as we do with pirated mp3's but I don't feel that's enough. Pupils can't run exes from their user areas (nor can they save them there) but what they can do is run them out of a .zip file, which IIRC extracts to temp under AppData.

 

Is it just a matter of adding .exe, .swf etc as a Software Restriction Policy on %APPDATA%, %TEMP%, etc (or even C:\Users\%USERNAME%? Would that work?) or is there a 'better' way to do it?

[mavhc]

I just blocked everything and whitelisted only folders I could write to, but you should be able to block c:\users, and then whitelist c:\users\administrator etc

[DJ-1701]

Exactly the same, block, then allow what is needed. Best way to prevent infection as well.

 

Example attached... (htm in zip file as I can't add the htm directly )

 

Note: The example it does show items that are set to Restricted, this is a belts and braces approach, as if everything is disable by default, it should not be needed to Restrict individual items.

 

User Protection.zip

 

 

Additional Note: I apply this to standard domain user accounts, but you could place a group policy on the Computer Settings instead, if for example you have any local non-admin accounts (why?! ) that you want to block.

Edited November 28, 2017 by DJ-1701

[chazzy2501]

urgh, I've just done this. Disable all then allow specifics. I had trouble allowing .lnk files. (those you have to exclude on a machine and user level, I think because I use rollback gpo policies)

 

if you want to allow exe's on mapped drives you have to actually allow the UNC path not the mapped path.

 

This was too allow microbits (which means allow usb sticks, which means files could be copied to the c drive and executed even if you don't allow usb execution and have file filtering on doc storage) ((you can't stop c drive access btw, the old 127 trick poo))

[jthompson]

I can't believe nobody replied back in October 2016!

 

Also, check that you don't block .lnk files, which I think are included as restricted files in SRP by default.

[Garacesh]

Note: The example it does show items that are set to Restricted, this is a belts and braces approach, as if everything is disable by default, it should not be needed to Restrict individual items.

Not working.

These are the current policies in place:

But I can still run tools like Open Hardware Monitor from a memory stick (D:\)

I don't have a self-contained (as in just the .exe, no .dll's or other supplementary files) to check from a .zip file, but when trying to run the OHW I get an error that it can't find a file, so that looks like it's allowing the .exe to launch still.

 

((you can't stop c drive access btw, the old 127 trick poo))

You can disallow browsing to network shares, so if they do \\127.etc it won't do anything. This will also stop any shortcuts they may have made.

You can't stop a shortcut to \\localhost\c$ working though. Even if you disable creating shortcuts, there are ways around it.

[jthompson]

But I can still run tools like Open Hardware Monitor from a memory stick (D:\)

 

Are you testing that as a non-administrative user?

 

Also, our SRP is all configured under computer configuration. I remember reading somewhere that SRP under user configuration was unreliable for some reason.

[mavhc]

Don't put *.exe in the path rule, use Designated File Types

 

I really recommend Disallow by default

[Garacesh]

Don't put *.exe in the path rule, use Designated File Types

What, just '%AppData%\', 'D:\', '\\Server\PupilData\' etc?

 

I really recommend Disallow by default

 

After looking at this, I think I would prefer to work on a whitelist-only rather than a blacklist, but I don't feel comfortable doing that in a live environment. Might tinker around with it over the holidays though.

[DJ-1701]

Are you testing that as a non-administrative user?

 

Also, our SRP is all configured under computer configuration. I remember reading somewhere that SRP under user configuration was unreliable for some reason.

 

Good point about non-administrative user account, although if he has UAC on then it would most likely be restricted anyway (that's the reason why I use SRP under User Settings, which works for two schools).

 

Though I think the thing here which is the major step is actually Restricting the files by default and testing. If you're allowing them by default but disable a path it *should* work, but it is better to Restrict by default, and only open up certain areas you want them to do run items from, which helps against any Potentially Unwanted Applications.

[Garacesh]

Are you testing that as a non-administrative user?

 

Good point about non-administrative user account,

 

Sorry, to confirm, yes, I'm testing it as a non-administrative account, just a bog-standard pupil.

[DJ-1701]

Don't put *.exe in the path rule, use Designated File Types

What, just '%AppData%\', 'D:\', '\\Server\PupilData\' etc?

Haven't had an issue myself, but a certainly worth a try.

 

I really recommend Disallow by default

After looking at this, I think I would prefer to work on a whitelist-only rather than a blacklist, but I don't feel comfortable doing that in a live environment. Might tinker around with it over the holidays though.

Another very sensible idea. Also worth testing on a few known troublemakers though.

[jthompson]

When setting ours up, I think I used this as a guide - How to make a disallowed-by-default Software Restriction Policy. Building it as a whitelist SRP is a bit of work to begin with, but it's a more robust defense and doesn't generate much work once you've got it set up. Also, if something legitimate is getting blocked, it's usually fairly obvious and quick to fix.

[mavhc]

First apply the SRP rules to say the ICT suite, and your trusted beta testers, staff who can report errors properly and like tech.

 

If possible collect the failed events centrally.

 

I have something like:

 

Public Key Policies/Trusted Publishers Certificates

Issued To Issued By Expiration Date Intended Purposes

Impero Solutions Ltd GlobalSign CodeSigning CA - SHA256 - G2 29/05/2019 12:46:54 Code Signing

Microsoft Corporation Microsoft Code Signing PCA 07/03/2011 22:40:29 Code Signing

 

For additional information about individual settings, launch the Local Group Policy Object Editor.

Software Restriction Policies

Enforcement

Policy Setting

Apply Software Restriction Policies to the following All software files except libraries (such as DLLs)

Apply Software Restriction Policies to the following users All users

When applying Software Restriction Policies Enforce certificate rules

 

Designated File Types

File Extension File Type

ADE ADE File

ADP ADP File

BAS BAS File

BAT Windows Batch File

CHM Compiled HTML Help file

CMD Windows Command Script

COM MS-DOS Application

CPL Control panel item

CRT Security Certificate

dll Application extension

efi EFI File

eml Microsoft Email Message

EXE Application

fon Font file

HLP Help file

HTA HTML Application

INF Setup Information

INS INS File

ISP ISP File

jar JAR File

js JavaScript File

jse JScript Encoded Script File

MDB MDB File

MDE MDE File

MSC Microsoft Common Console Document

msg MSG File

MSI Windows Installer Package

MSP Windows Installer Patch

MST MST File

OCX ActiveX control

PCD PCD File

PIF Shortcut to MS-DOS Program

REG Registration Entries

SCR Screen saver

sct Windows Script Component

shb SHB File

SHS SHS File

sys System file

URL Internet Shortcut

VB VB File

vbe VBScript Encoded Script File

vbs VBScript Script File

WSC Windows Script Component

wsf Windows Script File

wsh Windows Script Host Settings File

xlm XLM File

 

 

 

Software Restriction Policies/Security Levels

Policy Setting

Default Security Level Disallowed

 

Software Restriction Policies/Additional Rules

Certificate Ruleshide

Impero Solutions Ltd

Security Level Unrestricted

Description

Date last modified 28/04/2017 15:14:35

 

Microsoft Corporation

Security Level Unrestricted

Description MS Office 2010

Date last modified 01/09/2016 10:42:55

 

DismHost.exe (10.0.14393.0); dismhost; Dism Host Servicing Process; Microsoft® Windows® Operating System; Microsoft Corporation

startlauncher.jar; 12 KB; 20/05/2016 14:40:35

worldedit-forge-mc1.7.10-6.0-beta-01.jar; 1312 KB; 08/12/2015 11:12:00

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

\\server\SIMS\setups\

\\domain.local\d\NetworkApps\*

\\domain.local\netlogon\*

\\domain.local\share$\SoftwareInstall\*

\\domain.local\sysvol\*

C:\$WINDOWS.~BT

C:\Program Files\*

[Garacesh]

Still not working as a computer policy.

I can still plug in a memory stick as D:\ and run Open Hardware Monitor.

And I've double-checked, EXE is in the 'Designated File Types' list.

[Steve21]

Any reason you're trying to do it like this? Normal way would be block all, then allow C drive etc. Else you'll going to have to update it for every letter etc etc

 

But it should be like D:\* if you're doing it that way normally (You're applying it to computers though, not users So guessing that's why nothings working in that regards)

 

Steve

[Garacesh]

Any reason you're trying to do it like this? Normal way would be block all, then allow C drive etc. Else you'll going to have to update it for every letter etc etc

 

But it should be like D:\* if you're doing it that way normally (You're applying it to computers though, not users So guessing that's why nothings working in that regards)

Because it's too late to do a whitelist only as we're 'live' and I don't reckon I have the time to fully test a whitelist-only solution.

I'd like to do that, but for now I just want to get the minimum infrastructure in place to stop what's happening right now.

 

I am doing it on computer policy now, but without *.. I'll add asterisks and see if that works.

[Garacesh]

Nope. Asterisks ain't working either

[Steve21]

How are you running it direct from D:\ or is it zipped etc? Just noticed you aren't blocking things like userprofile etc

 

Steve

[Garacesh]

How are you running it direct from D:\ or is it zipped etc? Just noticed you aren't blocking things like userprofile etc

 

Steve

 

Both.

 

If I run it from D:\ (more specifically: D:\OpenHardwareMonitor\OpenHardwareMonitor.exe) it launches fine. No mess, no fuss.

I remembered the \*\* entries mentioned earlier, so I've tested running it from just D: (D:\OpenHardwareMonitor.exe) and that still works, too

If I run the OHW exe from inside a .zip folder, I get a message coming up saying it couldn't find Aga.Controls.dll (which is simply because I'm not extracting the full folder contents, goes back to my mentioning I don't have an exe on its own that works without supplementary files) - I take this to mean that the exe is still running, looks for its supplementary files, can't find them and throws an error.

[Steve21]

Try these as they block it fine here, just tested with the same program too (doesn't get to any dll issue as it blocks the exe before that)

 

%userprofile%\*

D:\*

C:\Windows\temp\*

 

But we do ours as user not computer, so just wondering if the appdata one is confusing it if it's trying to read the appdata variable for the computer

 

Steve

[jthompson]

I take this to mean that the exe is still running, looks for its supplementary files, can't find them and throws an error.

 

I think that's correct. If the SRP prevents execution, you should see an error message explicitly saying so (something like "This application has been prevented from running by Group Policy. Please contact your network administrator.").

[Garacesh]

Try these as they block it fine here, just tested with the same program too (doesn't get to any dll issue as it blocks the exe before that)

 

%userprofile%\*

D:\*

C:\Windows\temp\*

Shall try this.

Edit: I'm already using 'D:\*' though, and that doesn't work.

 

I think that's correct. If the SRP prevents execution, you should see an error message explicitly saying so (something like "This application has been prevented from running by Group Policy. Please contact your network administrator.").

That's how I thought it should play out, aye.

[jthompson]

Is the policy definitely getting applied on the computer?

 

If you run

gpresult -h gpres.htm && gpres.htm

are your path rules listed in the output?

[Garacesh]

%userprofile%\*

D:\*

C:\Windows\temp\*

 

And the results are in: No change.

I've put them back in as User policies too, and, still nothing.

 

This isn't like the bloody IE settings where I haven't pressed F5 somewhere to enable something, is it? Like I'm setting all the policies but I've missed something somewhere so none of it is actually getting enforced?