Now you see me: Exposing fileless malware

[Azure]

Those scripts will still execute in Constrained Language mode. If you want to learn why, the answer is here:

PowerShell Constrained Language Mode

Don't get too excited. Constrained Language Mode is bypassable using PowerShell 2.0.

I've said it millions of times. PowerShell should be disabled. There is no sweetspot for PowerShell. Disabling it on Windows breaks nothing in 99.999% of cases. It isn't needed by virtually 100 % of non-Enterprise, non-geek users. You don't need it enabled.

My wanting to know about configuring the language modes was just to know, and nothing else.

Can malware re-enable powershell even when the user disabled it?

 

[tonibalas]

They will be able to use any software that's on a victims PC

I beleieve you are right and already happened with CCleaner a few months back

 

[Andy Ful]

PowerShell 2.0 can be removed via 'Turn Windows features on or off'. I did not hear about the malware that could revert this. But, if the malware gets the sufficient rights then maybe it is possible. Anyway, such malware does not need PowerShell to do what it wants.

 

[WildByDesign]

Can malware re-enable powershell even when the user disabled it?

It is enabled via a System level Environment Variable. So if the malware includes any sort of elevation of privilege, then Yes it could disable and bypass Contrained Language Mode.

As Lockdown had said, Constrained Language Mode is only really a small step in the right direction. It should be only considered one small layer (or hardening step) in a layered security setup. Users that don't depend on PowerShell 2.0 should remove that as well. And utilize security solutions that can filter command lines used by PS and other scripting/interpreter engines.

 

[shmu26]

On Windows 10 it is becoming harder and harder to do without powershell.
I had powershell disabled on my wife's laptop, and I couldn't understand why she never ever got feature updates like Fall Creators. When I re-enabled powershell, she got the update right away.

And if you use softs that monitor powershell, such as NVT ERP, you have to be a total expert to figure out where those powershell command lines are coming from. For instance, they might be parented by svchost. And who spawned that instance of svchost? Even examining the logs won't always tell you.

 

[Deleted member 65228]

I think next level of file-less malware may not use PS other programs like it. They will be able to use any software that's on a victims PC. Like hijacking the update mechanism of any software a lot of data could be downloaded and uploaded without the AVs detecting it. Its a very difficult task but malware is getting more and more sophisticated.

They can already do this if they want but updating systems in software differs so it has to be a specific target.

PowerShell is used because it's quick and easy to deploy and a lot of AVs have trouble scanning PS scripts effectively (it would appear).

 

[shmu26]

On Windows 10 it is becoming harder and harder to do without powershell.
I had powershell disabled on my wife's laptop, and I couldn't understand why she never ever got feature updates like Fall Creators. When I re-enabled powershell, she got the update right away.

As far as I have seen, Appguard at default settings will allow these Microsoft powershell commands to run enough so that you will get the updates. But they won't necessarily achieve their full purpose. For instance, the command that I posted above: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\SmbShare\DisableUnusedSmb1.ps1 -Scenario Server"
It wants to modify system settings. Appguard won't let it do that. Probably not so important in the larger picture of things, but nevertheless, Microsoft is increasing the use of powershell, and we can't escape it.

 

[509322]

On Windows 10 it is becoming harder and harder to do without powershell.
I had powershell disabled on my wife's laptop, and I couldn't understand why she never ever got feature updates like Fall Creators. When I re-enabled powershell, she got the update right away.

And if you use softs that monitor powershell, such as NVT ERP, you have to be a total expert to figure out where those powershell command lines are coming from. For instance, they might be parented by svchost. And who spawned that instance of svchost? Even examining the logs won't always tell you.

As far as I have seen, Appguard at default settings will allow these Microsoft powershell commands to run enough so that you will get the updates. But they won't necessarily achieve their full purpose. For instance, the command that I posted above: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\SmbShare\DisableUnusedSmb1.ps1 -Scenario Server"
It wants to modify system settings. Appguard won't let it do that. Probably not so important in the larger picture of things, but nevertheless, Microsoft is increasing the use of powershell, and we can't escape it.

Windows Update is not dependent upon PowerShell. So stating there is a causal linkage based solely upon your observation of wife's system not getting feature updates via Windows Update and PowerShell being disabled is not correct.

Your statement that AppGuard does not permit certain parts of the DisableUnusedSmb1.ps1 script to succeed is correct. However, the whole purpose of the script is made at the second comment-out ! So it brings up a point that has been made over-and-over during the ridiculous Eternal Blue\Double Pulsar scare - if you are a home user that does not connect to a Server using SMB protocol then you don't need to worry about it.

# Copyright (c) 2017 Microsoft Corporation. All rights reserved.
#

# This script is used to automatically removes support for the legacy SMB 1.0/CIFS protocol when such support isn’t actively needed during normal system usage.
Param
(
    [Parameter(Mandatory=$True)]
    [ValidateSet("Client", "Server")]
    [string]
    $Scenario
)

