Fazza Posted June 7, 2016 Posted June 7, 2016 Please submit to Solution is usually to copy the temp files to an authorised location If that's the only solution then I'll have to remove the Group Policy or at least the the %TEMP% location from it I'll add it to that page in a moment. In the meantime we've just tried to install the NET2 security door software on a laptop for a member of staff and that also doesnt work! Not a good start for us!
mavhc Posted June 7, 2016 Posted June 7, 2016 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
Fazza Posted June 7, 2016 Posted June 7, 2016 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.
gaz350b Posted June 7, 2016 Posted June 7, 2016 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.
Fazza Posted June 7, 2016 Posted June 7, 2016 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?
jthompson Posted June 7, 2016 Posted June 7, 2016 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'.
jthompson Posted June 7, 2016 Posted June 7, 2016 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.
Fazza Posted June 7, 2016 Posted June 7, 2016 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.
Arthur Posted June 16, 2016 Posted June 16, 2016 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.
speckytecky Posted June 19, 2016 Posted June 19, 2016 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! Microsoft warns of worm ransomware, finds fix in Windows 10 upgrade
mavhc Posted June 20, 2016 Posted June 20, 2016 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
Arthur Posted June 22, 2016 Posted June 22, 2016 (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 June 22, 2016 by Arthur 1
Arthur Posted June 22, 2016 Posted June 22, 2016 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.
mavhc Posted June 22, 2016 Posted June 22, 2016 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"
Arthur Posted October 27, 2016 Posted October 27, 2016 How hard would it be to back port this given the severity of the macro virus threat?! Apparently not very. www.edugeek.net/forums/security/176254-office-2013-can-now-block-macros-documents-originating-internet.html
gshaw Posted October 27, 2016 Posted October 27, 2016 Apparently not very. www.edugeek.net/forums/security/176254-office-2013-can-now-block-macros-documents-originating-internet.html Glad to see they listened, this will be getting turned on asap!
Popular Post penfold Posted November 17, 2016 Popular Post Posted November 17, 2016 Just a heads up to add .thor to file extenstions after locky updates what it changes the file extension. Got hit by this the other day thanks to a user going out of their way to run an attachment sent via email. Link - Locky Variant 5
sonofsanta Posted November 18, 2016 Posted November 18, 2016 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. 3
Arthur Posted December 13, 2016 Posted December 13, 2016 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. 3
snagrat Posted December 13, 2016 Posted December 13, 2016 http://jpelectron.com/sample/Info%20and%20Documents/Stop%20crypto%20badware%20before%20it%20ruins%20your%20day/1-PreventCrypto-Readme.asp
mavhc Posted December 13, 2016 Posted December 13, 2016 Whitelist apps with SRP, don't blacklist extensions that are easy for programmers to change
penfold Posted December 14, 2016 Posted December 14, 2016 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.
ITGuyWestMidlands Posted December 14, 2016 Posted December 14, 2016 Set js, hta and the less common vb script file types such as vbe to open in notepad by default
ricki Posted December 14, 2016 Posted December 14, 2016 https://www.sophos.com/en-us/lp/ransomware.aspx?cmp=701j0000001ng0WAAQ
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now