A rash of invisible, fileless malware is infecting banks around the globe

Powershell is a system kernel process that loads at boot time. The current ver. for Win 10 is ver. 5.0. For Win 8, it is version 4.0. Etc..

Again what is stored in these directories, C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe and C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe, are the executables, .dlls, etc. used by the Powershell scripting shell; not those used by the internal Powershell process.

For example in Win 10, you can disable the scripting shell by opening uninstall programs - Windows features and uncheck the setting for PowerShell 2.0. As is true with all such features shown there in Win 10, the shell is disabled but not actually uninstalled. However, this activity has no impact whatsoever on internal Powershell processing. The equivalent of SRP, etc. for internal PowerShell processing is the "Language Mode" restriction as described previously with additional lockdown capability being provided by AppLocker.

 

So as I understand it, users must have a Windows SKU which contains AppLocker to lock down Powershell further via constrained language mode to help mitigate these types of attacks. That is certainly unfortunate for home users.

Do you (or anyone else) know specifically what AppLocker does under-the-hood to mitigate this when constrained language mode is enabled?

I am curious about seeing if and/or how this might be able to be achieved with other security solutions depending upon how AppLocker does this, whether that is blocking specific DLLs from loading into the memory space of other executables, etc. This is certainly an interesting topic and something which we can all potentially learn and gain from going forward.

 

There's a way around it for home users: https://www.wilderssecurity.com/thr...ter-in-addition-to-locky.391770/#post-2650397

 

OK, but does it mean that using it would break out of SUA + UAC? So user logged in with SUA can make system wide changes without Admin credentials using Powershell?

 

That I can't say for sure since I am running Win 10 which uses Powershell 5.0.

FYI - Powershell ver. by OS

Win 7 - 2.0
Win 8 - 3.0
Win 8.1 - 4.0

 

Malware will elevate to level required as noted in the example that is the subject of this thread. Internal use of Powershell APIs and the like is increasingly being used by .Net based malware to evade almost all conventional security methods as noted previously. Also noted previously, even lower level Powershell internal use can be done via assembler based programs and I believe using the C language.

 

