Pinewood Security Bulletin – Account compromise activity

Beschrijving

De afgelopen tijd ziet het Pinewood Security Operations Center (SOC) dat aanvallers er regelmatig in slagen om accounts binnen de Microsoft cloudomgevingen van organisaties over te nemen. De Microsoft cloud is populair, en het is dan ook geen verrassing dat aanvallers zeer geïnteresseerd zijn in de accounts die zich hierin bevinden (geconfigureerd in Microsoft Entra ID, voorheen Azure AD). Het succesvol overnemen van een account kan grote consequenties hebben. Immers, het verkrijgen van toegang tot een dergelijk account stelt een aanvaller in staat om bijvoorbeeld malafide e-mails uit naam van de eigenaar te versturen (Exchange Online) en om vertrouwelijke bestanden in te zien (SharePoint/OneDrive). Verschillende vragen komen dan ook naar boven: hoe kan dit gebeuren, hoe kun je het detecteren, wat gebeurt er na een succesvolle aanval, wat moet je doen als het misgaat en wat kun je doen om het te voorkomen?

Hoe kan dit gebeuren?

Bij vrijwel alle incidenten die het Pinewood SOC de afgelopen tijd heeft gezien, startte een succesvolle inbraak op een account met een zogenoemde Actor-in-the-Middle aanval, kortweg AitM-aanval. Een AitM-aanval is vergelijkbaar met een traditionele phishingaanval, met het verschil dat de aanvaller de gegevens die het slachtoffer invoert op een phishingwebsite niet alleen verzamelt, maar óók direct ter verificatie doorstuurt naar Microsoft. Daardoor krijgt het slachtoffer bijvoorbeeld ook gewoon een verzoek te zien in zijn/haar Authenticator app om de inlogactiviteit te bevestigen. Zodra het slachtoffer dit heeft gedaan, beschikt de aanvaller niet alleen over de gebruikersnaam en wachtwoord van het slachtoffer, maar ook over een session token én een refresh token. Met deze tokens kan de aanvaller zich toegang blijven verschaffen tot het account van het slachtoffer (standaard gedurende 90 dagen), zonder dat de aanvaller daarvoor opnieuw hoeft in te loggen.

Hoe kun je het detecteren?

Het detecteren van malafide inlogpogingen op een account kan vrij complex zijn. Gelukkig levert Microsoft binnen Entra ID Protection diverse alarmen die helpen om een mogelijke inbraak op een account te detecteren. Het belangrijkste alarm hierbij is Atypical travel: volgens de beschrijving van Microsoft gaat dit alarm af wanneer een gebruiker vanaf twee geografisch verschillende locaties inlogt, waarbij minstens één van deze locaties atypisch is voor de gebruiker. Stel bijvoorbeeld dat een gebruiker normaal gesproken altijd inlogt vanaf zijn thuisnetwerk en vanaf het netwerk van zijn werkgever, terwijl de gebruiker nu plotseling inlogt vanaf een adres in Nigeria. Dit is typisch een situatie die een atypical travel alarm triggert en wat een indicatie vormt dat een aanvaller mogelijk misbruik maakt van het account van de gebruiker.

Natuurlijk bestaan er meer manieren om inbraak op een account te detecteren (en meer manieren om op een account in te breken). Het Pinewood SOC heeft de afgelopen maanden dan ook diverse aanvullende detectieregels geïmplementeerd die moeten helpen om malafide gebruik van een account in een zo’n vroeg mogelijk stadium vast te stellen.

Wat gebeurt er na een succesvolle aanval?

Nadat een aanvaller succesvol toegang weet te krijgen tot het account van een slachtoffer, kunnen er allerlei verschillende activiteiten volgen. Veel is hierbij afhankelijk van de intenties van de aanvaller. Om een idee te geven, zijn hier wat mogelijke scenario’s:

• De aanvaller registreert een nieuw verificatiemechanisme zodat hij in staat is om op het account in te blijven loggen, zelfs als de tokens die hij heeft bemachtigd niet langer meer geldig zijn.
• De aanvaller verstuurt uit naam van het slachtoffer phishing e-mails naar een lijst aan bekende contacten van het slachtoffer. Hiermee probeert hij ook de accounts van andere slachtoffers over te nemen. De kans dat nieuwe slachtoffers geraakt worden door een dergelijke phishing e-mail is groot, aangezien ze bekend zijn met de verzender en veelal geen argwaan zullen hebben bij het aanklikken van links die zich in de e-mail bevinden.
• De aanvaller monitort de e-mails die het slachtoffer uitwisselt, in de hoop dat er een conversatie gaat plaatsvinden over een grote betaling. Op dat moment breekt de aanvaller in op de conversatie en zal hij bijvoorbeeld een bericht sturen om aan te geven dat het rekeningnummer van de organisatie is veranderd. Aangezien de andere partij “gewoon” een antwoord ziet op een e-mail binnen een bestaande e-mailconversatie, is de kans groot dat zij de wijziging in het rekeningnummer klakkeloos overneemt en een groot geldbedrag op de rekening van de aanvaller terechtkomt.

