Azure Sentinel at Home

As I mentioned last time, I’ve been running Azure Sentinel against my home network to see how well I can detect unusual events or malicious activity at home. For most people, running a commercial SIEM solution at home is ridiculously overkill – admittedly that’s probably true for me as well. However, while I do red teaming at work, it’s always good to take some time to learn the tools used by the blue team and what better way than to use them to protect a network I care about?

So… what kind of network am I monitoring? Let’s take a look at my LAN. My entire network is built using Ubiquiti hardware. I have a UDM Pro that acts as my router, security appliance, and network configuration controller. For the core of the network I have a Ubiquiti EdgeSwitch 48. This switch is the sole connection to the UDM. The EdgeSwitch then feeds several Unifi APs, as well as several 8-port Unifi switches located at key places like the entertainment center and my desk. The network consists of several VLANs and SSIDs. There are VLANs for my IOT devices, my computers, my security cameras, my VOIP devices, guest devices, and a management network for the network gear itself.

You might be thinking – IOT network? At a red teamer’s house? Yep, I know. I follow accounts like Internet of Shit and am highly skeptical of these devices. But I’m also a tech geek at heart – always have been – and don’t want to forgo all the cool blinky things just because security was item #37 on their developer’s priority list. That’s why they get an isolated network. Same deal with the security cameras, running who-knows-what kind of terrible firmware. And that’s another reason why having Sentinel monitoring is a good idea.

What do you need to start monitoring? Well, for starters you’re going to need an Azure subscription. Azure subscriptions themselves are free, you simply get charged for usage of services you provision in the subscription. The amount of data you end up pumping in to Sentinel will determine the cost. Luckily if you are just trying out Sentinel for non-production workloads, there are a few options to get free credits. If you have a Visual Studio subscription, you get up to $150/month in free credits. If you’re just signing up for a new Azure account, you could get a one-time $200 credit. Microsoft also runs a number of other credit offers for startups, students, and occasionally they have other promotions, too. Search around to see what’s currently available.

Once you have a subscription, you need to create an instance of the Sentinel service. This is a straight-forward process documented in detail here; at a high level you:

  1. Decide in which region (Azure datacenter) you want to host your resources. There are a few considerations when choosing a region:
    1. Location – you may want to chose a location close to you to reduce latency, or based on country if data sovereignty is important to you.
    2. Service Availability – not all services are available in every region. You’ll want to make sure the region supports at least Azure Sentinel, Azure Monitor, Log Analytics, and Azure Storage.
    3. Price – Some regions are more expensive than others for certain services, depending on capacity and other factors. For example, for Sentinel, West US 2 was less expensive than the West US region when I created my instance. The Azure pricing estimator can help you determine where you can get the most capacity for your buck.
  2. Create a Log Analytics Workspace. This is the log collection component of Azure Monitor, and the underlying data store for Sentinel.
  3. Proceed through the Sentinel wizard to create an instance. Select your workspace from step 2 during setup.

Next, you need to decide what types of events you want being sent to Sentinel. At the time of writing, there are 118 different Data Connectors in Sentinel, with more being added every month. A Data Connector is service code that runs in Azure that knows how to parse a specific type of log and merge the data into Sentinel. There are first-party data connectors for many Microsoft services, like Azure, M365, AAD, IIS, Windows Event Logs, etc., as well as third-party connectors for all kinds of products ranging from AV solutions to productivity suites. There are also generic connectors provided by Microsoft, such as the Syslog connector, that can ingest data from any device that outputs syslog-formatted data.

For my network, I decided I wanted to capture:

  • Network Device Events (devices joining the network, firewall events)
  • Windows Event Log data from my PCs
  • Sysmon events from my PCs for extra details about process execution and communication
  • Network flow data (to look for unusual connections)
  • Syslog logs from various IOT devices and servers
  • Azure events for the subscription running Sentinel
  • Web server logs from this website 🙂

