blog.dane.io

Unlimited, Unthrottled, and Anonymous LTE Access

2019-12-30T06:35:00+00:00

Protecting privacy and enabling free speech on the Internet is germane to a healthy society and functioning democracy. Unfortunately, we too frequently find ourselves victims of an escalating war against privacy. Whether you’re worried about your Government using their powers to snoop in your personal life or are simply tired of the ever-present panopticon tracking every fucking thing you do, you have options to fight back.

This post will walk you through improving your personal privacy by acquiring and using an unlimited, unthrottled, and anonymous* LTE hotspot offered through The Calyx Institute, all for about $40 a month. When The Calyx Institute states their LTE service is unlimited and unthrottled, they absolutely mean it – I’ve yet to experience slowdowns after using a metric shit-ton of data.

A 100GB/month plan from Verizon goes for about $700 a month.

Note: this is not the first article which describes this invaluable service. However, most of these articles are focusing on saving money through usage of this service as a primary ISP. This is not my intent. Rather, this post will focus the history behind this LTE offering, the very real and ongoing fight to keep this service operational, and some basic OPSEC to keep in mind.

*For some definition of anonymous.

The History Behind Unthrottled LTE

If you’re impatient and just want to get a hotspot, skip this next section.

I am personally shocked that unlimited, unthrottled LTE is accessible in the United States in late 2019, especially at the reasonable price of $40 a month.

Given mobile carrier plans are in a race to the bottom with expensive data, surplus charges, and aggressive throttling, this service should not logically exist. Yet it does. I’m going to quickly walk through the history behind this LTE service and how it could quickly disappear given the FCC is hell-bent on commercializing the wireless spectrum and we are seeing massive consolidation of wireless service providers.

Obligatory note: Ajit Pai (FCC Chairman) is an absolute clown.

The Educational Broadband Service

Our story starts back in the 1960s when the U.S. Government created a reservation for 114 MHz of the 2.5GHz wireless band. Known as the Educational Broadband Service (EBS), this band was only accessible to licensed academic and educational institutions. This ultimately reserved a massive chunk of high-speed, high-capacity spectrum that was inaccessible to the commercial industry.

In 1983, in an effort to encourage further adoption of the spectrum, the FCC allowed for excess capacity sales of the spectrum to commercial entities. As long the EBS licensee maintained good standing and complied with FCC regulations, they could sell most of their unused spectrum capacity to commercial entities. The best part? They could sign an agreement as long as 30 years. This is important as we will see shortly.

Game of Thrones: Mobile Carrier Edition

Fast-forward to 2006 and we find demand for wireless spectrum for high-speed cellular communications is exploding. With protected access to the EBS spectrum, nonprofit, academic, and educational institutions face massive demand from commercial wireless carriers. Using the excess capacity clause ruled by the FCC back in 1983, EBS licensees began collaborating, sharing, and selling portions of their spectrum allocation.

Relevant to our story are 5 EBS licensees, operating under the trade name Voqal, who formed such an agreement with the wireless internet service provider Clearwire Corporation. As part of the 30-year agreement, Voqal would lease a large portion of their EBS spectrum directly to Clearwire in exchange for unlimited, high-speed broadband access for schools, libraries, educational institutions, and nonprofit organizations. This access would be granted in terms of cost-free education accounts (CFEAs) which could be given away or resold at very favorable rates to qualifying educational institutions and nonprofit organizations.

To help qualified organizations gain access to these CFEAs provided under the Clearwire contract, Voqal founded the Mobile Citizen project. Mobile Citizen would act as the CFEA intermediary and broker cost-effective and high-speed Internet access to educational and academic institutions. Partnering with other projects, these CFEA agreements enabled low-income persons, nonprofits, and academic organizations to get unlimited access to the Internet at incredibly reasonable rates. All was well in the world, right?

Well no, all good things come to an end and in 2012, Sprint decided to buy Clearwire. In typical corporate fashion, Sprint tried to immediately shut down the Clearwire WiMAX service, throttle the unlimited data access, and not honor the previous agreement between Mobile Citizen and Clearwire established back in 2006. This led to a variety of lawsuits, court injunctions, bad press, and as far as I know, this lawsuit has still yet to be resolved. At some point, Sprint capitulated and decided to honor the agreement.

Yet the acquisitions weren’t done yet. In mid-2018, T-Mobile and Sprint announced a plan to merge with an estimated completion date of 2020. If that weren’t enough, the FCC voted 3-2 to auction off the EBS-protected spectrum to commercial entities sometime in 2020. (Editor’s note: Ajit Pai is a clown.)

With massive profit margins on per-gigabyte data transfer plans and the death of net neutrality, telecommunication carriers have little incentive to honor previous agreements or advocate for inexpensive, high-data plans. The future of Mobile Citizen services, and EBS operators more broadly, is uncertain.

The Calyx Institute and Unlimited LTE Access

Now that we’ve walked through the convoluted history of agreements, purchases, acquisitions, and lawsuits, where does the Calyx Institute come into play?

Founded in 2010, The Calyx Institute is a 501(c)(3) nonprofit organization dedicated to raising awareness about surveillance and privacy issues. Most notably, the Founder of The Calyx Institute, Nick Merrill, was hit with a National Security Letter under the USA PATRIOT Act, and successfully fought it in court. There’s a good 27c3 talk about his journey through the court system as part of this fight.

As a nonprofit organization, The Calyx Institute operates a variety of awesome services to help keep the Internet private. These services include a free and end-to-end encrypted jabber (chat) server, Tor exit nodes, and Mobile Citizen LTE access. That’s right. As they are a nonprofit organization, they can take advantage of that CFEA agreement between Mobile Citizen and Clearwire/Sprint back in 2006. The best part is: if you choose to join The Calyx Institute as a member, you are eligible for access to this LTE service. Neat, huh?

Joining the Calyx Institute

In order to be eligible for the LTE hotspot, you need to be a contributing member of The Calyx Institute. Dues start at $500 a year for the Contributor level, or $600 a year for the Contributor Plus level. After the first year, the dues drop $100 since you already have hotspot hardware.

If you spring for the Contributor level ($500/year), you’ll be given a Coolpad Surf hotspot with 12 months of unlimited LTE access via Sprint. This comes out to about $42 a month for unlimited LTE access.

Coolpad Surf Hotspot.

If you spring for the Contributor Plus level ($600/year), you’ll be given an Inseego MiFi 8000 hotspot with 12 months of unlimited LTE access via Sprint. This comes out to about $50 a month for unlimited LTE access.

Inseego Mifi 8000 Hotspot.

Between the two, the Inseego MiFi 8000 is the superior choice. With two TS9 ports for external antennas, a substantially larger battery, and USB-C charging, it’s one of the best 4G LTE hotspots you can get today.

Considering most hotspot deals are NOT unlimited, aggressively throttle, and are expensive, this deal is a no-brainer. Additionally, you can sign up for this service without giving any identifying information to the ISP.

Getting a Privacy-Friendly Hotspot

As stated at the beginning of this post, Mobile Citizen LTE access can be a very privacy-friendly option. While you can sign up with a credit card via their website (note: since they’re a nonprofit, this is tax deductible), there are other options available.

As noted on The Calyx Institute website, they will provide the following information to their mobile operator when a new user registers for service:

Name
Addresss
Hardware information (e.g. SIM card, device ID, etc.)

The important part here is that, at no point whatsoever, does it require your name or address need to be yours - or valid at all. As such, you have two primary ways of getting an LTE hotspot without attributing it directly to yourself:

Option 1: Pay in person with cash.

Did you know that The Calyx Institute shows up to DEF CON in person? Yup, they sure do. If you go to everyone’s favorite hacker summer camp, you’re in luck.

Simply show up to their vendor booth, give them a name (may I recommend Ajit Pai?), hand them a wad of cash, and walk away with your new hotspot.

Need to renew your membership? Simply show up with more cash next year and get a new SIM card.

Option 2: Pay with Bitcoin.

The Calyx Institute accepts payment via Bitcoin on their website. Simply give a name, give an address, and pay with Bitcoin.

Don’t want to use your real name? Put whatever you want on the package and have it delivered to your house.

Don’t want it delivered to your house? Use a remailer, a friend, or another service for receiving the package.

Either way, your hotspot will arrive activated and present with 12 months of unlimited, unthrottled Internet service.

Hotspot OPSEC

Important note: no matter how you get your hotspot, you’re agreeing to abide by the terms of service for LTE access.. Don’t be a jerk and use this for illegal, immoral, or unethical purposes.

Having a hotspot unassociated with your real name can be a major boon to privacy and enable freedom of speech. That said, there are some operational security (OPSEC) considerations you need to be mindful of:

