Geopolitical Cyber-Detection Lures for Attribution with Microsoft Sentinel 

Jordan Drysdale //

Summary!

There are tons of security event management (SIEM) solutions available these days, but this blog will focus on Microsoft Sentinel. Sentinel is easy to deploy, logs are inexpensive to retain, the platform is powerful, and even massive data queries are insanely responsive.  

Attribution is fun, and scary too! Have you ever wondered who is attacking your Remote Desktop Protocol (RDP) exposures? Read on to learn this simple technique attackers hate! Have you ever wondered who is trying to compromise your Linux Secure Shell (SSH) exposures? Read on to find out why geopolitical cybersecurity has never been more interesting! Attackers hate these tactics because they produce an instant readout of the threats your organization is facing right now! Today! In real time! 

This write-up assumes the following: 

• You have server assets exposed to the public internet 
• Your server assets have RDP and SSH exposed 
• Your server assets are running the Log Analytics agent and are connected to a Log Analytics (LA) workspace 
• Microsoft Sentinel is deployed and connected to the LA workspace 

Or, you can take the super basic query techniques here and apply them to your own internet-exposed servers. Since the only event IDs (EIDs) you need are 4624 and 4625, you do not need specialized audit policies in place either. The basic SIEM pseudo-logic could be:

[from auth_eids, grab src_ip, compare to geoIP.csv, sort by count, output "col1,col2,col3"]

If you are planning to perform the following tasks with your own sandbox, a quick-deployment ARM template is available at www.doazlab.com. Please note that if you see errors while deploying the sandbox environment, file an issue on our GitHub at https://github.com/DefensiveOrigins/DO-LAB. Microsoft is constantly changing SKUs, product availability, and image names. We do our best to keep up with them. 

Pre-Requisites!

First things first, then next things next — make sure your VMs are connected to the Log Analytics (LA) workspace.

Once connected, Sentinel should show logs are being ingested.

As mentioned, next pre-reqs next! Head back over to the LA workspace (Home > LA-workspace). Use the north-south navigation pane to get to the ’Agents configuration.’ Under Agents configuration, navigate to ‘Syslog’ and click to ’Add facility.’ Add both the 1. authpriv and 2. auth facilities. The changes will auto-apply to the Linux agent and syslogs will start flowing almost immediately.

The Important Bits!

• Windows logs flowing? Check!
• Syslogs flowing? Check!
• Sentinel operational? Check!

Time is an interesting ally in this attribution approach. While reviewing this material, it looks like it takes about an hour for each of these services to get picked up by the attacking bot networks. Once identified, the pandemonium really gets rolling in earnest and we start to see the results we want.

One of our goals with this approach is to create our own threat intel, and by the end of this story, you should be wondering why your threat intel feeds are not providing this kind of data. The first query is owed to a brilliant student that Kent and I had in an early run of Applied Purple Teaming in 2022 — so, let’s call this “Pierce’s RDP attribution query.”

Go here: https://github.com/DefensiveOrigins/SentinelKQL

Copy the “// blog query 1” bits shown below (skipping the README’s description).

Paste that KQL query over to your Sentinel > Logs > New Query pane. This query relies on simple parsing of the EID 4624 and 4625 events gathered from our exposed Windows systems. If you did not deploy the ARM template from doazlab.com, you may need to configure additional log collections on your VMs to ensure you have these events.

Run this query and behold the magnificence of identifying some of the internet’s most dangerous and uncaring adversaries. These folks script attacks, smash down doors, compromise systems, take over accounts, and rightfully escalate their compromises to their own version of “Tier 2 Support.”

Quick math: this is approximately 25,000 guesses against two systems in 24 hours. This is about 9 guesses per minute — and we are not taking EID 4776 into account with this query. If you honestly trust in your existing password policy, be it 8 or 10 characters, I have another story to tell you about compromise.

Black Hills InfoSec is a penetration testing firm. We author reports for a living and hack as a hobby. We are rather good at password attacks, and we usually find a way to recover an account or two in our time-limited and scope-controlled testing. These adversaries care not for your lockout policies, nor your log analytics capacities, nor the terms of your weeklong engagement. They do not care about your IR processes and are not flying under radar screens, but…

Most businesses have never seen anything like this type of log analysis — and that means most of us are blind to this kind of attack. We are up against legitimate and terrifyingly persistent adversaries. We keep reading about compromise. We keep reading about ransomware. These results demonstrate so many things that make me shiver and keep me awake at night. Every single authentication service that gets exposed to the public internet has about an hour of quiet time and peaceful life from inception. After that, our service exposures are under an endless stream of attacks.

Anyway, let’s get back to it! We just parsed two of the most common Windows event IDs to produce an eye-opening result set.

• 4624: An account was successfully logged on
• 4625: An account failed to log on

Randy Franklin Smith’s Ultimate Windows Security is my first stop, every time, for matters involving Windows events.

• https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/

A quick investigation of our top attacker against the Cisco Talos Intelligence engine does not tell us much. A poor rating for its email reputation, likely because it was listed on one of the spam monitors.

These results are plus/minus a stroke over a double bogey on a par 3 but are par for the state of threat intelligence feeds. However, know that with this basic level of analysis, I would strongly advise that you should absolutely, 100%, without a doubt, block all traffic from the networks in the next screenshot.

Ya, I know, I’m terrible at optimism! NEXT! What do the SSH logs look like?

Do you remember earlier when I mentioned one of our brilliant students? Let’s call this next one, “Pierce’s SSH attribution query.” You can find this with a quick page search here: https://github.com/DefensiveOrigins/SentinelKQL for “SSH attribution.”

Paste this query over to Sentinel > Logs > New Query pane.

This query looks at Syslog messages with “Failed Password” which matches against the SSH logs and look about like the following:

• sshd: Failed password for user from IP

One remarkably interesting thing of note is that the difference has been consistent across my research over the last six months. Attacks against exposed RDP services are primarily sourced from Russian IP blocks. Attacks against exposed SSH services are primarily sourced from Southeast Asia. These are the facts.

It is straightforward to build your own geo-heatmaps as well. This step is beyond the scope of this blog but could look something like the following.

Imagine sorting this by successful logon (which you can) and seeing a country where you have zero workforce? How would you react?

Check back in as we continue the deep dive through more of Sentinel’s amazing capabilities.

---

---

---

---