HABEMUS CURSO: 2019

if something I have made clear working with Powershell for so long is that it is not as simple as many want it to appear and the second is that such a very powerful program, which

has become the basis of many 'bypass', but the same way you have these huge and powerful commands, they can also be used against you

That is, if you think that powershell is downloading .ps scripts to do the AV / IDS bypass that, in reality, many do not know what they do because they have not studied power shell Why?

-Because they think it's more than two with some more commands
-Because it's windows, it's simple safe -Not worth anything, I have 'curl'

Well, for these people who have poweshell installed and are playing with it, well read this post I think that something will do

Gven that PowerShell cannot be disabled could be use as an attack vector.

Logging PowerShell Activity

PowerShell logging can be enabled via Group Policy for PowerShell modules:

Microsoft.PowerShell.* (i.e., Microsoft.PowerShell.Management module) – Logs most of PowerShell’s core capability.
ActiveDirectory – Logs Active Directory cmdlet use. A lightweight Windows PowerShell script that performs a single function.
BITS Transfer – Logs use of Background Intelligent Transfer Service (BITS) cmdlets.
CimCmdlets (2012R2/8.1) – Logs cmdlets that interface with Common Information Model (CIM).
GroupPolicy – Logs Group Policy cmdlet use.
Microsoft.WSMan.Management – Logs cmdlets that manage Web Services for Management (WS-Management) and Windows Remote Management (WinRM).
NetAdapter/NetConnection – Logs Network-related cdmdlets.
PSScheduledJob/ScheduledTasks (PSv5) – Logs cmdlets to manage scheduled jobs.
ServerManager – Logs Server Manager cmdlet use.
SmbShare – Logs Server Message Block (SMB) sharing activity.

For these logs to be useful, they need to be fed into a central logging system with alerts configured for known attack methods.

Relevant activity:

Downloads via .Net (New-Object Net.WebClient).DownloadString)
Invoke-Expression (and derivatives: “iex”)
BITS activity
Scheduled Task creation/deletion
PowerShell Remoting

The best method to detect PowerShell attack code is to look for key indicators – code snippets required for the code to run correctly.

Example: Detecting Mimikatz (a widely-used tool for logged user credential capture)
Invoke-Mimikatz Event Log Keywords:

“System.Reflection.AssemblyName”

“System.Reflection.Emit.AssemblyBuilderAccess “

“System.Runtime.InteropServices.MarshalAsAttribute”

“TOKEN_PRIVILEGES”

“SE_PRIVILEGE_ENABLED”

For obfuscated PowerShell, custom rules should be developed. For example:

Look for lots of brackets { }
Look for lots of quote marks ‘ ”

Both of these are heavily used in obfuscation techniques and usually are not used by legitimate software or normal administrators.

PSLockDownPolicy And PowerShell Constrained Language Mode

Constrained language mode limits the capability of PowerShell to base functionality, removing advanced feature support, such as .NET and Windows API calls and COM access. This lack of advanced functionality stops most PowerShell attack tools, because they rely on these methods. However, in enterprise environments it can negatively affect legitimate scripts; thus it is highly recommended to schedule a testing period before activating this option, to filter out the legitimately used code.

Enable Constrained Language Mode:[Environment]::SetEnvironmentVariable(‘__PSLockdownPolicy‘, ‘4’, ‘Machine‘)

Enable via Group Policy:
Computer Configuration\Preferences\Windows Settings\Environment (https://adsecurity.org/?p=2604)

PowerShell V.5 With Applocker And Device Guard

PowerShell v.5 comes with significant embedded security features that make its use more secure for enterprise environments. These security features include:

Script block logging. Script block logging provides the ability to log de-obfuscated PowerShell code to the event log.
System-wide transcripts. System-wide transcription can be enabled via Group Policy and provides an “over the shoulder” transcript file of every PowerShell command and code block executed on a system by every user on that system.
Constrained PowerShell. Constrained Language mode (as described above in best practice 1).
Antimalware integration (Windows 10). The new Windows 10 Antimalware Scan Interface (AMSI) enables all 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.

In addition, using Applocker to block executables from unwanted user locations will provide better control.

Device Guard whic

h is also applicable on Windows 10 and Windows Server 2016 can be used to enforce constrained language mode and application whitelisting by leveraging advanced hardware features where supported. (https://docs.microsoft.com/en-us/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies)

Just Enough Administration – JEA

This is included with the latest update of Windows Management Framework 5.0 and 5.1, and is a security technology that helps organizations enforce information security by restricting IT administrative rights. JEA provides a practical, role-based approach to set up and automate restrictions for IT personnel, and reduces the risks associated with providing users with full administrative rights following the principle of least privilege.

JEA is implemented as a Windows PowerShell session endpoint (it requires PS remoting to be enabled), which includes a PowerShell Session Configuration file and one or more Role Capability files.

PowerShell Session Configuration file. This file is used to specify who can connect to an endpoint. Users and security groups can be mapped to specific management roles. Those files are specific to each machine, so an access control per machine is available. They contain information of what will be the name of the JEA endpoint, which roles will be assigned and of course who will have access to this endpoint. These files are PowerShell data files ending in a .pssc extension (https://docs.microsoft.com/en-us/powershell/jea/session-configurations).
Role Capability files. These files are used to specify what actions users in a particular role can perform. For example it can be restricted to use certain pre-selected cmdlets, functions and external programs making the use of custom potentially malicious cdmlets practically impossible. Examples of potentially dangerous commands that should be constrained, are ‘Start-Process’, ‘New-Service’, ‘Invokde-Item’ etc. Detailed information on how to create such files can be found here https://docs.microsoft.com/en-us/powershell/module/Microsoft.PowerShell.Core/New-PSRoleCapabilityFile?view=powershell-5.1.
JEA configuration samples. Examples and templates can be found in Microsoft’s JEA Github repository (https://github.com/PowerShell/JEA)

It is obvious that the security features integrated in the latest versions of PowerShell do not apply to v.2, which makes its use very attractive to adversaries; PowerShell v.2 can be used for lateral movement and persistence techniques with the same functionality. PowerShell v.2’s extra value is that because it does not have native logging capabilities, it remains undetected and offers stealth in attacker operations.

For that and other reasons Microsoft has
recently announced that PowerShell v.2 will be deprecated from the next Windows 10 Update which is scheduled for this September

(https://support.microsoft.com/en-us/help/4034825/features-that-are-removed-or-deprecated-in-windows-10-fall-creators-up),

..so either way it is highly recommend to check and remove PowerShell v.2 from your environment.

You can check whether Windows PowerShell 2.0 is installed by running the following (as an administrator).

On Windows 7/8.1/10, the following will return a State as either Enabled or Disabled:
- Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
On Windows Server, the following will return an InstallState of either Installed or Removed:

Get-WindowsFeature PowerShell-V2
IowerShell scripts are used in an enterprise environment,
Script Code ode signing is another control that improves security posture, by ensuring authenticity and integrity. This feature, along with a defined Execution Policy or Group Policy as “AllSigned” or “RemoteSigned”, will permit only digitally signed scripts to run. However we have to consider that several attacks in the past used malicious files digitally signed so this control just adds another security layer since it can be bypassed.

With the help of 'technet', you can make a good compilation of how to use powershell safe

We also leave 12 tips with your link to technet or the specific source PowerShell has much more strength than many people might think but ...

"Give me a PowerShell and I will move the Cyber world