I also wanted to integrate some of the free/open source threat intelligence feeds from a few sources so traffic on my network could be correlated with known-malicious destinations. Luckily Sentinel has data connectors that could handle all of these different sources – I just needed to to get the logs into Azure.

Once you have your desired list of logs, go to the Data connectors page in your Sentinel instance. Search for services you want to add to see if there are native connectors. If so, great! If not, see if the service can be monitored using a more generic connector – for example, via a Syslog parser, an event log parser, or using Sysmon. At worst, you may need to write a custom parser for a more obscure type of log. Forums such as techcommunity.microsoft.com, the Sentinel GitHub page, Reddit, or your vendor’s support forums are all good resources to figure out the best way to connect your specific type of log to Sentinel.

Within the data connectors, you’ll find that there are several different ways that logs get ingested into the Log Analytics workspace. The most straight forward logs to import are those from Microsoft online services, like AAD, Azure, or M365. Generally these can be connected by simply going to the service and pointing it’s logging feature at the Log Analytics instance. The specific data connector page for each service will detail the exact steps.

The next easiest type of log to import are Windows host logs, such as Windows Events. To ingest these, download the Microsoft Monitoring Agent (MMA) package (the data connector page has a link) and install it on any host with logs you want. During the installation wizard it will ask if you want to forward logs to Azure. Say yes, and then enter the ID of your log analytics workspace and the workspace access key string. MMA client actually retrieves its configuration from Azure itself, so you select the log types and event severities you want within the Log Analytics workspace and your agents will begin forwarding the logs you requested.

The third type of log ingestion you’re likely to see is forwarded through a Linux host using the OMS Agent. This is similar to MMA, however you can run multiple instances on a single Linux host, with each agent configured to listen on a different port for a specific type of log. OMS Agent then forwards these events into Log Analytics. This is how the collection for Apache and Ubiquiti logging works.

In my network I set up a Linux VM and configured it with OMS to forward the logs from my Ubiquiti gear into the Ubiquiti data connector, syslogs from various other network devices (and the Linux VM itself), and my web server logs into my Log Analytics workspace. Then, on my Windows hosts, I installed MMA to gather event logs.

At this point I had decent coverage for events on my network, but I was still missing some details I wanted to capture. For one, the standard Windows Event logs don’t capture the level of detail you need to really investigate security incidents. This is where Sysmon logging comes in. Sysmon is a highly configurable logging utility developed by Mark Russinovich and Thomas Garnier as part of the SysInternals suite.

Configuring Sysmon can be intimidating. You need to create an XML file that defines all the different types of events to capture, and specifies events to ignore. For example, your backup utility probably looks an awful lot like malware trying to exfiltrate all of your documents or ransomware touching every file on disk. Luckily experts have already released sample Sysmon configs that make for a great starting point. Twitter’s SwiftOnSecurity has a popular example at https://github.com/SwiftOnSecurity/sysmon-config. Another good option is from Blue Team Labs: https://github.com/BlueTeamLabs/sentinel-attack. With Sysmon deployed, my Windows devices were reporting the crucial events I’d need if investigating a security incident.

This left one final datatype on my LAN to collect – net flows. While the Ubiquiti logging captures events such as devices joining the wireless network and firewall events, it does not log all the connection details I’d like. As someone who professionally spends a good deal of time looking for devices with weak security posture that can be used to pivot, I know that collecting this data is very important, and may be the best way to identify certain classes of threats.

Gathering this data requires having some way to tap into network traffic as it traverses the network. One way to do this is to get a LAN tap device and install it between your switch and router. Instead, I prefer to set up a mirror port on my core switch. There are a number of ways to capture this flood of traffic. For a while I fed this data into Security Onion, but was never completely satisfied with the experience. However I saw a talk hosted by SANS about a year ago from the Corelight team. Corelight makes hardware sensors that can capture this data, process it with Zeek and Suricata, and forward it to your logging platform of choice.

