CryptoLocker Prevention

[sonofsanta]

^ Doesn't this imply their AV software was out-of-date?

 

LCC are notorious hereabouts for running outdated software (Win 2k + Office 2003 for the longest time) and there was a good period of time where everyone knew not to connect LCC removable media because it was guaranteed to have Conficker on it.

 

The spokeswoman tried to hide behind "it was a zero day attack" but that's only the vector for penetration, and you could still prevent/limit the actual payload using everything in this thread. Defence in depth!

[mrbios]

I can't work out why the file name: \~$.1 work experience.docx was picked up by the FSRM rule in the OP. It's the first false positive i've had appear surprisingly, but i don't understand why in this instance. Suggestions? I'm not using the script yet (i was struggling to get it to work when i looked at it last, haven't revisited it in a while though)

[steve]

\~$.1 work experience.docx was picked up by the FSRM rule in the OP. It's the first false positive i've had appear surprisingly, but i don't understand why in this instance. Suggestions?

 

Its being picked up by the file screen ”*.*enc*” part of the script. As there is "." early in the file name - \~$.1, its then picking up the "enc" in the word experience

[halbaradkenafin]

I can't work out why the file name: \~$.1 work experience.docx was picked up by the FSRM rule in the OP. It's the first false positive i've had appear surprisingly, but i don't understand why in this instance. Suggestions? I'm not using the script yet (i was struggling to get it to work when i looked at it last, haven't revisited it in a while though)

 

Post here or drop me a PM with what problems you were having and I'll see what I can do to help.

[Arthur]

Useful article from Microsoft on how to avoid getting infected with the Locky ransomware using several techniques not mentioned in this thread so far...

 

https://blogs.technet.microsoft.com/mmpc/2016/02/24/locky-malware-lucky-to-avoid-it/

 

If given the chance Locky will encrypt files on every network share it can find, not just mapped drives.

 

 

Edit. These are the GPOs mentioned in the article...

 

http://i.cubeupload.com/yWzgFl.png

Edited February 25, 2016 by Arthur

[mowgli82]

I bet SIMS report macros aren't digitally signed so this setting might be hard to do.

[halbaradkenafin]

Useful article from Microsoft on how to avoid getting infected with the Locky ransomware using several techniques not mentioned in this thread so far...

 

https://blogs.technet.microsoft.com/mmpc/2016/02/24/locky-malware-lucky-to-avoid-it/

 

If given the chance Locky will encrypt files on every network share it can find, not just mapped drives.

 

I'll have a look at that, sounds like an interesting read. Hopefully most places will have good permissions set on their network shares to prevent this hitting too hard but I wouldn't be surprised if there are places with allow all on everything.

[gshaw]

Block macros from running in Office files from the Internet in your enterprise

 

Office 16 provides a Group Policy setting that enables you to block macros from running in Word, Excel and PowerPoint files from the Internet. Read about how to block macros from running in Office 16 files from the Internet.

 

After all the junk MS have brought down into Office 2013 from 2016 that's broken core functionality they keep this critical security feature as 2016-only. How hard would it be to back port this given the severity of the macro virus threat?!

 

Yes we get the software for free to upgrade but it's not trivial to change Office version on 2000+ machines. Never mind those who aren't as lucky as us EES customers and are stuck on their current Office version.

[Max_Power]

Had a cryptolocker once and it encrypted entire shared areas that the user had access too, anything they didn't it skipped, until the AV interrupted the process and stopped it running and we pulled plug on the machine.

 

Had a number of emails come through last week which were Locky. Came complete with suspect word documents where they are pretending to be invoices that ask the user to enable macros in order to process the invoice. These emails were from known addresses to our school.

 

Macros disabled for students anyway, but staff require them for SIMS reports as mentioned above so may look at the trust centre option that's been posted see if that helps as a prevention measure.

 

Emailed staff and students to be wary of this type of email and the education has paid off in this instance with staff alerting us, and deleting the said emails. Much rather staff and students ask us if something is potentially harmful than them just going ahead and happily clicking everything.

[sonofsanta]

I've emailed my lot here this morning to warn them (and emphasised that we really don't mind checking emails if two minutes work there saves us a week of rebuilding), but I've also come to the conclusion that I've never seen Word macros used in a school anyway, only Excel + PowerPoint, so I've blocked them in Word as the main vector anyway.

 

