DEV Community: CD Security Lab

One service died and took the orders with it. Kafka + AKHQ in one Docker Compose file

CD Security Lab — Tue, 10 Nov 2026 01:09:58 +0000

Sources: CD's devops wiki 02-kafka-rabbitmq/01-kafka-overview.md and 02-lab-kafka-with-docker-compose.md, updated to Kafka 4.x (KRaft, no ZooKeeper) and AKHQ, checked against the Apache Kafka docs and AKHQ releases on 2026-10-28. Lab names only.

Friday evening at Contoso's web shop. The inventory service restarts for a patch. For 40 seconds the order service, which calls inventory directly, gets connection errors and throws the orders away. Nobody finds out until Monday, when 212 customers ask where their stuff is. Nothing was hacked. Two services were simply holding hands too tightly.

TL;DR

Problem: services that call each other directly fail together. One restart, one slow dependency, one traffic spike, and work is lost.
Who it hurts: customers (lost orders), the business (refunds, reputation), developers on call (every outage is a 2 a.m. mystery), and anyone trying to add a new service without touching the old ones.
Fix: put a broker in the middle. Producers write events to a topic; consumers read when they are ready. This post runs Apache Kafka 4.1 and the AKHQ web UI in one Docker Compose file.
Cost: two containers, about 1 GB of RAM, zero licence. The 2023 way (ZooKeeper + broker + Confluent Control Center) was three containers, several GB, and a commercial UI.
Prove it: send three orders, stop the consumer, send three more, start it again. Nothing is lost.

1. The problem
2. Who gets hurt
3. Cost and value
4. Build it: one Compose file
5. Prove it works
Gotchas
Checklist
What changed recently
Sources

1. The problem

Direct calls between services are like phoning a colleague every time you need something. If they are at lunch, you wait. If they quit, you are stuck. If 500 people phone at once, nobody gets through.

A message broker is the office mailbox. You drop the letter and walk away. The colleague empties the mailbox when they are back. Letters wait in order. Nobody loses a letter because someone was at lunch.

Kafka is that mailbox, built for millions of letters a day. The words you need (from my notes):

Word	Plain meaning
Event	One letter: "Order 1042 was placed", with a key, a value and a timestamp
Producer	The service that drops the letter (order service)
Topic	A named mailbox (`orders`, `payments`)
Partition	A mailbox split into slots so several people can empty it in parallel
Consumer / consumer group	The services that read; a group shares the slots between its copies
Broker	The Kafka server that stores and serves it all

2. Who gets hurt

Who	What they lose without a broker
Customers	Orders, bookings, messages silently dropped during a restart or spike
The business	Refunds, support tickets, "the site is unreliable" reviews
Developers on call	A failure in service A shows up as an error in service B, C and D. Root cause takes hours.
Architecture	Adding a new consumer (analytics, fraud check) means changing the producer again
Security / audit	No durable record of what happened in which order; replay after an incident is impossible

3. Cost and value

What it costs to run this lab (checked 2026-10-28):

Stack	Containers	RAM on my laptop	Licence
2023 lab (my old notes): ZooKeeper + Kafka + Confluent Control Center	3	several GB; Control Center alone is the heavy one	Control Center is Confluent's commercial UI (free only for a single-broker dev setup)
This post: Kafka 4.1 (KRaft) + AKHQ	2	about 1 GB	Apache 2.0 for both. Free.

Kafka 4.0 (March 2025) removed ZooKeeper for good; the broker now coordinates itself with KRaft. AKHQ is an open-source UI that does what most people used Control Center for: topics, messages, consumer groups, lag.

What it is worth: the inventory restart above costs 212 lost orders. With a broker, the same restart costs nothing; the orders wait 40 seconds in the topic. Even on a laptop, learning this pattern is the difference between "we lost data" and "we were a bit late".

Managed alternatives, when the lab becomes real: every cloud sells Kafka as a service (Azure Event Hubs has a Kafka-compatible endpoint, AWS MSK, Confluent Cloud). They start at a few dollars a day for the smallest tier and remove the operations work. The protocol is the same, so what you learn here carries over.

4. Build it: one Compose file

Folder kafka-lab/, file compose.yaml:

services:
  kafka:
    image: apache/kafka:4.1.0
    container_name: kafka
    ports:
      - "29092:29092"          # for clients on your laptop
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093,PLAINTEXT_HOST://:29092
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_NUM_PARTITIONS: 3
      KAFKA_LOG_DIRS: /var/lib/kafka/data
    volumes:
      - kafka-data:/var/lib/kafka/data

  akhq:
    image: tchiotludo/akhq:0.28.0
    container_name: akhq
    depends_on:
      - kafka
    ports:
      - "8080:8080"
    environment:
      AKHQ_CONFIGURATION: |
        akhq:
          connections:
            lab-kafka:
              properties:
                bootstrap.servers: "kafka:9092"

volumes:
  kafka-data:

Three things in that file matter more than the rest:

Two listeners. kafka:9092 is what containers (AKHQ) use. localhost:29092 is what your laptop uses. Get the advertised listener wrong and clients connect, then time out on the first message.
Fixed versions. 4.1.0 and 0.28.0, not latest. My notes already said this in 2023; it is still the number one cause of "it worked yesterday".
A named volume. Without kafka-data, every docker compose down deletes every topic. (See my Docker volumes post.)

Run it:

docker compose up -d
docker compose ps

Both containers show running. First run pulls about 500 MB. Open http://localhost:8080: AKHQ lists the lab-kafka cluster with one node.

Create the topic:

docker exec kafka /opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic orders --partitions 3 --replication-factor 1

5. Prove it works

Terminal 1, the consumer (the inventory service):

docker exec -it kafka /opt/kafka/bin/kafka-console-consumer.sh \
  --bootstrap-server localhost:9092 --topic orders --group inventory --from-beginning

Terminal 2, the producer (the order service):

docker exec -it kafka /opt/kafka/bin/kafka-console-producer.sh \
  --bootstrap-server localhost:9092 --topic orders --property parse.key=true --property key.separator=:

Type three orders, one per line: 1042:placed, 1043:placed, 1044:placed. They appear in terminal 1 at once.

Now the Friday-evening test: stop the consumer (Ctrl+C in terminal 1), type three more orders, wait 40 seconds, start the consumer again with the same --group inventory. The three orders arrive, in order. Nothing was lost; the group remembered where it stopped.

In AKHQ, Consumer Groups → inventory shows lag 3 while the consumer is down and 0 after it catches up. That number is the one you will put on a dashboard later.

Gotchas

Advertised listeners. localhost:29092 for the laptop, kafka:9092 inside Compose. Mix them up and you get "connected" followed by timeouts.
latest is not a version. Pin both images.
No volume, no data. docker compose down without the named volume wipes the topics.
Replication factor 1 is a lab setting. Three brokers and min.insync.replicas: 2 for anything real; my Kubernetes notes do that with Strimzi.
Same key, same partition. Use the order ID as the key so events for one order stay in order.
Port 8080 is popular. If AKHQ does not start, something else owns the port.
Low on RAM? Drop AKHQ and use kafka-topics.sh; the broker alone is enough to learn on.

Checklist

[ ] compose.yaml with pinned apache/kafka:4.1.0 and tchiotludo/akhq:0.28.0
[ ] Two listeners: internal kafka:9092, host localhost:29092
[ ] Named volume for /var/lib/kafka/data
[ ] docker compose ps: both running
[ ] Topic orders, 3 partitions, visible in AKHQ
[ ] Produce 3, consume 3
[ ] Stop consumer, produce 3, restart consumer: 3 arrive, lag back to 0

What changed recently

Checked on 2026-10-28:

My 2023 lab used ZooKeeper and Confluent Control Center. Kafka 4.0 (March 2025) removed ZooKeeper; the apache/kafka image runs KRaft by default. Control Center is replaced by AKHQ here (Apache 2.0, version 0.28.0, August 2026).
The current Apache Kafka release is 4.4; 4.1.0 is used because it matches my Kubernetes notes. Either works with this file.
The official apache/kafka image documents the KAFKA_* environment variables used above; the extra PLAINTEXT_HOST listener and the named volume are my additions.

Sources

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

The playbook that was supposed to block the account ran zero times

CD Security Lab — Mon, 09 Nov 2026 01:09:26 +0000

Source: CD's readiness notes Sentinel-Readiness/Analytics rule.md (the Automation / SOAR notes: lab 2 "5 failed logons in 20 minutes → incident, reset password, block user, email the manager", lab 3 "how to stop a rule firing for one analytics rule"), rebuilt as a lab story and cross-checked against Microsoft Learn on 2026-10-28. Lab names only; screens are drawings.

In the spring Contoso's SOC built the automation from my notes: five failed sign-ins to the Azure portal in twenty minutes → incident → playbook pb-block-user disables the account, resets the password and emails the manager. It was demoed to the CISO. It worked.

In October a contractor's account takes 1,400 password guesses in an hour, then one success. The incident is created at 23:12. The account is disabled at 00:05, by hand, by the on-call analyst who happened to look. The playbook's run history for the last five months: 0 runs.

Nothing was broken on the night. It had been broken since the person who built it left in June.

It happened for real: Midnight Blizzard and Microsoft, 2024

Password guessing is not a beginner's attack. In January 2024 Microsoft disclosed that a Russian state actor, Midnight Blizzard, got into its corporate email by guessing a password, slowly enough that a "five failures in twenty minutes" rule would never have fired.

What happened

Date	Event
Late November 2023	Midnight Blizzard runs a password spray against a legacy, non-production test tenant. One account has no MFA and falls.
Next step	The attackers find a legacy test OAuth application with elevated access to Microsoft's corporate tenant, create new OAuth apps and grant themselves the Exchange Online `full_access_as_app` role.
12 January 2024	Microsoft detects the attack.
19 January 2024	Microsoft discloses it: a very small percentage of corporate mailboxes were read, including senior leadership, cybersecurity and legal.
March 2024	Microsoft reports the actor used what it found to reach some source code repositories and internal systems, and that password sprays increased.
April 2024	The US cyber agency CISA issues Emergency Directive 24-02, telling federal agencies to check and reset credentials exposed in emails with Microsoft.

Why it worked

Door 1, low and slow guessing. Microsoft's guidance says the actor used a small number of attempts per account to avoid detection. A per-account brute-force rule, like the one in this post, does not see a spray: it sees one or two failures per user.
Door 2, a test account without MFA. Non-production does not mean unimportant when it can reach production.
Door 3, an old app with too much power. A test OAuth app nobody reviewed could grant mailbox access to the whole company.
Door 4, no automatic response. The attack was found weeks later. An automated "disable and revoke" on the first successful sign-in after a spray shortens that to minutes.

What it cost

Who	What they lost
Microsoft	Emails of senior leaders and security staff read; source code repositories accessed; an SEC filing and months of public updates
US federal agencies	An emergency directive to review every email exchanged with Microsoft and reset exposed credentials
Customers	Secrets shared with Microsoft by email had to be treated as exposed

The same doors in a Microsoft tenant

Door 4, no automatic response: this whole post. A playbook that actually runs, tested every Monday.
Door 1, the spray: add a second analytics rule that looks across accounts, not per account (query below), and use Entra ID Protection, which has its own Password spray risk detection.
Door 2, the test account: Conditional Access MFA for all users, in every tenant you own, test tenants included.
Door 3, the old app: review apps with application permissions to Exchange (full_access_as_app, EWS.AccessAsUser.All) and Graph, and remove what is not needed. Defender for Cloud Apps app governance flags over-privileged and unused apps.

