Week 46, 2022
Last updated
Last updated
Have you ever noticed an IP address and thought to yourself: “where have seen that before?” Well, Oort can now answer that question for you with a couple of clicks. We’re rolling out context menus for IP addresses in the product so that when you see an IP address, you can click on it and pivot to a list of other users that have come from the same IP address. Or to simply jump right into a view of the activity coming from that IP. Just click the IP address in the user list and then one of the menu options to see the results.
Oort has included a feature to detect users who sign in from blocked browsers. Most employees use a handful of well-known web browsers. Attackers might use something else. We’ve added a few more entries to our blocked browsers list based on our threat research: lync, iris, and google_bot.
What happens when you lose your phone but you still have work to do and you can’t sign in with your multi-factor auth application? Call your helpdesk and they might issue you a temporary bypass code. We’ve recently been spending more time with Duo and this innocuous workaround can also be an attack vector. When a bypass code is created and used, Oort flags this down so that security teams can be aware and investigate if needed. With this week’s update, we’ve made it even easier to see who created the bypass code and what IP address they were signed in from at the time as well as the age of that IP address. Here we show that someone named Dennis Harper created a bypass code for Herburger Bagan from IP address 33.44.31.33.
Sharing information between your work email and your personal email can be tempting. Maybe you want a unified inbox and calendar. Or maybe you want to exfiltrate data from your employer. Either way, you may have run into Google’s capabilities to turn on email forwarding. For most security-minded organizations, this is a problem. Employees should not be forwarding emails outside of your organization, especially when so many authentication flows can be overridden if the attacker has access to your inbox. “Forgot password” flows make it too easy to takeover an account once the email is compromised and your organization has no control over personal inboxes. Oort detects when users add email forwarding rules to their accounts. And further, we now make it easier to see where emails are being forwarded to and when this was configured.
Usually, access to company applications comes in the form of an access request process. You request access to an application through a portal of some kind, a responsible individual such as your manager or the application owner approves it, and you get added to a group with a bunch of other users of that application. That’s how it typically works, but in some cases we take shortcuts and self-assign applications. Without a clear separation of duties, users can essentially assign their own privileges and without a group separating individual users from the applications they access, administrators are stuck with one-off permissions. Fortunately Oort now makes it even easier to see which applications were directly assigned to an individual and which applications were also self-assigned.
Not everyone is using phishing-resistant MFA quite yet. In fact, most of us are still using SMS and Push Notifications. It’s one thing to have these forms of MFA configured on your account and another thing entirely to be using them actively to sign in to sensitive applications.
This week we roll out a new check: “Weak MFA Was Used to Successfully Sign In” to help keep tabs on users who might be stuck in their ways and still using weaker forms of MFA. As with other checks, an Oort admin can configure automation to automatically message users and their managers when we notice this behavior to carefully nudge them back in the right direction (toward whichever MFA strategy your company has adopted).
Active in Okta, Terminated in Workday. That’s the nightmare scenario for many internal auditors. Since its inception, Oort has detected inconsistencies across multiple sources of identity. In fact, dealing with multiple different identity sources is our specialty. With this update, we’re making that capability even more robust in its ability to detect inconsistent states with fewer false positives.
Oort now embeds risk information for high risk activities from Microsoft Azure AD. For any activity events that Microsoft Azure AD deems risky, Oort surfaces this information and the context around it into our detailed view for the event so that admins can take a deeper look.
Enable slack notifications for email notification targets.
User-friendly messages when we encounter query parsing errors on the Users screen.
Show all Azure AD sign-in activities, including those with duplicate IDs - the ID from Azure AD sign-in activities is documented as “Unique ID representing the sign-in activity”. However, we see that ID is not unique, but rather acts as a correlation ID used to bundle multiple activities in a sign-in attempt. These activities can span over a few seconds. We now use the event timestamp along with event ID to uniquely identify an Azure AD sign-in activity.
Exclude password failure events from MFA flood query to reduce false alerts.
Graceful handling of 404 responses from ServiceNow.
Create a unified IDP check report when multiple IDP are failing the same check.
Recollect Azure AD applications in order to reflect credentials update, that is not reflected in MS Graph “delta” API.