Now to find out which obscure product I've accidentally broken. Probably something SEN used by one person for which I shall have to compromise all my security settings. Bah.

[mrbios]

Are you guys using trusted locations to get around excel macro issues?

 

I've tested this with a few users. Finance get sent macro filled spreadsheets from county, our head of IT has some he's made at home etc. I guess so long as trusted locations are minimal, then just by blocking macros from running when run directly from outlook is the most important aspect....i don't know of any people who save an attachment before opening it anyway.

 

EDIT: Presumably the default office settings still block these macros, up until someone clicks "enable content"?

Edited February 25, 2016 by mrbios

[sonofsanta]

Further to discussion in another thread, I'd recommend adding *locky* to your Cryptolocker File Group. You could just add *.locky for now, but (a) I can't see *locky* triggering many false positives, if any, (b) the ransomware is likely to evolve to mix up the filenames a bit.

[Arthur]

Something else that would be worth doing if your users use Microsoft Outlook is to hide OLE attachments. I can't think of a legitimate reason why anyone would need these (especially in an e-mail client!).

 

More details here...

 

#OLEOutlook - bypass almost every Corporate security control with a point’n’click GUI

 

In this tutorial, I will show you how to embed an executable into a corporate network via email, behind the firewall(s), disguised as a Word document. There is no patch for this issue.

 

Protection

Three avenues available:

• Application whitelisting. However, be careful for signed executables with parameters being embedded. E.g. there are many Microsoft digitally signed tools you can use to springboard for other content, and because they’re Microsoft you’ve probably already trusted their publisher certificate.
   
  
• Deploy the registry key ShowOLEPackageObj, for your version(s) of Office, to silently disable OLE Package function in Outlook. There is no way to disable it in wider Office, however, so attackers can still embed inside Word, Excel and PowerPoint.
   
  

  [b]Outlook 2016[/b]
  HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\security
  DWORD: ShowOLEPackageObj
  Value: 0

  
   
  

  [b]Outlook 2013[/b]
  HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\security
  DWORD: ShowOLEPackageObj
  Value: 0

  
   
  

  [b]Outlook 2010[/b]
  HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\security
  DWORD: ShowOLEPackageObj
  Value: 0

  
   
  

  [b]Outlook 2007[/b]
  HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\security
  DWORD: ShowOLEPackageObj
  Value: 0

  
   
  

• EMET. If you run Microsoft EMET (or a similar product such as Palo-Alto TRAPS), add this mitigation for Outlook.exe:
  

         packager.dll
  

By stopping packager.dll, you stop the issue.

 

http://i.cubeupload.com/nDUiiz.jpeg

[Arthur]

Presumably the default office settings still block these macros, up until someone clicks "enable content"?

They should, although it only takes one user to click that button.

 

http://i.cubeupload.com/mEF2Ji.png

[mrbios]

They should, although it only takes one user to click that button.

 

http://i.cubeupload.com/mEF2Ji.png

 

Must admit, I'm only looking to leave "enable content" available for 4-5 users, and only on excel documents. (Finance get sent excel stuff from county which gets blocked using the disable unless digitally signed rules)

 

Although, shouldn't SRP and Applocker restrictions, if setup properly, block the actual virus from running? From what I'm told the macro only downloads the content, the virus still has to run from the usual user profile/temp locations? I've got mine set to whitelisted locations only in SRP and applocker set to only allow executables outside of the userprofile (unless digitally signed by one of the approved list of companies)

Edited February 26, 2016 by mrbios

[Arthur]

shouldn't SRP and Applocker restrictions, if setup properly, block the actual virus from running?

In theory it should, although malware writers are always coming up with new ways to bypass security.

 

I've got mine set to whitelisted locations only in SRP and applocker set to only allow executables outside of the userprofile (unless digitally signed by one of the approved list of companies)

A potential issue with allowing all executables outside the user profile is that C:\Windows contains folders that are writable by standard users. Viruses/malware can copy files into one of these folders and execute from there because they have been whitelisted.

 

The following article lists a number of ways to bypass AppLocker...

 

http://dfir-blog.com/2016/01/03/protecting-windows-networks-applocker

 

Default rules is not as secure as you would think. You would think user can’t write into Windows folder and generally this is true, however there are a few folders that allow user write access, thus allowing easy bypass with default rules. Check your system with or use Sysinternals accesschk –

accesschk.exe -d -w username C:\Windows\*

 

http://i.cubeupload.com/EGcVPy.png

