You are using an unsupported browser. Please update your browser to the latest version on or before July 31, 2020.

06: Blocking Malware with PolicyPak and PDQ Deploy

No one wants to end up having to pay the bad guys or do a restore after they’re hit with a malware or crypto-malware attack. So just PREVENT these kinds of attacks in the first place. How will you do that? After you deploy the GOOD and RIGHT software using PDQ Deploy, you’ll then use PolicyPak Least Privilege Manager to ensure users can’t just run any ol’ application they happen to grab from the Internet. Prevent the attacks in advance, instead of cleaning up a white hot mess.

Blocking Malware with PolicyPak and PDQ Deploy

Jordan: Hey, I’m Jordan with This is Jeremy with PolicyPak, and he’s here to tell us how to prevent your users from installing software that you don’t want on there.

Jeremy: Yeah, like malware. Does that sound like a good idea?

Jordan: That seems like a good idea.

Jeremy: Here’s the lash-up. You want to be in charge of deploying stuff through PDQ Deploy and have your users run it, but you don’t want users to be able to just download any old junk off the Internet and run that. That’s how Windows works.

Ten seconds before we started the video, I downloaded this little video player (“CamPlay”). Hey, that might be okay. Or if I download “iTunes,” iTunes won’t let you install unless you do something like we did in a previous video. Or if you take “NotepadP.” Is it goodware? Is it malware? You have no idea if it’s good or not.

Said another way, you don’t want users to be able to install or run things that you’re not in charge of, including things like ransomware. Let’s take a look at “Ransomware Simulator” here. Just good old ransomware, double click and look at that. You do not want to be in the business of having to revert out of this. And, of course, we all agree you should be doing everything you can to try to prevent malware all the way from the network stack and all the way down to the last millimeter which is the endpoint.

To start off our demo, I’m going to have Jordan deploy two applications that you do want users to run. Let’s pick some browsers. Let’s pick Firefox and Chrome and get them deployed go “WIN10COMPUTER5.” Then the second thing we’re going to do is block all the unknown ware so the users can’t be naughty. Yep, “win10compter5,” you’ve got it. All right, excellent. And the packages we want are Firefox and….

Jordan: Oh, I just did each one individually because apparently I’m new to my own product.

Jeremy: That works though, right? There’s no downside.

Jordan: That works great.

Jeremy: Okay, great. All right, we’ll go ahead and let this finish up.

Jordan: All right, now that we’re all installed, let’s go take a look at the results.

Jeremy: Let’s go do that. All right, great. I can see “Google Chrome” is there. Let’s go ahead and run it and try it out and make sure it works because, of course, you want it to run. In fact, I have full confidence that that’s going to run. But again, we still haven’t blocked the malware part and the unknown ware that the user installed down here. I’m going to do that in a quick stroke using PolicyPak.

I’m going to create a new GPO against my “WEB_Engineers.” I’m going to do “PP Smack down Malware and unknownware.” Okay, there we go. Right click, click on “Edit” here. This feature of PolicyPak is part of our Least Privilege Manager product, and it’s called SecureRun. I’m going to show it working first and explain how it works second.

I’m going to dive down under user side, “PolicyPak.” I’m going to go to “Least Privilege Manager.” We had another video on this earlier today. We’re going to go right click and “Add” a “New SecureRun Policy.” Again, I’m going to show you how it works first and then come back and explain how it works second. I’m going to turn it on (“Enable”). We’re going to talk about this second. Click “OK,” and now it’s locked and loaded.

I’m going to go over to my endpoint and run GP Update (“gpupdate”). After this is done, we’re going to verify that the stuff we deploy using PDQ Deploy is all okay, stuff that users could run ten seconds ago is all smacked down. Then I’ll explain how we did the magic. Now that that’s done, let’s close the window out.

Now let’s go try PDQ Deploy stuff first. I’ll go ahead and run “Google Chrome” again and I’ll go ahead and run “Firefox” too. Again, you just deployed these. I have full confidence these are going to work just perfectly fine.

But the stuff that the user downloaded off the Intertubes, how do we know what’s going to be there? Let’s take “NotepadP.” And blocked. Let’s go ahead and take this video player “CamPlay.” Blocked. Most importantly, let’s take “Ransomware Simulator” and try that guy. And blocked. How did we magically do this? Do we have some reporting cloud thing in the sky?

Jordan: How do I know that you didn’t manually put all of these programs in beforehand because you knew what you had?

Jeremy: Exactly. So here’s the secret sauce. Remember back when we created the SecureRun policy? Let’s “Edit SecureRun Policy.” Here’s what we did. We said if you’re not on this list, you can’t run it. What does that mean? That means when PDQ Deploy deploys something and we go to “Properties” and we take a look at the “Security” and we take a look at “Advanced,” the owner is the “SYSTEM” or Administrator or maybe your PDQ Deploy account.

If I take a look at something that the user downloads off the Intertubes and I go to “Properties” and I go to “Security” and I go to “Advanced,” who owns the file? The user. Let’s go back to the list. Who’s not on the list?

Jordan: I don’t see the user anywhere.

Jeremy: Exactly. When the user downloads stuff, they own the file. And you’re saying don’t run the application or launch the file if you’re not on the list. It’s just that simple. You might be thinking to yourself, wait a second. This works out great, but what about applications that are sanctioned? Like “CamPlay.” That’s a perfectly fine application. Let’s go ahead and let that run. Does that make sense?

Jordan: Okay, yes.

Jeremy: So let’s go ahead and do that. What we’ll do is create a new rule. “Add” a “New Executable Policy.” I’m going to “Use simple rule.” I could use it by “Path” which is the name, by a fingerprint or “Hash,” or by it’s “Signature.” I’m going to use “Path,” and I’m going to say let this thing run if it’s called CamPlay. So I’ll say it’s cool if it’s called “camplay.exe.” And if I wanted it to be a little bit more strong I could say and signed by Camtasia people.

Jordan: So it looks at exclude first and then include after?

Jeremy: That’s right.

Jordan: Fantastic.

Jeremy: Yes, smacking down everything; opening up the doggy doors as needed. So “Allow and log.” We don’t need to “Run with elevated privileges” and run with the scissors. We just need to open up the doggy door just for CamPlay, se we’re going to “Allow and log.” So “let camplay run.” Okay, we’re good to go there.

Now remember, ten seconds ago and now “CamPlay” is not working. We’re correctly blocking it down. Now we’ll go ahead and run GP Update (“gpupdate /force”). We’ll get this last directive. We’ll keep things running when deployed by PDQ Deploy, keep things smacked down automatically from PolicyPak, and open up the doggy door just for the application or applications that meet our criteria, the things that are sanctioned that the user can run.

Jordan: So just to be clear, if you just made the owner of CamPlay SYSTEM or one of the approved, then it would also work right out of the gate?

Jeremy: Yeah, that’s correct. If you deploy it using your thing, you’re ready to rock. So “NotepadP,” smacked down. “CamPlay” opens right back up.

Jordan: Fantastic.

Jeremy: That’s it. That’s how you can block all malware and unknown ware from your systems all in one click and then use PDQ Deploy to deploy anything you want and have that run just the way you would expect.

Jordan: All right, well, thank you for tuning in. For Jeremy, I’m Jordan from

Jeremy: Thanks so very much.

  • 1046
  • 09-Mar-2022