#
# ------------------
# FUNCTIONS - START
# ------------------
#

Function UninstallSmb1 ($FeatureNames)
{
  try
    {
       Disable-WindowsOptionalFeature -Online -FeatureName $FeatureNames -NoRestart
    }
    catch {}
}

#
# ------------------
# FUNCTIONS - END
# ------------------
#

#
# ------------------------
# SCRIPT MAIN BODY - START
# ------------------------
#


$ScenarioData = @{
    "Client" = @{
        "FeatureName" = "SMB1Protocol-Client";
        "ServiceName" = "LanmanWorkstation"
    };
    "Server" = @{
        "FeatureName" = "SMB1Protocol-Server";
        "ServiceName" = "LanmanServer"
    }
}

$FeaturesToRemove = @()

foreach ($key in $ScenarioData.Keys)
{
    $FeatureName = $ScenarioData[$key].FeatureName
    $ServiceName = $ScenarioData[$key].ServiceName

    $ScenarioData[$key].FeatureState = (Get-WindowsOptionalFeature -Online -FeatureName $FeatureName).State
    $ScenarioData[$key].ServiceParameters = Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\${ServiceName}\Parameters"
}

$FeaturesToRemove += $ScenarioData[$Scenario].FeatureName
$ScenarioData[$Scenario].FeatureState = "Disabled"

$RemoveDeprecationTasks = $true

foreach ($key in $ScenarioData.Keys)
{
    if($ScenarioData[$key].FeatureState -ne "Disabled" -and
       $ScenarioData[$key].ServiceParameters.AuditSmb1Access -ne 0) {

        $RemoveDeprecationTasks = $false
    }
}

if ($RemoveDeprecationTasks) {
    $FeaturesToRemove += "SMB1Protocol-Deprecation"

    $RemoveToplevelFeature = $true

    foreach ($key in $ScenarioData.Keys)
    {
        if($ScenarioData[$key].FeatureState -ne "Disabled") {
            $RemoveToplevelFeature = $false
        }
    }

    if ($RemoveToplevelFeature) {
        $FeaturesToRemove += "SMB1Protocol"
    }
}

UninstallSmb1 -FeatureName $FeaturesToRemove

$NewFeatureState = (Get-WindowsOptionalFeature -Online -FeatureName $ScenarioData[$Scenario].FeatureName).State

if ($NewFeatureState -ne "Enabled")
{
    $ServiceName = $ScenarioData[$Scenario].ServiceName
    $RegistryPath = "HKLM:\System\CurrentControlSet\Services\${ServiceName}\Parameters"
    New-ItemProperty -Path $RegistryPath -Name AuditSmb1Access -Value 0 -PropertyType DWORD -Force | Out-Null
}

If you are a home user not using SMB1 and never using SMB1 then it is stupid to run that SMB1 task over-and-over. You're lowering your system security for the sake of allowing a useless repetitive task to run.

PowerShell is a menace. It should be disabled.

Microsoft recommends the disabling of PowerShell to IT Pros to eliminate the PowerShell menace.

You don't have to be a total expert to figure out your system, but you do have to put forth the time and effort to learn. Without knowing what is on and what is happening on your ecosystem at a certain level you as the user might as well just play security theater.

Security begins with knowledge and a certain mind set.

This is where I leave the discussion.

They can already do this if they want but updating systems in software differs so it has to be a specific target.

PowerShell is used because it's quick and easy to deploy and a lot of AVs have trouble scanning PS scripts effectively (it would appear).

The Microsoft group responsible for the item in question decides what and how. They may use PowerShell if they wish. It's not an AV-conflict avoidance tactic. It's up to the Microsoft group to decide. And PowerShell is used very infrequently.

 

[shmu26]

Windows Update is not dependent upon PowerShell.

It is not dependent in principle, but there are certain updates where Microsoft wants to know your hardware/software config before they decide to give you the update. So I am guessing this is where a powershell script comes into the picture. I have observed more than once that a Microsoft update was preceded by a powershell script.

 

[509322]

Can malware re-enable powershell even when the user disabled it?

Malware can provide its own copy of powershell.exe.

On top of that, when powershell.exe is disabled in Windows, PowerShell is not really disabled on Windows. system.management.automation.dll must be prevented from loading.

The best way to deal with the PowerShell menace is just to disable it and remove the attack surface and lock down the system. Period.

If you want to use default-allow then you will always be subject to the "Behind the 8-Ball Rule."

 

[509322]

It is not dependent in principle, but there are certain updates where Microsoft wants to know your hardware/software config before they decide to give you the update. So I am guessing this is where a powershell script comes into the picture. I have observed more than once that a Microsoft update was preceded by a powershell script.

PowerShell never runs during WIndows 10 Updates. Verify it for yourself. If it did, you would see AppGuard block events.

I've been running multiple systems with PowerShell completely disabled (to include PowerShell *.dlls) and not a single Windows Feature has ever failed to be installed.