[mrbios]

Interesting, I'm yet to see anyone speak of this as a cypto attack front yet though? Although i guess if something doesn't exist that uses those locations, it's only time before something does.

 

Suggestions for locking these down? (Can they all even be locked down without causing problems!?) Might stick a VM on and test some policies later.

Edited March 2, 2016 by mrbios

[Arthur]

Although I guess if something doesn't exist that uses those locations, it's only time before something does.

Even if malware doesn't use these folders, it's good knowing students won't be able to either.

 

Suggestions for locking these down?.

There's one in the 'Mitigating Bypasses' section of that article. Definitely worth testing on a VM or test PC beforehand though.

[Arthur]

Hackers are targeting OS X users with ransomware for the first time

 

On 4 March, we detected that the Transmission BitTorrent client installer for OS X was infected with ransomware, just a few hours after installers were initially posted. We have named this Ransomware “KeRanger.” The only previous ransomware for OS X we are aware of is FileCoder, discovered by Kaspersky Lab in 2014. As FileCoder was incomplete at the time of its discovery, we believe KeRanger is the first fully functional ransomware seen on the OS X platform.

 

Attackers infected two installers of Transmission version 2.90 with KeRanger on the morning of 4 March.

 

The KeRanger application was signed with a valid Mac app development certificate; therefore, it was able to bypass Apple’s Gatekeeper protection. If a user installs the infected apps, an embedded executable file is run on the system. KeRanger then waits for for three days before connecting with command and control (C2) servers over the Tor anonymizer network. The malware then begins encrypting certain types of document and data files on the system. After completing the encryption process, KeRanger demands that victims pay one bitcoin (about $400) to a specific address to retrieve their files. Additionally, KeRanger appears to still be under active development and it seems the malware is also attempting to encrypt Time Machine backup files to prevent victims from recovering their backup data.

 

Palo Alto Networks reported the ransomware issue to the Transmission Project and to Apple on 4 March. Apple has since revoked the abused certificate and updated XProtect antivirus signature, and Transmission Project has removed the malicious installers from its website. Palo Alto Networks has also updated URL filtering and Threat Prevention to stop KeRanger from impacting systems.

Edited March 7, 2016 by Arthur

[Arthur]

Detecting Offensive PowerShell Attack Tools

 

PowerShell is a built-in command shell available on every supported version of Microsoft Windows (Windows 7 / Windows 2008 R2 and newer) and provides incredible flexibility and functionality to manage Windows systems. This power makes PowerShell an enticing tool for attackers. Once an attacker can get code to run on a computer, they often invoke PowerShell code since it can be run in memory where antivirus can’t see it. Attackers may also drop PowerShell script files (.ps1) to disk, but since PowerShell can download code from a website and run it in memory, that’s often not necessary.

 

on how PowerShell could be leveraged by attackers. Matt Graeber developed PowerSploit and blogged at Exploit-Monday.com on why PowerShell is a great attack platform. Offensive PowerShell usage has been on the rise since the release of “PowerSploit” in 2012, though it wasn’t until Mimikatz was PowerShell-enabled (aka Invoke-Mimikatz) about a year later that PowerShell usage in attacks became more prevalent. PowerShell provides tremendous capability since it can run .Net code and execute dynamic code downloaded from another system (or the internet) and execute it in memory without ever touching disk. These features make PowerShell a preferred method for gaining and maintaining access to systems since they can move around using PowerShell without being seen. PowerShell Version 5 (v5) greatly improves the defensive posture of PowerShell and when run on a Windows 10 system, PowerShell attack capability is greatly reduced.

 

PowerShell is more than PowerShell.exe

Blocking access to PowerShell.exe is an “easy” way to stop PowerShell capability, at least that’s how it seems. The reality is that PowerShell is more than a single executable. PowerShell exists in the System.Management.Automation.dll dynamic linked library file (DLL) and can host different runspaces which are effectively PowerShell instances. A custom PowerShell runspace can be instantiated via code, so PowerShell can be executed through a custom coded executable (such as MyPowershell.exe). In fact there are several current methods of running PowerShell code without Powershell.exe being executed. Justin Warner (@SixDub) blogged about bypassing PowerShell.exe on Red Team engagements in late 2014, aka PowerPick). Since PowerShell code can be executed without running PowerShell.exe, blocking this executable is not an ideal solution to block attacks.

 

