@inversecos

There are many ways an attacker can maintain persistence and create ‘backdoors’ in Azure allowing them re-entry back into the environment. Persistence is important to an attacker if compromised accounts have been discovered and removed by the victim organisation as the attackers still need to find a way to re-gain access to the environment.  Installation of a webhook to interact with malicious runbooks created through automation accounts is one way an attacker can re-gain access into a tenant if compromised account access has been revoked. I was inspired to write this blog post about how to detect this technique when I came across an excellent post  written by Karl Fosaaen  detailing how an attacker can abuse automation accounts to maintain persistence. I have broken down this blog post into two sections covering both the detection methodology and the attack flow. For a more detailed attack flow, I urge you to take a read Karl’s blog as I took what he detailed in his post...

During the Solarwinds breach  performed by Russian threat actors, one of the techniques utilised by the threat actors to gain control of a victim's Azure Active Directory (AAD) was to create an AAD backdoor through identity federation. The implication of this attack was that the threat actors were able to log in and impersonate any Microsoft 365 (M365) user and bypass all requirements for MFA as well as bypass any need to enter a valid password. As you can imagine, if the correct detection controls are not in place – this can allow persistence for the threat actors to impersonate any user and maintain access and control of the victim’s AAD / M365 instance. The technique of backdooring AAD is a technique that tends to be used post-compromise – whereby an attacker has already gained access to an account with Global Administrator or Hybrid Identity Administrator privileges. As such, it’s crucial organisations are monitoring for accounts that get given these two privileges. There are m...

If an attacker gains access to an Azure tenant (with sufficient permissions) they can add a “secret” or a “certificate” to an application. This will allow an attacker single-factor access to Azure allowing the attacker to persist within the client environment. Further, each application that exists within an Azure tenant has a service principal automatically assigned/created. This happens every time an application is registered within an Azure portal. A service principal account is basically an identity that’s used by applications, tools to access resources / perform automated actions.   Attackers want to target service principals because: Service accounts and service principals do not have MFA Attackers can log into Azure using a service principal account These accounts exist with all applications in Azure (most companies have several)  These accounts cannot be controlled through conditional access This blog post is going to show you how to create / register an applicatio...

I worked a case recently where unauthenticated threat actors were able to access and perform reconnaissance and session manipulation in Citrix via API requests. These threat actors proceeded to abuse single-sign-on (SSO) for access. As such, I wrote this blog post to highlight some of the things to be aware of when hunting through Citrix logs that can hopefully help some security analysts when they're performing their threat hunts / investigations. Please note, how and whether this works depends on your clients Citrix configuration and settings. The reason why this is interesting to someone in a blue team is because an unauthenticated attacker could potentially (depending on the Citrix configuration) do the following: Enumerate resources available to a user i.e. what hosts they have access to and what method Force sessions to last longer without signing the attacker out Detect what methods of authentication are utilised (5 documented) and if SSO is enabled Abuse SSO for access to r...

In my previous blog post, I detailed an attack matrix for Microsoft 365 (M365), documenting the various attacks and actions on objectives that can be taken by threat actors. My original matrix did not touch on some other hybrid attacks that can happen on Azure AD which are relevant to the Microsoft Cloud environment. As such, I have modified and updated the attack matrix below to show all the various attacks collated into one matrix. For those of you who are not familiar with M365 or Azure AD (AAD), the reason I built this matrix is because the Mitre O365 matrix did not include a comprehensive list of all the various attack vectors. To be a good responder / defender, it’s important to understand the different types of attacks that your organisation or client may be plagued with. Attacks on Azure AD and M365 are not limited to simple business email compromise cases (BECs) but are now actively being exploited by nation-state APT groups. The reason that these actors choose the cloud as ...