Stop stating incorrect things.

 

[shmu26]

Malware can provide its own copy of powershell.exe.

On top of that, when powershell.exe is disabled in Windows, PowerShell is not really disabled on Windows. system.management.automation.dll must be prevented from loading.

The best way to deal with the PowerShell menace is just to disable it and remove the attack surface and lock down the system. Period.

If you want to use default-allow then you will always be subject to the "Behind the 8-Ball Rule."

How to prevent the dll from loading? Simply disabling powershell won't do that.

 

[509322]

How to prevent the dll from loading? Simply disabling powershell won't do that.

Add it to the User Space list and set it to YES.

 

[shmu26]

PowerShell never runs during WIndows 10 Updates. Verify it for yourself. If it did, you would see AppGuard block events.

I've been running multiple systems with PowerShell completely disabled (to include PowerShell *.dlls) and not a single Windows Feature has ever failed to be installed.

Stop stating incorrect things.

Do you have systems with MS Office installed? When I receive Microsoft updates, I receive updates for Windows and Office at the same time. Hard to tell what is causing what, but I have seen powershell run. I don't see blocks in Appguard because I have AG at close to default settings, so for me PS is a guarded app, but not blocked.

 

[509322]

Do you have systems with MS Office installed? When I receive Microsoft updates, I receive updates for Windows and Office at the same time. Hard to tell what is causing what, but I have seen powershell run. I don't see blocks in Appguard because I have AG at close to default settings, so for me PS is a guarded app, but not blocked.

I have Microsoft Office installed. And once again, Microsoft Office updates are not dependent upon PowerShell.

 

[Andy Ful]

It is enabled via a System level Environment Variable. So if the malware includes any sort of elevation of privilege, then Yes it could disable and bypass Contrained Language Mode.
...

That is true for the reg tweak mentioned in one of the previous posts, but not true when someone uses Applocker or Device Guard. However, I am not a fan of the above logic.
If the malware runs elevated, then the game is over. You cannot rely on such system and it does not matter if the malware bypassed Constrained Language mode or not.
Building security based on the assumption that malware can run elevated is a very complicated task and probably impossible to achieve in practice.
The user should concentrate on not allowing the malware to run or as a backup solution, allow the malware to run restricted with possibly low rigths (not elevated).
That is the purpose of Applocker, Device Guard, AppContainer, SRP, AppGuard, Comodo Firewall, Excubits drivers, VoodooShield, NVT ERP, using SUA, using PowerShell Constrained Language mode, etc.
Actually, Constrained Language mode can stop almost all dangerous PowerShell attacks. It can be bypassed, but this would be unnecessary effort, because almost no one uses it (at present moment).
.
By the way, thanks for your posts on Excubits drivers.

 

[shmu26]

That is true for the reg tweak mentioned in one of the previous posts, but not true when someone uses Applocker or Device Guard. However, I am not a fan of the above logic.
If the malware runs elevated, then the game is over. You cannot rely on such system and it does not matter if the malware bypassed Constrained Language mode or not.
Building security based on the assumption that malware can run elevated is a very complicated task and probably impossible to achieve in practice.
The user should concentrate on not allowing the malware to run or as a backup solution, allow the malware to run restricted with possibly low rigths (not elevated).
That is the purpose of Applocker, Device Guard, AppContainer, SRP, AppGuard, Comodo Firewall, Excubits drivers, VoodooShield, NVT ERP, using SUA, using PowerShell Constrained Language mode, etc.
Actually, Constrained Language mode can stop almost all dangerous PowerShell attacks. It can be bypassed, but this would be unnecessary effort, because almost no one uses it (at present moment).

Just trying to make sure I understand: Constrained Language achieved by reg tweak can be bypassed, but only if malware has already attained elevated privileges, in which case "gameover" is anyways very close?

 

[Andy Ful]

Just trying to make sure I understand: Constrained Language achieved by reg tweak can be bypassed, but only if malware has already attained elevated privileges, in which case "gameover" is anyways very close?

Generally yes. But Constrained Language mode will not protect you against some PowerShell attacks performed as standard user (uncommon in the wild).

 

[shmu26]

Actually, Constrained Language mode can stop almost all dangerous PowerShell attacks. It can be bypassed, but this would be unnecessary effort, because almost no one uses it (at present moment)

MICRO$OFT is probably trying to keep constrained language hidden away and hard to enable, so they can sell it as part of their expensive enterprise security packages.

 

[Deleted member 65228]

Unless you really need PS... Just disable it...

The Microsoft group responsible for the item in question decides what and how. They may use PowerShell if they wish. It's not an AV-conflict avoidance tactic. It's up to the Microsoft group to decide. And PowerShell is used very infrequently.

I don't know what you are saying. The post I made which you quoted is about malware authors not genuine developers at MS. I'm saying that malware authors choose to use it when they do because is quick and easy for them to do/deploy and it is true that many AVs struggle with PS scripts.