Blocking PowerShell.exe does not stop PowerShell attacks

Since blocking PowerShell is not effective in stopping PowerShell-based attacks, a more nuanced approach is required (see PowerShell Constrained Language mode and PowerShell v5).

 

--- Snip ---

 

Limiting PowerShell Attack Capability with Constrained Language Mode

Additionally, PowerShell supports various language modes that restrict what PowerShell can do. The PowerShell Constrained Language Mode was developed to support the Surface RT tablet device, though this mode is available in PowerShell in standard Windows as well. Constrained language mode limits the capability of PowerShell to base functionality removing advanced feature support such as .Net & Windows API calls and COM access. The lack of this advanced functionality stops most PowerShell attack tools since they rely on these methods. The drawback to this approach is that in order to configured PowerShell to run in constrained mode, an environment variable must be set, either by running a command in PowerShell or via Group Policy.

 

Constrained language mode is a useful interim PowerShell security measure and can mitigate many initial PowerShell attacks, though it is not a panacea. It should be considered minor mitigation method on roadmap to whitelisting. Keep in mind that bypassing Constrained PowerShell is possible and not all PowerShell “attack scripts” will be blocked – certainly the ones that use advanced functionality to reflectively load a DLL into memory like Invoke-Mimikatz will be blocked.

 

Enable Constrained Language Mode:

[Environment]::SetEnvironmentVariable('__PSLockdownPolicy', '4’, 'Machine')

 

Enable via Group Policy:

Computer Configuration\Preferences\Windows Settings\Environment

 

 

Once Constrained Language Mode is enabled, many PowerShell attack tools don’t work since they rely on components blocked by constrained language.

 

This environment variable can be modified by an attacker once they have gained control of the system. Note that they would have to spawn a new PowerShell instance to run code in full language mode after changing the environment. These changes would be logged and could help the defender in identifying unusual activity on the system.

 

Pairing PowerShell v5 with AppLocker – Constrained Language Mode No Longer Easily Bypassed

PowerShell v5 also supports automatic lock-down when AppLocker is deployed in "Allow" mode. Applocker Allow mode is true whitelisting and can prevent any unauthorized binary from being executed. PowerShell v5 detects when Applocker Allow mode is in effect and sets the PowerShell language to Constrained Mode, severely limiting the attack surface on the system. With Applocker in Allow mode and PowerShell running in Constrained Mode, it is not possible for an attacker to change the PowerShell language mode to full in order to run attack tools.When AppLocker is configured in "Allow Mode", PowerShell reduces its functionality to "Constrained Mode" for interactive input and user-authored scripts. Constrained PowerShell only allows core PowerShell functionality and prevents execution of the extended language features often used by offensive PowerShell tools (direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects).

 

Note that scripts allowed by AppLocker policy such as enterprise signed code or in a trusted directory are executed in full PowerShell mode and not the Constrained PowerShell environment. This can’t be easily bypassed by an attacker, even with admin rights.

 

[mdrabble]

You need to add in your other servers using the Invoke-Command section, just duplicate it for the needed servers and update the names etc.

 

Yeah done that but it's not having it. Most of the time with these things if I leave it a while and return for a fresh look I'll find a resolution.

 

Implemented this but it only seems to wipe out the connections to the shares on the file server where the files are detected, as opposed to all of them. I'll have a look at it again later.

 

I seem to be having the same issue - will only disconnect the server the files are found.

 

I've added the other servers in the invoke command but still no joy.

 

@clockend25 did you managed to resolve this?

[mdrabble]

hmm interesting..... If I run Disconnect-Shares.ps1 manually with a username it works perfectly but if it runs as a command from FSRM it only disconnects the server the files are found on.

[AliG]

FSRM

 

1) is there an easy way to import the keywords / filetypes without copying and pasting each one?

 

2) once I have FSRM setup on server1 can I export / import the file groups to server2, 3, 4 etc?

[sonofsanta]

FSRM

 

1) is there an easy way to import the keywords / filetypes without copying and pasting each one?

 

2) once I have FSRM setup on server1 can I export / import the file groups to server2, 3, 4 etc?

 

That's what the New-FSRMFileGroup PowerShell in the first post does. No import/export, but just run the same script on each server.

[clockend25]

 

@clockend25 did you managed to resolve this?

 

Afraid not. I gave up trying to work it out as the screens were generating too many false positives. They're now set as passive and simply alert us via email, without blocking any access.