Wat moet je doen als het misgaat?

Op het moment dat een account in handen van een aanvaller valt, is het allereerst van groot belang om dit zo snel mogelijk vast te stellen. Het spreekt voor zich dat de schade het kleinst is als de aanvaller al snel weer de toegang tot een account kwijtraakt. Na het vaststellen van misbruik van een account raden wij aan om standaard een aantal stappen uit te voeren:

1. Schakel het account in eerste instantie uit (disable account) zodat de aanvaller geen gebruik meer kan maken van het account. Verklaar tevens direct alle refresh tokens die aan het account hangen ongeldig zodat de aanvaller ook daar geen gebruik meer van kan maken.
2. Ga ervanuit dat de aanvaller volledige controle heeft over de authenticatie-informatie van de gebruiker. Reset daarom het wachtwoord én de verificatiemethoden (MFA) van de gebruiker. Controleer of alle voorgaande MFA-methoden van de gebruiker zijn verwijderd.
3. Het is bekend dat aanvallers na een succesvolle inbraak op een account ook regelmatig mail forwarding rules aanmaken zodat zij toegang blijven houden tot de e-mails van een gebruiker, zelfs als zij de controle over het account zelf zijn kwijtgeraakt. Controleer daarom altijd alle mailbox rules en mailbox forwarding rules die op het account zijn geconfigureerd.
4. In sommige gevallen slaagt een aanvaller er zelfs in om een eigen apparaat (device) te registreren op naam van de gebruiker welke vervolgens vertrouwd wordt. Controleer daarom ook altijd of de lijst aan “enrolled devices” valide is.
5. Controleer tot slot alle activiteiten die vanuit het account zijn uitgevoerd vanaf het moment dat dit account in handen van de aanvaller viel. Maak hiervoor gebruik van de uitgebreide audit-functionaliteiten die Microsoft biedt.

Hoe kun je het voorkomen?

Het is cliché, maar voorkomen blijft altijd beter dan genezen. Er zijn verschillende manieren waarop een organisatie succesvolle aanvallen kan voorkomen. Wij raden dan ook aan nog eens kritisch naar de inrichting van de Microsoft-tenant van de organisatie te kijken en daar waar mogelijk verbeteringen door te voeren. Ga er daarnaast vanuit dat een aanvaller er altijd in kan blijven slagen om een account over te nemen en dat een goede detectie van malafide activiteiten op accounts daarom een essentieel vangnet blijft.

Multifactor-authenticatie

Het spreekt tegenwoordig voor zich dat multifactor-authenticatie standaard moet zijn. Het beschermen van een account op basis van alleen een gebruikersnaam en wachtwoord is uitermate onveilig en zal men alleen op basis van hele stringente restricties mogen toestaan (bijvoorbeeld gebruik van een serviceaccount vanuit één IP-adres). Daarnaast biedt Microsoft tegenwoordig de mogelijkheid tot “MFA number matching”, waarbij de gebruiker een code moet invoeren bij het aanroepen van de multifactor-authenticatie. Uiteraard raden wij het gebruik hiervan sterk aan (sinds mei 2023 is dit ook de standaardoplossing vanuit Microsoft). Verder heeft het gebruik van phishing-resistente MFA-oplossingen de voorkeur boven de oplossingen die wél gevoelig zijn voor phishing, zeker voor het beveiligen van administratieve accounts. Onder phishing-resistente MFA-oplossingen vallen FIDO2 security keys, Windows Hello for Business en certificaatauthenticatie.

Conditional access

Via conditional access biedt Microsoft de mogelijkheid om aanvullende restricties op te leggen aan inlogactiviteiten op de Microsoft-tenant van de organisatie. Specifiek voor het voorkomen van een aanval zoals beschreven in dit artikel, raden wij het volgende aan:

• Verklein de standaard “sign-in frequency” van 90 dagen naar een kortere periode. Deze waarde beschrijft hoe lang een gebruiker maximaal gebruik mag maken van refresh tokens zonder zich opnieuw aan te hoeven melden.
• Vereis dat gebruikers zich alleen kunnen aanmelden vanuit managed en compliant devices. Hoewel dit voor veel organisaties wellicht lastig in te regelen valt, zorgt dit wel voor een veel kleinere kans op misbruik.
• Maak gebruik van de “location”-conditie waarmee het mogelijk is om eisen op te leggen m.b.t. de locatie van waaruit de gebruiker inlogt. Zo is het bijvoorbeeld mogelijk om de toegang te blokkeren vanuit landen waarin de organisatie niet actief is of om alleen maar toegang te verlenen vanuit de netwerken van de organisatie zelf.
• Maak gebruik van Entra ID Protection Risk policies. Microsoft maakt daarbij onderscheid tussen user risk policies en sign-in risk policies. De eerste policy richt zich m.n. op signalen die erop wijzen dat het account van de gebruiker is gecompromitteerd (op basis van activiteiten van de gebruiker over langere tijd), terwijl de tweede policy zich vooral richt op verdachte eigenschappen van de specifieke inlogpoging.  Voor beide policies geldt dat geautomatiseerde actie mogelijk is voor laag, gemiddeld en hoog risico. Microsoft adviseert om bij de user risk policy bij een hoog risico een wachtwoordwijziging te vereisen (incl. de vereiste om opnieuw aan te melden met MFA) en bij de sign-in risk policy een extra MFA-verificatie te vereisen bij een gemiddeld of hoog risico.

Tot slot

Aanvallers zullen continu op zoek blijven gaan naar nieuwe manieren om gebruikersaccounts over te nemen. Veel beveiligingsmaatregelen die Microsoft en klantorganisaties implementeren, leiden uiteindelijk vaak weer tot nieuwe aanvalsmethodieken waarmee de aanvallers pogen deze maatregelen te omzeilen. Het is dan ook belangrijk om de beveiliging van een omgeving continu up-to-date te houden en gebruik te blijven maken van de laatste mogelijkheden en inzichten om succesvolle aanvallen zoveel mogelijk te voorkomen.

Meer informatie

• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-session
• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition
• https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies

Vragen

Voor vragen over deze security bulletin kunt u contact opnemen met het Pinewood Security Operations Center (SOC). Het Pinewood SOC is bereikbaar via +31 15 251 36 33 en via soc@pinewood.nl.

===== ENGLISH =====

Description

Recently, the Pinewood Security Operations Center (SOC) has seen attackers regularly succeed in taking over accounts within organizations’ Microsoft cloud environments. The Microsoft cloud is popular, so it is no surprise that attackers are very interested in the accounts contained within it (configured in Microsoft Entra ID, formerly Azure AD). Successfully taking over an account can have major consequences. After all, gaining access to such an account allows an attacker to, for example, send malicious emails in the owner’s name (Exchange Online) and access confidential files (SharePoint/OneDrive). Several questions therefore arise: how can this happen, how can you detect it, what happens after a successful attack, what should you do if an account gets compromised and what can you do to prevent it?

How can this happen?

In almost all of the incidents the Pinewood SOC has seen recently, a successful break-in to an account started with what is known as an Actor-in-the-Middle attack, or AitM attack for short. An AitM attack is similar to a traditional phishing attack, except that the attacker not only collects the data the victim enters on a phishing website, but also sends it directly to Microsoft for verification. As a result, the victim also will receive e.g. a prompt in his/her Authenticator app to confirm the login activity. Once the victim has done this, the attacker not only possesses the victim’s username and password, but also a session token and a refresh token. With these tokens, the attacker can continue to gain access to the victim’s account (by default for 90 days), without the need to log in again.

How can you detect it?

Detecting rogue login attempts to an account can be quite complex. Fortunately, Microsoft provides several alarms within Entra ID Protection that can help detect a potential intrusion into an account. The most important alarm here is Atypical travel: according to Microsoft’s description, this alarm triggers when a user logs in from two geographically different locations, with at least one of these locations being atypical for the user. For example, suppose a user normally always logs in from his home network and from his employer’s network, and now the user suddenly logs in from an address in Nigeria. This is typically a situation that triggers an atypical travel alarm and which is an indication that an attacker may be abusing the user’s account.

Of course, there are more ways to detect account intrusions (and more ways to break into an account). Accordingly, the Pinewood SOC has implemented several additional detection rules in recent months to help identify malicious use of an account at the earliest possible stage.

What happens after a successful attack?

After an attacker successfully manages to gain access to a victim’s account, a variety of different activities may follow. Much here depends on the attacker’s intentions. To give you an idea, here are some possible scenarios:

• The attacker registers a new authentication mechanism so that he is able to continue logging into the account even if the tokens he obtained are no longer valid.
• The attacker sends phishing emails in the victim’s name to a list of the victim’s known contacts. In doing so, he also tries to take over the accounts of other victims. The chances of new victims being hit by such a phishing email are high, since they are familiar with the sender and will usually not be suspicious when clicking on links located in the email.
• The attacker monitors the emails exchanged by the victim, hoping for a conversation about a large payment. At that point, the attacker breaks into the conversation and will, for example, send a message indicating that the organization’s bank account number has changed. Since the other party “just sees” a response to an email within an existing email conversation, there is a good chance that they will blindly adopt the change in the account number and a large amount of money will end up in the attacker’s account.

What should you do if an account gets compromised?

First of all, the moment an account falls into the hands of an attacker, it is very important to determine this as soon as possible. Obviously, the damage is the least if the attacker quickly loses access to an account again. After determining that an account has been compromised, we recommend a number of standard steps:

1. First disable the account so that the attacker can no longer use it. Also immediately invalidate all refresh tokens attached to the account so that the attacker can no longer use them either.
2. Assume that the attacker has full control over the user’s authentication information. Therefore, reset both the user’s password and authentication methods (MFA). Verify that all the user’s previous MFA methods have been removed.
3. Attackers are also known to regularly create mail forwarding rules after a successful intrusion into an account so that they continue to have access to a user’s emails even if they have lost control of the account itself. Therefore, always check all mailbox rules and mailbox forwarding rules configured on the account.
4. In some cases an attacker even manages to register his own device in the name of the user which is then trusted. Therefore, always check if the list of “enrolled devices” is valid.
5. Finally, verify all activities performed from the account from the time this account fell into the hands of the attacker. To do this, take advantage of the extensive auditing functionality provided by Microsoft.

How can you prevent it?

It’s cliché, but prevention is always better than cure. There are several ways in which an organization can prevent successful attacks. We therefore recommend taking another critical look at the organization’s Microsoft tenant setup and making improvements where possible. In addition, assume that an attacker can always succeed in taking over an account and that proper detection of malicious activity on accounts therefore remains an essential safety net.

Multifactor authentication

It goes without saying these days that multifactor authentication should be standard. Protecting an account based only on a username and password is extremely insecure and should only be allowed on the basis of very stringent restrictions (for example, use of a service account from a single IP address). In addition, Microsoft now offers the option of “MFA number matching,” which requires the user to enter a code when invoking multifactor authentication. Of course, we strongly recommend using this (since May 2023, this is also the default solution from Microsoft). Furthermore, the use of phishing-resistant MFA solutions is preferable to those that are indeed susceptible to phishing, especially for securing administrative accounts. Phishing-resistant MFA solutions include FIDO2 security keys, Windows Hello for Business and certificate authentication.

Conditional access

Through conditional access, Microsoft provides the ability to impose additional restrictions on login activities on the organization’s Microsoft tenant. Specifically for preventing an attack as described in this article, we recommend the following:

• Reduce the default “sign-in frequency” of 90 days to a shorter time period. This value describes the maximum time a user can use refresh tokens without having to sign in again.
• Require that users can only log in from managed and compliant devices. While this may be difficult for many organizations to set up, it does ensure a much lower chance of abuse.
• Make use of the “location” condition that makes it possible to impose requirements on the location from which the user logs in. For example, it is possible to block access from countries in which the organization does not operate or to allow access only from the organization’s own networks.
• Make use of Entra ID Protection Risk policies. Microsoft distinguishes between user risk policies and sign-in risk policies. The first policy focuses on signals that the user’s account has been compromised (based on user activity over time), while the second policy focuses on suspicious characteristics of the specific login attempt. For both policies, automated action is possible for low, medium and high risk. Microsoft recommends that the user risk policy requires a password change at high risk (including the requirement to re-login with MFA) and that the sign-in risk policy requires additional MFA authentication at medium or high risk.

In conclusion

Attackers will continuously continue to look for new ways to take over user accounts. Many security measures implemented by Microsoft and customer organizations often eventually lead to new attack methodologies with which attackers attempt to circumvent these measures. Therefore, it is important to continuously keep an environment’s security up to date and continue to use the latest capabilities and insights to prevent successful attacks as much as possible.

More information

• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-session
• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition
• https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies

Questions

For questions about this security bulletin, please contact the Pinewood Security Operations Center (SOC). The Pinewood SOC can be contacted at +31 15 251 36 33 and via soc@pinewood.nl.