Jump to content

Recommended Posts

Posted

The whole idea is to stop users installing stuff, you can either install it as admin, if you have "don't apply to admins" or, better, only install stuff from your software installation share which only you can write to. Whitelist vs blacklist. Does depends on a stricter environment, but it's the only way to be sure.

 

Of course the next stage is to use IPSec to only let domain computers connect to your servers, otherwise random home computer teacher brings in could still infect the files

Posted
only install stuff from your software installation share which only you can write to.

 

That's where it was installing from. Using the setup.exe -ms (silent install) seems to not use the AppData folder during its installation.

Posted

do you not have separate user and admin accounts? your admin accounts shouldn't be in the same OU as your users you are applying policies to.

 

As you are only using accounts with admin rights to do admin tasks and not day to day tasks like browsing the internet or checking email, you don't need to aply the SRP to your admin accounts. so you should therefore have no issues installing software on those accounts.

Posted
do you not have separate user and admin accounts? your admin accounts shouldn't be in the same OU as your users you are applying policies to.

 

As you are only using accounts with admin rights to do admin tasks and not day to day tasks like browsing the internet or checking email, you don't need to aply the SRP to your admin accounts. so you should therefore have no issues installing software on those accounts.

 

I've just checked and the Group Policy is computer based so it doesnt matter who logs on as it's applied to the computer. Have the settings been set in the wrong place then?

Posted
I've just checked and the Group Policy is computer based so it doesnt matter who logs on as it's applied to the computer. Have the settings been set in the wrong place then?

 

Our SRP is also computer based, but is set to not apply to local administrators (our regular users do not have admin rights on their machines).

 

In the GPO, under 'Software Restriction Policies' -> 'Enforcement', pick the option 'All users except local administrators'.

Posted

As a follow up, we've also exploited that 'Enforcement' option to give ourselves a quick and dirty way around the SRP for those times when it just needs to be disabled for a particular userland task (e.g. an app isn't running for a member of SLT and you can't immediatley see why).

We have a group in AD that is configured via Group Policy to be included as local administrators on all the computers. It's normally an empty group, but dropping a user in there (discretion advised) and getting them to login again will allow them to continue without the SRP getting in their way. Once the problem is solved, remove them from the group and their next logon on the network will take away their admin and bump them back under the SRP again.

Posted
Our SRP is also computer based, but is set to not apply to local administrators (our regular users do not have admin rights on their machines).

 

In the GPO, under 'Software Restriction Policies' -> 'Enforcement', pick the option 'All users except local administrators'.

 

I think I'll have to so some giggery-pokery with the loopback setting and AD OU's then as a lot of our staff laptops have the users as local admins for something to do with SIMS so some users would be at risk if I did that.

  • 2 weeks later...
Posted

Where’s the Macro? Malware authors are now using OLE embedding to deliver malicious files

 

Recently, we’ve seen reports of malicious files that misuse the legitimate Office object linking and embedding (OLE) capability to trick users into enabling and downloading malicious content. Previously, we’ve seen macros used in a similar matter, and this use of OLE might indicate a shift in behavior as administrators and enterprises are mitigating against this infection vector with better security and new options in Office.

 

In these new cases, we’re seeing OLE-embedded objects and content surrounded by well-formatted text and images to encourage users to enable the object or content, and thus run the malicious code. So far, we’ve seen these files use malicious Visual Basic (VB) and JavaScript (JS) scripts embedded in a document.

 

The script or object is surrounded by text that encourages the user to click or interact with the script (which is usually represented with a script-like icon). When the user interacts with the object, a warning prompts the user whether to proceed or not. If the user chooses to proceed (by clicking Open), the malicious script runs and any form of infection can occur.

Posted

Thanks @Arthur on the money as ever. Pretty alarming that isn't it; so the answer from MS is that the best way toward prevention is to replace all OS with Windows 10; rather worrying that they don't seem to be pushing out the same sort of support for 7 and 8 isn't it?

 

Yesterday we had a family luncheon to celebrate my mum turning 90 at a swanky hotel and I was shocked to see the version of Windows they were running was XP!

 

 

Posted

Good job we blocked users from running JS and VBS files in folders they can write to/the internet.

 

Whitelisting filetypes is the solution for now it seems

Posted (edited)
so the answer from MS is that the best way toward prevention is to replace all OS with Windows 10; rather worrying that they don't seem to be pushing out the same sort of support for 7 and 8 isn't it?

Considering that Windows 7 is almost 7 years old I wouldn't expect Microsoft to add any security features that are in Windows 10 to the OS. It's just too old and therefore too complicated, time consuming or expensive! I think MS would rather people forget about 8/8.1. :)

 

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/windows-10-security-guide

 