An enterprise Corelight sensor is beyond the budget, size, and scope of a home lab, but the Corelight team recently released a new solution: Corelight@Home (C@H). This is a free-for-personal-use Corelight image that runs on a Raspberry Pi. It doesn’t have the nice UI or all the filters and options of an enterprise Corelight sensor, but it is perfectly capable for monitoring a home lab. Sentinel already has a Corelight connector, which is compatible with the logs C@H sends.

For my C@H sensor, I got a Raspberry Pi 4, a 64 GB SD card, and a 1Gbps USB3 NIC, as well as a PoE hat so I can power the Pi using my switch. The second network connection is needed, as one NIC will be on the mirror port where it won’t be able to send – only listen. You can use the built-in WiFi for this, but I prefer a hardwired connection. With the hardware set up, I signed up for the C@H program and got links to the image file, license key, and PDF guide shortly thereafter. They also provided an invite to a Slack channel where users can ask questions and get support.

I realized that the C@H documentation assumes most people will be using Humio for their log collection, and it didn’t cover configuring C@H for Sentinel. Luckily this wasn’t hard to set up. First, I installed Sentinel’s Corelight data connector OMS agent on my Linux VM. Then I ran the setup script on my Pi and opted to not to configure an exporter during setup. Once setup was complete, I opened the config file at /etc/corelight-softsensor.conf and changed two lines:

Corelight::json_enable       T
Corelight::json_server       (Linux VM IP):21234

This enables the forwarding of events in JSON format to my OMS Corelight listener agent on the VM. I then restarted the sensor by running sudo systemctl restart corelight-softsensor. Within a couple of minutes Corelight events began showing up in Sentinel.

With my LAN covered, it was time to take care of my external services. This website is hosted on a Linux VM running Apache, so it was easy to enable the Apache data collector in Sentinel and then install the agent on the VM and point it at the Apache log path. After that, I enabled collectors for Azure itself, and forwarded my subscription logs to it.

That’s it! In just a few hours I had coverage of all the critical elements on my network. While I don’t have a lot of experience with other SIEMs, I was really impressed with Sentinel that it was this fast to go from beginner to successful deployment. It was certainly a lot better experience than the free options I had tried in the past.

Azure

Azure Sentinel: Add Automation to All Alert Rules

Recently, I decided to try Azure Sentinel out on my home lab network to get a better understanding of how it’s deployed and used. Once I get some spare cycles, I plan to write up my experience deploying sensors and adding data connectors for my network [now available here], but for now I thought I should start with a script I wrote that others might find useful.

After configuring dozens of analytics rules to generate alerts, I decided I wanted to use an Azure Logic App to send me notifications when a rule fires. After a bit of research, I found this forum post, which indicates there is no current way to bulk add an automation playbook to all of the existing rules you’ve already configured: https://techcommunity.microsoft.com/t5/azure-sentinel/how-to-mass-apply-a-playbook-to-all-analytic-rules-at-once/m-p/2070715. The answer in this post goes on to state that that feature is currently in private preview.

Not wanting to wait for a beta feature to go public, I decided to create a PowerShell script to apply my notification automation app to all of my active rules at once. The code for the script is below (and also shared on my GitHub page). Just fill out the top variables with the details of your subscription, automation Logic App, and Sentinel instance and run it. This worked for me and my rules, though be sure to do a test on your non-prod environment to confirm it works for you before you use it in production. The script requires the Az and Az.SecurityInsights PowerShell modules.

# READ LICENSE TERMS AT BOTTOM OF SCRIPT BEFORE USE!

# Change these values:

$tenantId = "Your-subscription-AAD-tenant-ID"
$subscriptionID = "Your-Azure-subscription-ID"

$logicAppName = "Your-logic-app-name"
$logicAppRG = "Your-logic-app-resource-group-name"
$triggerName = "When_a_response_to_an_Azure_Sentinel_alert_is_triggered" # This is the default name