@itman
After rereading your post (#2) I see that it still needs Administrator credentials to install. So SUA users couldn't install it system-wide.

 

Note: In regards to running Powershell in "Constrained Language" mode, it is a global setting that affects everything running on the system.

I have seen evidence that it will affect Win 10 native apps as shown below for Edge. The event log entry shows that a COM based privilege request is being denied. Whether this has any effect on Edge's security or actually is blocking nefarious activities by Edge has yet to be determined. It does not have any effect on any visible operation of Edge.

I use IE11 as my primary browser which is not a native Win 10 app and works just fine. I also don't use any the Win 10 apps.

Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 2/11/2017 11:54:55 AM
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
User: XXXXX\XXXXX
Computer: XXXXX
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{9E175B6D-F52A-11D8-B9A5-505054503030}
and APPID
{9E175B9C-F52A-11D8-B9A5-505054503030}
to the user XXXX\XXXXX SID (S-1-5-21-688685898-805468341-453270983-XXXX) from address LocalHost (Using LRPC) running in the application container Microsoft.MicrosoftEdge_38.14393.0.0_neutral__8wekyb3d8bbwe SID (S-1-15-2-3624051433-2125758914-1423191267-1740899205-1073925389-3782572162-737981194). This security permission can be modified using the Component Services administrative tool.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
<EventID Qualifiers="0">10016</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2017-02-11T16:54:55.588646100Z" />
<EventRecordID>35316</EventRecordID>
<Correlation />
<Execution ProcessID="384" ThreadID="5760" />
<Channel>System</Channel>
<Computer>XXXX</Computer>
<Security UserID="S-1-5-21-688685898-805468341-453270983-XXXX" />
</System>
<EventData>
<Data Name="param1">application-specific</Data>
<Data Name="param2">Local</Data>
<Data Name="param3">Activation</Data>
<Data Name="param4">{9E175B6D-F52A-11D8-B9A5-505054503030}</Data>
<Data Name="param5">{9E175B9C-F52A-11D8-B9A5-505054503030}</Data>
<Data Name="param6">XXXX</Data>
<Data Name="param7">XXXX</Data>
<Data Name="param8">S-1-5-21-688685898-805468341-453270983-XXXX</Data>
<Data Name="param9">LocalHost (Using LRPC)</Data>
<Data Name="param10">Microsoft.MicrosoftEdge_38.14393.0.0_neutral__8wekyb3d8bbwe</Data>
<Data Name="param11">S-1-15-2-3624051433-2125758914-1423191267-1740899205-1073925389-3782572162-737981194</Data>
</EventData>
</Event>

 

This just removes PowerShell 2.0 - which is shipped with Windows for backwards compatibility with some rare scripts that require PoSH 2.0. PoSH 2.0 won't work unless .NET Framework 3.5 is enabled - which it is disabled by default.

There's no way to remove PowerShell from the system.

 

I just took a look via VSTS and found some "stuff":

Windows 10 supports User Mode Code Integrity. Setting Powershell to ConstrainedLanguage mode prevents users from violating or circumventing UMCI. Once ConstrainedLanguage is set, some of these cmdlets have restrictions: https://technet.microsoft.com/library/mt634481.aspx

ConstrainedLanguage mode is not officially supported on any Windows 10 except Enterprise\Education and RT. In RT it is used to enforce UMCI. Setting CL on W10Home is not officially supported, but can be done.

The key limitation of ConstrainedLanguage is this: The Add-Type cmdlet can load signed assemblies, but it cannot load arbitrary C# code or Win32 APIs.

Infos on ConstrainedLanguage are spread across TechNet and MSDN.

-- All cmdlets in Windows modules, and other UMCI-approved cmdlets, are fully functional and have complete access to system resources, except as noted.
-- All elements of the Windows PowerShell scripting language are permitted.
-- All modules included in Windows can be imported and all commands that the modules export run in the session.
-- In Windows PowerShell Workflow, you can write and run script workflows (workflows written in the Windows PowerShell language). XAML-based workflows are not supported and you cannot run XAML in a script workflow, such as by using "Invoke-Expression -Language XAML". Also, workflows cannot call other workflows, although nested workflows are permitted.
-- The Add-Type cmdlet can load signed assemblies, but it cannot load arbitrary C# code or Win32 APIs.
-- The New-Object cmdlet can be used only on allowed types (listed below).
-- Only allowed types (listed below) can be used in Windows PowerShell. Other types are not permitted.
-- Type conversion is permitted, but only when the result is an allowed type.
-- Cmdlet parameters that convert string input to types work only when the resulting type is an allowed type.
-- The ToString() method and the .NET methods of allowed types (listed below) can be invoked. Other methods cannot be invoked.
-- Users can get all properties of allowed types. Users can set the values of properties only on Core types.
-- Only the following COM objects are permitted. -- Scripting.Dictionary -- Scripting.FileSystemObject -- VBScript.RegExp
Allowed Types: The following types are permitted in ConstrainedLanguage language mode. Users can get properties, invoke methods, and convert objects to these types.
AliasAttribute AllowEmptyCollectionAttribute AllowEmptyStringAttribute AllowNullAttribute Array Bool byte char CmdletBindingAttribute DateTime decimal DirectoryEntry DirectorySearcher double float Guid Hashtable int Int16 long ManagementClass ManagementObject ManagementObjectSearcher NullString OutputTypeAttribute ParameterAttribute PSCredential PSDefaultValueAttribute PSListModifier PSObject PSPrimitiveDictionary PSReference PSTypeNameAttribute Regex SByte string SupportsWildcardsAttribute SwitchParameter System.Globalization.CultureInfo System.Net.IPAddress System.Net.Mail.MailAddress System.Numerics.BigInteger System.Security.SecureString TimeSpan UInt16 UInt32 UInt64

 

This error message has nothing to do with Powershell ContrainedLanguage mode.

 

Exactly. That is what I meant.

 

Yes. I just checked that out and you saved me reply.

 

Which will stop .Net based malware.

 

Microsoft is slow to fix the .NET Framework known crappiness - despite the voluminous complaints.

 

PS>Attack can bypass PowerShell Constrained Language mode because as I noted previously(bold text):

PS>Attack

PS>Attack is a self contained custom PowerShell console which includes many offensive PowerShell tools which calls PowerShell (System.Management.Automation.dll) through .Net. The PowerShell attack tools are encrypted (AV evasion) and decrypted to memory at run-time.

PS>Attack includes some of the most popular PowerShell attack tools:

- Powersploit

- --Invoke-Mimikatz
- --Get-GPPPassword
- --Invoke-NinjaCopy
- --Invoke-Shellcode
- --Invoke-WMICommand
- --VolumeShadowCopyTools

-PowerTools
-PowerUp
-PowerView
-Nishang
-Powercat
-Inveigh

While PS>Attack is simply one method that an attacker can leverage PowerShell offensive tools without running PowerShell.exe, it is extremely effective.

Since PS>Attack is calling PowerShell from an exe, the executed PowerShell code bypasses constrained language mode.

Ref.: https://adsecurity.org/?p=2921
​

Solution? https://www.wilderssecurity.com/thr...s-around-the-globe.391870/page-2#post-2651693 which I will probably give a shot to determine what it "borks." Mode can always be changed to Constrained Language mode if Powershell scripting is required.

​

 

FYI - Constrained Language mode was introduced in PowerShell 3.0. So it appears Win 7 users SOL.

 

A bit more info on how Win 10's AMSI protects against PowerShell attacks that use System.Management.Automation.dll. So whether it is invoked using .Net, rundll32.exe, etc.. the code will be scanned as long as you're using an AV solution that utilizes the AMSI interface.

Antimalware Integration (Windows 10)

The new Windows 10 Antimalware Scan Interface (AMSI) enables all of the scripting engines (PowerShell, VBScript, and JScript) to request analysis of dynamic content, from a script file, typed commands at the command line, and even code downloaded and executed in memory. This enables scanning of PowerShell code before it is executed on the computer and is a potential game-changer when it comes to defending systems from offensive PowerShell code. When code is delivered to the PowerShell “engine” (System.Management.Automation.dll), it is sent to the AMSI for anti-malware checks. The anti-malware solution installed on the system needs to support AMSI in order for the code to be scanned. Windows Defender supports AMSI on Windows 10 out of the box. After scanning, if the AMSI returns a status OK, the code is executed. If it returns a negative, then the code is not executed.



This means that PowerShell attack code can be prevented from executing on Windows 10 computers, as long as the anti-virus/anti-malware solution supports the AMSI.

Ref.: https://adsecurity.org/?p=2277

 

Is this generally the case, or not? ESET appears to be one of those.
From BleepingComputer:
ESET Antivirus (and Smart Security) also includes script-based attack protection which protects against javascript in web browsers and Antimalware Scan Interface (AMSI) protection against scripts that try to exploit Windows PowerShell.

Emsisoft?

 

Related to AMSI implementation:

https://www.virusbulletin.com/blog/2017/01/living-dead-anti-virus/

 

Glad VB posted this. I posted equivalent comments on the Eset forum.

AMSI natively will only monitor direct execution of wscript, jscript, and PowerShell. If Google, Mozilla, and Microsoft can get "their act together" and instead of bashing the AV vendors for HTTPS interception provide an AMSI interface to their browsers that will allow the security vendors to examine web traffic after it is decrypted by the browser, external browser MITM interception will be a moot point.

Personally, I believe that will never happen. Quoting an old truism, "talk is cheap", bashing the AV vendors costs them nothing. Additionally and in my opinion the real reason is the browser vendors don't want any traffic intercepted and subject to external examination. Draw your own conclusions as why that might be.

 

AVG, and Bitdefender do for sure. Suspect all the major AV vendors also do so. As far as I am aware of, Emsisoft does not.

Also, Eset scans web traffic in the Windows Filtering Platform(WFP) in the current versions. For HTTPS traffic, the SSL protocol filtering option must be enabled to do so.

In prior Eset versions, it used a NDIS miniport filter attached to the network adapter to do so. This was problematic since any changes to IPv4/6 network adapter settings would cause Eset to "hiccup" resulting in the need for a repair install to be performed.

 

Does using cmd instead avoid at least some of the above vulnerabilities inherent in PowerShell? I use cmd for Microsoft store and app-related fiddle-faddle, having avoided PS for the longest. . CMD has issues also, otherwise my anti-exe wouldn't block it. But is it "safer" to use?