
The increased use of PowerShell in attacks [pdf] - selmat
https://www.symantec.com/content/dam/symantec/docs/security-center/white-papers/increased-use-of-powershell-in-attacks-16-en.pdf
======
ezquerra
PowerShell is obviously a much better scripting language than the ancient DOS
BAT "language" (if you can call it that). In theory it's also mostly
ubiquitous on Windows which means that you can rely on it being there when
creating a script. Yet I've found that often people keep using BAT files (e.g.
in build scripts, etc). I think it is because you cannot just execute a
PowerShell script unless it is signed or the user has manually enabled non
signed script execution (by executing a command on the PowerShell command).
This means you cannot rely on it just working, at which point it's often best
to fall back to DOS or use another scripting language such a Python.

I understand that this is done for security reasons, but Windows already lets
you execute any executable or BAT file that you might have downloaded from the
Internet. So I'm not sure that disabling PowerShell script execution really
gains you much (and there are probably other better solutions anyway).

So IMHO as long as DOS is available and PowerShell is so limited by default
BAT files will not go away, which is unfortunate.

~~~
Arnavion
My heart sinks every time I see foo.bat next to foo.ps1, where foo.bat is just
`powershell -ExecutionPolicy Unrestricted -Command foo.ps1` so that it's
double-click-friendly.

~~~
henrikschroder
I'm definitely guilty of doing that the very few times I had to write a
powershell script.

But what's the alternative? What's the proper way of signing a script, and how
much work is it to do that?

~~~
hobs
Just put your powershell file in an executable, its been around for ages.

[https://gallery.technet.microsoft.com/PS2EXE-Convert-
PowerSh...](https://gallery.technet.microsoft.com/PS2EXE-Convert-
PowerShell-9e4e07f1)

Read more on how to use it at
[https://redmondmag.com/articles/2017/01/27/convert-a-
powersh...](https://redmondmag.com/articles/2017/01/27/convert-a-powershell-
script-into-an-exe-file.aspx)

~~~
userbinator
Over 18KB for a "Hello World" _script_ (even a _native_ EXE would be
smaller)...? A "stub" batch file to execute it is a few dozen bytes at most.

Then again, those using PS probably don't care about such things being small
and efficient anyway.

~~~
hobs
I didn't downvote you, but consider that I answered the GP's question and
solved a problem they are having, and you added some snark.

There is plenty of talk in this space about trading off machine resources for
programmer effectiveness, so while your gripe is technically accurate that
ship has sailed long long ago.

------
gregmac
This is not very surprising at all.

The use of PowerShell is completely analogous to using shell scripts on linux,
along with making use of things like the GNU core utils and other nearly
universally-installed utilities (curl/wget, tar, etc).

Traditionally there wasn't a lot you could do purely from a shell or scripting
environment on Windows -- all the "good stuff" was in Win32 APIs, hence
needing to ship binaries.

Microsoft has been adding everything to PowerShell, to the point that you can
now do nearly anything you can do with the GUI -- and in many cases more,
since most of the administrative commands accept a -ComputerName parameter and
are integrated with domain authentication. It's only natural to take advantage
of that.

~~~
krallja
Disagree strongly with the need to ship binaries to get up to mischief. Win32
is available from WSH (cscript.exe/wscript.exe), which has been included by
default since Windows 98.

------
dkhenry
I think this is just a observation that correlates with an increase in the
usability of powershell. I have been very impressed with recent releases, they
have a lot of functionality built in and the ecosystem is _finally_ starting
to mature with NuGet and Chocolatey.

------
tyingq
Not a huge surprise. A fairly ubiquitous, already installed interpreter that
has routines to do system level stuff. Same reason PHP scripts are popularly
uploaded by similar groups on Unix machines.

------
tarlinian
This explains why we're not allowed to run _any_ PowerShell scripts that are
not signed by some IT root certificate on my work laptop. However, given that
I can run any arbitrary executable (with user rights), this does seem a bit
ridiculous.