$workspaceName = "Your-Sentinel-Workspace-Name" 
$sentinelRG = "Your-Sentinel-Resouce-Group-name"

#---- No need to edit any of the below ----

Import-Module Az
Import-Module Az.SecurityInsights

# Connect to the Azure subscription
Connect-AzAccount -TenantId $tenantId
Select-AzSubscription -SubscriptionId $subscriptionID -TenantId  $tenantId

# Get the details of the Logic App to be used, and its trigger URL
$logicapp = Get-AzLogicApp -ResourceGroupName $logicAppRG -Name $logicAppName
$trigger = Get-AzLogicAppTrigger -ResourceGroupName $logicAppRG -Name $logicAppName -TriggerName $triggerName
$triggerUri = Get-AzLogicAppTriggerCallbackUrl -ResourceGroupName $logicAppRG -Name $logicAppName -TriggerName $triggerName

# Get all the existing active Sentinel alert rules
$rules = Get-AzSentinelAlertRule -ResourceGroupName $sentinelRG -WorkspaceName $workspaceName
foreach($rule in $rules)
{
    if($rule.Kind -eq "Error")
    {
        write-host "Skipping rule $($rule.Name), because Kind==Error"
    }
    else
    {
        write-host "Adding action to $($rule.Name)"
        New-AzSentinelAlertRuleAction -ResourceGroupName $sentinelRG -WorkspaceName $workspaceName -AlertRuleId $($rule.Name) -LogicAppResourceId $($logicapp.Id) -TriggerUri $($triggerUri.Value)
    }
}

# -----------------------------------

# Copyright 2021 Matt Burrough
# 
# Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
# associated documentation files (the "Software"), to deal in the Software without restriction, 
# including without limitation the rights to use, copy, modify, merge, publish, distribute, 
# sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is 
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all copies or 
# substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING 
# BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, 
# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Azure

Repinning an American 1305

For the past six months, I’ve been focused on a project I hope to share with everyone very soon. In the meantime I took a break a couple of days ago to work on building a progressive set of American 1305 locks – removing 1, 2, and 3 pins from these 5-pin locks. This set makes a great practice set for locksport folks – especially those who aren’t comfortable picking American locks and overcoming the strong spring tension needed to release the shackle. I decided to document this process on video – my first locksport-related YouTube video. Enjoy! Hopefully we’ll start having in-person meetups again soon and people can try picking these.

Locksport

SANS Cloud Summit Keynote

If you are interested in cloud security, take a look at the 2020 SANS Cloud Summit coming up at the end of May. In addition to some greats SANS courses, like 545, they are also hosting a virtual CTF and have a series of speakers to kick off the event. I’ll be giving a keynote on red team assessments in the cloud. I hope you can join us!

Speaking

New Impressioning Meetup

Join us Sunday, March 8 at 1:00 PM at Black Lodge Research in Redmond, WA for Seattle Locksport‘s first lock impressioning meetup. All experience levels welcome! We’ll have all the gear, locks, and key blanks you need. We’ll be meeting every 2nd Sunday of the month to practice, teach, learn, and socialize.

Curious about impressioning? Check out this overview from DEFCON, or see world champ Jos Weyers open a lock in under 2 minutes!

Locksport

DEF CON 27 Talk: Master Key Insider Attacks

Earlier this month, I spoke at DEF CON 27’s Lock Pick Village on insider attacks that can be executed on master-keyed systems. (Note: Not Master brand locks. 😊) A copy of my slides can be downloaded from: https://burrough.org/papers/Burrough-DC27_Master_Key_Talk.pdf.

Abstract
As a lock enthusiast and professional pentester, I think a lot about ways to quickly or reliably gain access to restricted areas without relying on my picks. This talk will cover several ways to perform escalation of privilege in the physical world.

  • DC27 LPV Talk
Locksport / Speaking