Table of contents

Intro

“Was this you?” is probably the most frequently asked question in cybersecurity. For most internal Security Operations Centers (SOCs), the first investigative step (rightly or wrongly) in response to any flavor of alert is to message the relevant end user, “Hey, we saw your account doing X. Was this you?”

Examples include:

• “Hey, we saw you running net user and net group commands to enumerate administrative users and groups. Was that you?”
• “Hey, we saw you logged in from an IP address associated with ExpressVPN, which you don’t normally do. Was that you?”
• “Hey, we saw you logged in from a Mac after failing MFA four times. You normally use Windows. Was that you?”
• And so on.

Probing Problems

“Was this you?” is also a tremendously frustrating question. Not just because it is so frequently asked, but because of the reactions it often elicits. Examples include:

• “Yes, that was me running those net user commands. I was unaware that the built-in Windows utilities were not an approved method to view Active Directory users. What would you have me do instead?”
• “Yes, I logged in from ExpressVPN on my phone. Could you please point me to the section in the employee handbook that states I cannot use a VPN?”
• “Yes, I logged into my Mac. It is an approved business system that was approved by security. @SecurityManager, @SecurityDirector, has the usage of corporate Mac systems been disapproved? This Security Analyst is telling me I cannot use it.”
• (No response)
• And so on.

Granted, most folks do not react so negatively. Still, in a world where security departments have to swim uphill both ways to get a modicum of buy-in from the business, annoying users with a barrage of seemingly trivial, time-consuming questions is not a fast way to make friends. Especially when the answer is so plainly obvious to the person being asked: “Of course it was me! My name’s right there!”

On the Blueprint podcast from SANS, Carson Zimmerman, an author of MITRE’s 11 Strategies of a World-Class SOC, states the following:

A proportion of the detections that the SOC will perform, particularly in enterprises where there is a large number of not just users, but privileged users, doing highly privileged things will amount to rules and detections that look for users acting in ways that stray from accepted behavior in cases where a hard rule would be inappropriate. The trap that they can fall into is becoming a spam cannon of, “Was that you?”, “Did you mean to do that?”, “Was that you?”, “Was that you?”, “Was that you?” … and it can be a huge resource drain.

Another problem with “Was this you?” in the cloud identity space is that if it really wasn’t the end user in question, then how can you trust the response that you receive over email, Teams, or Slack? You can’t! At least not with high confidence or a high amount of effort.

Why We Need to Ask the Question, Even Though it Sucks

Despite all of the pain and suffering it causes, I am reluctant to affirm that we, in fact, must continue asking users “Was this you?” This is simply because evil is often indistinguishable from anomalous.

Here are some examples of anomalous events I’ve observed confirmed later to be benign:

• Authentication over RDP from an IPVanish VPN IP address for the first time ever
• Authentication from an IP address associated with a geographical location on the opposite side of the globe 3 minutes after performing activity from a historically known and expected location
• Authentication from an IP address associated with a data center from an anomalous operating system for the user followed by adding a phone with an anomalous operating system for the user as a multi-factor authentication mechanism
• Creating a mailbox rule to move all emails from the IT Service Desk or containing the subject line “phish” to the “Deleted Items” folder.

To throw a wrench into things, I have also observed those same activities all represent confirmed malicious behavior. They are, in fact, textbook examples of what to look for in identity-based threat detection. And yet, 99% of the time, they will represent activity that constitutes no evil whatsoever. Bob just got an IPVanish subscription. Bob was traveling by plane and his phone started routing traffic through a different cell tower. Bob was completing income verification for a home loan and the system reached out from its data center IP address on behalf of his personal computer to his company’s internal SAP instance, but he wasn’t able to complete the process until he added an MFA method. Bob thinks the company phishing warnings and notifications from the IT Service Desk are annoying, so he created an email rule to delete them all.

Thus, despite my strong preference for avoiding misery, we are forced to conclude that the painful, morale-damaging, mind-numbingly stupid, and monotonous task of asking our users “Was this you?” must go on.

But it doesn’t have to be this way. This process can be faster. It can be more accurate. It can be more meaningful. It can be less harmful to relationships. It can be better.

An Ideal Solution

I think there exists enormous opportunity for the cybersecurity industry to massively increase security investigation timeliness and accuracy through the invention of a simple tool: a high-quality activity verification system.

In my mind, this tooling would be best implemented as an extension of existing multi-factor authentication tooling. If you suspect a user account is compromised, and you want to validate whether or not an anomalous login was truly performed by the user in question, you generally can’t with 100% confidence trust the account’s response to something like an email, Teams/Slack message, and so on. Communicating out-of-band is time-consuming and often comes with its own slew of problems. What, then, can we generally trust and rely on? A response to a custom prompt from a trusted device on a multi-factor authentication app.