// Password spray: one IP, many accounts, few attempts each (last 24 hours)
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50053")
| summarize Accounts = dcount(UserPrincipalName), Attempts = count(), FirstSeen = min(TimeGenerated) by IPAddress
| where Accounts >= 10
| order by Accounts desc

Point the same pb-block-user automation at this rule's incidents, with one change: block the sign-in for any account that later succeeds from the same IP, and revoke its sessions.

TL;DR

Problem: between "incident created" and "account disabled" there is a chain of six links: trigger, conditions, order, the permission Sentinel's own identity needs on the playbook, the playbook's connections, and the identity the playbook acts with. Each one fails silently, and the SOC only sees a playbook that "exists".
Who it hurts: the on-call analyst (manual response at midnight), the user whose account is abused for 53 minutes instead of 90 seconds, the CISO who was shown a demo, and the budget that paid for a SOAR nobody tested after June.
Fix: incident-trigger automation rules (not playbooks attached to analytics rules, deprecated March 2026), Manage playbook permissions so the Sentinel service account holds Microsoft Sentinel Automation Contributor on the playbook's resource group, managed identity instead of a person's connection, and a weekly test incident that must produce a run.
Cost: the playbook costs cents: about $0.0005 per run on Logic Apps Consumption, under $1 a month for a busy lab. The 53 minutes cost more.
Prove it: a test incident produces a green run within two minutes; the test account shows Account enabled: No in Entra; the run history is checked every Monday.

It happened for real: Midnight Blizzard and Microsoft, 2024
1. The problem
2. Who gets hurt
3. Cost and value
4. How to fix it
5. Prove it
Gotchas
Checklist
What changed recently
Sources
News sources

1. The problem

A fire alarm wired to a sprinkler. The alarm rings; the sprinkler needs the valve open, the pipe connected, the pump powered and the pump's key in it. Any one missing, and the alarm rings over a dry room. Nobody tests the sprinkler, because the alarm is loud and that feels like testing.

In Sentinel the chain is:

Link	What it is	How it failed in the lab
1. Trigger	Automation rule on When incident is created (or updated, or alert created)	The playbook was attached to the analytics rule (alert trigger). That path is deprecated as of March 2026 and never fired for the incident that mattered, which came in via Defender XDR.
2. Conditions	Analytics rule name contains "Failed logons"	The rule was renamed "Brute force: Azure portal" in July. Condition never true again.
3. Order	Rules run in order, each sees the previous rule's result	Order 1: "Auto-close pentest incidents" (left from a pentest, no expiry) closed it. Order 2 saw a closed incident; condition Status equals New failed.
4. Sentinel's own permission	The Sentinel service account needs Microsoft Sentinel Automation Contributor on the playbook's resource group	Playbook moved to `rg-soar` in June. Nobody re-granted. In the rule the playbook shows greyed out.
5. Connections	The playbook's Office 365 / Entra connections	Authorised with the builder's account. Builder left in June; token revoked; every run would have failed with 401.
6. Acting identity	Who disables the account	The Logic App's managed identity never got User.EnableDisableAccount.All on Graph; the demo had run under the builder's delegated rights.

2. Who gets hurt

Who	What they lose
On-call analyst	A midnight manual response for something a machine was paid to do
The user / the company	53 minutes of a valid session in the attacker's hands instead of 90 seconds
CISO	A control that was demoed, reported as "automated", and did nothing for five months
Budget	SOAR licensed (Sentinel), Logic Apps provisioned, analyst hours still spent
The product	"Sentinel automation is unreliable", when every link that failed was a configuration nobody re-tested

3. Cost and value

Checked 2026-10-28, USD list, pay-as-you-go. Logic Apps per-execution prices are not readable from Microsoft's static pricing page; the figures below are the published Consumption rates quoted across Microsoft partner material in 2026. Confirm in the pricing calculator.

What the playbook costs to run (Consumption):

Item	Rate	`pb-block-user` per run
Built-in actions (conditions, compose, HTTP to Graph)	about $0.000025 each	8 actions = $0.0002
Standard connector calls (Office 365 mail, Sentinel comment)	about $0.000125 each	3 calls = $0.000375
Per run		about $0.0006
500 incidents a month		about $0.30

The first thousands of built-in actions per subscription per month are free. A Standard plan (WS1, 1 vCPU / 3.5 GB) is about $175 a month for unlimited built-in actions, worth it only when you run dozens of playbooks at volume or need VNet integration.

What the failure cost:

Item	Lab estimate
Manual response, 53 minutes, one analyst at night	small in money, large in exposure
Five months of "automated" in the compliance report	a finding
Re-building trust in automation	the real cost

Value of the fix: the same playbook, correctly wired, disables the account in about 90 seconds from incident creation, for less than a dollar a month. Response time goes from "whenever someone looks" to a number you can put in a report.

How others do it: Palo Alto XSOAR and Splunk SOAR are quote-based per user or per action; Tines publishes a free Community Edition and per-story tiers. All of them have the same six links; none of them tests your connections for you.

4. How to fix it

Lab: workspace law-contoso-sec, playbooks in rg-soar, analytics rule Brute force: Azure portal (Scheduled, 5 failed sign-ins in 20 minutes).

Step 1: incident trigger, not analytics-rule attachment. Automation → Create → Automation rule. Trigger When incident is created. If the workspace is onboarded to the Defender portal, this is the only incident-creation trigger that exists; alert-triggered automation for Defender XDR alerts is not available there.

Step 2: conditions that survive a rename. Use Analytics rule name contains "Brute force", or better, tag the analytics rule's incidents and condition on Tags contains "auto-block". Mind the tag semantics: any individual tag versus collection of all tags evaluate "does not contain" differently.

Step 3: order and expiry. Give the blocking rule order 1. Give every "auto-close" rule an expiration date; the pentest rule from the story should have died with the pentest.

Step 4: Sentinel's own permission. In the rule, Actions → Run playbook. If pb-block-user is greyed out, select Manage playbook permissions, tick rg-soar, Apply. You need Owner on rg-soar to do this; it grants the Sentinel service account Microsoft Sentinel Automation Contributor there. Any automation rule can then run any playbook in that resource group.

Step 5: no person in the playbook. Logic App → Identity → System-assigned: On. Grant it:

Microsoft Sentinel Responder on the workspace resource group (to update the incident).
Graph application permissions User.EnableDisableAccount.All and User.ReadWrite.All (admin consent) for the HTTP action that disables the account:

# grant Graph app roles to the Logic App's managed identity
$mi    = Get-MgServicePrincipal -Filter "displayName eq 'pb-block-user'"
$graph = Get-MgServicePrincipal -Filter "displayName eq 'Microsoft Graph'"
foreach ($perm in 'User.EnableDisableAccount.All','User.ReadWrite.All') {
  $role = $graph.AppRoles | Where-Object { $_.Value -eq $perm -and $_.AllowedMemberTypes -contains 'Application' }
  New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $mi.Id -PrincipalId $mi.Id -ResourceId $graph.Id -AppRoleId $role.Id
}

The HTTP action: PATCH https://graph.microsoft.com/v1.0/users/{upn} with body {"accountEnabled": false}, authentication Managed identity, audience https://graph.microsoft.com. The Office 365 connection for the manager email: a shared mailbox soc-noreply@contoso.com, not an analyst's account; the Microsoft Sentinel connector: managed identity.

Step 6: a test that runs every Monday. A scheduled analytics rule, 06:00 Monday, that raises a Low incident tagged auto-block-test for lab.test01@contoso.com. The automation rule disables that account; a second automation rule (order 2) re-enables it and closes the incident. If Monday's run history is not green, someone is paged, on a Monday morning, not at midnight.

5. Prove it

