TinyInfoSec

 Ever get one of these? An alert that says "User at Risk Detected... We detected a new user with at least high risk in your [company] directory.  This might be because we noticed suspicious account activity or we found their emails and passwords posted in a public location." This is Azure AD Identity Protection at work.  But if you click on "View Detailed Report" to dig into the risk events, you may get the rather vague "Unfamiliar Sign in Properties" as the source of the alert.  But.what property in particular caused this alert?  The portal doesn't seem to say. The good news is you may be able to find the answer in Sentinel.  Use this query to look at the high risk detection: //The details on identity protection risk detections, highlighting what you're probably looking for @tinyinfosec May, 2022 //Then go back to SignInLogs to review all recent signins in context SecurityAlert | where ProductName == "Azure Active Directory Identity Protectio...

Business Email Compromise (BEC) isn't fun for the owner of the compromised mailboxes, or the folks on the receiving end of phish sent from those compromised mailboxes.  This post is for those in the latter camp, a place I've been on a couple of occasions in my career.  In one instance the bad actor got rather ambitious and sent numerous phishing messages to my organization - all were leveraging existing threads in multiple mailboxes, and using at least one of three malicious hyperlinks. Here is how I attacked the problem with Sentinel: We blocked inbound mail from the source to stop the bleeding, and then went about identifying the messages involved: let suspectmessages = ( EmailEvents | where SenderFromDomain contains "sourceofphish.net" ) | summarize by NetworkMessageId; EmailUrlInfo | where NetworkMessageId has_any (suspectmessages) | summarize by Url Of course this could also be done in MS 365 Advanced Hunting, but I was SO HAPPY when email data was add...

If you use KnowBe4 to perform phishing assessments of your company, you know that a handy feature is the map of the world showing where people clicked on assessments.  Under: Phishing > Campaigns > Inactive > (Click on a finished campaign) Scroll down to "Failure by IP Address Location".  If you know all of your staff is based in the Canada and see that someone fell for a phishing message in Madagascar, you're thinking that either someone is on vacation, or the mailbox has been compromised .    Red Alert! Or not.  I had a situation where I had a failure on an IP address in Israel.  I confirmed that the recipient of that message was not on vacation to the middle east and was not using a VPN. This prompted an investigation seeking any suspicious activity involving the user account in question and any suspicious activity or successful logons from unexpected countries.  Passwords were changed, meetings cancelled, and I was JUST about to call ...

 Hackers, the good ones and the evil ones, are lazy.  In the interest of fewer keystrokes they will use filenames with single characters (e.g. "f.exe" or "2.ps1").  So this short but sweet query will help you find potentially problematic executables: let allowlist = datatable (DName:string) ['because you are going to have exceptions','Put em here']; let allowarray = allowlist | summarize make_set(DName); DeviceProcessEvents | where FileName matches regex @'^.\.[eE][xX][eE]' or FileName matches regex @'^.\.[pP][sS][0-9]' or FileName matches regex @'^.\.[cC][mM][dD]' or FileName matches regex @'^.\.[cC][oO][mM]' | where SHA1 !in (allowarray) | project AccountName, DeviceName, SHA1, FileName, FolderPath, InitiatingProcessAccountName, InitiatingProcessAccountUpn   I was reminded of this when reading this tweet from @GossiTheDog and @h2jazi, but please note that the above query will NOT de...

Sentinel shop?   Azure Sentinel This Week, by Microsoft guru Rod Trent, has to be on your list.  Check it out   I SWEAR I just posted this before he included a link to this humble blog trying to get off the ground!

IOC’s.  You can’t afford one of those $70,000 feeds of hashes and IP addresses (and larger companies may be wasting their money anyway), but from time to time you receive you receive a bunch of indicators from a reliable source and you don’t want them to go to waste.  If you are a Microsoft shop, step one might be pasting those indicators into a spreadsheet template and uploading them into the MS365 portal.  That’s great for protecting yourself right now and going forward, but what about looking back in time to make sure that you weren’t already pwned?  Sure, you could construct a query with a huge array, but referencing a text file would be a lot easier. Here are instructions for using Azure Sentinel to do this with minimal fuss. Pre-Requisites : Azure Sentinel Instance with Microsoft 365 Defender Data Connector in place Ingredient: A simple text file called evilipaddrs.txt which is just a list of known bad IP’s. Steps: Azure    Portal -> Creat...