This post is inspired by a twitter debate I observed between a pentester and a defender. It's characteristic of several such debates I've seen on this topic.
The debate goes something like this:
And on and on. Here's my take on it. I'm a pentester, but was also a defender for many years at a F500. This response will not please everyone. That's fine, it's just an opinion. =)
They are both right.
Lemme splain....
Defenders do not view the world of infosec through the eyes of a determined, skilled attacker. They view the world through the quantity and quality of tickets generated by their SIEM (if they have one). It is true that a determined, skilled attacker (read and understand that) can work around a correctly implemented PowerShell block. One such method is to drop an exe to disk call a dlls. While there are tools to aid an attacker, this process is substantially harder to pull off. As a result, this extra effort is more likely to raise more alarms. Is it possible? Yes. Is it just as easy as landing with a call to powershell.exe? No. This has the effect of forcing the attacker to work harder and be yet more determined to compromise the org.
However, the benefit is still fully realizeable simply by taking a look at PowerShell based malware samples from say John Lambert or Security Doggo. If they use PowerShell, they are generally making a call to powershell.exe. If that is blocked, payload doesn't fire, the day is saved. There is merit to this argument because the environment is inherently more protected via by the inability to execute code via powershell.exe. Additionally, the vast majority of users have no use for it, with obvious exceptions for orgs that use it in their loginscript, which you can simply whitelist with applocker.
Bottom line: The environment is more secure without powershell.exe than with it. It is not perfect security, but that's why we have defense in depth. To suggest that it doesn't work in a pentester's edge use case is simply throwing the baby out with the bathwater and is not a good excuse for not considering the blocking of powershell.exe as a defensive control.
I can work around a block of powershell.exe, therefore there's no reason to block it. This is blunt way to put it, but generally the crux of the argument. It's absolutely true that PowerShell code can be run without powershell.exe and this attack is able to be pulled off in most environments (albeit with more work and plumbing in your attack). Additionally, it is well known that Microsoft is basically pushing all apps to use and/or support PowerShell. Server 2016, Nano, etc. are all heavily managed via PowerShell. That's a great convenience for defenders as well as attackers. Additionally, Microsoft is effectively ditching cmd.exe in favor of powershell.exe in future releases of Windows 10 (yes, I know, cmd.exe will still be available, but the point is undeniable: PowerShell is the future of Windows administration).
Finally, PowerShell v5 (with Windows 10) security enhancements are substantial. From advanced event logging to controls like Device Guard and JEA, along with ConstrainedLanguageMode (available since PSv3), the use of powershell.exe can be configured to make it difficult for attackers to execute their payload, while still allowing use for end users if necessary, plus like I said, we can just work around your block anyways...
Bottom Line: Don't block powershell.exe. It's a waste of time because my attacks are so 1337 that I can run PS without PS. Plus, even if you did block it, you'll have to remove the block eventually for new versions of Windows cuz you'll cripple yourself.
While both arguments have merit, here is what I tell my clients: If you are running a Win7 shop with PSv2 as your default with little to no hope for upgrading in the future, then configure Applocker or SRP to block powershell.exe for non-administrators (Good instructional article on Applocker). I agree with pentesters that this control can be worked around and is not perfect, but you will block attacks, dangerous attacks, by blocking powershell.exe. Generally these attacks will be executed by Bob the sales bro who 'Enables all the Content' in every spreadsheet he opens. Hopefully, Bob is not a system administrator (RIGHT???). If powershell.exe is blocked, you may just save the day.
However, do so with the understanding that this will not work forever and you will have to change tactics before long, especially after you upgrade to a current OS. Also, do so with the understanding that you should still layer this with other controls (e.g. blocking macro-enabled docs from the internet) and not rely on it completely to keep you out of the news.
This is, and always will be, a cat and mouse game. The minute we become stuck in a way of thinking, we are simply fast-tracking our own irrelevance. Shift and move your environment as necessary, not letting the drive for tomorrow's perfect security get in the way of today's good security.
This build doesn't require any "black magic" or hours of frustration like desktop components do. If you follow this blog and its parts list, you'll have a working rig in 3 hours. These instructions should remove any anxiety of spending 5 figures and not knowing if you'll bang your head for days.
Upgrade our current rig from 6 gtx 970s to 8 gtx 1080. Don't blow a fuse.
Nowadays building mid-grade to high-end password crackers is like playing with legos, albeit expensive legos.
We did a time lapse of the build:
There are few things we learned during the purchasing and assembly.
The memory slots are not labeled. Fill the banks similar to this image.
In the image below you can see the brackets that attach to the rear of the GPU for added support. Probably not needed but if you were to ship this rig I'd install them. This thing is HEAVY!
We had no hardware issues but we installed one GPU, booted the system, and once we verified it could POST with no issues, we started installing the OS. Once Ubuntu finished installing, we later reinstalled all GPUs. Since things went so smoothly, next time I'd just fully install all GPUs and fire it up. Nothing to worry about.
Not going to cover this in detail. But here are few things we considered.
Once OS is installed, verify GPUs are detected by OS:
lspci | grep VGA
Update and install dependencies for drivers and hashcat
sudo apt-get update && apt-get upgrade sudo apt-get install gcc make p7zip-full git lsb-core
Download Nvidia drivers. Nvidia 375.26 was current at the time of this build (January 2017).
UPDATE 4/10/2017 - If using 1080 Ti, use driver 378.13
wget http://us.download.nvidia.com/XFree86/Linux-x86_64/375.26/NVIDIA-Linux-x86_64-375.26.run chmod +x NVIDIA-Linux-x86_64-375.26.run sudo ./NVIDIA-Linux-x86_64-375.26.run
If you get warning messages about x86 you can ignore them. Here's an example of one:
WARNING: Unable to find a suitable destination to install 32-bit compatibility libraries. Your system may not be set up for 32-bit compatibility. 32-bit compatibility files will not be installed; if you wish
[Cto install them, re-run the installation and set a valid directory with the --compat32-libdir option
Install OpenCL runtime (not required but why not, use those CPUs too)
wget http://registrationcenter-download.intel.com/akdlm/irc_nas/9019/opencl_runtime_16.1.1_x64_ubuntu_6.4.0.25.tgz tar -xvf opencl_runtime_16.1.1_x64_ubuntu_6.4.0.25.tgz cd opencl_runtime_16.1.1_x64_ubuntu_6.4.0.25 ./install.sh
wget https://hashcat.net/files/hashcat-3.30.7z 7z x hashcat-3.30.7z cd hashcat-3.30
Test hashcat by running a benchmark...at 341 GH/s!!!!
meatball@kraken3:~/hashcat-3.30$ ./hashcat64.bin -m 1000 -b hashcat (v3.30) starting in benchmark mode... OpenCL Platform #1: NVIDIA Corporation ====================================== * Device #1: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU * Device #2: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU * Device #3: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU * Device #4: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU * Device #5: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU * Device #6: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU * Device #7: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU * Device #8: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU Hashtype: NTLM Speed.Dev.#1.....: 42896.1 MH/s (62.48ms) Speed.Dev.#2.....: 42604.1 MH/s (62.97ms) Speed.Dev.#3.....: 42799.0 MH/s (62.57ms) Speed.Dev.#4.....: 42098.9 MH/s (63.68ms) Speed.Dev.#5.....: 42871.5 MH/s (62.57ms) Speed.Dev.#6.....: 42825.0 MH/s (62.64ms) Speed.Dev.#7.....: 42848.9 MH/s (62.54ms) Speed.Dev.#8.....: 42449.8 MH/s (63.16ms) Speed.Dev.#*.....: 341.4 GH/s Started: Mon Feb 13 17:54:12 2017 Stopped: Mon Feb 13 17:54:31 2017
Install dependencies
sudo apt-get update sudo apt-get install mysql-server libmysqlclient-dev redis-server openssl mysql_secure_installation
Optimize the database
vim /etc/mysql/my.conf
Add the following line under the [mysqld] section:
innodb_flush_log_at_trx_commit = 0
Restart mysql
service mysql restart
Install RVM - (commands below are from https://rvm.io/rvm/install)
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 \curl -sSL https://get.rvm.io | bash -s stable --ruby
Download and setup Hashview
git clone https://github.com/hashview/hashview cd hashview
Install gems (from Hashview directory)
rvm install ruby-2.2.2 gem install bundler bundle install
Setup database connectivity
cp config/database.yml.example config/database.yml vim config/database.yml
Create database
RACK_ENV=production rake db:setup
In another terminal or screen session, kick off resque
RACK_ENV=production TERM_CHILD=1 QUEUE=* rake resque:work
note: In production mode no output will be displayed until a job has started
Run Hashview
RACK_ENV=production ruby hashview.rb
Start a job and start cracking!
Then intensely watch analytics in realtime while sipping on your favorite cocktail
We just bought our second 8 GPU rig! In a future post we'll show you how to easily support distributed cracking using Hashview.
@caseycammilleri