~~~
T-hawk
This is PowerShell's default behavior, to only run scripts that are signed.
The configuration is changeable by an administrator.

I think this is a reasonable precaution, given PowerShell's potential scope as
an attack surface, compared to the tiny fraction of Windows machines that are
ever actually used to do anything with PowerShell.

~~~
tarlinian
I know that. But they won't let users change the default policy to
RemoteSigned...that's what I find annoying. (I can't use stuff like posh-git
as a result.) The proposed workaround is to copy scripts into ISE and then use
the "Run Snippet" feature. How does PowerShell present more of a surface than
the standard Windows APIs available to any executable though?

~~~
T-hawk
PowerShell scripts have the same access capability as any executable... but it
may be easier to get a malicious PowerShell script onto and running on a
target machine. Antivirus programs will scan executables and users may know to
be suspicious of them, but it's not hard to imagine a user clicking a
harmless-looking .ps1 file inside an archive that suddenly starts executing.

------
dsl
I might be a bit biased working in offensive security, but 90% of the
PowerShell I see in use is malicious.

Unfortunately Microsoft has let the genie out of the bottle, and most of the
advancements in PowerShell security are centered around trying to add ACLs and
logging to a scripting language, or figuring out how much of it you can
disable and still have things work in production.

One of the best things we can hope to do going forward is sign on more
Antivirus vendors to support Microsoft AMSI [1] which is basically a hook to
pass PowerShell (and other scripting languages) off to your AV engine before
they get executed.

1\. [https://msdn.microsoft.com/en-
us/library/windows/desktop/dn8...](https://msdn.microsoft.com/en-
us/library/windows/desktop/dn889587\(v=vs.85\).aspx)

~~~
kogir
> Unfortunately Microsoft has let the genie out of the bottle

PowerShell has no more rights or power than the user it runs as. Anything you
can do in PowerShell you could also do via WMI, Win32 API calls, etc.

------
PaulHoule
So far as I know people have been using bash to implement atta cks on Unix
systems since 1992 if not earlier.

------
Numberwang
Not that I have much to add here, but as a complete non-techie PowerShell
seems amazingly powerful for this use.

I went from having no knowledge at all to having written a web scraping
function and checked 7000 sites for a specific phrase in less than two hours.
It was the most intuitive piece of technology I've ever used.

~~~
simooooo
are you nuts? its about 10x harder to use than c#, and twice as hard to debug.

I've come to the conclusion that its just better to write a small c# app than
try and use powershell

~~~
joeyaiello
PM on PowerShell here: if you have any of those small C# apps handy, I'd love
to take a look at them to see what you're doing that's difficult in
PowerShell.

