Set-ExecutionPolicy Restricted notice this policy is sometimes overlooked Get-ExecutionPolicy -List Charl
The prevention of "Fileless" malware execution via a PShell script just takes one not being blind when downloading any script not from a reputable source. A few things to keep in mind: - Absolutely no script should have Base64 encoding for any large parts of the primary script. Many scrubs will disguise malicious code in Base64 encoding and those who may not be familiar with the encoding PowerShell can do may be convinced it's a type of encryption to protect the writer's "proprietary" code. This is nonsense, as most of these are malicious lines of code that will task processes to run from memory which basically makes what they're doing invisible to the majority of people, as they're designed to use very little memory resources. - Possibly the post important: Make use of the "WhatIf" switch. If you are not sure about a script, run it using the "WhatIf" switch. This switch will display everything the script will do, but it will not process any of the script's code and instead give you an exact idea as to what the script will do if you were to run it normally. If you notice the script just doing a bunch of stuff you are not familiar with, get rid of it. - Make use of the "Get-Help Get-Cmdlet -examples" commands to see exactly what a command or cmdlet in a script is designed to do if you're unsure. - Stay away from scripts that do not display any verbosity console content (i.e. run entirely silent). Though PowerShell is designed to run scripts fairly silently, verbosity output is something everyone who writes scripts uses just to let the end-user know what process is about to run, and/or results of any completed processes. - Stay away from poor code. It does not take a genius to create a half-a**ed script with no error-checking to dictate how the script will handle errors. - Keep your Execution Policy set to "AllSigned" or "Restricted." I sign all my scripts using a code-signing certificate from a verified certificate authority. Granted one can create self-signed certificates, generally those who go the extra step to sign their code are doing so as a way to verify the source it came from. - Stay away from scripts that are accompanied with a batch script that will call said script by simply double-clicking. Though a batch script to call a PowerShell script can be very useful, as it can alleviate the constant requirement to manually type parameter and switches, many of these auto-elevate the script and could run it with undesirable switches or parameters. Make sure you inspect the call script before running it and make sure it's not trying to bypass your current Execution Policy or the script's administrative requirements. - Be wary of any script that runs functions that have detrimental consequences to a system without using the [CmdletBinding(SupportsShouldProcess = $true)] advanced function parameter. Examples would be functions that delete files, registry values/keys and the like. These types of functions should always use the SupportsShouldProcess CmdletBinding parameter as it prompts you what it's about to do before it actually does it, allowing you to approve/deny. - Lastly, if you're still unsure, test it on a virtual machine.
What if some website drops/ loads a malicious java script containing instructions to excecute rowershell script silently?
Blocking "System.Management.Automation.dll" via SRP or other will help prevent Powershell-based Fileless malware.