Preventing exe running by name or checksum

I seem to recalled seeing a long time ago in a meeting about AD, that
there would be a feature where you could prevent an exe from being
executed on the domain with a setting. The example they gave, you could
prevent users from playing minefield.exe and you would simply enter that
name in the appropriate setting. A smart user could rename the file to
something different and it would still run, so they allowed you to
prevent based on a checksum rather than a specific file (helps with
virus which change their names).

Anyone know if this feature made it into AD? Perhaps vista?

Wjr,

wjr wrote:
> I seem to recalled seeing a long time ago in a meeting about AD, that
> there would be a feature where you could prevent an exe from being
> executed on the domain with a setting. The example they gave, you could
> prevent users from playing minefield.exe and you would simply enter that
> name in the appropriate setting. A smart user could rename the file to
> something different and it would still run, so they allowed you to
> prevent based on a checksum rather than a specific file (helps with
> virus which change their names).
>
> Anyone know if this feature made it into AD? Perhaps vista?

The "feature" you're searching for is called "Software Restriction
Policies" and is part of Active Directory since Windows 2000. It's a
Group Policy feature. Hitting "Software Restriction Policy" into Google
will bring you to a bunch of sites on how to set this up.

cheers,

Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste

Howdie!

Florian Frommherz [MVP] wrote:
> is part of Active Directory since Windows 2000. It's a

That part, I take back: it's there since Server 2003 and XP.

cheers,

F.
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste

Florian Frommherz [MVP] wrote:
> Wjr,
>
> wjr wrote:
>
>> I seem to recalled seeing a long time ago in a meeting about AD, that
>> there would be a feature where you could prevent an exe from being
>> executed on the domain with a setting. The example they gave, you
>> could prevent users from playing minefield.exe and you would simply
>> enter that name in the appropriate setting. A smart user could rename
>> the file to something different and it would still run, so they
>> allowed you to prevent based on a checksum rather than a specific file
>> (helps with virus which change their names).
>>
>> Anyone know if this feature made it into AD? Perhaps vista?
>
>
> The "feature" you're searching for is called "Software Restriction
> Policies" and is part of Active Directory since Windows 2000. It's a
> Group Policy feature. Hitting "Software Restriction Policy" into Google
> will bring you to a bunch of sites on how to set this up.
I couldn't for the life of me remember what is was called and I searched
on a few things with no results. Then I thought it might have been a
vista feature. Thanks!

Florian Frommherz [MVP] wrote:
> Howdie!
>
> Florian Frommherz [MVP] wrote:
>
>> is part of Active Directory since Windows 2000. It's a
>
>
> That part, I take back: it's there since Server 2003 and XP.
>
> cheers,
>
> F.

Wanted to recommend this to a customer site, because of this e-card.exe
exploit that people are clicking on. Not sure if this can be used to
prevent e-card.exe in an email from running, but I hope so. When will
people learn not to run these things? And they use Trend AV, which
doesn't seem to do so well in these situations.

Wjr,

wjr wrote:
> Wanted to recommend this to a customer site, because of this e-card.exe
> exploit that people are clicking on. Not sure if this can be used to
> prevent e-card.exe in an email from running, but I hope so. When will
> people learn not to run these things? And they use Trend AV, which
> doesn't seem to do so well in these situations.

Good approach - that should work. But to be honest: people will never
learn. In fact, you'll never ever find a technical restriction on
something that in the end depends on human interaction and their ability
to make the choice between "dancing pigs" and security.

I've seen a partner company of ours do something really cool: Depending
on what budget you have and how willing your customer is, you could have
a "afternoon party" with snacks and drinks (non-alcoholic of course) for
those people and train them on how to separate "good" mails from "bad"
mails and attacks from all kinds (social engineering, evil co-workers
and stuff) just to get them a better sense of how they can protect
themselves. Tell them all of this stuff applies to their computers at
home too -- and that their credit card might be electronically stolen.
People hate training they think they can't use -- but people love
parties. Parties with drinks and food, they love even more.

cheers,

Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste

In addition to Florian's "social conditioning" suggestion :-), I would
suggest several steps for the e-card exploit. Software Restriction Policy
"hash" rules will work assuming there are not different versions of the exe
floating around out there. If there are, then you would need to create a
hash rule for every version. You could also using the Admin Template policy,
in addition to the hash rule, that blocks code of a certain name. The
combination of both might be a good line of defense here. Finally, if folks
are downloading this from email or the browser, typically when they do that
and click "Run" or "Open" (assuming they click open or run and not save
first), the file is usually downloaded to a temp folder prior to executing.
You can also use Software Restriction policy to create path rules to prevent
code execution. For example putting %temp% or the Temporary Internet Files
path in as a disallowed path might prevent anything that is downloaded and
run from executing. It could of course, impact other legitimate user actions
so you will probably want to test thoroughly first, with your users, but it
is definitely another step you can take.

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy

