Who needs malware? IBM says most hackers just PowerShell through boxes now, leaving little in the way of footprints A company's internal network, once compromised, is now more likely to be ransacked by automated scripts than a piece of malware. This according to researchers with IBM's X-Force, who found that in 2018 just 43 per cent of the attacks it analyzed utilized any sort of locally installed files. Rather, the hackers utilized …
The article didn't suggest the attack vector is new. Heck, it's been available long before your phrack 2004 article.
However, PS makes it very easy to do.
For instance: with one line of PS code you can load into memory and run mimikatz--with various options, or run your favorite script(s).
Perhaps you should take some time to learn PowerShell, instead of thinking there is no way it can be better than Linux.
Think about it... if all you can do is Linux, then you're half the hacker of someone who can do both!
I am experienced in Linux, shells (particularly bash), scripting (perl/tcl/...) and programming, and am only fairly low level in PowerShell but even I can see that PS is very powerful, particularly the native support for (and extension of piping to) full objects. Yes, it is wordy and slow and often tedious, and I don't like it, but it is more powerful in its constructs than bash -- close to the power of a typical Linux scripting language like perl or python.
Combined with its native support for some remote actions and remote objects, I can see that it is an effective vector for security issues. Unfortunately, it is also very useful for those of us who like to script many tasks and I fear that the knee-jerk reaction of many corporates will be to prevent users being able to create and run their own scripts (Powershell has options to prevent running unsigned scripts).
indeed i do , i live for scripting, but if you have a task that needs the power of powershell , you're gonna need ws admin privelideges , and probly access to servers where data is held , in which case you must be manually doing a job the I.T. dept should have automated for you already.
An apprentice left our office , to another where they had him manually looking up 5 or 6 hundred email address in outlook address book using a list of names they had, and adding them to an outgoing email
They do that every month apparently. It takes all day.
I automated that for them in 20 minutes,
I just try not to think how much of that kind of thing is going on all over this hospital , and industry in general, especially as nobody seems to appreciate my talents for automating things and saving 1000s of man hours regularly , at least not enough to make it my job and pay me appropriately.
Powershell has the ability to dynamically attach to and use any shared library on a Windows (desktop or server) machine. I am unaware of any Linux or Unix shell that has such a powerful facility.
The article's suggestion of using only digitally signed scripts when in super user mode is the best solution to my knowledge. That would put a stop to all this nonsense until the bad guys figure out a way around that. Perhaps all executables should be digitally signed.
I really like powershell - the utility of it, and the concept behind it.
I just dislike working with it. I wish I didn't, but I do, and a lot of it has to do with the verbosity of it.
Linux shells can be just as or more cryptic, but at least the commands tend to fit on one line.
Personally, I'm happy using python to perfom the sort of tasks I might want to use a shell script for, and as long as I stay away from OS features it's already completely cross platform, with those additional features only taking a little more effort to implement based on host.
Because Linda the accountant happens to have some computing knowledge and can be more effective at her particular job by automating some analysis of invoices that arrive by Outlook mail, extracting some useful data and inserting it into an Excel object in a Powerpoint slide.
Scripting is a poweruser tool, not an administrator tool.
"Scripting is a poweruser tool, not an administrator tool."
Irrelevant. Either it is a serious vulnerability or it is not.
If it is, lock it down.
Ninety percent of the time security reduces convenience or efficiency.
Unlocked doors are much easier to go through - no unlocking, no looking for keys, no need to ask permission to enter a restricted area. That doesn't mean they are always a good idea.
Trying to do the math:
29% - phishing attacks of which 45% (13% overall) were "business email compromise"
43% - unsecured public facing systems
At this point, I still don't know what proportion of attacks used Powershell, so i read the IBM press release and get:
"More than half of cyberattacks (57 percent) leveraged common administration applications like PowerShell and PsExec to evade detection". Only now I'm at almost 140% of attacks so I assume there is some overlap and if a large chunk of that is unsecured public facing systems, then the answer is likely the convenience of Powershell vs bring your own tools that might trip AV scanners.
Assuming good practices are followed (privilege separation between user and any administrative accounts, LAPS for administrative access to workstations, regular password changes for administrative user accounts/ widely used service accounts on workstations, disabling cached credentials where possible, patching, web access filtering, local AV/malware prevention), has there been an actual rise in attacks/successful attacks because of Powershell/PsExec?
Presumably you're an admin though?
There's zero need for a standard user to be able to execute PowerShell. Decent Windows security people have been advocating disabling PS for users for quite a while. Likewise for VBA, and in fact all kinds of other stuff that comes with the operating system. This used to be called hardening, but is now just good security practice.
There's zero need for a standard user to be able to execute PowerShell.
That is not a true statement. For some standard users there are non-zero needs to use PowerShell. It is the only effective scripting language on Windows so anyone who wants to script anything (particularly anything recent) finds themselves using it.
For example, I, as a user. have a script which synchronises the database for my password manager regularly, including determining whether the network is available at this time, etc.
I have another script which gathers data from items in Outlook, and I am planning to create another script which automates some Outlook tidying up.
And I have several other scripts.
Yes, users writing Powershell scripts is relatively uncommon, but it is certainly not the case that there is "zero need".
Sure, but allowing access to PS for all non-privileged users on the basis that a small percentage of folk might have a use case for it isn't the best approach either.
I agree the "zero-need" is incorrect, but it's a pedantic issue to take; the intent behind the whole comment is that non-priv users should not have access to PS. Nothing wrong with that assertion.
If there is a use case, then allow controlled access to the shell on a case-by-case basis.
"Sure, but allowing access to PS for all non-privileged users on the basis that a small percentage of folk might have a use case for it isn't the best approach either."
And this is where the detail of the article is missing - is Powershell the issue or Powershell with admin access? There is very little you can do with Powershell in terms of reconnaissance of a network that can't be done with existing script files if you aren't an admin user other than the convenience of not needing a telnet/SSH client if they aren't installed (i.e. default settings) even with relatively restrictive policies (i.e. block cmd.exe/cscript/jscript, common script extensions and use AV that blocks hacking tools) as there is usually something left to run logon scripts or similar admin functions.
If the report details are actually "unsecured systems allow attackers full access to the tools on those systems to then use against other connected systems" what would the response be?
There's more going on here than simply "using Power Shell". Unix has had a "powerful" shell since forever, yet has less frequent and harder to perform attacks. Are the attackers using Power Shell to perform operations that are easy because of weaknesses in the system? So the message should be "easy to exploit weaknesses" rather than "OMG Power Shell"?
The point is less "PS is bad" and more "malware in the field is moving to PS, making detection of files on disk less reliable as a method of confirming you're safe". There could be several reasons that a PS script is less secure than a Linux shell script, but it could simply be that more effort is being put into using those scripts. Either way, you have to get in enough to run the script.
Also, while this comes from someone who dislikes PS, I'll say that PS is inherently more powerful than the average *nix shell, since a) there is lots of builtin functionality in modern PS that can do everything a modern *nix shell can and more by worming its way into every modicum of Windows functionality, and 2) modern versions of Windows ship with .NET and PS can directly utilize its classes, types, methods, et al., giving it even more power. Ever used PS on the latest Server?
I only use PS when it is the best option, but when I do, it puts in work. I utilize it on the job to provision gold images, in deployment, patching workstations, and for remote shell logins... I even replaced our old, crufty, expensive, multi-phase, unmaintained ADToolkit setup with a grand total of 10 lines of PS on the domain controller, running as a scheduled task every hour.
The bottom line is PowerShell has a module for every part of the system; can be extended with scripts, modules, binaries, and .NET classes/methods; and comes preinstalled on every modern Windows in some version or another... Just like Bourne shells, really. Combine that with the fact it's made by Microsoft and is targeted for Windows, and it's suddenly ripe for exploitation and vulnerability automation, so it's a surprise it took until now to finally start getting noticed—by either side.
Addendum: Funnily enough, PS shares a similar issue with *nix shells and unreliable userlands; the latest versions of PS greatly differ from the original incarnation, including changes to syntax and loads of incompatible features. Even the installed .NET version is enough to cause headache.
For years people complained that UNIX system were much better than Windows for system administration because so much housekeeping can be automated with a small shell script - Microsoft listened to us and along came Power Shell ... and the hackers are demonstrating what a powerful shell script can do to the system.
"Live and Learn" used to be a phrase everybody used, but who learns from history these days?
For years people complained that UNIX system were much better than Windows for system administration because so much housekeeping can be automated with a small shell script
and then some idiot decided "curl … | /bin/bash" was a brilliant way to install software.
and then some idiot decided "curl … | /bin/bash" was a brilliant way to install software.
Well, that's an idiots last resort to installing s/w on 'Linux. So it's idiots all the way down that trouserleg of time.
1) your distros repo
2) compile it youself (inc. Arch AUR and similar)
3) deb repos (for debian), PPAs and other options for getting out of repo or fresher packages on release based distros.
3) (most recent, and gain popularity on some distros) snaps, flatpacks or Appimages.
The last thing anyone should do is run curl commands or bash scripts copy/pasted or sourced from the internet without proofreading, especially if it needs root access.
Never mind how powerful PS is or is not, or how secure Windows is or isn't the first gatekeeper to a system is how wary the human who is controlling, operating or managing
Powershell v5 supports enhanced logging beyond the normal logging "PS Engine started / Stopped", or "PS Shell opened / closed". Enhanced logging includes stuff like script tracing (kind of like a key logger, but for powershell, also includes logging for spawned or called processes), module logging (triggers events if certain cmdlets or combinations of are executed) etc.
Trouble is, as with any comprehensive logging strategy, it requires a lot of storage to maintain any useful timeframe of logs (and potential costs with implementing something like Splunk or ELK to ingest and index those logs), and company's still shy away from spending buckets of cash on security solutions and strategies which might be needed (i.e. cannot guarantee the need or ROI).
There are other issues at play though too; previous versions of the PS engine can still be present on a system which don't support enhanced logging.
PS v2/3 are perfect examples; they don't provide the same level of support for modern cmdlets, but they also don't support enhanced logging, and are still directly integrated into the .Net Framework. An attacker would still have a massive range of effects using the old engines, and a much lower likelihood of detection.
Haven't read IBM's reporting direct yet, but I would be curious to see what version of PS they typically see actors using...
"It is possible to wrap protections around PowerShell to stop it being abused, such as requiring scripts to be digitally signed."
People pay for digital signatures or steal them. Been going on for years. I have the Sysinternals Video Library on my YouTube channel that Mark Russinovich and David Solomon were kind enough to allow me to upload. Those are old now, over 10 years old and it's even mentioned in there that "digital signatures" are purchased by malware authors so mean very little.
This supports the argument I have been making for many years that any corporate body should have its own internal certificate authority. whee I have seen this implemented it's not a huge cost but does give you the ability to sign with a self generated certificate which never needs to leave your network boundary. This allows much greater granularity of control and prevents the organisation becoming the victim of an external cheap or free cert provider being hacked.
There are some very specific hardware controls you need to take over the physical root CA server however and I have seen more than one which was hosted in heavy duty steel cage bolted to a concrete floor.
When I heard signed script, I thought they were talking about corporate CA certs. The certificate store has grown to be a mess though with CAs from world+dog pre-populated for your convenience. This is another area where hardening needs to targeted. You have to trust the CA which can produce a code signing certificate. Enough damage can be done even when the rouge CA only produces TLS certs and javascript execution is permitted on that basis.
I don't see why a corporate CA has to be limited to internal use either. Properly managed (I know fanatsy world) corporate CAs can be used to vet comms between partners, more trustworthy than common TLS or even some EV TLS certs issued by traditional third-party CAs.
Take a browse through the certificate store in a default Windows install. Allow your paranoia to interpret the names of some of them. Is there a five eyes CA in there? How about an FSB? Don't leave China out of consideration nor North Korea, Isreal, Iran; all of their spy groups have entertained the idea of gaining a foothold this way. If not, they do not deserve to have Intelligence in their names.
Big Blue: "In cases where networks were compromised by attackers, IBM X-Force saw a shift to cybercriminals abusing administrative tools, instead of malware, to achieve their goals. "
Are you sure the local Admin wasn't pressured/bribed to share admin passwords and credentials ?
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
