SRP, LUA = protect autostart?

Hello all,

I have a question whether it is necessary to perform KAFU (and similar tweaks) in order to protect autostarting locations.

I run LUA + SRP in W7 Pro and my gut feeling says drive by downloads won't be able to infect my system even if I don't tweak the registry settings in HKCU.
Did I get it right that malware _may_ write under HKCU /run /run once etc, but no execution is [at least in theory] is possible due to the LUA+SRP setup?

Thanks.

 

Looking into gpedit, there are two tweaks that I believe will result in disabling RunOnce and Run :

More info:
http://support.microsoft.com/kb/314488

However, I am not sure if this will protect HKCU...

 

(going solo here! )

Same entries can be found in : User Configuration->Administrative Templates->System->Logon

I _think_ these settings will prohibit runonce + run invoked by the users?

 

I see you're not using any realtime protection.

Have you by any chance read some previous threads on SRPs recently?

Several users came to the conclusion that SRPs and other anti-execution tools do not provide much actual enhanced security since malware authors, if they wanted to, could "do a ton" even without writing and executing a payload to your hard drive.

EMET will definitely help cover many ends paired with SRP but there still theoretically could be memory-only attacks aka attacks that need only to be in RAM to do their nasty deeds.

HungryMan was one of the main sources of this relatively new position on anti-execution efficacy and he generously offered back in July to do some of his own tests to verify just how much security you really get with SRPs. I don't think he has yet to post results.

I can't wait!

 

Hi STV0726 - I've been trying to read up what the consensus is concerning SRP is today, but I haven't seen any new(er) threads.

I've seen posts that describe malware in theory that could carry out execution and deliver payload in the memory area, but I understood it as patching your software + EMET would protect you from those as the necessary step for abuse would involve taking advantage of any weakness in the code writing.

I'll look for the threads you recommended.
Yes, it will be interesting to see Hungryman's test results!

Edit: I think this is the thread you had in mind? I honestly don't remember if I've read this particular thread (I've read so many with similar titles) but I'll have a look.

 

Use GPEDIT to harden your Limited User/Software Restriction Policy

See Picture, I keep the runonce, since it used often (like delayed file operations) to clean up after installs/de-installs.

When you you don't stop delayed file operations in HKCU, it has not much use of stopping RunOnce either, that is why I left it untouched,

 

Hi Kees,
Thanks for the tip. It makes sense to allow RunOnce and disable the Run Legacy option. I will follow your advise.
I didn't touch the Run Legacy entry because I saw somewhere (not at Wilders) that disabling it would affect both HKLM and HKCU run options.

 

You can specify your HKLM run entries at "Run these programs at user logon", just use autoruns to see what to enter.

Since I run a group policy/access control list protected Windows Ultimate with no 3th party (how light is that , I don't have any programs starting in HKLM run

 

Thanks Kees. I've disabled Run Legacy as well with no ill effects. I don't know if it's related but my HKLM [..]Wow6432Node[..]Run entry hasEMET notifier but other Run entries such as HKLM[..]Currentversion[..]Run /Run Once are empty. EMET notifier runs fine after Run Legacy has been disabled.

Yeah, running light [and reasonably secure] is what I aim for too.

 

What is the advantage of making those further modifications, Kees/New2?

And furthermore...what is the potential risk of breaking apps or improper configurations occurring after having made those changes?

 

It are legacy options like running 16 bits software. It does affect your HKLM also. Alternatively you could allow only admins to set these keys in stead of denying through GPO.