Your hotspot is tied to your physical location. As an active LTE client with a static mobile device identifier, your location and usage of the hotspot can and will be tracked. The primary benefit of this service is that your mobile carrier (e.g. Sprint) simply does not know who you are but will only know where you are. For the maximally paranoid, you may consider using a mobile carrier other than Sprint, which will ensure your devices aren’t all beaconing to the same towers as the same time.
Your ISP can still see everything you do. All this hotspot provides is Internet access, not guarantees of privacy or confidentiality. You should assume that all your traffic will be inspected, dissected, logged, and recorded in perpetuity. As such, you will need to employ VPNs, encrypt DNS traffic, use TLS, and control metadata leakage yourself.
This hotspot still provides advantages over Wi-Fi access points. While not private, the hotspot has clear advantages over traditional public access points. Public Wi-Fi access points may be metered, unencrypted, require registration (e.g. an e-mail address, name, room number, device MAC address), or use privacy-hostile services (e.g. Google Wi-Fi).
Never forget that OPSEC is a mindset and a process, not a silver bullet. When this access is used intelligently, you can bolster your privacy. When used poorly, it may erode it. Be vigilant, be paranoid, and fight for your right to privacy (and party).

Paired well with a travel router, your Mobile Citizen LTE hotspot will grant you enjoyable and fully unlimited, unshaped Internet access, no matter where you go. *

(*As long as it’s within the United States and has Sprint service.)

Deploying a Static Website via Azure

2019-12-28T02:49:22+00:00

While AWS remains the market leader for public cloud providers, I have personally found Azure to be significantly more security-conscious and pleasurable to work with. As part of the learning process, I’ve slowly been migrating and deploying services onto Azure – including this blog.

This post is going to focus on deploying a simple, static website onto an Azure storage account (AWS S3 equivalent). As part of this deployment, I will front the storage account with a content delivery network (CDN), enable a valid HTTPS certificate, configure reasonable caching defaults, and set up continuous integration for deployment via CircleCI. The goal of this project is to have a remarkably secure website with minimal time, energy, and resources committed to maintaining it.

I will caveat this post by stating that I am definitively not a web developer, and most of these web technologies are outside my proficiency.

The Case for a Static Web Page

So the first question we should answer is: why do we want a static web page? There are a few compelling reasons why static web pages are so attractive:

Static web pages can be incredibly secure. A static web page has no moving parts, plugins, servers, or dynamic content that present attack surface. While this blog has absolutely nothing of significance or value if hacked, a static deployment means one less thing to worry about.
Static web pages don’t need a traditional hosting provider. You don’t need to shell out large amounts of cash for a wordpress or other hosting provider. You can simply throw your static web page in a cheap bucket and call it a day.
Static web pages are dead simple. There are no dynamically generated components to maintain which means every viewer receives the same viewing experience. Static web pages are typically also small and incredibly fast to load.
Static web pages are compatible with git and CI/CD. You can edit your web pages in markdown, manage versions through git, and auto-deploy with CI/CD. It’s a pretty magical process.

The static web page zeitgeist likely originated with the creation of Jekyll, a static site generator (SSG) which powers GitHub Pages functionality. Since Jekyll, SSGs have exploded in popularity and created a rich ecosystem of frameworks. While you can craft an artisanal static website by hand, these frameworks make it trivial to get started and deploy a new project.

There are a variety of SSG frameworks available, but Hugo, Jekyll, and Gatsby.js are perhaps the most well-known and popular. Each of these have their own language preferences, features, and benefits, but all serve the same purpose. A cross-comparison of these frameworks is outside the scope of this post (and outside of my depth of my knowledge), but I ultimately selected Jekyll for my personal blog.

Once you’ve selected a framework and found a free theme that appeals to you, you’ll need to get a local development environment ready.

Windows Development Environment

As most of my devices run with application whitelisting enabled, I needed to spin up a local development environment. If you’re not foolish enough to use application whitelisting, run another operating system (e.g. MacOS), or already have a local developer environment, this section may not be useful for you. Feel free to skip it.

For Jekyll, we’ll need a few components installed:

Windows Subsystem for Linux (WSL)
Git
Ruby
Jekyll (Ruby Gem)
HTML-Proofer (Ruby Gem)
Other ruby gems for your site (e.g. “jekyll-sitemap”, “jekyll-seo-tag”, etc.)

In my instance, I spun up a new Windows 10 developer environment in Hyper-V, but you could just as easily do this on your host.

Install WSL using PowerShell.

 Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Install Ubuntu 16.04 LTS via PowerShell and Reboot.

 Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile Ubuntu.appx -UseBasicParsing
 Add-AppxPackage .\app-name-as-per-above.appx

Update WSL.

 sudo apt-get update && sudo apt-get upgrade -y

Install Basic Tools.
```
 sudo apt-get install gnupg2
```

Install Jekyll.

 sudo apt-add-repository ppa:brightbox/ruby-ng
 sudo apt-get update
 sudo apt-get install ruby2.5 ruby2.5-dev build-essential dh-autoreconf
 gem update
 gem install jekyll bundler html-proofer

Create a New Site OR Install a Theme.

At the end of this process, you should have a Jekyll-compatible environment ready and either a new site, or a templated site, ready for configuration. This is the part where you actually make your blog, configure your template, and add content.

Protip: To test your local changes, you can use the jekyll serve command. This will open up a listener on http://127.0.0.1:4000 where you can preview your changes.

Configuring Your Repository

Now that we’ve got a rough skeleton for our blog, we’ll throw it in a GitHub.com repository.

Create a .gitignore file

First, we’ll create a local .gitignore file for your repository and add the following contents:

_site
.sass-cache
node_modules
.jekyll-cache/
.jekyll-metadata

This will allow us to version control the web site content without uploading the actual HTML pages. We’ll generate these from the source files as part of our CI/CD pipeline.

Upload Web Site Files

Next, we’ll commit everything and upload it to our repository. We can now version control all changes to our web site using our GitHub repository. An example of what this looks like is below.

Private GitHub repo for blog.dane.io.

We’ll come back and make some additional changes to our repository later but, for now, we’re going to move over to our Azure account and get that configured.

Configuring Azure

Protip: If you’re new to Azure, you can register for a free account and get $200 worth of credit and 12 months of some free services.

Double Protip: If you’re a Visual Studio subscriber, you get $50 a month in Azure credits in addition to software access (e.g. Windows 10, Server 2019) and other benefits. You might consider purchasing a subscription, or convincing your workplace to sponsor it, if you intend to play with Azure and the Windows platform long-term.

We’ll need an Azure account for hosting our web site. If you use Office365, you already have an Azure account. If not, you’ll need to get one. Go ahead and login or create your Azure account now.

Create the Storage Account

Note: By default, all storage accounts in Azure are encrypted using server side encryption (SSE) by Microsoft. We don’t need to do anything special for encryption at rest.

Next, we’ll create our storage account for hosting our static website. As our website content is stored in a GitHub repository, we don’t need to worry about backups, redundancy, or other availability or integrity protection mechanisms at the storage account level.

Navigate to Storage Accounts within the Azure Portal.
Create a new storage account with the following specifications:
- Resource Group: New (e.g. blog_dane_io)
- Storage Account Name: something representative (e.g. daneio). Note: this must be globally unique within Azure.
- Location: Choose your location (e.g. US-West-2)
- Performance: Standard
- Account Kind: Storagev2 (general purpose)
- Replication: Locally-redundant storage (LRS)
- Access tier: Hot (can change this later if needed)
- Connectivity method: Public endpoint (all networks)
- Secure transfer required: Enabled
Navigate to the storage account you created.
Configure the following settings on the storage account:
- Static website: Enabled. (Use default index.html and 404.html paths)

Storage account configuration.

Static website configuration.

We now have a storage account ready for hosting our static website content. If you use the Storage Explorer, you’ll notice that a default $web container now exists and is ready to serve up our website.

Static website container ($web).

If we only wanted to serve out of the bucket itself, we could simply configure a domain name and stop here. However, we want to do a few more things before we can call this project finished. Let’s go set up our custom domain name.

Configure Custom Domain Name

If you’re into vanity domains (and who isn’t?), you might consider using a custom domain or subdomain for your website. As I use Azure for managing my DNS, I’ll configure it to use the blog.dane.io subdomain.

Navigate to DNS Zones within the Azure Portal.
Create a new Resource Group and Instance (e.g. dane.io).

Navigate to the newly created instance and grab the name server information:

 Name server 1: ns1-06.azure-dns.com.
 Name server 2: ns2-06.azure-dns.net.
 Name server 3: ns3-06.azure-dns.org.
 Name server 4: ns4-06.azure-dns.info.

Update your domain registrar to point at the Azure name servers.

Validation of DNS changes.

We are now using Azure to manage our DNS. We’ll be able to create the custom records for our CDN by creating a record set within the Azure DNS console.

Enabling the Azure CDN

We’re going to front our website with an Azure content delivery network (CDN) to improve speeds, reduce bandwidth usage of our bucket, and distribute our content to geographically distributed points of presence.