If an adversary has control of an account, they can easily send, respond to, and hide any message or email they want using the relevant web app. What they can’t do is respond to a custom prompt sent to a specific, trusted device. I emphasize a prompt to a specific, trusted device, as chosen by a human analyst or an automated high-quality decision tree, to mitigate an adversary’s ability to circumvent trust by simply registering their own device within a multi-factor authentication application. For example, a custom “Was this you?” prompt ought be sent to a device that is MDM-compliant, corporate-owned, and registered with Entra ID for over a year as opposed to a random Android phone that was registered 12 minutes ago.

To illustrate this ideal solution, I created a sequence diagram (SOAR = Security Orchestration Automation & Response):

Practical Examples of the Solution

Consider the following example from earlier:

1. An alert is received for an anomalous login from an IP address associated with ExpressVPN. The alert indicates that the usage of ExpressVPN is rare for this user.
2. A human analyst sends a prompt to the user’s device with the following text:

Bob,

We observed that your account logged in to Outlook from an IP address associated with ExpressVPN. We just need to validate that this was known, expected activity. Was this you?

3. The user, receiving a popup notification on their phone, responds to the above prompt with “Yes, this was me” from the following options:
   1. “Yes, this was me.”
   2. “No, this was not me.”
   3. “I’m not sure, please contact me.”

The end result is that what originally could have been a multi-day waste of time due to negative end user perception, missing/ignoring of messages, internal corporate politics, etc., is transformed into an interaction that will almost always be resolved within 30 seconds of the analyst sending the initial prompt.

A significant portion of the timeliness benefit lies in what was not done. The analyst in question did not have to…

• Write or use a pre-cooked complicated SIEM query that takes forever to run to validate if the usage of ExpressVPN was actually anomalous for the user.
• Perform a time-consuming review of activity performed by the user from that IP address or session token, potentially leveraging multiple disparate and unparsed evidence sources that are painful to work with.
• Explain to a befuddled user that there is no corporate policy against using ExpressVPN and that they are not in trouble for using it, but that an investigation into whether usage was expected was necessary for security.

The outcome here is also more accurate because the user’s response coming from a multi-factor authentication app on a trusted device is inherently more trustworthy than the typical status quo of an instant message or an email.

Another example:

1. An alert is received for an anomalous login for a user coming from an unexpected device — a Mac.
2. A human analyst sends a prompt to the user’s device with a canned “Was this you?” message
3. The user chooses, “No, this was not me.”
4. Well-designed, pre-planned, high-quality integration with SOAR immediately:
   1. Locks the user’s account
   2. Sends a notification message to the user, their supervisor, and the security team
   3. Pages the analyst to investigate this urgently.
5. The analyst prioritizes this investigation over any other on their plate.

This time, through the use of SOAR, not only was the identification of a threat done very quickly but so too was the response performed to that threat. For a well-structured and common alert, you could even completely remove the initial human analyst interaction and simply leverage SOAR automations.

What About Conditional Access? Or Okta Adaptive MFA? And Other Flavors of Step-Up Authentication?

Microsoft Conditional Access, Okta Adaptive MFA, Duo Risk-Based Authentication, and so on are all incredibly valuable game changers in identity security. The way these product features generally work is that upon detection of anomalous or threatening login session properties, an additional authentication challenge is required of the user. This helps stop adversaries when signals like impossible travel, usage of suspicious IP addresses, anomalous user agents, etc., are present. While undeniably valuable, the fact of that matter is that attackers are clever and regularly find ways to circumvent these protections. Whether by bypassing MFA requirements or tricking users with MFA fatigue or adversary-in-the-middle phishing attacks, adversaries gain access to accounts. Speaking from experience, these features have not removed the need to ask, “Was this you?”

Furthermore, these product features are great for protecting against cloud identity-related threats. But as in the net user example, which may be indicative of malware on an endpoint, identity-related threats are not the only time when we find ourselves needing to ask, “Was this you?” Malware performing evil on a user’s on-prem corporate workstation is not going to generate an Entra (or any other cloud identity provider) alert. The need to answer the painful question is omnipresent.

What Can We Do Today?

It is very possible to achieve a similar result to my preferred, ideal solution using existing native corporate messaging tooling. Simply replace the MFA app in my solution with your email or instant messaging solution. Responses can be retrieved using instant messaging APIs or a webhook. The end result is the same, though not as trustworthy.

If I were in a typical Microsoft shop F500 corporate cybersecurity role today, I would perform notifications through Teams instant messaging as sent by a “security bot.” I strongly recommend keeping “Was this you?” a question anonymized as coming from “security” at large to ensure more consistent, impartial responses and to reduce overhead. I would collect responses using Power Automate or Azure Logic Apps, both of which could be used to trigger follow-on actions like locking accounts, isolating endpoints, and sending notifications. In situations where a user fails to reply, I would have the bot send a follow-on reminder message as well as ping a human analyst shortly after the original message send time.

While existing automation opportunities are nowhere near as elegant, effective, or trustworthy as the ideal, I think they are a very worthwhile investment. Asking users “Was this you?” is important and best to do as quickly as possible. But it is extremely repetitive and eats up a lot of time. In other words, it is an excellent candidate for automation.