Similarly, we're trying to make some improvements to debugging right now with
PowerShell 6.0 [1] (the one that's cross-plat and built on .NET Core), and I'm
very interested in hearing your feedback on how we can do a better job there.

Even if it's "fix your docs" or "too hard to learn", that's great info,
especially coming from a C# guru.

[1]:
[https://github.com/powershell/powershell/issues?utf8=%E2%9C%...](https://github.com/powershell/powershell/issues?utf8=%E2%9C%93&q=label%3AArea-
Debugging%20)

~~~
mpw222
Writing a _robust_ , idiomatic PowerShell function of any complexity is
deceptively challenging, and the background required to do it correctly is
almost all unique to PowerShell. PS is a weird amalgamation of C#, Bash, Perl,
VB and cmd-isms that ends up being incredibly confusing to basically everyone.

Try getting an experienced C# developer to write a PS function that:

\- Initializes an IDisposable resource and deterministically disposes of it
when the function terminates (successfully, with an error, or due to ctrl+C).
\- Honors the caller's $ErrorActionPreference/-ErrorAction. \- Understands
that catches won't catch "non-terminating" errors. \- Throws errors without
trashing the ErrorRecord so that the caller gets a meaningful stacktrace. \-
Copes with the difference between process working directory and PS working
directory if a .NET method and a relative path are involved. \- Doesn't blow
up on a square bracket because someone didn't realize they needed
-LiteralPath. \- Doesn't accidentally write an unintended object to the
pipeline. \- Does something reasonable with pipeline input. \- Doesn't get
tripped up by type coercion magic - $a = @(); $a -eq $null \- Uses multiple
ParameterSets without creating ambiguity problems. \- Doesn't get tripped up
by PS silently swallowing exceptions thrown by property getters. \- Uses some
appropriate subset of language features and modules available across different
versions of the OS and WMF. The OS based limitations are understandable. The
hard dependencies that Microsoft's own products have on specific PS versions
are not. \- Is not super-slow.

It's not impossible, but it sure is hard (and takes a ton of boilerplate), and
there aren't many resources out there to teach you how. It's all quick and
dirty "how to do X" recipes for sysadmins that don't care about more than what
they need to paste into a console.

To be clear, I actually mostly like PS I'm just trying to express a set of
pain points here.

~~~
joeyaiello
That list you just provided is actually an AWESOME list of things we should
make more accessible/understandable in our documentation. There's a few that
would also make great rules for PSScriptAnalzyer[1] (basically our linter; the
LiteralPath one in particular would probably be easy to write as a warning).

At this point I should also plug our tooling improvements. First, our VS Code
Extension[2] is AWESOME, debugging there has massively improved, there's
snippet support for boilerplate with best practices, it integrates directly
with PSScriptAnalzyer, and even enables some "quick fix" of linter warnings.
We've also got something called Plaster[3] that does templating to encourage
best practices (think of it like a "Yeoman for PowerShell").

But yeah, as we craft new docs for writing the best "cross-CLR, cross-
platform" (aka universal, aka portable) PowerShell modules, I want to make
sure we tick all these boxes.

Oh, and we believe we addressed the whole "different singleton version on
different versions of Windows/WMF" thing by making sure that PowerShell 6[4]
is x-copyable, fully side-by-side, and supported downlevel to Windows 7/2008
R2 (though Win7 support is currently busted, we're working through fixing it).
If you've got a workload or an application that depends on a new feature of
PowerShell, you can include PowerShell 6 app-local, or you can distribute it
to machines in an environment through either MSI or a ZIP-based file copy.

As for Microsoft products that support specific versions: again, I totally
hear you. The best thing you can do is push on those products their respective
feedback mechanisms (almost everything is on the Feedback Hub or some product-
specific UserVoice now) to support all versions of PowerShell. In the
meantime, the side-by-side nature of PowerShell 6 means you can install the
latest version without fear that you'll void your support or break existing
scripts/workloads.

[1]
[https://github.com/PowerShell/PSScriptAnalyzer](https://github.com/PowerShell/PSScriptAnalyzer)

[2] [https://github.com/PowerShell/vscode-
powershell](https://github.com/PowerShell/vscode-powershell)

[3]
[https://github.com/PowerShell/Plaster](https://github.com/PowerShell/Plaster)

[4]
[https://github.com/PowerShell/PowerShell](https://github.com/PowerShell/PowerShell)

------
GlobalServices
I love PowerShell. We use it to manage farms of machines, and I use Amazon's
excellent PowerShell aws library to do everything from managing my Route53 DNS
to setting up new Amazon VPCs.

Security issues aside, it's by far the best OS shell scripting language
around, and it has concepts that make it different from any other attempt to
write a shell language that includes pipes and redirections.

------
ghrifter
Is there a list of these symantec white papers to read?

~~~
usrme
A lot of them can be seen by Googling for "site:symantec.com filetype:pdf
white paper" and appending any other term you are interested in.

Admittedly not the best way to get at them, but Symantec's own website doesn't
seem to list them in a more user-friendly fashion than straight up Googling...

~~~
ghrifter
Thanks, forgot about searching for file types!