Create a test incident (or wait for Monday's): the Runs tab on the incident shows pb-block-user Succeeded within about two minutes.
Entra ID → lab.test01@contoso.com → Account enabled: No; AuditLogs | where OperationName == "Disable account" shows the Logic App's identity as the actor.
The incident has a comment from the playbook and the manager's mailbox has the email, sent from soc-noreply.
Run history for the last 30 days: zero Failed, zero Unauthorized in any Office 365 or Sentinel action.

// playbooks that never ran: incidents the rule matched vs runs on them
SecurityIncident
| where TimeGenerated > ago(30d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Title startswith "Brute force"
| summarize incidents = count(), with_comment = countif(tostring(Comments) contains "pb-block-user")

Gotchas

Greyed-out playbook = permission, not a bug. The list greys out playbooks in resource groups where the Sentinel service account has no role. Fix it in the panel; do not move the playbook.
Playbooks on analytics rules are deprecated (March 2026). Migrate them to automation rules with Microsoft's migration guidance; the old attachments will stop working.
Alert trigger only for Scheduled / NRT (and Microsoft security) rules. Incidents from Defender XDR need the incident trigger.
Connections belong to people by default. Any connector authorised with "Sign in" carries that person's token. Use managed identity where the connector supports it, a service mailbox where it does not.
Defender portal batching. Several updates to one incident within 5 to 10 minutes reach Sentinel as the last one only; update-trigger rules see fewer events than you expect.
Order collisions. Two rules with the same order run in random sequence. Give every rule a unique number.
Expiry is a feature. Any rule created for a test or a pentest gets an expiration date on day one.
Retries are billed. An action with five retries is six executions. A playbook stuck retrying a dead connection is the one that costs money.

Checklist

[ ] Every playbook is called from an automation rule, none from an analytics rule
[ ] Conditions use tags or stable names; a rename cannot silence them
[ ] Unique order numbers; auto-close rules have an expiry
[ ] Sentinel service account has Automation Contributor on every playbook resource group
[ ] Playbooks run as managed identity; no personal connections
[ ] Graph / Sentinel roles granted to the identity and recorded
[ ] Weekly synthetic incident proves the chain end to end
[ ] Run history reviewed; any Failed run is a ticket

What changed recently

Checked against Microsoft Learn on 2026-10-28:

My notes (2024) attach playbooks to analytics rules as one of two options. Learn now states that calling playbooks from analytics rules is deprecated as of March 2026 and should be migrated to automation rules (run-playbooks page updated 2026-07-01).
The permission model is unchanged but better named: the Sentinel service account needs Microsoft Sentinel Automation Contributor on the playbook's resource group; the UI step is Manage playbook permissions and requires Owner on that resource group (automation rules page updated 2026-05-11).
Defender-portal specifics are new since my notes: incident-created trigger only there, no alert trigger for Defender XDR alerts, 5 to 10 minute batching of incident updates, and "Simple flows" (preview) with case triggers.
Update-trigger conditions gained state-change operators (changed from / changed to / added) and the tag any-vs-collection distinction.
Logic Apps billing (page updated 2026-07-10): triggers are billed per execution even when skipped, retries and loop iterations count, disabled logic apps are free.

Sources

News sources

Microsoft Security Response Center, "Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard" (19 January 2024): https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/
Microsoft Security Blog, "Midnight Blizzard: Guidance for responders on nation-state attack" (25 January 2024): https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/
CISA, Emergency Directive 24-02 (April 2024): https://www.cisa.gov/news-events/directives/ed-24-02-mitigating-significant-risk-nation-state-compromise-microsoft-corporate-email-system

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

Defender Says "Not Onboarded"? 4 Reasons Your Devices Aren't Protected

CD Security Lab — Sun, 08 Nov 2026 01:10:07 +0000

In my lab, Defender was paid for on 50 devices, but 20 of them were not protected and no alert said so. I read the device inventory, count every onboarding and sensor state with one KQL query, and walk through the four causes I found: the Intune EDR policy assigned to the wrong group, a proxy that blocks the sensor's WinHTTP traffic, devices onboarded to another tenant (check the OrgId), and servers outside Azure that need Azure Arc plus Defender for Servers. Result: from 60% to 98% of devices protected.

What the video covers

20 of 50 devices not protected (0:00)
4 causes (0:09)
Who gets hurt (0:15)
Read the device inventory (0:29)
KQL 1: count every state (0:50)
Cause 1: the package never arrived (1:01)
Cause 2: the proxy blocks the sensor (1:19)
Cause 3: onboarded to the wrong tenant (1:38)
Cause 4: servers outside Azure (2:00)
KQL 2: onboarded but not Active (2:18)
Inactive is not always broken (2:27)
The result: 60% to 98% (2:41)
The checklist (2:56)

Every command from the video

// KQL 1: every onboarding and sensor state (Advanced hunting)
DeviceInfo
| where Timestamp between (ago(30d) .. now())
| summarize arg_max(Timestamp, *) by DeviceId
| summarize Devices = dcount(DeviceId) by OnboardingStatus, SensorHealthState

// KQL 2: onboarded but not Active (your to-do list)
DeviceInfo
| where Timestamp between (ago(30d) .. now())
| summarize arg_max(Timestamp, *) by DeviceId
| where OnboardingStatus == "Onboarded" and SensorHealthState != "Active"
| project DeviceName, OSPlatform, SensorHealthState, Timestamp

// On the device: WinHTTP proxy the sensor uses
netsh winhttp show proxy

// On the device (PowerShell): Sense service and which tenant it reports to
Get-Service -Name Sense
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" | Select-Object OnboardingState, OrgId

Sources (Microsoft Learn, checked 2026-11-01)

Fix unhealthy sensors: https://learn.microsoft.com/en-us/defender-endpoint/fix-unhealthy-sensors
Device inventory field reference: https://learn.microsoft.com/en-us/defender-endpoint/device-inventory-field-reference
DeviceInfo table: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-deviceinfo-table
Troubleshoot onboarding: https://learn.microsoft.com/en-us/defender-endpoint/troubleshoot-onboarding
Defender for Endpoint integration in Defender for Cloud: https://learn.microsoft.com/en-us/azure/defender-for-cloud/integration-defender-for-endpoint

Lab names and made-up numbers only (contoso.com, LAB-WIN11-xx).

What percent of your devices are really Active? Run KQL 1 and tell me in the comments, or watch the full video here: https://youtu.be/15fH5RftAYA

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

SC-500 deep dive #1: your Contributors can read your Key Vault secrets

CD Security Lab — Sat, 07 Nov 2026 01:15:05 +0000

Every Thursday I post SC-500 practice questions. Every Saturday, from this week, I take one exam topic and go deep: the real problem, how it works, the fix, and the exam traps. Week 1: who can really read the secrets in Azure Key Vault.

Lab story, lab names only (contoso.com). Screens are drawings, numbers are invented.

The problem: a "deploy-only" account that read 41 secrets

In my lab, Contoso gave a contractor account, lab.contractor02, the Contributor role on the resource group rg-lab-payments. The reason was simple: "they need to fix a deployment, nothing else". Contributor cannot give roles to anyone, so it felt safe.

Two weeks later a review of the vault kv-lab-pay-01 found something nobody had added:

a new access policy for lab.contractor02, with Get and List on secrets
created by lab.contractor02 itself
41 secrets readable, including the payment API key and the SQL connection string

No alarm fired. Nothing was "hacked". The vault simply used the old permission model, and in that model, Contributor is enough to give yourself the keys.

How it works: two permission models, one vault

A key vault has two layers:

Layer	What it controls	Example
Management plane	The vault as an Azure resource	create, delete, change network rules, change the permission model
Data plane	What is inside	read a secret, sign with a key, import a certificate

For the data plane, a vault uses one of two models:

Vault access policy (legacy). The permission list lives inside the vault, as a vault property. Anyone who can write the vault can edit that list. Microsoft's built-in roles page says it plainly: Contributor, Key Vault Contributor, or any role with Microsoft.KeyVault/vaults/write can add an access policy and give themselves data plane access.
Azure RBAC (recommended). Data access is a normal role assignment, such as Key Vault Secrets User. Only roles that can write role assignments can grant it, such as Owner or User Access Administrator. Contributor and Key Vault Contributor manage the vault but cannot read secrets.

So the same role, Contributor, means "manage the vault" in one model and "manage the vault and read every secret" in the other.

Why it matters right now

Microsoft is making RBAC the default:

With Key Vault API version 2026-02-01 or later, a new vault uses Azure RBAC by default. If you still want access policies, you must set enableRbacAuthorization to false when you create it.
Existing vaults do not change. A vault created with an older API version keeps using access policies until you switch it.
All Key Vault control plane API versions before 2026-02-01 retire on 27 February 2027. Azure CLI 2.90.0 and Azure PowerShell 16.3.0 (or later) support the new version.

The trap: a team creates a new vault with the new CLI, their app gets 403 Forbidden because it has no role, and someone "fixes" it by switching the vault back to access policies. Now the problem from my lab is back.

The fix: find, map, switch, lock

1. Find every vault still on access policies

Azure Resource Graph, across all subscriptions you can see:

resources
| where type == "microsoft.keyvault/vaults"
| extend rbac = tobool(properties.enableRbacAuthorization)
| where isnull(rbac) or rbac == false
| project name, resourceGroup, subscriptionId, policies = array_length(properties.accessPolicies)

In my lab: 9 vaults, 3 still on access policies.

2. List who is in each access policy today

az keyvault show --name kv-lab-pay-01 --query "properties.accessPolicies[].{objectId:objectId, secrets:join(',', permissions.secrets)}" -o table

Remove anyone who should not be there (in my lab: lab.contractor02). Then write down what each real user or app needs.

3. Give the same access with RBAC roles, before you switch

Map each access policy to the smallest built-in role:

Access policy today	RBAC role
Secrets: Get, List (an app reads secrets)	Key Vault Secrets User
Secrets: all (a team manages secrets)	Key Vault Secrets Officer
Keys: Get, Wrap, Unwrap (encryption at rest)	Key Vault Crypto Service Encryption User
Everything (vault admins)	Key Vault Administrator
Reads names only, not values	Key Vault Reader

Assign at the vault scope, not the resource group:

KV_ID=$(az keyvault show --name kv-lab-pay-01 --query id -o tsv)
az role assignment create --role "Key Vault Secrets User" --assignee "$APP_ID" --scope "$KV_ID"

For people, make the role eligible in Privileged Identity Management instead of permanent. PIM works with RBAC roles. It does not work with access policies.

4. Switch the vault to RBAC

az keyvault update --name kv-lab-pay-01 --enable-rbac-authorization true

The moment you switch, all access policies stop working. That is why step 3 comes first. Role assignments can take a few minutes to apply, so switch in a quiet hour and test the app right after.

5. Lock it so it cannot come back

Assign the built-in Azure Policy "Azure Key Vault should use RBAC permission model" at the management group, first in Audit, then Deny.
Watch for changes. In Microsoft Sentinel (Azure Activity connector):

AzureActivity
| where OperationNameValue in~ ("MICROSOFT.KEYVAULT/VAULTS/ACCESSPOLICIES/WRITE", "MICROSOFT.KEYVAULT/VAULTS/WRITE")
| project TimeGenerated, Caller, ResourceGroup, _ResourceId, ActivityStatusValue
| order by TimeGenerated desc

An access policy write on any vault after the switch is either a mistake or someone trying the old trick. Both deserve a ticket.

SC-500 exam traps

Key Vault permission questions were a classic in AZ-500 and they are still in scope for SC-500. Watch for these:

"The user has Contributor. Can they read the secret?" The answer depends on the permission model. Access policy vault: they can give themselves access. RBAC vault: no.
"Key Vault Contributor" sounds like data access. It is not. It manages the vault resource only.
"Grant the least privilege for an app that reads one secret." Key Vault Secrets User, scoped to the vault (or to that one secret), not Key Vault Administrator, not Contributor.
"You switch the vault to RBAC. What happens to existing access policies?" They stop applying. Assign roles first.
"Who can grant data access on an RBAC vault?" Roles with role assignment write permission, such as Owner and User Access Administrator. Not Contributor.

Before and after in my lab

	Before	After
Vaults on access policies	3 of 9	0 of 9
People who could read payment secrets	7 (incl. the contractor)	2 eligible admins + 1 app
Access policy changes alerted	No	Yes, Sentinel rule
New vaults with access policies	Allowed	Denied by Azure Policy

Coming next

Next deep dive: managed identities, and why "no secrets at all" beats "secrets in a well-locked vault". On Thursday: SC-500 practice questions, as usual.

Sources

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

The uploads vanished when the pod restarted. Kubernetes networking and storage: what actually breaks

CD Security Lab — Fri, 06 Nov 2026 01:09:48 +0000

Sources: CD's devops wiki 03-kubernetes/03-network-fundamentals.md, 04-storage-fundamentals.md and 07-lab-storage-nfs.md, cross-checked against kubernetes.io, Calico docs and cloud storage price lists on 2026-10-28. Lab names only; screens are drawings.

Two tickets, one week, same cluster.

Monday. Contoso's support portal lets customers attach files to tickets. A routine deploy rolls the pods. Every attachment uploaded in the previous 9 days is gone: 1,240 files. The app wrote them to a folder inside the container. The folder died with the pod, exactly as designed.

Thursday. The orders API stops answering. Nothing was deployed. A node was drained for patching, the API pod moved to another node and got a new IP. The web tier had that IP in a config file, copied from kubectl get pods -o wide three months earlier because "the Service thing was confusing".

Neither is a Kubernetes bug. Both are the two parts of Kubernetes that behave nothing like a VM: the network and the disk.

TL;DR

Problem: pods are disposable. Their IP and their local disk are disposable with them. Anything that remembers a pod IP or writes to a pod's filesystem will lose data or connectivity on the next restart, drain or deploy.
Who it hurts: customers (lost files, broken checkout), support and legal (data you promised to keep is gone), the on-call engineer (outages with no deploy and no error), security (a flat network where every pod can reach the database).
Fix: talk to Services by DNS name, never pod IPs; write data to a PersistentVolumeClaim, never the container; add a default-deny NetworkPolicy so "every pod can talk to every pod" stops being the default.
Cost: a 128 GiB persistent disk is about $10 to $20 a month in Azure or AWS; an NFS share on a VM you already have is free. The 1,240 lost files cost two days and a customer apology.
Prove it: delete the pod. Files still there, DNS still answers, the blocked connection still times out.

1. The problem
2. Who gets hurt
3. Cost and value
4. Networking: the three things to know
5. Storage: the three things to know
6. Prove it
Gotchas
Checklist
What changed recently
Sources

1. The problem

On a VM, the IP address and the disk are the two most permanent things about the machine. In Kubernetes they are the two least permanent. That inversion is where most first-year incidents come from.

On a VM	In Kubernetes	What breaks if you forget
The IP lasts for years	Every pod gets its own IP; it changes on every restart or move	Hard-coded IPs, allowlists of pod IPs, "ping the pod" runbooks
The disk is the machine	The container filesystem is thrown away with the pod	Uploads, SQLite files, logs, anything written "locally"
A firewall sits between servers	All pods can reach all pods, no NAT, by default	Any compromised pod can reach the database
Storage is attached by an admin	Storage is requested by a claim and bound by the cluster	Pods stuck in `Pending` because no volume matched

The real world has the same shape. AdGuard VPN's public post-mortem (incident 2025-12-02) describes a Redis StatefulSet recreated on Kubernetes to fix a disk-size drift; the controller restarted the whole cluster at once, there were no startup or readiness probes to slow it down, and the service was down for about 50 minutes. The disk resize was fine. The parts that behave differently from a VM were not understood.

2. Who gets hurt

Who	What they lose
Customers	Files they uploaded, carts they built, sessions that vanish on every deploy
Support / legal	"We keep your attachments" was a promise. 1,240 of them are gone, with no backup because "the disk is on the server"
On-call engineer	Outages with no deploy and no error log: a node drain, a pod reschedule, a new IP
Security	A flat network. The web pod can open a connection to the database pod. So can the compromised one
Finance	Premium disks attached to pods that write 2 MB a day, because nobody chose a StorageClass

3. Cost and value

What persistent storage costs (list prices, checked 2026-10-28):

Option	Price	Fits
Azure Standard HDD S10, 128 GiB	$5.89 a month	Backups, cold files
Azure Standard SSD E10, 128 GiB	$9.60 a month	Uploads, small databases (this post)
Azure Premium SSD P10, 128 GiB	$19.71 a month (East US)	Databases that need IOPS
AWS EBS gp3	$0.08 per GB-month, so 128 GB is about $10.24; 3,000 IOPS included	Same as E10 on AWS
NFS share on a VM you already run (my lab)	$0 extra	Shared RWX storage for a few pods, labs, small teams
minikube default StorageClass `standard`	$0	Learning only: hostPath on the minikube node

What the incidents cost: the Monday ticket was 1,240 files, two days of engineering to confirm they were unrecoverable, and an apology email. The Thursday ticket was 35 minutes of failed orders. A $9.60 disk and a DNS name would have prevented both.

What networking costs: nothing. Services, CoreDNS and NetworkPolicy are in the cluster already. The only paid item is a cloud load balancer when you use type: LoadBalancer (roughly $18 to $25 a month per public IP on the big clouds), which is why the Gateway API with one shared load balancer is the cheaper way to expose many apps.

4. Networking: the three things to know

From my networking notes, in the order they bite:

1. Every pod has an IP, and all pods can reach each other without NAT. The CNI plugin (Calico, Flannel, Cilium) hands out the IPs and routes between nodes. That IP is not yours to keep. Never write it down.

2. A Service is the name you keep. It gets a stable ClusterIP and, through CoreDNS, a stable name: orders-api.contoso-shop.svc.cluster.local (or just orders-api from the same namespace). kube-proxy rewrites traffic to whichever pods match the selector right now.

Service type	Reachable from	Use
`ClusterIP` (default)	Inside the cluster	Everything internal: web → api → db
`NodePort`	`<node IP>:30000-32767`	Labs, or behind your own load balancer (my kubeadm lab used an external NGINX in front of three NodePorts)
`LoadBalancer`	A cloud load balancer with a public IP	One app, one public entry point; costs money per IP
Ingress / Gateway	HTTP by host name and path	Many apps behind one load balancer. Ingress NGINX is retired; use the Gateway API or a maintained controller

3. Flat is the default; you must say no. Kubernetes ships with no network restrictions. A NetworkPolicy with an empty podSelector and no rules is the "deny everything in this namespace" switch. It only works if the CNI enforces policies: Calico and Cilium do, Flannel and minikube's default bridge do not (start minikube with --cni=calico).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: contoso-shop
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: contoso-shop
spec:
  podSelector:
    matchLabels: { app: db }
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: orders-api }
      ports:
        - port: 27017

(You also need an egress rule for DNS to kube-system, or nothing resolves. See Gotchas.)

5. Storage: the three things to know

1. emptyDir and the container filesystem die with the pod. They are for cache and scratch. Monday's uploads were in the container filesystem.

2. A PersistentVolumeClaim is how a pod asks for a disk that outlives it. The claim names a size, an access mode and a StorageClass; the cluster binds it to a PersistentVolume, either one an admin created or one the StorageClass provisions on demand.

Piece	Who creates it	Analogy
StorageClass	Admin, once	The catalogue: "standard SSD", "premium", "nfs"
PersistentVolume (PV)	Admin by hand, or the StorageClass automatically	The actual disk
PersistentVolumeClaim (PVC)	The app team, in the namespace	The order form: "10 GiB, ReadWriteMany, class nfs-storage"
Pod `volumes` + `volumeMounts`	The app team	Plugging the disk into the pod at a path

3. Access modes decide how many pods can share it. ReadWriteOnce (one node, the normal cloud disk), ReadOnlyMany, ReadWriteMany (many nodes at once; NFS, Azure Files, EFS). Uploads served by three web pods on three nodes need RWX.

My lab does RWX with an NFS server on the database VM (nfs-lab-01), exported as /data, with nfs-common on every node:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-uploads-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes: [ReadWriteMany]
  persistentVolumeReclaimPolicy: Retain      # PVC deleted -> data kept
  storageClassName: nfs-storage
  nfs:
    server: nfs-lab-01.contoso.com
    path: /data/uploads
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uploads
  namespace: contoso-shop
spec:
  accessModes: [ReadWriteMany]
  storageClassName: nfs-storage
  resources:
    requests:
      storage: 5Gi

And in the Deployment from last week's post, two additions:

      containers:
        - name: web
          volumeMounts:
            - name: uploads
              mountPath: /app/uploads
      volumes:
        - name: uploads
          persistentVolumeClaim:
            claimName: uploads

On minikube without NFS, delete storageClassName and the PV; the built-in standard class provisions a hostPath volume for the claim (RWO only, fine for the test).

6. Prove it

kubectl get pv,pvc -n contoso-shop              # STATUS Bound on both
kubectl exec -n contoso-shop deploy/web -- sh -c 'echo hello > /app/uploads/test.txt; ls /app/uploads | wc -l'
kubectl delete pod -n contoso-shop -l app=web   # all three
kubectl exec -n contoso-shop deploy/web -- ls /app/uploads | wc -l      # same number

Networking, from a throwaway pod:

kubectl run probe -n contoso-shop --rm -it --image=busybox:1.36 -- sh
# inside:
wget -qO- http://orders-api:8080/health      # by name: ok
wget -qO- http://orders-api.contoso-shop.svc.cluster.local:8080/health
nc -zv db 27017                              # with default-deny + allow-api-to-db: times out from "probe"

Then label the probe pod app=orders-api and the same nc succeeds. That is the whole proof that the policy is enforced and not silently ignored.

Gotchas

Default deny also blocks DNS. Add an egress rule to kube-system on UDP/TCP 53, or every name lookup fails and it looks like the network is down.
NetworkPolicy with no enforcing CNI is a comment. kubectl apply succeeds, nothing happens. Test it (section 6) before trusting it.
RWO means one node, not one pod. Three replicas on three nodes with an RWO claim: two of them stay Pending forever. Use RWX (NFS, Azure Files, EFS) or a StatefulSet with one claim per pod.
Reclaim policy. Dynamically provisioned volumes default to Delete: delete the PVC and the disk is gone. Set Retain on anything you care about.
A PVC can only grow. And only if the StorageClass has allowVolumeExpansion: true. The AdGuard incident started here: the StatefulSet template could not be edited in place.
hostPath is for one-node labs. It pins the pod to one node and gives the container the node's disk. Never in production.
NodePort is not a public endpoint. It is a port on every node. Put a load balancer or a Gateway in front.
service/web has a name per namespace. web from contoso-shop is web.contoso-shop.svc.cluster.local from anywhere else.

Checklist

[ ] No pod IP in any config file, allowlist or runbook; Services by DNS name only
[ ] default-deny NetworkPolicy per namespace + explicit allow rules + DNS egress; CNI confirmed to enforce
[ ] Every path the app writes to is a PVC mount (or emptyDir on purpose, for cache only)
[ ] StorageClass chosen on purpose: standard SSD for uploads, premium for databases, RWX where many pods write
[ ] persistentVolumeReclaimPolicy: Retain and allowVolumeExpansion: true where it matters
[ ] Backup of the PV, because a volume is not a backup
[ ] Section 6 run after every cluster upgrade: files survive, DNS answers, the blocked port times out

What changed recently

Checked on 2026-10-28:

My notes list Calico, Flannel and Cilium as CNIs; that is still the list, and still only Calico and Cilium enforce NetworkPolicy by default. The kubeadm lab in my notes used Calico 3.27; current releases are 3.30+ and the manifest URL pattern is unchanged.
Ingress NGINX retired in March 2026 (Kubernetes blog statement 2026-01-29; no further security fixes). The "External to cluster" row in my notes now reads: NodePort or LoadBalancer, fronted by the Gateway API (v1.6, June 2026) or a maintained Ingress controller.
Storage prices (Azure Retail Prices API via a 2026-10 third-party guide, AWS EBS pricing page): E10 $9.60, P10 $19.71, gp3 $0.08/GB-month. Azure's own pricing page renders client-side; worth confirming in the pricing calculator.
AdGuard VPN post-mortem (published 2025-12-10) is the clearest recent public example of StatefulSet storage drift causing an outage; it is linked below.

Sources

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

The $6.34B Binance Hack Started With a Job Interview: The Full Chain and 4 Microsoft Locks

CD Security Lab — Thu, 05 Nov 2026 02:58:03 +0000

On 29 October 2026, about $6.34 billion in assets was hit at Binance. On 3 November, Binance published its initial findings. The story is not about broken encryption or a stolen private key. Attackers made a legitimate system do an illegitimate thing.

This article walks through what happened in plain words, explains the five terms you need, and then maps every step to a Microsoft control I rebuilt in my contoso.com lab.

The Microsoft part is a defensive model, not a claim that Binance uses Microsoft or would have been saved by it. No tool catches everything. Layers do.

What happened, in one paragraph

A fake recruiter gave an engineer a coding test. The test hid malware. From that laptop the attackers reached two more engineers, found a token that could deploy containers, used it to run their own code inside Binance, and that code made Binance's own hot wallets send funds out.

Who got hurt and what it cost

The exchange: about $6.34B in assets affected. About $2.85B was frozen or intercepted. Binance says 98% of affected tokens were replenished from company funds by 31 October.
Users: Binance says customer balances are covered. Most companies could not absorb a loss like this.
The security team: funds left between 20:05 and 23:56 UTC. The bad delegation was cleared at 00:10 UTC on 30 October. That is almost four hours, not "minutes" as early reports said.
Attribution: the FBI attributed the attack to North Korea.

5 terms in plain words

Term	Plain meaning
Hot wallet	The cash drawer. Online so withdrawals are fast. Cold wallets are the offline safe.
Signing service	The clerk with the stamp. A request that passes the checks gets signed.
Token	A concert wristband you get after sign-in and MFA. Whoever wears it gets in.
MPC	Multi-party computation. The key is split into shares that sign together. No single key to steal, and no single key to revoke fast.
EIP-7702	An Ethereum feature that lets a wallet delegate execution to a smart contract. If the attacker owns that contract, money moves without the key.

Step 1: the laptop (June and September)

In June, a wallet engineer installed a tampered Homebrew package while looking for an AI coding tool. Binance caught it and replaced the device, but the attackers had already mapped the team. In September, Engineer B was contacted on a real job site, did two video interviews, and downloaded a coding test to a work laptop. The repo replaced a legitimate pyenv file with a malicious one and contacted the attackers' server. Binance says it was zero-day malware that endpoint security did not flag.

Lock 1: a rule, then Defender for Endpoint

Strangers' code never runs on a work laptop. Use a throwaway VM with no real credentials.
Defender for Endpoint looks at behavior chains, not only signatures: editor, then shell, then download, then file swap, then an unknown server.
Attack disruption can contain a device once an attack is recognized. It does not guarantee a zero-day is caught. That is why the next locks exist.

Step 2: moving sideways (20 October)

From Engineer B's laptop and an internal AI tool, the attackers reached Engineers A and C. Binance has not explained how the AI tool was used. Engineer A's machine held a container deployment token.

Lock 2: Conditional Access, Token Protection, PIM

Conditional Access: privileged users only from compliant, company-managed devices.
Token Protection: binds supported sign-in sessions to one device, so a copied token fails elsewhere. It covers supported apps and platforms, not every API token.
Privileged Identity Management: nobody holds deploy rights all day. Activate for an hour, with a reason and, if needed, an approval.

Step 3: a container gets the right to act for a wallet (29 October)

From Engineer C's machine, using Engineer A's credentials, the attackers deployed a container and ran a script. Using EIP-7702, an attacker contract gained execution rights over a hot wallet. Pausing withdrawals did not stop it, and with MPC there was no single key to revoke.

Lock 3: protect who can ask the key to sign

Keys or key shares in Key Vault or Managed HSM where the architecture fits. Key Vault is not a drop-in replacement for an MPC wallet.
Only one managed identity may call sign. RBAC, not shared secrets.
The application checks what it signs: a new delegation, a new destination or a large amount needs an independent second approval. PIM approves role activation, not individual blockchain transactions.

Step 4: almost four hours of outflow

Funds left from 20:05 UTC (XRP first, then SOL, OP and BTC). The last transfer settled at 23:56.

Lock 4: Sentinel detection plus a tested response

Send the signing service's audit logs to Log Analytics and Microsoft Sentinel.
Alert on a new delegation, a new destination or an unusual total value, not only on a count.
A Logic Apps playbook opens the incident, notifies the SOC in Teams, revokes the deploy token and calls the wallet team's own API to pause signing. Sentinel cannot freeze a blockchain wallet by itself. You build that hook and you test it.

"But the engineer had those rights anyway. Why couldn't he do it?"

This is the most dangerous point of the whole case, so it deserves its own section.

Engineer A could deploy containers, call internal APIs and reach the signing service. He was given those rights to do his job. The attackers did not need his skills or his role. They needed his session. To the system it looked like this:

User:        Engineer A
Token:       valid
Permission:  authorized
Result:      access granted

Nothing in that check asks who is at the keyboard or why.

Legitimate engineer	Attacker with the same rights
Was granted access	Stole access
Follows the process	Abuses the process
Creates valid requests	Creates malicious requests that look valid
Goal: ship software	Goal: move assets

Knowing how to use a system is not the same as knowing how to exploit it. A DevOps engineer can deploy an app and still have no idea how the hot-wallet signing flow or EIP-7702 delegation works. The attacker's skill was chaining three laptops, one deploy token and one blockchain feature into a theft. A bank teller can reach the transfer system; that does not mean the teller knows how to bypass every control to move billions.

Could an insider have helped? Investigators cannot exclude it, and only evidence settles it: external attack, insider threat, or collusion. A hijacked account is not proof that its owner took part.

One line to keep:

Authentication proves who you are. Authorization decides what you may do. Neither proves that what you do is legitimate.

That gap is exactly why behavior monitoring, process controls and an independent approval exist on top of MFA and antivirus.

Check your own tenant (contoso lab queries)

// 1. Admins signing in from devices that are not compliant (14 days)
SigninLogs
| where TimeGenerated between (ago(14d) .. now())
| where ResultType == "0"
| where UserPrincipalName in~ ("admin1@contoso.com", "devops1@contoso.com")
| extend Compliant = tostring(DeviceDetail.isCompliant), Device = tostring(DeviceDetail.displayName)
| where Compliant != "true"
| summarize SignIns = count() by UserPrincipalName, Device

// 2. Code editor starts a shell that reaches the internet
DeviceProcessEvents
| where TimeGenerated between (ago(7d) .. now())
| where InitiatingProcessFileName in~ ("code.exe", "code", "electron")
| where FileName in~ ("zsh", "bash", "sh", "powershell.exe", "pwsh.exe", "cmd.exe")
| join kind=inner (
    DeviceNetworkEvents
    | where RemoteIPType == "Public"
    | project DeviceId, NetTime = TimeGenerated, RemoteUrl, RemoteIP, InitiatingProcessId
  ) on DeviceId, $left.ProcessId == $right.InitiatingProcessId
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, RemoteUrl, RemoteIP

// 3. Signing burst by one identity, by count or by value (lab table WalletSigning_CL)
WalletSigning_CL
| where TimeGenerated between (ago(1h) .. now())
| summarize Requests = count(), TotalAmount = sum(Amount_d), Destinations = dcount(Destination_s) by Identity_s, bin(TimeGenerated, 5m)
| where Requests between (10 .. 1000000) or TotalAmount between (1000000 .. 1000000000000)

WalletSigning_CL is a custom table in my lab, not Binance data. Replace the admin list with your own accounts.

Prevent, detect, respond

Question	Controls
Prevent: how do they not get in?	Throwaway VM rule, Defender for Endpoint, Conditional Access, Token Protection, PIM
Detect: if they are in, how do we see it?	Defender XDR, Sentinel analytics rules, KQL hunting
Respond: once seen, how do we stop the damage?	Device isolation, session revoke, disable identity, playbook that pauses signing

A valid account does not make every action valid. Protect the identity and the actions it is allowed to take.

Checklist

[ ] Written rule: no untrusted code on work devices; throwaway VM provided
[ ] Defender for Endpoint on every engineer laptop, attack disruption on
[ ] Conditional Access: privileged roles only from compliant devices
[ ] Token Protection enabled where supported
[ ] PIM for deploy and admin roles, with approval on the most sensitive
[ ] Signing callable by one managed identity; second approval for new delegations or destinations
[ ] Signing logs in Sentinel; rule on value and destination, not only count
[ ] Playbook to revoke tokens and pause signing, tested this quarter

Sources

Incident:

CoinDesk, 3 Nov 2026: https://www.coindesk.com/business/2026/11/03/binance-s-usd6-3-billion-hack-began-with-a-fake-job-interview-exchange-says
Hackread, 4 Nov 2026: https://hackread.com/binance-hack-fake-job-interviews-hackers-steal-billions/
Binance initial findings: https://www.linkedin.com/pulse/29-october-binance-security-incident-initial-findings-response-modgf/

Official Microsoft:

Contagious Interview (Microsoft Security Blog): https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/
Require compliant device: https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance
Token Protection: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
Privileged Identity Management: https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
Key Vault logging: https://learn.microsoft.com/en-us/azure/key-vault/general/logging
Automatic attack disruption: https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

Stop Buying the Same Microsoft 365 License for Everyone

CD Security Lab — Wed, 04 Nov 2026 01:10:37 +0000

Many companies pick one Microsoft 365 plan when they are small and every new hire gets it by default for years. That is money wasted every month on features nobody uses. In this video I map a lab company, Contoso Retail with 120 people, into three blocks (office, frontline, sensitive roles) and match a plan family to each: Business Premium for the office, Frontline plans for the store and warehouse, a security add-on for the ten who need more. Mixing plans in one tenant is allowed, and the 300-seat line of the Business family decides when Enterprise plans enter the picture. No prices in the video: they change by region, use Microsoft's pricing pages.

What the video covers

One default license for everyone (0:00)
Why everyone gets the same license (0:36)
Who gets hurt (0:52)
Draw your company first (1:07)
The question per group (1:27)
Frontline plans exist for a reason (1:40)
Office staff: Business, not Enterprise (2:18)
The 10 who need more (2:56)
Yes, you can mix plans (3:18)
The 300 line (3:38)
Contoso before and after (3:59)
Where the saved money goes (4:19)
Prove it in the admin center (4:34)
Gotchas (4:55)
Recap (5:19)

Sources (Microsoft Learn, checked 2026-10-29)

Microsoft 365 for business FAQ (300 users, mixing plans): https://www.microsoft.com/en-us/microsoft-365/business/microsoft-365-business-faq
Understand frontline worker user types and licensing: https://learn.microsoft.com/en-us/microsoft-365/frontline/flw-licensing-options
What is Conditional Access?: https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
Assign licenses to users in the Microsoft 365 admin center: https://learn.microsoft.com/en-us/microsoft-365/admin/manage/assign-licenses-to-users

Lab names and made-up numbers only (contoso.com). No prices: they change by region.

In your company, does every new hire still get the same license by default? Tell me in the comments, or watch the full video here: https://youtu.be/tlHCu3PfRjQ

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

Sentinel showed the same attack twice. Then it missed the next one.

CD Security Lab — Tue, 03 Nov 2026 01:09:57 +0000

Source: CD's readiness notes Sentinel-Readiness/Data Connector - M365D.md (free vs paid tables, bi-directional sync, the "duplicated incidents" checklist question), rebuilt as a lab story and cross-checked against Microsoft Learn on 2026-10-28. Lab names only; screens are drawings.

Monday morning at Contoso. The SOC queue shows two High incidents, same device LAB-WIN11-01, same minute, same title "Suspicious PowerShell command line". An analyst closes one as a duplicate. Ten minutes later it is back, reopened, because the other portal still considers it Active.

The same week a Defender for Cloud incident arrives with no entities and no alerts in it, just a title. And a hunting rule written against DeviceProcessEvents has been silent for a month. Not because nothing happened: the table was never switched on.

Three symptoms, one cause: the Defender XDR connector was turned on next to the old per-product connectors, and nobody read the checkbox.

It happened for real: Target, 2013

Duplicates sound like a tidiness problem. They are not. A queue full of copies is how a real alert gets closed or ignored, and the best-known example is Target's breach during the 2013 holiday season.

What happened

Date (2013)	Event
Autumn	Attackers get into Target's network with credentials stolen from an HVAC contractor.
Mid-November to early December	They move from the vendor area to the payment systems and install malware on the checkout terminals.
30 November onwards	Target's malware detection tool raises urgent alerts on the malware. According to the US Senate staff report, citing Bloomberg Businessweek, the alerts reached the security team and nobody acted on them.
Mid-December	The US Justice Department tells Target about the breach.
19 December	Target announces it.

Why it worked

Door 1, a vendor account with too much reach. The contractor's credentials led to a network that also held the payment systems. The Senate report notes that two-factor authentication was not required for all vendors.
Door 2, alerts that nobody acted on. The tool did its job. The process around it did not: the warnings sat in a queue with everything else.
Door 3, automatic removal turned off. The same report says the tool could have removed the malware by itself, and that option was off.

What it cost

Who	What they lost
About 40 million card holders	Card numbers stolen at checkout
Up to 70 million customers	Names, addresses, phone numbers, email addresses
Target	A total breach cost of 202 million USD (company figure, 2017), including an 18.5 million USD settlement with 47 states and Washington, D.C.
Leadership	The CIO resigned in March 2014; the CEO resigned in May 2014

The same doors in a Microsoft tenant

Door 2, the alert lost in the noise: this whole post. One attack, one incident, synced both ways, so a "closed as duplicate" can never hide the real one. Then the check below: high-severity incidents that nobody has picked up.
Door 3, the tool that could have acted: Defender XDR automatic attack disruption contains a device or disables a user during an attack without waiting for an analyst. Check it is not excluded for your critical devices.
Door 1, the vendor account: Conditional Access for guests and external users, with MFA and access only to the apps they need.

// High-severity incidents still New after an hour (nobody picked them up)
SecurityIncident
| where TimeGenerated > ago(7d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Severity == "High" and Status == "New"
| where CreatedTime < ago(1h)
| project IncidentNumber, Title, CreatedTime, Owner = tostring(Owner.assignedTo)

Run it as a scheduled analytics rule every 30 minutes, and send the result to the SOC lead, not to the same queue.

TL;DR

Problem: Defender XDR already builds incidents from Defender for Endpoint, Identity, Office 365 and Cloud Apps alerts. If Sentinel also builds incidents from the same alerts (Microsoft incident creation rules, per-product connectors), you get two incidents per attack, and the two do not agree.
Who it hurts: analysts (double triage, reopened tickets), the SOC manager (MTTR and incident counts are wrong), the CISO (one real Defender for Cloud incident arrives empty), and the budget (events tables cost money whether or not anyone queries them).
Fix: one connector for all Defender products, Turn off all Microsoft incident creation rules ticked, per-product connectors left disconnected, Defender for Cloud connector on so those incidents are not empty, and only the events tables you have rules for.
Cost: incidents and alerts are free. Raw device events are billed per GB. For a 200-device lab that is about $650 to $800 a month at pay-as-you-go, less with the Microsoft 365 E5 data grant.
Prove it: one incident per Defender XDR incident ID, status changes in either portal within a minute, Defender for Cloud incidents with entities.

It happened for real: Target, 2013
1. The problem
2. Who gets hurt
3. Cost and value
4. How to fix it
5. Prove it
Gotchas
Checklist
What changed recently
Sources
News sources

1. The problem

Think of two receptionists at the same front desk, each with their own visitor book. Every visitor is written down twice. When one receptionist marks a visitor "left", the other book still says "in the building". Nobody is lying; there are just two books.

In Sentinel the two books are:

Defender XDR's own incident engine. It correlates alerts from all Defender products into one incident and sends that incident to Sentinel through the Microsoft Defender XDR connector. These incidents stay in sync both ways: close it in Sentinel and it closes in the Defender portal, and the other way round.
Microsoft incident creation rules in Sentinel (Analytics, rule type "Microsoft security"), fed by the old per-product connectors (Defender for Endpoint, Identity, Office 365, Cloud Apps). These make a separate Sentinel incident per alert and do not sync with the Defender portal.

Run both and every Defender alert becomes two incidents. Close the wrong one and the synced one comes back. That is the Monday morning queue.

The other two symptoms come from the same connector page:

The XDR connector also brings Defender for Cloud incidents, but their alerts and entities only arrive if the Defender for Cloud connector is enabled too. Otherwise the incident is a title with nothing inside.
The connector's Events section is opt-in per table. No tick on DeviceProcessEvents means no rows, and a scheduled rule on that table returns nothing forever, without an error.

2. Who gets hurt

Who	What they lose
Analysts	Two tickets per attack, one of them reopening itself. Comments and classification written on the wrong copy are lost.
SOC manager	Incident counts, MTTR and "closed as duplicate" statistics are fiction; so is the staffing argument built on them.
CISO / risk owner	A Defender for Cloud incident about an exposed storage account arrives empty and is closed as noise.
Budget owner	Events tables ticked "to be safe" bill per GB. Rules that need them were never written, or were written and silently get nothing.
The product	"Sentinel duplicates everything" becomes the story, when the connector page already has the fix as a recommended checkbox.

3. Cost and value

Prices are USD list, pay-as-you-go, checked 2026-10-28; your region and agreement differ.

What is free. SecurityIncident and SecurityAlert from the XDR connector are not billed. My notes had this table already; Learn still agrees. So the fix for duplicates, empty incidents and sync costs nothing.

What is billed. The advanced hunting events tables (DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents, DeviceFileEvents, DeviceEvents, ...) are analytics-tier data at about $4.30 per GB in East US (up to about $5.59 in the most expensive US region); commitment tiers start at 50 GB a day and save up to 52%.

Lab example, 200 Windows devices, three tables ticked (process, network, logon):

Item	Estimate
Volume	about 30 MB per device per day = 6 GB/day
Pay-as-you-go	6 GB × $4.30 × 30 = about $775 a month
With Microsoft 365 E5 data grant (5 MB per user per day, covers Microsoft 365 advanced hunting data)	200 users × 5 MB = 1 GB/day free → 5 GB billed = about $645 a month
All ten tables ticked "to be safe"	2 to 3 times that, with no extra rules to use it

What the duplicates cost. 40 Defender incidents a week doubled is 40 extra triages × 10 minutes = about 7 hours a week, about 28 analyst hours a month, plus the reopened-ticket loop.

Value of the fix. Zero licence, zero ingestion: one checkbox and one disconnected connector return the 28 hours. The events tables are the only real spend, so switch on exactly the ones your rules read.

How others do it. Any SIEM that pulls both the Defender alerts API and the incidents API has the same doubling; Splunk's Microsoft Defender add-ons let you pick one input for the same reason. The problem is not the product, it is two books on one desk.

4. How to fix it

Lab: workspace law-contoso-sec, Defender XDR tenant for contoso.com, 200 devices in Defender for Endpoint, Defender for Cloud on sub-lab-prod.

Step 1: one connector. Content hub → install Microsoft Defender XDR solution → Data connectors → Microsoft Defender XDR → Open connector page. Under Connect incidents and alerts, tick Turn off all Microsoft incident creation rules for these products. Recommended and then Connect incidents & alerts. The checkbox disappears once connected, so do it now; afterwards you disable the rules by hand under Analytics.

Step 2: leave the per-product connectors alone. When the XDR connector is on, Sentinel disconnects the Defender for Endpoint, Identity, Office 365 and Cloud Apps connectors in the background. They may still look connected on the gallery page; no data flows through them. Do not reconnect them. If you kept a "Microsoft security" analytics rule for any of these products, disable it (Analytics → filter rule type Microsoft security).

Step 3: Defender for Cloud. Enable the Microsoft Defender for Cloud connector (the tenant-based one) so the Defender for Cloud incidents that arrive via XDR carry their alerts and entities. Do not add a Microsoft incident creation rule for it; the XDR incident is already the incident.

Step 4: events, on purpose. Back on the XDR connector page, under Connect events, tick only the tables that a rule or hunt reads. In the lab: DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents. Apply changes. Each table you add is per-GB money.

Step 5: automation that survives sync. An automation rule that closes incidents must set a classification; "closed" with no reason syncs to the Defender portal as Not set → Undetermined. If two incidents are merged on the Defender side, Sentinel closes one with the tag redirected; teach analysts that tag before they ask why incidents vanish.

5. Prove it

One incident per Defender incident:

SecurityIncident
| where TimeGenerated > ago(7d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| summarize n = count(), providers = make_set(ProviderName) by tostring(ProviderIncidentUrl), Title
| where n > 1

Zero rows. Before the fix, each pair shows one Microsoft XDR and one Azure Sentinel provider for the same Defender incident URL.

Close an incident in the Defender portal with True positive; Sentinel shows Closed / True Positive / Suspicious activity on refresh, within a minute.
A Defender for Cloud incident in Sentinel has entities (the resource) and at least one alert.
DeviceProcessEvents | where TimeGenerated > ago(1h) | count is greater than zero and the scheduled rule that reads it fires on a test powershell -enc run on LAB-WIN11-01.

Gotchas

The checkbox is a one-time offer. It is shown only before you connect. After that, disable Microsoft security rules yourself.
Per-product connectors look alive. The gallery still shows "Connected"; it is cosmetic. Reconnecting them brings the duplicates back.
Alert schema changes. Alerts arriving via XDR have a slightly different SecurityAlert shape (provider, extended properties) than the standalone connectors. Queries and workbooks written against the old shape need a check.
150 alerts. A Sentinel incident holds at most 150 alerts; a bigger XDR incident shows "150+" and a link to the full set in the Defender portal.
TVM tables are not ingested. DeviceTvm* tables appear in the schema and return nothing. Query vulnerabilities in Defender advanced hunting, or export them yourself.
Status mapping is not 1:1. Active in Defender becomes New in Sentinel; Not set becomes Undetermined. Build reports on the Sentinel values.
Comments sync one way per comment. New comments cross over; edits do not.
Defender portal onboarding. If the workspace is onboarded to the Defender portal, the XDR connector is turned on for you and Microsoft incident creation rules are not supported at all. Same end state, one less step.

Checklist

[ ] Microsoft Defender XDR solution installed, connector connected with the incident creation rules checkbox ticked
[ ] No enabled "Microsoft security" analytics rules for Defender XDR products
[ ] Per-product Defender connectors not reconnected
[ ] Defender for Cloud connector enabled, no incident creation rule for it
[ ] Only the events tables a rule reads are ticked; cost estimated per table
[ ] Automation rules set a classification when closing
[ ] Duplicate query returns zero; sync test passes both ways
[ ] Analysts know the redirected tag and the "150+" link

What changed recently

Checked against Microsoft Learn on 2026-10-28:

My notes call it the Microsoft 365 Defender connector; it is Microsoft Defender XDR now, same connector, same free/paid table split (connector page updated 2026-07-02).
The connector page now says plainly that the per-product connectors are disconnected in the background when XDR is connected, and that they still appear connected. My notes only asked the question.
The Turn off all Microsoft incident creation rules checkbox is the documented way to avoid duplicates (integration page updated 2026-06-17); the status and classification mapping table on that page is what step 5 relies on.
Defender for Cloud incidents via XDR need the Defender for Cloud connector or they arrive empty. Not in my notes at all.
DeviceFileCertificateInfo joined the list of available events tables; the DeviceTvm* tables are explicitly not ingested.
Sentinel in the Azure portal retires after 31 March 2027; in the Defender portal the connector is automatic and Microsoft incident creation rules are not supported.

Sources

Connect data from Microsoft Defender XDR to Microsoft Sentinel
Microsoft Defender XDR integration with Microsoft Sentinel
Microsoft Sentinel pricing (per-GB figures as published for East US, pay-as-you-go, 2026-10-28)
Automatic attack disruption in Microsoft Defender XDR
Conditional Access for B2B collaboration users

News sources

US Senate Committee on Commerce, Science and Transportation, "A 'Kill Chain' Analysis of the 2013 Target Data Breach" (majority staff report, March 2014), as reported by NBC News: https://www.nbcnews.com/business/consumer/target-missed-many-warning-signs-leading-breach-senate-report-n62021
Nevada Attorney General, 47 states reach 18.5 million USD settlement with Target (May 2017): https://ag.nv.gov/News/PR/2017/Attorney_General_Laxalt_and_47_States_Reach_$18_5_Million_Settlement_With_Target_Corporation_over_2013_Data_Breach
NBC News, "Target settles 2013 hacked customer data breach for 18.5 million" (May 2017): https://www.nbcnews.com/business/business-news/target-settles-2013-hacked-customer-data-breach-18-5-million-n764031

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

If Binance Ran on Microsoft: 4 Locks That Stop a $6.3B Hack

CD Security Lab — Mon, 02 Nov 2026 01:10:00 +0000

Binance's first findings point to one hacked DevOps laptop and about 6.3 billion dollars affected. The investigation is still ongoing, so this is not a claim about exactly how Binance was breached. It is a simple question: if the same four steps happened in a Microsoft tenant, which settings would stop each one, and how do you check your own tenant today?

What we know (initial findings)

A DevOps engineer's laptop was compromised; Binance has not said how.
From there the attackers reached a server inside the company.
No private key was reported stolen: the attackers made Binance's own signing system sign the withdrawals.
One transaction carried 50 pre-signed approvals, and about three and a half minutes later that hot wallet was empty.

Microsoft described a trick aimed at developers this year (fake recruiter, coding test, open the repo in VS Code and click "trust"). It is shown in the video as a known technique, not as what happened at Binance.

The 4 locks

Hacked laptop: run strangers' code in a throwaway VM; Defender for Endpoint with automatic attack disruption isolates the device
Laptop to server: Conditional Access requires a compliant device, Token Protection binds the session (supported apps), PIM removes standing admin rights
Signing system made to sign: Key Vault with very few signers, signing rights approved by a second person in PIM
50 signatures in minutes: Microsoft Sentinel alert plus automation disables the identity

What the video covers

$6.3B and one laptop (0:00)
Step 1: a hacked laptop (0:29)
Lock 1: Defender + throwaway VM (0:56)
Step 2: laptop to server (1:20)
Lock 2: Conditional Access, Token Protection, PIM (1:30)
Check your tenant: KQL 1 (2:00)
Step 3: the system signed it (2:12)
Lock 3: Key Vault + second approver (2:27)
Step 4: 3.5 minutes (2:41)
Lock 4: Sentinel automation (2:53)
KQL 2 and 3 (3:09)
Recap: 4 locks (3:20)

KQL to check your tenant

Run these in Log Analytics (Logs). Lab names (contoso.com); replace the admin list with your own accounts. If your workspace uses the resource-specific Key Vault table (AZKVAuditLogs), adapt query 2.

// Door 1: admins signing in from devices that are not compliant
SigninLogs
| where TimeGenerated between (ago(14d) .. now())
| where ResultType == "0"
| where UserPrincipalName in~ ("admin1@contoso.com", "devops1@contoso.com")
| extend Compliant = tostring(DeviceDetail.isCompliant), Device = tostring(DeviceDetail.displayName)
| where Compliant != "true"
| summarize SignIns = count() by UserPrincipalName, Device

// Door 3: a burst of Key Vault sign operations (50 = about 10x the lab baseline)
AzureDiagnostics
| where TimeGenerated between (ago(1d) .. now())
| where ResourceProvider == "MICROSOFT.KEYVAULT" and OperationName == "KeySign"
| summarize Signs = count() by bin(TimeGenerated, 5m), Resource, CallerIPAddress
| where Signs between (50 .. 1000000)

// Who was given access to a key vault in the last 30 days
AzureActivity
| where TimeGenerated between (ago(30d) .. now())
| where OperationNameValue =~ "Microsoft.Authorization/roleAssignments/write"
| where _ResourceId has "/vaults/"
| project TimeGenerated, Caller, _ResourceId

Official Microsoft sources

Conditional Access, require compliant device: https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance
Token Protection: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
Privileged Identity Management: https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
Azure Key Vault logging: https://learn.microsoft.com/en-us/azure/key-vault/general/logging
Automatic attack disruption: https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption
Contagious Interview (Microsoft Security Blog, Mar 2026): https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/

News sources

The Hacker News, 30 Oct 2026: https://thehackernews.com/2026/10/binance-suffers-security-breach.html
Euronews, 30 Oct 2026: https://www.euronews.com/2026/10/30/how-the-binance-hack-happened-and-who-was-behind-it
Hackread: https://hackread.com/binance-devops-engineer-hacked-laptop-billion-theft/

All lab data comes from my contoso.com test tenant.

How many admins in your tenant have standing access right now? Tell me in the comments, or watch the full video here: https://youtu.be/RLguDhsYiz0

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

Case study: the VIP list nobody updated

CD Security Lab — Mon, 02 Nov 2026 01:09:16 +0000

Source: CD's readiness notes Sentinel-Readiness/Watchlist.md (VIP travellers allowlist, restricted-employee blocklist, SearchKey), rebuilt as a lab story and cross-checked against Microsoft Learn on 2026-10-28. Lab names only; screens are drawings.

In January, Contoso's SOC did the sensible thing. Executives travel, "impossible travel" alerts on them were noise, so an analyst built a VIP Users watchlist from an HR spreadsheet and told the analytics rule to skip those twelve accounts. Everyone got their evenings back.

In October a former regional director's account, never disabled properly, signs in from two continents in one hour. No incident. The account was still on the VIP list. Meanwhile the new CFO, hired in June, generates four "impossible travel" incidents a week because nobody added her. The list was right for exactly one month.

It happened for real: Colonial Pipeline, 2021

The lab story above is invented. The pattern is not. In May 2021 the largest fuel pipeline on the US East Coast stopped for five days because of one account nobody was using any more.

What happened

Date (2021)	Event
29 April	Attackers log in to Colonial Pipeline's network through a VPN account. According to Mandiant, as reported by Bloomberg, the account was no longer in use and its password had appeared in a leak.
7 May	DarkSide ransomware hits the business network. Colonial shuts down its 5,500-mile pipeline, which carries about 45% of the fuel used on the East Coast.
7 May	Colonial pays a ransom of 75 bitcoin, about 4.4 million USD.
12 May	The pipeline starts to restart. Gas stations across the South-East run dry in the days around it.
7 June	The US Justice Department recovers 63.7 bitcoin, about 2.3 million USD at the time.
8 June	CEO Joseph Blount tells the US Senate the VPN was a legacy profile without multi-factor authentication, and that the password was a complicated one.

Why it worked

Door 1, an account that should not exist. Nobody used the VPN account, so nobody disabled it. It is the ex-director from the lab story: still on a trusted list, still able to sign in.
Door 2, no second factor. A leaked password was enough. A complicated password does not help once it is in a leak.
Door 3, nobody watching the quiet accounts. A sign-in from an account that has been silent for months is one of the strongest signals you can get, and nothing was looking for it.

What it cost

Who	What they lost
Colonial Pipeline	4.4 million USD ransom (about half recovered later), five days of shut-down, a Senate hearing
Drivers and airlines on the East Coast	Fuel shortages, panic buying, emergency rules for fuel transport in 17 states and Washington, D.C.
Everyone else	The attack that turned ransomware into a national-security topic in the US

The same doors in a Microsoft tenant

This post's fix closes Door 1 and Door 3. Add Door 2 and you have the full set:

Door 1, the leaver still trusted: steps 1 to 3 in section 5 below. Feed the lists from Entra groups, move leavers to TerminatedEmployees, and find inactive accounts with the signInActivity report in Entra ID (or an access review for inactive users) and disable them.
Door 2, no MFA: a Conditional Access policy that requires MFA for all users and all resources, including the VPN, which can use Entra ID for sign-in.
Door 3, the quiet account that wakes up: the query below, as a scheduled analytics rule, every hour.

// Accounts that signed in today but had no successful sign-in in the previous 60 days
let today = SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "0"
    | distinct UserPrincipalName;
let before = SigninLogs
    | where TimeGenerated between (ago(60d) .. ago(1d))
    | where ResultType == "0"
    | distinct UserPrincipalName;
today
| join kind=leftanti before on UserPrincipalName

Your workspace must keep SigninLogs for at least 60 days for this to work. New joiners also show up once: that is expected, and it is exactly the list HR should confirm.

TL;DR

Problem: a watchlist is a snapshot of the business. The business moves; the snapshot does not. A stale allowlist suppresses the exact alerts you most need; a stale blocklist misses the people it was built for.
Who it hurts: the SOC (blind to compromised ex-VIP accounts, flooded by new-VIP noise), HR and legal (a leaver's access is "monitored" on paper only), the exec whose account is abused, and the budget that pays analysts to close false positives.
Fix: feed the watchlist from a source of truth (an Entra group HR already maintains) on a schedule, use the right template and SearchKey, add a Terminated Employees watchlist that raises severity instead of lowering it, and alert when the list is older than 14 days.
Cost: the watchlist itself is close to free. The stale one cost about 10 analyst hours a month in noise, and one unseen compromise.
Prove it: _GetWatchlist('VIPUsers') matches the Entra group exactly, and the test sign-in from a leaver's account opens a High incident.

It happened for real: Colonial Pipeline, 2021
1. The problem
2. Who gets hurt
3. Cost and value
4. What went wrong, in the lab
5. The fix
6. Prove it
Gotchas
Checklist
What changed recently
Sources
News sources

1. The problem

A watchlist is a guest list at the door. Security checks every name against it. Two kinds exist, from my notes:

Allowlist: "these people may do unusual things, do not stop them." VIP travellers.
Blocklist: "if any of these people show up, call me immediately." Restricted or terminated employees.

A guest list printed in January is wrong by February. Someone left, someone joined, someone changed name. The bouncer does not know; the paper looks the same. In Sentinel the paper is the Watchlist table, the bouncer is your analytics rule, and _GetWatchlist('alias') is how the rule reads the list.

2. Who gets hurt

Who	What they lose
SOC analysts	The suppressed sign-in from the ex-director is the one incident they needed. The CFO's 16 false positives a month are the ones they did not.
HR / legal	"Leavers are monitored" is a control on paper. The leaver's account is on the trusted list.
The executive	Her account is either over-watched (noise, slower response) or invisible (no response)
Budget	Analyst time on noise, and the cost of a breach found late
The product	Watchlists get blamed for being "useless", when the process around them was missing

3. Cost and value

What a watchlist costs: almost nothing. Items land in the Watchlist table (tiny rows), limits are generous (10 million active items per workspace, 3.8 MB per local upload, 500 MB via Azure Storage). The Logic App that refreshes it weekly runs 4 times a month; at consumption pricing that is cents. Checked 2026-10-28.

What the stale list cost in the lab story:

Item	Lab estimate
False positives on the new CFO	about 16 incidents a month × 15 min triage = 4 hours
Other joiners/movers not on the list (3 people)	another 6 hours a month
Suppressed sign-ins on 3 leavers still on the list	0 incidents, which is the problem
Total	about 10 analyst hours a month, plus one missed compromise

Value of the fix: the same rule, the same watchlist feature, but fed from the Entra group HR already keeps. Zero extra licence. The 10 hours come back, and leavers move from the allowlist to a blocklist that raises severity.

How other tools do it: every SIEM has the same concept (lookup tables, reference sets, asset lists) and the same failure mode. The fix is never a feature; it is a feed and an expiry date.

4. What went wrong, in the lab

Workspace law-contoso-sec. Watchlist VIPUsers, created in January from the VIP Users template (mandatory column User Principal Name, SearchKey set to that column). The analytics rule:

let vip = _GetWatchlist('VIPUsers') | project UserPrincipalName = tolower(SearchKey);
SigninLogs
| where ResultType == "0"
| where tolower(UserPrincipalName) !in (vip)      // skip VIPs
| ... impossible-travel logic ...

Three things nobody set up:

No feed. The list came from a spreadsheet. HR changed the Entra group sg-exec-leadership all year; the watchlist never heard about it.
No expiry. Nothing told the SOC the list was 280 days old. (Watchlist rows show a TimeGenerated that Sentinel refreshes every 12 days, so even that date lies about freshness.)
Wrong direction for leavers. A leaver should move from "trust more" to "watch more". There was no Terminated Employees list at all.

5. The fix

Step 1: pick the source of truth. The Entra group sg-exec-leadership, owned by HR. If a name is not in the group, it is not a VIP.

Step 2: refresh the watchlist on a schedule. A Logic App, weekly:

Trigger: Recurrence, every 7 days.
Action: Microsoft Graph, list members of sg-exec-leadership (userPrincipalName).
Action: Microsoft Sentinel connector, Watchlists - Add a new watchlist item for each member (or build the CSV and call the Watchlist API).
Removals: bulk upload appends and never deletes. For a list this small, the honest approach is delete-and-recreate the watchlist once a week from the group, or delete departed items explicitly from the diff.

Step 3: add the blocklist. Create TerminatedEmployees from the template (mandatory: User Principal Name, UserState, Termination date), fed from HR's leaver process. Rule: any successful sign-in by a listed account → High incident.

let leavers = _GetWatchlist('TerminatedEmployees') | project UserPrincipalName = tolower(SearchKey);
SigninLogs
| where ResultType == "0"
| where tolower(UserPrincipalName) in (leavers)
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName

Step 4: alert on staleness. A scheduled rule that compares the watchlist with the group is ideal; a simpler one fires if the Logic App run history shows no success in 14 days.

6. Prove it

_GetWatchlist('VIPUsers') | count equals the member count of sg-exec-leadership. The three leavers are gone, the CFO is there.
Test sign-in with a lab leaver account (lab.leaver01@contoso.com, on TerminatedEmployees): a High incident within the rule's 5-minute schedule.
The CFO travels to the Singapore office: zero impossible-travel incidents.
The Logic App run history shows a green run every Monday.

Gotchas

Bulk update appends. Re-uploading a smaller CSV does not remove anyone. Delete items, or delete and recreate the list.
SearchKey decides performance and joins. Set it to the column you filter on (UPN here). Changing it later means recreating the list.
Case. tolower() both sides; UPNs arrive in mixed case.
Narrow time ranges return empty watchlists. _GetWatchlist() on a 5-minute query window can come back empty or partial; widen the scope when testing.
28 days is not an expiry. The Watchlist table keeps 28 days and Sentinel refreshes rows every 12 days, so the list never disappears on its own. Freshness is your job.
Daily cap. A new watchlist with zero rows right after upload can be the workspace daily cap, not a bug.
Templates are preview. Columns can still change; pin yours in the Logic App.

Checklist

[ ] Each watchlist has an owner and a source of truth (group, HR export)
[ ] Template + SearchKey chosen on purpose (UPN)
[ ] Scheduled refresh (Logic App or API), removals handled explicitly
[ ] Allowlist for VIPs and blocklist for leavers
[ ] Staleness alert (no refresh in 14 days)
[ ] Count matches the source, test leaver sign-in raises High
[ ] Reviewed quarterly with HR

What changed recently

Checked against Microsoft Learn on 2026-10-28:

My notes describe allowlist/blocklist and SearchKey; Learn now adds hard limits (10 million items, 3.8 MB local upload, 500 MB via Azure Storage), the 12-day refresh and the 28-day table retention (watchlists page updated 2026-06-23).
Watchlist templates (VIP Users, Terminated Employees, High Value Assets, Network Addresses, Identity Correlation, Service Accounts) exist, still in preview (schemas page updated 2026-06-28).
The manage page (updated 2026-07-01) states that bulk update appends and de-duplicates exact rows; it does not delete. That rule shaped step 2.
Sentinel in the Azure portal retires after 31 March 2027; watchlists live under Microsoft Sentinel → Configuration → Watchlist in the Defender portal.

Sources

News sources

US Senate Homeland Security and Governmental Affairs Committee, hearing with Colonial Pipeline CEO Joseph Blount (8 June 2021), as reported by Dark Reading: https://www.darkreading.com/attacks-breaches/colonial-pipeline-ceo-ransomware-attack-started-via-pilfered-legacy-vpn-account
Cybersecurity Dive, "Colonial Pipeline CEO: legacy VPN" (June 2021): https://cybersecuritydive.com/news/colonial-Joseph-Blount-ransomware-legacy-vpn/601523
US Department of Justice, seizure of 2.3 million USD paid to DarkSide (7 June 2021): https://www.justice.gov/opa/pr/department-justice-seizes-23-million-cryptocurrency-paid-ransomware-extortionists-darkside

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

Copilot Showed Me My Coworker's Files (It Wasn't Hacked)

CD Security Lab — Sun, 01 Nov 2026 01:10:25 +0000

In the first week of a Microsoft 365 Copilot trial, a normal question returned a summary of the HR salary review. Nothing was hacked: Copilot only surfaces what the user could already open, and years of "share with everyone" links did the rest. This video shows who gets hurt, where the open doors came from, and the three-step fix: measure with the SharePoint data access governance reports, pull the brake with Restricted Content Discovery, then clean up the sharing itself and label the crown jewels. And why turning Copilot off does not close a single door.

What the video covers

Copilot showed a coworker's files (0:00)
The story (0:33)
Who gets hurt (0:51)
Copilot only reads what you can read (1:10)
Where the open doors came from (1:34)
Search had the same hole (1:59)
Step 1: measure it (2:16)
Step 2: pull the brake (2:41)
Step 3: fix the sharing itself (3:03)
Label the crown jewels (3:23)
What turning Copilot off would do (3:39)
Prove it worked (4:03)
Gotchas (4:21)
Do this BEFORE the rollout (4:44)
Checklist (5:03)
Recap (5:25)

Sources (Microsoft Learn, checked 2026-10-29)

Data, privacy, and security for Microsoft 365 Copilot: https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy
Data access governance reports for SharePoint sites: https://learn.microsoft.com/en-us/sharepoint/data-access-governance-reports
Restricted Content Discovery: https://learn.microsoft.com/en-us/sharepoint/restricted-content-discovery
Learn about sensitivity labels: https://learn.microsoft.com/en-us/purview/sensitivity-labels

Lab names and made-up numbers only (contoso.com). No prices: they change by region.

Have you run the oversharing reports in your tenant before rolling out Copilot? Tell me in the comments, or watch the full video here: https://youtu.be/HvuBSAHcJuk

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

Microsoft Sentinel Bill Tripled? Find the Cause in 5 Steps

CD Security Lab — Sat, 31 Oct 2026 01:09:31 +0000

Your Microsoft Sentinel bill tripled and the team says nothing changed. Someone did change something. This video walks the 5-step path to the culprit (meter, day, table, source, event), the rate trap that raises the bill without more gigabytes, the fixes (filter at the source, data lake tier, commitment tier sizing) and the guardrails (volume alert, budget, daily cap used carefully).

What the video covers

Your Sentinel bill tripled (0:00)
Who pays for a Sentinel spike (0:19)
How Sentinel pricing works (0:44)
Lab: 3 GB a day becomes 14 (1:14)
Find the meter in Cost analysis (1:37)
Find the spike day (Usage table) (1:47)
Find the table that grew (1:56)
Find the machine (_BilledSize) (2:09)
Find the noisy event IDs (2:22)
Free trial and commitment rate trap (2:32)
Filter logs at the source (2:44)
Cost saved and results (3:17)
Volume alert, budget, daily cap (3:36)
Recap (3:58)

KQL used in the video

Run these in Log Analytics (Logs) on the Sentinel workspace, in this order. Lab names; swap in your own machine names.

// Step 2: find the spike day (billable GB per day)
Usage
| where TimeGenerated between (ago(32d) .. now())
| where IsBillable == true
| summarize BillableGB = sum(Quantity) / 1000. by bin(TimeGenerated, 1d)
| render columnchart

// Step 3: find the table that grew (this week vs last week)
Usage
| where TimeGenerated between (ago(14d) .. now())
| where IsBillable == true
| summarize ThisWeekGB = sumif(Quantity, TimeGenerated between (ago(7d) .. now())) / 1000.,
            LastWeekGB = sumif(Quantity, TimeGenerated between (ago(14d) .. ago(7d))) / 1000.
            by DataType
| extend GrowthGB = ThisWeekGB - LastWeekGB
| sort by GrowthGB desc

// Step 4: find the source (billed size per machine)
SecurityEvent
| where TimeGenerated between (ago(7d) .. now())
| where _IsBillable == true
| summarize BillableGB = sum(_BilledSize) / 1e9 by Computer
| sort by BillableGB desc
| take 10

// Step 4b: same for CEF/syslog devices
CommonSecurityLog
| where TimeGenerated between (ago(7d) .. now())
| where _IsBillable == true
| summarize BillableGB = sum(_BilledSize) / 1e9 by Computer, DeviceVendor, DeviceProduct
| sort by BillableGB desc
| take 10

// Step 5: find the noisy event IDs on that machine
SecurityEvent
| where TimeGenerated between (ago(7d) .. now())
| where Computer == "LAB-WIN11-01"
| summarize Events = count(), BillableGB = sum(_BilledSize) / 1e9 by EventID
| sort by BillableGB desc
| take 10

// Guardrail: volume alert (log alert rule, runs once a day)
// 6 = about twice a normal day in the lab; set your own baseline
Usage
| where TimeGenerated between (ago(1d) .. now())
| where IsBillable == true
| summarize BillableGB = sum(Quantity) / 1000.
| where BillableGB between (6.0 .. 100000.0)

Sources (Microsoft Learn, checked 2026-10-29)

Plan costs and understand Microsoft Sentinel pricing and billing: https://learn.microsoft.com/en-us/azure/sentinel/billing
Reduce costs for Microsoft Sentinel: https://learn.microsoft.com/en-us/azure/sentinel/billing-reduce-costs
Set a daily cap on a Log Analytics workspace: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/daily-cap
Analyze usage in a Log Analytics workspace: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/analyze-usage

Lab names and made-up numbers only (contoso.com). No prices: they change by region.

Where did your last Sentinel ingestion spike come from? Tell me in the comments, or watch the full video here: https://youtu.be/xXQOidCbvQI

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

▶️ YouTube (daily Shorts + explainers): CD Security Lab
💼 LinkedIn: Cuong Do
📘 Facebook: CD Security Lab
📸 Instagram: @cdsecuritylab
📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.

DEV Community: CD Security Lab

One service died and took the orders with it. Kafka + AKHQ in one Docker Compose file

TL;DR

Table of contents

1. The problem

2. Who gets hurt

3. Cost and value

4. Build it: one Compose file

5. Prove it works

Gotchas

Checklist

What changed recently

Sources

The playbook that was supposed to block the account ran zero times

It happened for real: Midnight Blizzard and Microsoft, 2024

What happened

Why it worked

What it cost

The same doors in a Microsoft tenant

TL;DR

Table of contents

1. The problem

2. Who gets hurt

3. Cost and value

4. How to fix it

5. Prove it

Gotchas

Checklist

What changed recently

Sources

News sources

Defender Says "Not Onboarded"? 4 Reasons Your Devices Aren't Protected

What the video covers

Every command from the video

Sources (Microsoft Learn, checked 2026-11-01)

SC-500 deep dive #1: your Contributors can read your Key Vault secrets

The problem: a "deploy-only" account that read 41 secrets

How it works: two permission models, one vault

Why it matters right now

The fix: find, map, switch, lock

1. Find every vault still on access policies

2. List who is in each access policy today

3. Give the same access with RBAC roles, before you switch

4. Switch the vault to RBAC

5. Lock it so it cannot come back

SC-500 exam traps

Before and after in my lab

Coming next

Sources

The uploads vanished when the pod restarted. Kubernetes networking and storage: what actually breaks

TL;DR

Table of contents

1. The problem

2. Who gets hurt

3. Cost and value

4. Networking: the three things to know

5. Storage: the three things to know

6. Prove it

Gotchas

Checklist

What changed recently

Sources

The $6.34B Binance Hack Started With a Job Interview: The Full Chain and 4 Microsoft Locks

What happened, in one paragraph

Who got hurt and what it cost

5 terms in plain words

Step 1: the laptop (June and September)

Step 2: moving sideways (20 October)

Step 3: a container gets the right to act for a wallet (29 October)

Step 4: almost four hours of outflow

"But the engineer had those rights anyway. Why couldn't he do it?"

Check your own tenant (contoso lab queries)

Prevent, detect, respond

Checklist

Sources

Stop Buying the Same Microsoft 365 License for Everyone

What the video covers

Sources (Microsoft Learn, checked 2026-10-29)

Sentinel showed the same attack twice. Then it missed the next one.

It happened for real: Target, 2013