Newer OSs (whether that's Windows, macOS, iOS, Android, Chrome OS) are almost always going to be more secure than older versions of the OS.

Edited by Arthur
  • Thanks 1
Posted
Whitelisting filetypes is the solution for now it seems

Speaking of which...

 

https://blogs.technet.microsoft.com/enterprisemobility/2016/06/20/configmgr-as-a-managed-installer-with-win10/

 

Windows 10 introduced a new set of features called Device Guard that helps enterprises protect their business critical machines against malware and other unwanted software. Key amongst these is a new application and software whitelisting technology known as configurable code integrity that, together with AppLocker, enables enterprises to strongly control what is allowed to run in their environment.

 

Like all whitelisting solutions, configurable code integrity and AppLocker policies can be complex to set up and difficult to maintain, particularly for enterprises whose software catalogs are large, ever-changing, and include applications from a variety of internal and 3rd-party software developers. Enter the concept of the Managed Installer.

 

As of Windows 10 Enterprise Anniversary Edition, administrators can configure a new type of AppLocker rule that identifies a specific trusted installation authority, or Managed Installer. Any applications or other software (executables and .dll’s) that are installed by that specified installation authority will be automatically trusted by AppLocker and allowed to run without needing to create any other rules. Applications and software that are installed using any other mechanism will not pass the Managed Installer rule and will only run if explicitly allowed by another AppLocker rule. This will drastically reduce the overhead required to maintain whitelisting policy when deploying applications and software to systems protected by Windows AppLocker.

Posted
Considering that Windows 7 is almost 7 years old I wouldn't expect Microsoft to add any security features that are in Windows 10 to the OS. It's just too old and therefore too complicated, time consuming or expensive! I think MS would rather people forget about 8/8.1. :)

 

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/windows-10-security-guide

 

Newer OSs (whether that's Windows, macOS, iOS, Android, Chrome OS) are almost always going to be more secure than older versions of the OS.

 

Except for all the new bugs they introduce with new code.

 

Seems like the major new Win10 security feature is (ironically?) named VBS. "There's good VBS and bad VBS"

  • 4 months later...
  • 3 weeks later...
Posted

In doing some testing for setting a new file server up, I realised all this wasn't actually firing properly--it wasn't ever blocking the shares on the remote servers, only the server that was triggered by FSRM.

 

Here's how I've fixed it:

 

1) servers didn't have permission to connect to the other servers to invoke-command

 

On each file server, in Powershell, run

Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell

and tap enter to confirm that yes, you want to perform this action.

 

That pops up a permissions window, similar to any folder security tab. Click Add, click Object Types and tick Computers, then type out the object names of the other servers e.g. the ones that will connect to this one to shut down the shares. Give them Execute(Invoke) permissions.

 

Click OK, then tap enter in the PS to restart WinRM.

 

(Source: top answer here)

 

2) invoke-command credentials weren't being passed properly

 

This is related to @halbaradkenafin's point in his original post about the secure password file: For encrypting the password in another file then run the following from a PowerShell prompt while logged in as the user who the script will run as

 

I'd taken that to mean I should run it as the admin account whose credentials were being passed, but it actually means as the account that will run the script, as detailed in the FSRM template--so Local System.

 

So you need to run the password encrypting command in a PowerShell window running as LocalSystem, which is a bit of a faff; you have to do it using psexec.

 

Basically, from a command window in your psexec folder, run

psexec -i -s Powershell.exe

and in the PowerShell window that opens, run whoami to confirm it's running as nt authority\system

 

Run the code to create the secure password file in that window and it should then be fine.

  • Thanks 3
  • 4 weeks later...
Posted

A new extension to add to the list is .filock. This is used by the Popcorn Time ransomware.

 

New Scheme: Spread Popcorn Time Ransomware, get chance of free Decryption Key

 

Yesterday a new in-development ransomware was discovered by MalwareHunterTeam called Popcorn Time that intends to give victim's a very unusual, and criminal, way of getting a free decryption key for their files. With Popcorn Time, not only can a victim pay a ransom to get their files back, but they can also try to infect two other people and have them pay the ransom in order to get a free key.

 

To make matters worse, there is unfinished code in the ransomware that may indicate that if a user enters the wrong decryption key 4 times, the ransomware will start deleting files.

 

It should be noted, that this ransomware is not related to the Popcorn Time application that downloads and streams copyrighted movies.

 

Want a free decryption? Just be a scumbag!

In a move that we have not seen with any other ransomware, the ransomware developer offers a "nasty way" for a victim to get a free decryption key by having them help to spread the ransomware. If two people become infected via the victim's "referral" link" and pay the ransom, then the victim will supposedly get a free key.

 

How the Popcorn Time Ransomware Encrypts a Computer

Once started, the Popcorn Time ransomware will check to see if the ransomware has been run already by checking for various files such as %AppData%\been_here and %AppData%\server_step_one. If the been_here file exists, it means the computer has already been encrypted and the ransomware will terminate itself. Otherwise, it will either download various images to use as backgrounds or start the encryption process.

 

As this ransomware is currently in development, it only targets a test folder on the victim's desktop called Efiles (see update below). It will search this folder for files that match certain extensions and then encrypt them using AES-256 encryption. When a file is encrypted it will have the .filock extension appended to it. So a file called test.jpg would be encrypted as test.jpg.filock.

  • Thanks 3
Posted
Using FSRM is just another layer into stopping Ransomware spreading. We are still going through a battle of restricting users access in what they can do and having a file screen is another layer of protection which has already helped us limit crypto damage.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...