*******************************
Secure and configure your Windows desktops accurately every time without
having to learn or install new technology.
Find out more about Desktop Policy Manager at
http://www.sdmsoftware.com/desktop_management
*******************************
"Florian Frommherz [MVP]" <florian@frickelsoft.DELETETHIS.net> wrote in
message news:%231KtdD6BJHA.1628@TK2MSFTNGP03.phx.gbl...
> Wjr,
>
> wjr wrote:
>> Wanted to recommend this to a customer site, because of this e-card.exe
>> exploit that people are clicking on. Not sure if this can be used to
>> prevent e-card.exe in an email from running, but I hope so. When will
>> people learn not to run these things? And they use Trend AV, which
>> doesn't seem to do so well in these situations.
>
> Good approach - that should work. But to be honest: people will never
> learn. In fact, you'll never ever find a technical restriction on
> something that in the end depends on human interaction and their ability
> to make the choice between "dancing pigs" and security.
>
> I've seen a partner company of ours do something really cool: Depending on
> what budget you have and how willing your customer is, you could have a
> "afternoon party" with snacks and drinks (non-alcoholic of course) for
> those people and train them on how to separate "good" mails from "bad"
> mails and attacks from all kinds (social engineering, evil co-workers and
> stuff) just to get them a better sense of how they can protect themselves.
> Tell them all of this stuff applies to their computers at home too -- and
> that their credit card might be electronically stolen. People hate
> training they think they can't use -- but people love parties. Parties
> with drinks and food, they love even more.
>
> cheers,
>
> Florian
> --
> Microsoft MVP - Group Policy
> eMail: prename [at] frickelsoft [dot] net.
> blog: http://www.frickelsoft.net/blog.
> Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste

Darren Mar-Elia wrote:
> In addition to Florian's "social conditioning" suggestion :-), I would
> suggest several steps for the e-card exploit. Software Restriction
> Policy "hash" rules will work assuming there are not different versions
> of the exe floating around out there. If there are, then you would need
> to create a hash rule for every version. You could also using the Admin
> Template policy, in addition to the hash rule, that blocks code of a
> certain name. The combination of both might be a good line of defense
> here. Finally, if folks are downloading this from email or the browser,
> typically when they do that and click "Run" or "Open" (assuming they
> click open or run and not save first), the file is usually downloaded to
> a temp folder prior to executing. You can also use Software Restriction
> policy to create path rules to prevent code execution. For example
> putting %temp% or the Temporary Internet Files path in as a disallowed
> path might prevent anything that is downloaded and run from executing.
> It could of course, impact other legitimate user actions so you will
> probably want to test thoroughly first, with your users, but it is
> definitely another step you can take.
>
Thats a good approach. I would assume that this is kind of standard
proceedure but not sure. Any tools out there to help automate this and
perhaps make some good default settings?

There are a bunch of articles on TechNet about SRP. I would check those out
as a starting point. You can create rules fairly easily through the GP
Editor UI, once you understand how they work.

In terms of automation, without being too self-serving, the only automation
mechanism available for SRP is the one my company (sdmsoftware.com)
built--called the GPExpert Scripting Toolkit, which lets you automate GP
settings in general, and SRP rules in particular, via PowerShell.

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy

*******************************
Secure and configure your Windows desktops accurately every time without
having to learn or install new technology.
Find out more about Desktop Policy Manager at
http://www.sdmsoftware.com/desktop_management
*******************************


"wjr" <virtual2@gomonarch.com> wrote in message
news:48B4469C.7080602@gomonarch.com...
>
>
> Darren Mar-Elia wrote:
>> In addition to Florian's "social conditioning" suggestion :-), I would
>> suggest several steps for the e-card exploit. Software Restriction Policy
>> "hash" rules will work assuming there are not different versions of the
>> exe floating around out there. If there are, then you would need to
>> create a hash rule for every version. You could also using the Admin
>> Template policy, in addition to the hash rule, that blocks code of a
>> certain name. The combination of both might be a good line of defense
>> here. Finally, if folks are downloading this from email or the browser,
>> typically when they do that and click "Run" or "Open" (assuming they
>> click open or run and not save first), the file is usually downloaded to
>> a temp folder prior to executing. You can also use Software Restriction
>> policy to create path rules to prevent code execution. For example
>> putting %temp% or the Temporary Internet Files path in as a disallowed
>> path might prevent anything that is downloaded and run from executing. It
>> could of course, impact other legitimate user actions so you will
>> probably want to test thoroughly first, with your users, but it is
>> definitely another step you can take.
>>
> Thats a good approach. I would assume that this is kind of standard
> proceedure but not sure. Any tools out there to help automate this and
> perhaps make some good default settings?
>

Darren Mar-Elia wrote:
> There are a bunch of articles on TechNet about SRP. I would check those
> out as a starting point. You can create rules fairly easily through the
> GP Editor UI, once you understand how they work.
>
> In terms of automation, without being too self-serving, the only
> automation mechanism available for SRP is the one my company
> (sdmsoftware.com) built--called the GPExpert Scripting Toolkit, which
> lets you automate GP settings in general, and SRP rules in particular,
> via PowerShell.
>

Thanks!!