Navigate to your storage account you created within the Azure portal.
Under “Azure CDN”, create a new endpoint with the following specifications:
- Create new CDN profile.
- Name: Use a representative name (e.g. daneio)
- Pricing: Standard Microsoft.
- CDN Endpoint Name: Use a representative name (e.g. daneio.azureedge.net) Note: this must be globally unique within Azure.
- Origin hostname: Grab the name from the “Primary Static Website Endpoint” under the Properties tab. (Example: https://daneio.z5.web.core.windows.net)
- Click create.

Custom origin information.

Next, we’re going to configure our DNS record to point to the CDN endpoint that we specified above (e.g. https://daneio.azureedge.net).

Navigate to the DNS Zone you created within the Azure portal.
Create a new record set with the following specifications:
- Name: blog.dane.io (or whatever your own domain is)
- Type: CNAME
- TTL: 1 hour
- Alias: daneio.azureedge.net.

This will redirect any requests to our subdomain (e.g. blog.dane.io) to the Azure CDN endpoint.

Successfully validated DNS record.

Once the record has been created, we’ll need to associate the domain with our Azure CDN endpoint.

Navigate to the Azure CDN endpoint you created.
Under “Custom Domains”, add a new custom domain with the following specifications:
- Endpoint hostname: daneio.azureedge.net (or whatever your Azure CDN endpoint is)
- Custom hostname: blog.dane.io (or whatever you used for the domain above)
Click add.

Enabling TLS Encryption

Once we have confirmed the DNS record, we can have Azure provision and manage a digital certificate for us.

Navigate to the Azure CDN endpoint you created.
Under “Custom Domains”, select the custom domain you added.
Enable custom domain HTTPS with a CDN-managed certificate.

Once this has been kicked off, it may take a few hours for the TLS certificate to be provisioned.

Successfully issued TLS certificate.

Configuring CDN Compression

Next, we’re going to ensure that compression is enabled for content delivered via the Azure CDN. While images are likely already compressed, we can save some bandwidth and improve delivery speed by compressing other MIME formats.

Navigate to the Azure CDN endpoint you created.
Under “Compression” ensure that Compression is enabled.

By default, fonts, XML, plaintext, CSV, HTML, and other MIME formats will be compressed. You may add additional MIME signatures to this list to provide compression on-the-fly.

MIME types compressed during CDN delivery.

Configuring CDN Cache

Next, we’re going to configure our CDN cache. This is especially important as assets cached via the CDN will be retained until the time-to-live (TTL) expires. If we fail to configure reasonable caching, updates to our website will be painful.

By default, Azure storage accounts set a cache on a per-object basis with a default of 7 days. While this is fine for static content (e.g. image assets, fonts), it will be a very poor experience for updates to HTML pages. While we could set the TTL for each object individually as we add it to the bucket, there is a really lazy way to solve this problem.

We’ll set the general CDN caching rule for our CDN:

Navigate to the Azure CDN endpoint you created.
Under “Caching rules” ensure that the query string caching behavior is set to ignore query strings.

Default caching behavior.

Next, we’ll create some custom cache rules using the rules engine. Our goal will be as follows:

Set the default TTL to a short-lived value (e.g. 5 minutes) for all assets. This will allow for quick updates when critical files (e.g. HTML) are changed.
Explicitly set the TTL to a long-lived value (e.g. 7 days) for all other static assets loaded (e.g. images, fonts, CSS).

Managing the cache in this way ensures that we can centrally adjust values instead of setting them on a per-object basis in the storage account.

To do so, perform the following:

Navigate to the Azure CDN endpoint you created.
Navigate to “Rules Engine”.
Under the global rule click add action and add the following:
- Always cache expiration: Override with 5 minute TTL.
Click add rule and add the following:
- Name: CacheControl
- Logic: If URL file contains ‘/assets/’ (to lowercase), then set cache expiration override to 7 days.

In this instance, I have configured 2 specific rules:

Rule 1 (Global): Default assets get a 5 minute TTL.
Rule 2 (CacheControl): Any file delivered out of the /assets/ folder is given a 7 day TTL. We’ll use this folder for images, javascript, CSS, etc.

This combination of short and long TTLs ensures that our CDN is only delivering compressed text (e.g. HTML, CSS) on a frequent basis, but all large and static assets (e.g. images, gifs, fonts) are cached. When we make production changes to our website, it takes around 5 minutes for the HTML CDN cache to expire and be refreshed, making it a seamless user browsing experience.

Custom caching behavior rules.

Adding Basic Security Features

Note: Due to issues with the Microsoft CDN and Twitter card support, I switched over to Standard Akamai. Unfortunately, the Akamai CDN does not allow custom header manipulation. As such, I’m leaving this documentation for those who might still need to use the Microsoft CDN.

Next, we’ll want to configure a few basic security features:

While many of these are not strictly necessary given the static nature of the website, it’s fairly trivial to add and deploy. We’ll do it for completion’s sake.

We’ll start with HTTPS redirection. This is important as the CDN will not serve content over HTTP.

To do so, perform the following:

Navigate to the Azure CDN endpoint you created.
Navigate to “Rules Engine”.
Click add rule and add the following:
- Name: EnforceHTTPS
- Logic: If request protocol equals HTTP, then URL redirect found (302) to protocol HTTPS.

Custom EnforceHTTPS rule.

Next, we’ll configure HSTS and a Content Security Policy for the website. HSTS ensures that browsers will only connect to the website over HTTPS, and the CSP will help prevent cross site scripting (XSS), as much of a rarity as that might be.

To do so, perform the following:

Navigate to the Azure CDN endpoint you created.
Navigate to “Rules Engine”.
Under the global rule click add action and add the following:
- And modify response header: Append Strict-Transport-Security with value max-age=315360000; preload.
- Click add action again.
- And modify responder header: Append Content-Security-Policy with the value default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'.

HSTS and CSP configured.

Next, we’ll prevent our site from being embedded on other websites (e.g. X-Frame-Options), prevent MIME sniffing (X-Content-Type-Options), and configure a referrer policy.

To do so, perform the following:

Navigate to the Azure CDN endpoint you created.
Navigate to “Rules Engine”.
Click add rule and add the following:
- Name: SecurityHeaders
- Logic: If request method equals GET, then modify response header to append X-Content-Type-Options with value nosniff.
- Click add action again.
- Logic: Then modify response header to append Referrer-Policy with value strict-origin-when-cross-origin.
- Click add action again.
- Logic: Then modify response header to append X-Frame-Options with value DENY.

X-Frame-Options and HSTS.

We’ll go ahead and do a quick scan via Security Headers and validate things look good:

While not an A+, it’s good enough for Government work.

Configuring CircleCI

Note: It’s really easy to spill secrets via CircleCI and GitHub. I highly recommend you keep your repository private to reduce the likelihood of accidental misconfiguration.

Hooking CircleCI to GitHub

Once we have built our website, configured the storage account, configured the Azure CDN, and have a valid TLS certificate, we’re ready to hook everything together. We’ll first configure a CircleCI project for our GitHub repository:

Authenticate to CircleCI using your GitHub account.
Click Set Up Project for your website repository. Ignore the CircleCI yaml file right now.
Under your new project in CircleCI, navigate to Advanced Settings. Change the following:
- Build Forked Pull Requests: Disable this.
- Pass Secrets to Builds From Forked Pull Requests: Disable this.

CircleCI now has a deploy key from the GitHub repository, and we’ve disabled building of forked pull requests. This is especially important if your repository is public, as adversaries can potentially steal secrets from environmental variables in your CircleCI node if these settings are enabled.

Also known as the “wreck my world” buttons.

Next, we’re going to go grab some credentials for our storage account in Azure:

Navigate to the Azure storage account you created.
Navigate to “Access Keys”.
Copy the key specified under key1.

This is your access key. Keep it safe; anyone with access to this key will be able to do whatever they’d like to your storage account. We’re going to go ahead and give it to CircleCI so it’ll be able to modify the bucket (and pray CircleCI never has a breach).

To do so, perform the following:

Navigate to the settings for your project in CircleCI.
Under Build Settings, navigate to Environment Variables.
Add the following two environmental variables:
- Name: AZURE_STORAGE_ACCOUNT with value daneio (or whatever your bucket name is.)
- Name: AZURE_STORAGE_KEY with value <paste your key here>.

Using environmental variables keeps credentials out of files in your repository.

Generating a CircleCI YAML File

Now we have CircleCI configured and ready to rock. The last step here will be generating a CircleCI YAML file for controlling when to build containers with our code. This is part art-form, part science, and may take a few (dozen) tries to get it right. I’ve included a copy of my current config.yml file below, which I’ll explain in further detail. Whether you use mine, grab a premade one, or make your own, you’ll need to throw it in your GitHub repository as .circleci/config.yml.

version: 2
jobs:
  build:
    docker:
      - image: circleci/ruby:latest
    working_directory: ~/repo
    steps:
      - checkout
      - restore_cache:
          keys:
            - rubygems-v2-\{\{ checksum "Gemfile.lock" \}\}
            - rubygems-v2-fallback
      - run:
          name: Install Dependencies
          command: |
            bundle install --jobs=4 --retry=3 --path vendor/bundle && bundle clean
      - save_cache:
          key: rubygems-v2-\{\{ checksum "Gemfile.lock" \}\}
          paths:
            - vendor/bundle
      - run:
          name: Jekyll build
          command: bundle exec jekyll build
      - run:
          name: HTMLProofer tests
          command: |
            bundle exec htmlproofer ./_site \
            --allow-missing-href \
            --allow-hash-href \
            --check-favicon \
            --check-html \
            --disable-external \
            --only-4xx
      - run:
          name: Cleanup filters
          command: |
            rm -f gulpfile.js jekyll-theme-clean-blog.gemspec LICENSE README.md package-lock.json package.json
      - persist_to_workspace:
          root: ./
          paths:
            - _site
  deploy:
    docker:
      - image: circleci/python:latest
    working_directory: ~/repo
    steps:
      - attach_workspace:
          at: ./
      - run:
          name: Install Azure CLI
          command: curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
      - run:
          name: Upload to Azure bucket
          command: az storage blob sync --source ./_site --container='$web'
workflows:
  version: 2
  Production Deployment:
    jobs:
      - build
      - deploy
      - deploy:
          requires:
            - build
          filters:
            branches:
              only: master

This YAML file is configured with two specific jobs: build and deploy.

The build job runs against every commit to the repository and performs the following:

A new linux container is spun up using one of Circle’s ruby images.
(Optional) Some caching shenanigans are used to speed up deploys.
The GitHub repository is checked out using the SSH deploy key.
(Optional) The ruby bundle for my theme is installed and cleaned.
Jekyll runs and builds the website. The output is saved to the _site folder locally within the CircleCI container.
HTMLProofer runs against the output website and looks for broken links, errors, etc.
Some junk files are deleted since I don’t want them hanging out in my webroot.
The output of the _site folder is saved for later use by the deploy job.

The deploy job only runs against changes to the master branch and performs the following:

A new linux container is spun up using one of Circle’s python images.
We re-attach the build workspace containing the contents of the _site folder.
We install the AzureCLI tool.
We use the AzureCLI tool to synchronize the storage account with the files we have locally.

Configuring GitHub Checks

The final step of this project is configuring branch protection and status checks for our GitHub repository. This will force us to use pull requests for merging to master, and force successful CircleCI builds as part of that pull request. This will hopefully prevent us from pushing something broken into production by relying on our CircleCI build jobs as a gate.

To do so, perform the following:

Navigate to your GitHub repository and go to Settings -> Branches.
- Enforce branch protection for master.
- Enable Require status checks to pass before merging.
- Enable Require branches to be up to date before merging
- Select the status check for ci/circleci: build as required.
- Select include administrators to force compliance for yourself.

Branch protections requiring a build CI Job to pass.

Example CircleCI Workflow

When properly configured, every commit to our website will automatically perform the build and identify any jekyll or HTML issues. When we feel comfortable with the final results and merge to the master branch, the deploy job will execute, updating our website on production. The synchronize command will manage all of our file uploads and deletes, making this CI job rather trivial to maintain.

To perform an update to the website, simply:

Commit all changes to a new branch.
Perform a pull-request to master from your branch. Pass the CircleCI build job.
Merge to master and the deploy CircleCI job will run. You’re done.

Pull requests need to pass a CI job to deploy.

Successful build and deploy.

Pricing

Lastly, how much does all of this cost? Well, so far, it’s cost about $0.25 for a handful of days. Most of the costs incurred have been from figuring out the services and experimenting with CircleCI jobs (e.g. syncing lots of files to storage.)

I anticipate that (a) it will typically cost between $10 and $15 per month, and (b) some clown will likely decide to try and drive up the costs substantially through malicious abuse.

Luckily, you can set a set a spending limit on Azure subscriptions to prevent costs from going through the roof. We’ll see how this shakes out after a month or two of operation.

Temporary pricing chart.

Detecting Windows Endpoint Compromise with SACLs

2018-07-16T08:00:00+00:00

This post is going to focus on using the system access control list (SACL) functionality to detect endpoint compromise on Windows hosts. The goal is to quickly, cheaply, and effectively detect anomalous activity on an endpoint without focusing purely on anomalous process and thread execution.

If you’re unfamiliar with SACLs, the concept is quite simple: Apply an audit access control entry (ACE) to an object (e.g. a file, registry key) which logs when that object is successfully or unsuccessfully (or both) accessed or modified by one or more principles. These events will, with appropriate configuration, generate event log entries that may be analyzed to identify post-exploitation activity.

Note: This particular blog post will only cover object access and manipulation SACL entries. There are many other uses for SACLs which I may explore in future posts.

ACE and ACL Basics

Note: This is a very basic primer of ACEs, ACLs, and Security Descriptors. It is highly recommended you perform deeper research on these technologies to understand their nuance and internals.

Before we dig into deploying SACLs, we’ll cover a very basic and quick primer on access control lists (ACLs) and access control entries (ACE).

In the Windows world, an ACL is a list structure that can contain zero, one, or multiple ACE. Each ACE in an ACL describes a security identifier (SID) and specific access (or deny) rights allowed for that SID against a given object. For instance, an ACE can allow specific users to read/write/modify an object, while another ACE can deny access to the object altogether for other users.

ACLs are applied against securable objects, such as files, folders, registry keys, and kernel objects. While there are many documented securable objects, research has identified there are still many dozens of objects that remain undocumented.

An ACL can be one of two specific varieties: a discretionary access control list (DACL) or a system access control list (SACL). The DACL is primarily used for controlling access to an object, whereas a SACL is primarily used for logging access attempts to an object.

There’s a lot going on here, so we’ll look at a quick visual:

https://eneter.blogspot.com/2013/08/windows-security-wiki.html

We’ll first walk through the DACL. As noted in the above image, the DACL has both Access Denied and Access Allowed ACEs. When an attempt is made to access a securable objects, the system will check the ACEs specified in the object’s DACL and make a determination on whether access should be allowed or not.

This is referenced in the following diagram:

https://msdn.microsoft.com/en-us/library/cc246052.aspx

In this example, a process is attempting to access a securable object and the token is inspected and compared against ACE entries on the object’s DACL. As the SIDs specified in the access token match those specified in the ACE, access is granted.

This diagram also outlines the order of ACE evaluation when attempting to access an object:

Explicit Deny ACEs
Explicit Allow ACEs
Inherited Deny ACEs
Inherited Allow ACEs

We’ll next walk through the SACL, the often-ignored and underutilized friend of the DACL. Unlike the DACL, the SACL provides access to the Audit ACE. The audit ACE simply describes whether or not access to an object was allowed, denied, or both, and with what access was granted.

This will prove to be incredibly valuable for a few key reasons:

DACLs generally won’t stop post-exploitation activity for a given user. Compromise of a user’s process will allow the adversary to access the user’s files and folders with impunity.
Endpoint detection and response tooling has major blind spots. Some tooling may straight up ignore file reads while others may only report changes to objects, but not specify what changed.
We can quickly apply audit ACEs to objects and record access (successful or not) for specific actions (e.g. read, write, delete, permission changes, etc.) without requiring additional tooling or telemetry sources.

In summary: DACLs control what SIDs can access what objects, while SACLs tell you whether or not they were successful in their attempt to perform a given set of actions against that object.

Defensive SACL Primitives

There two defensive SACL primitives that we will use in this post:

Object Read SACLs. These are SACLs designed to detect unusual post-exploitation activity focused on credential theft, privilege escalation, file pilfering, etc. The premise is simple: Log when someone accesses this object.
Object Write SACLs. These are SACLs designed to detect writes, modifications, permission changes, or other activity used for persistence, anti-forensics, or system tampering. The premise is simple: Log when someone writes to/modifies this object.

These two object primitives can be easily applied to both file system and registry objects. These primitives are defined in powershell as follows:

# SACL Primitive for File Reads / Directory Traversals / Ownership Changes
$AuditUser = "Everyone"
$AuditRules = "ReadData, TakeOwnership"
$InheritType = "None"
$PropagationFlags = "None"
$AuditType = "Success"
$FileReadSuccessAudit = New-Object System.Security.AccessControl.FileSystemAuditRule($AuditUser,$AuditRules,$InheritType,$PropagationFlags,$AuditType)

# SACL Primitive for File Writes / Appends / Deletes / Ownership Changes
$AuditUser = "Everyone"
$AuditRules = "CreateFiles, AppendData, DeleteSubdirectoriesAndFiles, Delete, TakeOwnership"
$InheritType = "None"
$PropagationFlags = "None"
$AuditType = "Success"
$FileWriteSuccessAudit = New-Object System.Security.AccessControl.FileSystemAuditRule($AuditUser,$AuditRules,$InheritType,$PropagationFlags,$AuditType)

# SACL Primitive for Registry Key Value Sets / Key Creation / Key Writes / Ownership Changes
$AuditUser = "Everyone"
$AuditRules = "SetValue, CreateSubkey, WriteKey, TakeOwnership"
$InheritType = "None"
$PropagationFlags = "None"
$AuditType = "Success"
$RegistryWriteSuccessAudit = New-Object System.Security.AccessControl.RegistryAuditRule($AuditUser,$AuditRules,$InheritType,$PropagationFlags,$AuditType)

# SACL Primitive for Registry Key Value Sets / Key Creation / Key Writes / Ownership Changes
$AuditUser = "Everyone"
$AuditRules = "SetValue, CreateSubkey, WriteKey, TakeOwnership"
$InheritType = "ContainerInherit, ObjectInherit"
$PropagationFlags = "None"$AuditType = "Success"
$RegistryRecursiveWriteSuccessAudit = New-Object System.Security.AccessControl.RegistryAuditRule($AuditUser,$AuditRules,$InheritType,$PropagationFlags,$AuditType)

Adding a SACL

Note: You will need appropriate Windows event logging enabled for object manipulation event IDs to log. I recommend the audit settings specified here.

Now, we’ll walk through how to configure a SACL manually. This is ill-advised for any production deployment, but it’s important to know how to investigate and modify these by hand.

For this example, we’ll configure a SACL on a super secret filed called KFC_Recipe.docx with the object read primitive we described above. The goal will be to log any access to this file and then identify unusual access by investigating the events.

Using the Security GUI

Navigate to the KFC_Recipe.docx file and Right-click > Properties.
Click on the Security tab.
Click Advanced.
Click on the Auditing tab.

Our unprotected KFC Recipe. Shame.

This panel will detail any configured audit ACEs configured on the object. As we haven’t added an ACE, it will be empty. Let’s fix that.

Click Add.

We first need to specify a principal (SID) to audit.

Click on “Select a Principal”.
Type “Everyone” and Check Names. Hit OK.

This will audit all principals that access this object.

Click the Advanced button and uncheck all boxes except List Folder / Read Data. Set the Type to All.

This will audit all principals that successfully or unsuccessfully read the file.

The final output of the audit ACE.

Using Powershell

This process is substantially easier to deploy via powershell:

# SACL Primitive for File Reads / Directory Traversals / Ownership Changes
$AuditUser = "Everyone"
$AuditRules = "ReadData, TakeOwnership"
$InheritType = "None"
$PropagationFlags = "None"
$AuditType = "Success"
$FileReadSuccessAudit = New-Object System.Security.AccessControl.FileSystemAuditRule($AuditUser,$AuditRules,$InheritType,$PropagationFlags,$AuditType)
$FilePath = "$ENV:USERPROFILE\Documents\KFC_Recipe.docx"# Get the ACL with Audit ACEs
$Acl = Get-Acl $FilePath -Audit# Set the ACE
$Acl.SetAuditRule($FileReadSuccessAudit)# Apply the ACL
$Acl | Set-Acl | Out-Null

Verify the ACE Works

Now we’ll perform validation on this ACE to ensure it’s logging appropriately.

We’ll first test as an innocuous user by opening the document in Microsoft Word:

Opening the document in Word generates a 4663 Event (File System Object Access).

Looking at the windows event log reveals that a 4663 (File System Object Access) event was logged. In this event, we can see the Object_Name references the KFC_Recipe.docx file, and the Process_Name references WINWORD.exe (Microsoft Word).

Let’s now try to access this file via another process:

Malicious file copying the KFC_Recipe.docx file.

In this instance, I used a malicious file (C:\Windows\Temp\runsystem32.exe) to simply copy the KFC_Recipe.docx file to C:\Windows\Temp prior to exfiltrating it.

In this instance, the SACL worked and our malicious binary was logged attempting to access our sensitive document. We can now operationalize this data by looking for anomalous processes accessing this file.

Alerting and Detection Strategies

Here are some examples of potential alerting and detection strategies that could be developed and exploited with appropriately configured SACLs:

Browser Data Harvesting

Alerting and Detection Strategy: Identify when a non-browser process accesses sensitive browser files, databases, and folders.

SACL Primitive: Object Read

Baseline Activity: Browser processes (e.g. Chrome and Firefox) will routinely access these files.

Activity Caught: Interrogation of browser history, theft of browser cookies, theft of browser login data, etc.

Powershell.exe accessing Chrome History DB.

Key and Credential Harvesting

Alerting and Detection Strategy: Identify when a non-legitimate process accesses sensitive files, keys, and credential stores in a user’s home directory.

SACL Primitive: Object Read

Baseline Activity: Password vaults, SSH/SSH key manager binaries, GPG binaries, administration tools.

Activity Caught: Theft of SSH/GPG keys, theft of password vaults, theft of AWS/Azure credentials, etc.

Unusual process reading SSH keys.

Registry Persistence

Alerting and Detection Strategy: Identify malicious persistence — or malicious modification of legitimate persistence entries — in commonly-abused registry locations.

SACL Primitive: Object Write

Baseline Activity: Variable depending on software installation and behavior.

Activity Caught: Addition of new malicious binary run key entries, hijacking of malicious persistence entries, etc.

Legitimate persistence mechanism hijack by a malicious binary.

Malicious System Tampering

Alerting and Detection Strategy: Identify when there are malicious modifications to critical system security, logging, or protective controls.

SACL Primitive: Object Write

Baseline Activity: GPO activity, normal administrative changes.

Activity Caught: Modification of trust stores [PDF], modification of logging (e.g. commandline, powershell), manipulation of security tooling controls (e.g. sysmon configuration), etc.

Powershell logging disabled by a malicious binary.

Protips

There are a few protips that I’ve learned while deploying this across my home environment:

The objects you deploy a SACL to will determine the overall volume, but you should expect this technique to be very noisy. You likely will need to employ some tuning and whitelisting on the front-end to reduce the overall volume of indexed events.
You will need centralized log collection of Windows Event Logs to operationalize these detection strategies. You cannot rely on host-based logs stored only on the endpoint, so plan to ship off logs as quickly as possible. I recommend looking at the Windows Event Forwarding project from Palantir for a native way of collecting/managing logs for DFIR purposes.
There are tons of legitimate alerting strategies you can develop using SACLs. These are merely the tip of the iceberg, and I would encourage you to think deeply about what makes the most sense for your environment.
You can audit “Read Permissions”, “Change Permissions”, and “Take Ownership” to further monitor sensitive files. Attempts by an adversary to (a) enumerate and (b) manipulate audit ACEs applied to an object will be logged with a 4663 (filesystem) or 4657 (registry) event.
There is a nuclear auditing option called the Global Audit Policy. This can enable object-access auditing for all file-system objects, registry keys, or both. The benefit of this option is that it removes the need to manually handjam auditing ACEs onto the objects you care about. The downside is that the volume of audit events is astronomical. Global audit policy is outside the scope of this post.
Object access monitoring is one of many ways SACLs can be used. There are several other defensive primitives which are outside the scope of this post.

DARKSURGEON: A Windows 10 Packer Project for Defenders

2018-05-14T08:00:00+00:00

I’m happy to announce the alpha release of DARKSURGEON, a Windows 10 packer project to empower incident response, digital forensics, malware analysis, and network defense.

DARKSURGEON is designed to perform the following:

Accelerate incident response, digital forensics, malware analysis, and network defense with a preconfigured Windows 10 environment complete with tools, scripts, and utilities.
Provide a framework for defenders to customize and deploy their own programmatically-built Windows images using Packer and Vagrant.
Reduce the amount of latent telemetry collection, minimize error reporting, and provide reasonable privacy and hardening standards for Windows 10.

If you haven’t worked with packer before, this project has a simple premise:

Provide all the tools you need to have a productive, secure, and private Windows virtual machine so you can spend less time tweaking your environment and more time fighting bad guys.

Example DARKSURGEON Applications.

Development Principles

DARKSURGEON is based on a few key development principles:

Modularity is key. Each component of the installation and configuration process should be modular. This allows for individuals to tailor their packer image in the most flexible way.
Builds must be atomic. A packer build should either complete all configuration and installation tasks without errors, or it should fail. A packer image with missing tools is a failure scenario.
Hardened out of the box. To the extent that it will not interfere with investigative workflows, all settings related to proactive hardening and security controls should be enabled. Further information on DARKSURGEON security can be found later in this post.
Instrumented out of the box. To the extent that it will not interfere with investigative workflows, Microsoft Sysmon, Windows Event Logging, and osquery will provide detailed telemetry on host behavior without further configuration.
Private out of the box. To the extent that it will not interfere with investigative workflows, all settings related to privacy, Windows telemetry, and error reporting should minimize collection.

Hardening

Hardening of the host must balance the needs of productivity with risk mitigation. DARKSURGEON pre-configured with scripts to enable either a High or Low Security mode, each tailored towards different workflows. Currently, only the low security mode is available for testing.

The default selection, Low Security, caters primarily to ephemeral use virtual machines (e.g. incident response or malware analysis, etc.)

Regardless of your selection, all default installations of DARKSURGEON have the following security features:

Windows OS security guidelines are implemented.
The latest Windows security patches are applied.
Windows Secure Boot is Enabled.
LLMNR is Disabled.
NBT/NBT-NS is Disabled.
WPAD is Disabled.
Powershell v2 is Removed.
SMB v1 is Disabled.
Application handlers for commonly-abused file extensions are defanged (opened in notepad).

In Low Security mode, the following hardening features are present:

Windows Defender Anti-Virus (WDAV) is enabled with hourly auto-updates.
Windows Defender Anti-Virus Real-Time Scanning is Disabled.
Windows Defender Anti-Virus Cloud Checks are Disabled.
Windows Defender SmartScreen is Disabled.
Windows Defender Credential Guard is Disabled.
Windows Defender Exploit Guard is Disabled.
Windows Defender Exploit Guard Attack Surface Reduction (ASR) is Disabled.
Windows Defender Application Guard is Disabled.
Windows Defender Firewall is Enabled with default rules.

Telemetry

Whether analyzing unknown binaries or working on sensitive projects, endpoint telemetry powers detection and response operations. DARKSURGEON comes pre-configured with the following telemetry sources available for analysis:

Windows Event Log Auditing is enabled. (Palantir Windows Event Forwarding Guidance).
Windows Powershell Auditing is enabled. (Palantir Windows Event Forwarding Guidance).
Sysinternals Sysmon is installed and configured. (SwiftonSecurity Ruleset)

Privacy

Your operational environment contains some of the most sensitive data from your network, and it’s important to safeguard that from prying eyes. DARKSURGEON implements the following strategies to maximize privacy without hindering workflows:

Windows 10 telemetry settings are configured to minimize collection.
Cortana, diagnostics, tracking, and other services are disabled.
Windows Error Reporting (WER) is disabled.
Windows Timeline, shared clipboard, device hand-off, and other synchronize-by-default applications are disabled or neutered.
Microsoft Guidance for reducing telemetry and data collection has been implemented.

Base Tooling

Out of the box, DARKSURGEON comes equipped with tools, scripts, and binaries to make your life as a defender easier. The following are a non-exhaustive listing of the various categories and tools present in the project:

Android Analysis: Tools, scripts, and binaries focused on android analysis and reverse engineering. Examples include:

APKTool

Blue Team: Tools, scripts, and binaries focused on blue team, network defense, and alerting/detection development. Examples include:

Atomic Red Teaming (Red Canary)
Bloodhound / Sharphound
CimSweep
Dumpsterfire
EndGame Red Team Automation (RTA)
Kansa
Invoke-ATTACKAPI
Posh-Sysmon
PowerForensics
Yara

Debuggers: Tools, scripts, and binaries for debugging binary artifacts. Examples include:

Ollydbg
x64dbg
Windbg

Disassemblers: Tools, scripts, and binaries for disassembling binary artifacts. Examples include:

IDA 7 (Demo)
Binary Ninja (Demo)

DotNet Analysis: Tools, scripts, and binaries for performing analysis of DotNet artifacts. Examples include:

DNSpy
DotPeek

Flash Analysis: Tools, scripts, and binaries for performing analysis of flash artifacts. Examples include:

FFDec

Forensic Analysis: Tools, scripts, and binaries for performing forensic analysis on application and operating system artifacts. Examples include:

Amcache Parser
AppCompatCache Parser
Shellbags Explorer
TSK (The Sleuthkit)
Volatility

Hex Editors: Hex editing software. Examples include:

HxD
010 Editor

Java Analysis: Tools, scripts, and binaries for performing analysis of Java artifacts. Examples include:

JD-GUI
Dex2JAR

Network Analysis: Tools, scripts, and binaries for performing analysis of network traffic and protocols. Examples include:

Burp Free
FakeNet-NG
Wireshark

PE Analysis: Tools, scripts, and binaries for performing analysis of PE artifacts. Examples include:

ExplorerSuite (CFF Explorer)
PEStudio
PEview

Powershell Modules: Administration, productivity, and support modules for Powershell. Examples include:

Active Directory (RSAT)
Azure Management
Pester

Python Libraries: Administration, productivity, and support libraries for Python. Examples include:

OLETools
Passivetotal
PEFile
PyCryptodome
Scapy
Shodan
Vivisect
Yara-Python

Red Team: Tools, scripts, and binaries focused on red team, network exploitation, and alerting/detection development. Examples include:

Grouper
Inveigh
PowerupSQL
PSAttack
Responder

Remote Management: Administration, productivity, and support modules for remote management of systems and applications. Examples include:

AWS Command Line (AWSCLI)
Remote Server Administration Tools (RSAT)

Utilities: Administration, productivity, and support utilities. Examples include:

API Monitor
Chocolatey
Cyber Chef
Windows Subsystem for Linux (WSL)
Winlogbeat

Visual Basic Analysis: Tools, scripts, and binaries for performing analysis of Visual Basic artifacts. Examples include:

VBDecompiler

Building DARKSURGEON

The Mark of a Successful Build.

Build Process

DARKSURGEON is built using the HashiCorp application packer. The total build time for a new instance of DARKSURGEON is around 2–3 hours.

Packer creates a new virtual machine using the DARKSURGEON JSON file and your hypervisor of choice (e.g. Hyper-V, Virtualbox, VMWare).
The answers.iso file is mounted inside the DARKSURGEON VM along with the Windows ISO. The answers.iso file contains the unattend.xml needed for a touchless installation of windows, as well as a powershell script to configure Windows Remote Management (winrm).
Packer connects to the DARKSURGEON VM using WinRM and copies over all files in the helper-scripts and configuration-files directory to the host.
Packer performs serial installations of each of the configured powershell scripts, performing occasional reboots as needed.
When complete, packer performs a sysprep, shuts down the virtual machine, and creates a vagrant box file. Additional outputs may be specified in the post-processors section of the JSON file.

Setup

Note: Hyper-V is currently the only supported hypervisor in this alpha release. VirtualBox and VMWare support are forthcoming.

Install packer, vagrant, and your preferred hypervisor on your host.
Download the repository contents to your host.
Download a Windows 10 Enterprise Evaluation ISO (1803).
Move the ISO file to your local DAKRSURGEON repository.
Update the DARKSURGEON.json file with the Windows ISO SHA1 hash and file name.
(Optional) Execute the powershell script New-DARKSURGEONISO.ps1 to generate a new answers.iso file. There is an answers ISO file included in the repository but you may re-build this if you don’t trust it, or you would like to modify the unattend files:
powershell.exe New-DARKSURGEONISO.ps1
Build the recipe using packer:
packer build -only=[hyperv-iso|vmware|virtualbox] .\DARKSURGEON.json

Configuring DARKSURGEON

Need new capabilities? Add them to DARKSURGEON.json.

DARKSURGEON is designed to be modular and easy to configure. An example configuration is provided in the DARKSURGEON.json file, but you may add, remove, or tweak any of the underlying scripts.

Have a custom CA you need to add? Need to add a license file for IDA? No problem. You can throw any files you need in the configuration-files directory and they’ll be copied over to the host for you.

Want to install a custom package, or need some specific OS tweaks? No worries. Simply make a new powershell script (or modify an existing one) in the configuration-scripts directory and add it as a build step in the packer JSON file.

Using DARKSURGEON

Note: Hyper-V is currently the only supported hypervisor in this alpha release. VirtualBox and VMWare support are forthcoming.

Vagrant up to fight bad guys.

Once DARKSURGEON has successfully built, you’ll receive an output vagrant box file. The box file contains the virtual machine image and vagrant metadata, allowing you to quickly spin up a virtual machine as needed.

Install vagrant and your preferred hypervisor on your host.
Navigate to the DARKSURGEON repository (or the location where you’ve saved the DARKSURGEON box file).
Perform a vagrant up: vagrant up

Vagrant will now extract the virtual machine image from the box file, read the metadata, and create a new VM for you.

Want to kill this VM and get a new one? Easy, just perform the following: vagrant destroy && vagrant up

Once the DARKSURGEON virtual machine is running, you can login using one of the two local accounts:

Note: These are default accounts with default credentials. You may want to consider changing the credentials in your packer build.

Administrator Account:
Username: darksurgeon
Password: darksurgeon

Local User Account:
Username: unprivileged
Password: unprivileged

If you’d rather not use vagrant, you can either import the VM image manually, or look at one of the many other post-processor options provided by packer.

Next Steps

Ready to get started? Just head over to the GitHub Repository and download the project.

Contributing

Contributions, fixes, and improvements can be submitted directly against this project as a GitHub issue or pull request. Tools will be reviewed and added on a case-by-case basis.

Endpoint Isolation with the Windows Firewall

2018-04-22T08:00:00+00:00

Over the last few weeks, I’ve had conversations with several individuals around mitigating lateral movement in a Windows environment. In all of these cases, I was surprised to learn that these defenders were not using the native Windows Firewall as one of their defense-in-depth layers. This was curious to me as the firewall is both present by default and is one of the easiest ways to limit remote access to many commonly-abused services.

This post is going to focus on using the Windows Firewall for isolating and securing endpoints in an Active Directory environment. The goal is to limit the potential attack surface of endpoints by limiting access to potentially exploitable services, require IPSEC authentication to management services, and provide additional encryption to services which rely on plaintext or weak ciphers. The configurations listed in this post should be immediately deployable in a production environment and ultimate make our adversary’s lateral movement attempts that much more frustrating.

An important note: you should go watch Jessica Payne’s Demystifying the Windows Firewall talk from Ignite 2016. Most of the content in this post is simply a re-hash of the best practices and strategies that she has outlined in her presentation. Her talk is the reference for the Windows Firewall. Seriously, go watch it right now.

Firewall Principles

There are some basic principles to adhere to when developing a comprehensive firewall policy:

Manage centrally. We’re going to rely on using Group Policy Objects (GPO) for managing our firewall rules. This has the benefit of native integration within Active Directory and, if using Advanced Group Policy Management (AGPM), change control, rollback, and auditing features.
Block by default. We’re going to block services by default. We will whitelist critical services we need with appropriate scope. Everything else can get tossed to the void.
Require authentication. We’re going to challenge remote devices and users to authenticate before they can communicate to our critical services. If they fail authentication, they get tossed to the void.
Encrypt plaintext protocols. We’re going to apply encryption and integrity protections on plaintext protocols.
Use strong cryptographic settings. We’re going to use strong ciphers, key sizes, and protocols when establishing IPSec tunnels.
Ignore local policies. By default, any user or application can create local firewall rules. To ensure our ruleset isn’t accidentally or intentionally subverted, we’re going to deny local rules from applying in the firewall.

Firewall Base Settings (Endpoints)

From these principles, we can now start the process of building our firewall settings. These will configure how the firewall operates, determine logging settings, and set authentication and encryption options for IPSEC.

To start, we’ll open up the Group Policy Management editor (gpmc.msc) and make a new GPO called Workstation Firewall Policy. Scope this to the OU containing your workstations of choice but do not apply it yet (remove “Authenticated Users” from the security filter).

In the GPO manager, navigate to Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security

Configuring Firewall Settings

The first option we’ll set is to enforce the Firewall to be enabled on all profiles. Navigate to each of the Profile Tabs and set the following settings:

Firewall State: On
Inbound Connections: Block
Outbound Connections: Allow

Settings

Display a Notification: No
Allow Unicast Response: Yes
Apply Local Firewall Rules: No
Apply Local Connection Security Rules: No

Logging

Name: Default
Size Limit: 4096 (or higher - dealer’s choice)
Log Dropped Packets: Yes
Log Successful Connections: No

Desired firewall settings.

Configuring IPSEC Settings

NOTE: IPSEC ciphers, key sizes, and exchange protocols may need to be tailored to your environment and needs. These selections assume a modern fleet with strong security requirements. Avoid DES and MD5 in any configuration.

The second option we’ll set are the IPSEC settings. Navigate to the IPSEC Settings Tab and set the following settings:

Key Exchange Main Mode: Advanced
Security Methods:

SHA-384-AES-CBC-256-Elliptic Curve Diffie-Hellman-P-384
SHA-384-AES-CBC-192-Elliptic Curve Diffie-Hellman-P-384
SHA-384-AES-CBC-128-Elliptic Curve Diffie-Hellman-P-384
SHA-256-AES-CBC-256-Elliptic Curve Diffie-Hellman-P-256
SHA-256-AES-CBC-192-Elliptic Curve Diffie-Hellman-P-256
SHA-256-AES-CBC-128-Elliptic Curve Diffie-Hellman-P-256

Key Lifespan: 480 minutes
Use Diffie-Hellman: Yes
Data Protection Quick Mode: Advanced
Security Methods (Data Integrity):

ESP-AES-GMAC-256 (60/100,000)
ESP-AES-GMAC-192 (60/100,000)
ESP-AES-GMAC-128 (60/100,000)

Security Methods (Data Integrity/Encryption):

ESP-AES-GCM-256 (60/100,000)
ESP-AES-GCM-192 (60/100,000)
ESP-AES-GCM-128 (60/100,000)

Authentication Method: Computer and Kerberos (v5)

Desired IPSec Key Exchange Settings.

Desired IPSec Quick Mode Settings.

Desired IPSec Settings.

At this stage, we’ve gone ahead and configured the base policies for the firewall. This has the following effects:

The firewall will be enabled on all profiles.
The firewall will ignore locally applied rules.
The firewall will log dropped packets for debugging purposes.
Local firewall rules will not be applied.
IPSec is configured to use strong ciphers, keys, and protocols.
IPSec authentication will use kerberos for user and computer accounts.

Firewall Connection Security Rules (Endpoints)

Note: As you develop new rules, you should deploy to a subset of systems using the security filter. Failure to adequately test firewall rules could cause a loss of availability for critical systems.

We will now start the process of implementing connection security rules for the endpoints. Connection security rules allow for complex management of IPSEC tunnels to include authentication from users or computers prior to establishment of sessions.

In essence, we will use these rules to require both computers on each end of a given session to establish an authenticated (and optionally: encrypted) session to protect critical services. These rules do not deal with directionality or access controls, so they will be used in conjunction with standard firewall rules later in this post.

In the GPO editor, open up the Workstations Firewall Policy and navigate to Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Connection Security Rules.

We’ll use a standard naming scheme for our rules to make it easier to understand and troubleshoot rule issues:
GPO-{Secure}-{Service}-Profile

Connection Security Rules.

Securing WinRM

Note: As you develop new rules, you should use the “Request Authentication for Inbound and Outbound Settings” option, as it will gracefully fall back for troubleshooting purposes. This should be changed to “Require Authentication” once it is stable.

The first rule we’ll implement will secure WinRM by requiring successful kerberos authentication from trusted computers and users. This is designed to gate access to WinRM only from trusted machines on the network, such as Windows Event Collectors, bastion hosts, and other management devices. This additionally mitigates the risk of exploits targeting WinRM and associated services.

Implement this rule with the following details:

Rule Type: Custom
Endpoint 1: Any
Endpoint 2: Any
Requirements: Request Authentication for Inbound and Outbound Settings
Authentication Method: Default (User/Computer Kerberos v5)
Protocol Type: TCP
Endpoint 1 Port: 5985, 5986
Endpoint 2 Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Profile: All
Name: GPO-Secure-WinRM-Policy

Securing RDP

The next rule we’ll implement will secure RDP by requiring successful kerberos authentication from trusted computers and users. This is designed to gate access to RDP only from trusted machines on the network, such as help-desk machines, bastion hosts, and other management devices. This additionally mitigates the risk of exploits targeting RDP and associated services.

Implement this rule with the following details:

Rule Type: Custom
Endpoint 1: Any
Endpoint 2: Any
Requirements: Request Authentication for Inbound and Outbound Settings
Authentication Method: Default (User/Computer Kerberos v5)
Protocol Type: TCP
Endpoint 1 Port: 3389 Endpoint 2 Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Profile: All
Name: GPO-Secure-RDP-Policy

Firewall Rules (Endpoints)

We will now start the process of implementing firewall rules for the endpoints.

We’ll use a standard naming scheme for our rules to make it easier to understand and troubleshoot rule issues:

GPO-{Allow,Block,Secure}-{Service}-{Protocol}

Example of My Firewall Rules.

Blocking SMB / Remote Named Pipes

The first rule we’ll implement will block incoming Server Message Block (SMB) connections. This is designed to prevent remote access to file shares on the workstation, as well as mitigate the risk of exploits targeting SMB and associated services.

Implement this rule with the following details:

Rule Type: Custom
Programs: All Programs
Protocol Type: TCP
Local Port: 445
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block the Connection
Profile: All
Name: GPO-Block-SMB-TCP

Blocking NetBIOS / NBT

The next rule we’ll implement will block incoming NetBIOS and NetBIOS over TCP (NBT) connections. As NetBIOS is not required in a modern environment, this rule will mitigate the risk of exploits targeting NetBIOS and associated services.

Implement this rule with the following details:

Rule Type: Custom
Programs: All Programs
Protocol Type: TCP
Local Port: 137, 138, 139
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block the Connection
Profile: All
Name: GPO-Block-NetBIOS-TCP

We’ll repeat this rule, but for UDP. Implement this rule with the following details:

Rule Type: Custom
Programs: All Programs
Protocol Type: UDP
Local Port: 137, 138, 139
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block the Connection
Profile: All
Name: GPO-Block-NetBIOS-UDP

Blocking RPC/DCOM/WMI

The next rule we’ll implement will block incoming Remote Procedure Call (RPC) connections. RPC allows access to the Distributed COM (DCOM) service, the WMI service, and many other windows services. This rule will mitigate the risk of exploits targeting RPC and associated services. Implement this rule with the following details:

Rule Type: Custom
Programs: All Programs
Protocol Type: TCP
Local Port: 135, 593
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block the Connection
Profile: All
Name: GPO-Block-RPC-TCP

We’ll repeat this rule, but for UDP. Implement this rule with the following details:

Rule Type: Custom
Programs: All Programs
Protocol Type: UDP
Local Port: 135, 593
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block the Connection
Profile: All
Name: GPO-Block-RPC-UDP

Securing WinRM Connections

The next rule we’ll implement will secure incoming WinRM connections with an authenticated IPSEC tunnel using the security connection rule we previously built.

Implement this rule with the following details:

Rule Type: Custom
Programs: All Programs
Protocol Type: TCP
Local Port: 5985, 5986
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Allow if Secure
Profile: All
Name: GPO-Secure-WinRM-TCP

Then, right-click on the rule and navigate to properties. Select the Remote Computers tab. This allows you to specify which computers in your Active Directory environment are allowed to connect to this machine remotely.

In this example, I am going to allow my desktop monolith to connect remotely via WinRM to any device in my network via WinRM. I am also going to allow my Windows Event Collector machine WEF to connect for event forwarding purposes.

You can substitute this for any privileged access workstations (PAWs), bastion hosts, Windows Event Collectors, or other management hosts in your fleet.

Remote Computer Requirements.

Next, we’ll specify legitimate remote users. Select the Remote User tab. This allows you to specify which users in your Active Directory environment are allowed to connect to this machine remotely.

In this example, I am only going to allow myself to connect remotely via WinRM.

You can substitute this for any user or user group in your fleet. These could include help-desk, workstation administrators, or other user types.

Remote User Requirements.

Lastly, I am going to specify the requirements needed to secure this connection. Select the General Tab and click Customize under the Allow Connection if it is secure option.

As WinRM uses encryption natively (e.g. kerberos or HTTPS), I do not need to double-encrypt the payload with IPSEC encryption. Additionally, I feel pretty confident that the integrity of these sessions will be guaranteed by the underlying protocol. As such, I am going to select Allow the Session to Use Null Encapsulation, which will ensure we authenticate the connection, but do not apply any encryption or integrity protections.

WinRM IPSEC Settings.

The result of this rule is that:

Only kerberos-authenticated connections originating from HOME\dane can connect to WinRM on this machine.
Only kerberos-authenticated connections originating from HOME\WEF$ and HOME\monolith$ can connect to WinRM on this machine.
When the IPSEC session is established, it will be authenticated, but no other protections will be applied.

Securing RDP Connections

The next rule we’ll implement will secure incoming RDP connections with an authenticated IPSEC tunnel using the security connection rule we previously built.

Implement this rule with the following details:

Rule Type: Custom
Programs: All Programs
Protocol Type: TCP
Local Port: 3389
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Allow if Secure
Profile: All
Name: GPO-Secure-RDP-TCP

I will repeat the Remote Users and Remote Machines configuration as per the previous rule. However, since I don’t trust RDP encryption or authentication, I am going to specify additional IPSEC security requirements.

Select the General Tab and click Customize under the Allow Connection if it is secure option.

I am going to select Require the connections to be encrypted, which will not only authenticate the session, but force integrity and encryption protections. Additionally, select Allow the Computers to Dynamically Negotiate Encryption.

RDP Secure Settings Settings.

The result of this rule is that:

Only kerberos-authenticated connections originating from HOME\dane can connect to RDP on this machine.
Only kerberos-authenticated connections originating from HOME\monolith$ can connect to RDP on this machine.
When the IPSEC session is established, it will be authenticated, but also require encryption and integrity protection.

Blocking Outbound Connections (Endpoints)

Lastly, the firewall provides an excellent interface for developing rules to prevent outbound connections from binaries on endpoints. These can be used to prevent services from communicating on untrusted profiles (e.g. Public, Private networks), preventing binaries from communicating to non-private resources (e.g. Non-RFC1918 addresses), or even from communicating at all. These rules can be very useful for catching unsophisticated techniques, especially those which rely on living off the land principles.

Outbound Firewall Deny Rules.

Blocking Calc.exe

While not the most glamorous of defensive strategies, calc.exe is commonly abused by default behaviors for process migration and injection techniques. This is an example rule which prevents calc.exe from communicating with any network resources. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\System32\calc.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Calc-All

We’ll repeat this rule, but for the syswow64 path. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\Syswow64\calc.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Calc-All

Blocking Notepad.exe

While not the most glamorous of defensive strategies, notepad.exe is commonly abused by default behaviors for process migration and injection techniques. This is an example rule which prevents notepad.exe from communicating with any network resources.

Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\System32\notepad.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Notepad-All

We’ll repeat this rule, but for the syswow64 path. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\Syswow64\notepad.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Notepad-All

Blocking Conhost.exe

While not the most glamorous of defensive strategies, conhost.exe is commonly abused by default behaviors for process migration and injection techniques. This is an example rule which prevents conhost.exe from communicating with any network resources.

Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\System32\conhost.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Conhost-All

We’ll repeat this rule, but for the syswow64 path. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\Syswow64\Conhost.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Conhost-All

Blocking Mshta.exe

Mshta.exe is commonly abused by attackers to proxy execution of malicious .hta files and Javascript or VBScript. This is an example rule which prevents mshta.exe from communicating with any network resources.

Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\System32\mshta.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Mshta-All

We’ll repeat this rule, but for the syswow64 path. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\Syswow64\mshta.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Mshta-All

Blocking Cscript.exe

Cscript.exe is commonly abused by attackers to execute malicious scripts. This is an example rule which prevents Cscript.exe from communicating with any network resources.

Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\System32\Cscript.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Cscript-All

We’ll repeat this rule, but for the syswow64 path. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\Syswow64\Cscript.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Cscript-All

Blocking Wscript.exe

Wscript.exe is commonly abused by attackers to execute malicious scripts. This is an example rule which prevents Wscript.exe from communicating with any network resources.

Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\System32\Wscript.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Wscript-All

We’ll repeat this rule, but for the syswow64 path. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\Syswow64\Wscript.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-Wscript-All

Blocking RunScriptHelper.exe

RunScriptHelper.exe is commonly abused by attackers to execute malicious scripts. This is an example rule which prevents RunScriptHelper.exe from communicating with any network resources.

Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\System32\RunScriptHelper.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-RunScriptHelper-All

We’ll repeat this rule, but for the syswow64 path. Implement this rule with the following details:

Rule Type: Custom
Programs: %SystemRoot%\Syswow64\RunScriptHelper.exe
Protocol Type: Any
Local Port: Any
Remote Port: All Ports
Scope (Local): Any IP Address
Scope (Remote): Any IP Address
Action: Block
Profile: All
Name: GPO-Block-RunScriptHelper-All

Server Configuration

The steps to require servers are mostly identical to the steps listed above for workstations. That said, there are a few important caveats to be mindful of:

You will want to create a base Server Firewall Policy GPO with all of the default firewall settings configurations and connection security rules.
You will want multiple GPOs for different server types. For example, file servers will want their own policy GPO which allows SMB inbound (preferably with IPSEC authentication, integrity, and encryption).
Remember that Active Directory Organizational Units (OUs) are policy boundaries for GPOs. Try to put like-kind servers in the same OU or, failing that, use security filtering and security groups to apply firewall rules.

Again, it is very important to use the request option for security connection rules when testing. This will allow graceful fallback to the underlying protocol, which will prevent service availability issues.

Protips

There are a few protips that I’ve learned while deploying this across my home environment:

Test slowly using security filtering. It is easy to accidentally roll out a bad firewall rule or security configuration profile, which could cause loss of access to your device. I recommend having a low frequency for GPO refreshes and a slow roll-out to quickly recover from any bad firewall rules.
These rules will override locally set rules. If you have specific applications that require inbound connectivity, you will need to ensure it’s managed via a relevant GPO. Failure to plan out what applications you’re using on your network will break connectivity.
If you intend to use Hyper-V on machines running the Windows Firewall, you will need to create a rule allowing inbound DNS (TCP/UDP 53) on all interfaces from all profiles. This is required to process DNS packets from Hyper-V guests to the hypervisor. Failure to do so will break default DNS resolution within Hyper-V guests.
You will need to ensure that UDP Port 500 (IKE) and ESP are not filtered by any network firewalls. Using IPSEC to protect protocols will initiate the tunnel via IPSEC (UDP 500) and then tunnel traffic over ESP, which could be filtered by firewalls inside your network. Use wireshark and validate all the connections look sane and reasonable.
If you’re looking to use bloodhound or Windows ATA on your network, you’ll need to ensure you have a rule allowing RPC from your trusted hosts. This is required to allow SAMR requests from these tools, which can provide deeper insight into the configuration of your endpoints.
I highly recommend installing Glasswire, a freemium application which provides deeper insight into network connectivity on windows hosts. The paid upgrade for glasswire additionally allows for more restrictive firewall policies (e.g. ask for connectivity for new binaries), but these may require enabling local rule processing in your GPO.

blog.dane.io

Unlimited, Unthrottled, and Anonymous LTE Access

The History Behind Unthrottled LTE

The Educational Broadband Service

Game of Thrones: Mobile Carrier Edition

The Calyx Institute and Unlimited LTE Access

Joining the Calyx Institute

Getting a Privacy-Friendly Hotspot

Hotspot OPSEC

Further Reading and Acknowledgements

Deploying a Static Website via Azure

The Case for a Static Web Page

Windows Development Environment

Configuring Your Repository

Create a .gitignore file

Upload Web Site Files

Configuring Azure

Create the Storage Account

Configure Custom Domain Name

Enabling the Azure CDN

Enabling TLS Encryption

Configuring CDN Compression

Configuring CDN Cache

Adding Basic Security Features

Configuring CircleCI

Hooking CircleCI to GitHub

Generating a CircleCI YAML File

Configuring GitHub Checks

Example CircleCI Workflow

Pricing

Further Reading and Acknowledgements

Detecting Windows Endpoint Compromise with SACLs

ACE and ACL Basics

Defensive SACL Primitives

Adding a SACL

Using the Security GUI

Using Powershell

Verify the ACE Works

Alerting and Detection Strategies

Browser Data Harvesting

Key and Credential Harvesting

Registry Persistence

Malicious System Tampering

Protips

Further Reading and Acknowledgements

DARKSURGEON: A Windows 10 Packer Project for Defenders

Development Principles

Hardening

Telemetry

Privacy

Base Tooling

Building DARKSURGEON

Build Process

Setup

Configuring DARKSURGEON

Using DARKSURGEON

Next Steps

Contributing

Further Reading and Acknowledgements

Endpoint Isolation with the Windows Firewall

Firewall Principles

Firewall Base Settings (Endpoints)

Configuring Firewall Settings

Settings

Logging

Configuring IPSEC Settings

Firewall Connection Security Rules (Endpoints)

Securing WinRM

Securing RDP

Firewall Rules (Endpoints)

Blocking SMB / Remote Named Pipes

Blocking NetBIOS / NBT

Blocking RPC/DCOM/WMI

Securing WinRM Connections

Securing RDP Connections

Blocking Outbound Connections (Endpoints)

Blocking Calc.exe

Blocking Notepad.exe

Blocking Conhost.exe

Blocking Mshta.exe