KnowBe4 as Poor Person's Intrusion Detection System & The Catch

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 in third party IR reinforcements when I decided to call KnowBe4 support to see if they could provide further insight into the situation.  They did.

Long story short: The message in question had been forwarded internally after receipt (the recipient was dutifully questioning the validity of the message without clicking on anything therein).  By doing this the hyperlinks were scrutinized by two different email security solutions and their automatic sandboxes - at least one of which then passed it around the world.  It's analogous to VirusTotal - you don't upload a file to VT unless you're comfortable with the file being accessible to 34,521 security people around the globe.  Exclusions put in place to avoid KnowBe4 messages being scrutinized were limited to inbound Internet messages only.  

When you look at the Failures map in KnowBe4, or export the failures data to .csv, you are only seeing the last failure for a given user/message.  Support staff have access to all the clicks, and the analyst with whom I spoke could see 20 on this given message as it traversed the email security interwebs.

So the moral of the story is: Don't panic if, at first blush, it looks like an evildoer opened your phishing assessment message.



Comments

Post a Comment

Popular posts from this blog

MS 365: Handilng False Positives Is Two Step Process on the Back End

Today in "weird things I just noticed", I was looking at a group of messages falsely flagged as Junk Mail in the Explorer (within the 365 Defender portal).  I selected the messages, clicked Message Actions, and then Report Clean.  All done? Not quite.  If you do this within Outlook, your message is reported and automatically moved to the Inbox.  In Explorer, you then need to separately take the action "Move to Inbox"- which presents a Remediation wizard to document what you're doing and set the priority.  Once complete you can go to the Action Center to track process. That's fine, I see where Microsoft is coming from since it's a back-end administrative action that involves getting hands within someone's mailbox.  It's just something to keep in mind if you identify a source of false positives in email filtering.
Read more

Microsoft Sentinel - Hunting for Single Character Filenames

 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...
Read more

Active Directory Identity Protection Alerts & Using Microsoft Sentinel For the Deets

Image
 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...
Read more