Microsoft 365 em baixo: o que fazer durante a falha e antes da próxima

A 12 de novembro de 2026, às 16:17 UTC, utilizadores de várias regiões deixaram de conseguir abrir as suas caixas de correio do Exchange Online. Boa parte do que depende do Exchange foi atrás: os calendários e o agendamento de reuniões do Teams, partes do SharePoint e do Copilot, as chamadas ao Microsoft Graph para correio, calendário e contactos, e peças da stack de segurança. A Microsoft acompanhou-o como incidente EX1550543, mais o MO1550821 para os serviços que dependem do Exchange Online, e na manhã seguinte ainda estava a restaurar servidores região a região.

Não consegues resolver uma falha na nuvem de outra pessoa. O que controlas é quanto te custa: a rapidez com que sabes, o que os teus utilizadores fazem enquanto esperam, se um atacante aproveita a confusão e o que tens pronto antes da próxima. Este post cobre essas quatro coisas, com um pequeno monitor que testámos e que te avisa por um canal que não depende do Microsoft 365.

O que sabemos desta falha

Estado a 13 de novembro de 2026, de manhã (UTC): os dois incidentes continuam abertos e a Microsoft não publicou a causa raiz. As atualizações diziam:

• Um processo dos servidores afetados que estabelece as ligações seguras ficou sobrecarregado. Esses servidores deixaram de responder e a carga caiu sobre os restantes.
• Começou a reverter uma alteração recente de configuração de rede que coincide com o início do impacto. É uma coincidência no tempo, não uma causa confirmada.
• Suspendeu os deploys enquanto trabalhava na recuperação e disse que não havia indícios de que a falha resultasse de atividade maliciosa.
• O correio recebido está atrasado, não perdido.

Vamos atualizar este post quando sair o relatório pós-incidente. Se o teu tenant foi afetado, guarda já uma cópia do incidente a partir do Service health: o histórico só cobre 30 dias.

Os primeiros 15 minutos: és tu ou é a Microsoft?

O pior uso da primeira hora é depurar a tua própria rede enquanto o problema está no centro de dados do fornecedor. Antes de alguém mudar alguma coisa:

• Vê o Service health no centro de administração do Microsoft 365 (Health e depois Service health). Um incidente ativo aparece entre os problemas em que a Microsoft está a trabalhar, com um ID como EX1550543; abre-o e acompanha as atualizações. Os administradores de Helpdesk e de Service Support também o conseguem ver, por isso quem responde primeiro não precisa de um Global Administrator.
• Se não consegues entrar no centro de administração, usa a página pública de estado em status.cloud.microsoft, que existe precisamente para este caso.
• Se ainda não aparece nada, testa a partir de fora da tua rede, por exemplo num telemóvel com dados móveis. Se também falhar aí, reporta-o com "Report an issue" na página do Service health. Nos incidentes grandes, o aviso oficial costuma chegar depois das primeiras queixas dos utilizadores.
• Aponta a hora de início que observaste, os serviços afetados e o número de utilizadores. Vais precisar disso para o teu registo do incidente e para qualquer pedido de créditos de serviço.

Avisa as pessoas por um canal que continue a funcionar

Se a única forma de chegares à tua equipa é o email ou o Teams, não tens forma de chegar a ela. Envia uma mensagem curta por algo fora do Microsoft 365: SMS, uma página de estado alojada noutro sítio, um grupo de mensagens criado com antecedência. Diz três coisas:

• O que está em baixo, e que é uma falha do fornecedor, não algo que eles fizeram.
• O que usar entretanto: o telefone, o chat alternativo combinado, o correio que já está na cache do Outlook para leitura.
• O que não fazer: não reinstalar o Office, não apagar o perfil do Outlook, não mudar a password. Nada disso ajuda, e cada uma dessas coisas gera trabalho ao suporte durante dias depois de o serviço voltar.

Depois publica atualizações a horas fixas, mesmo quando nada mudou. O silêncio faz as pessoas improvisarem.

As armadilhas de segurança que uma falha abre

Uma falha é um evento de segurança mesmo quando ninguém atacou ninguém. As defesas em que confias podem estar degradadas, os teus utilizadores estão confusos e à espera de mensagens estranhas, e os teus administradores estão sob pressão para fazer alguma coisa.

• Phishing que usa a falha como pretexto. Conta com mensagens como "a tua caixa de correio foi afetada, inicia sessão aqui para a restaurar" durante o incidente e nos dias seguintes. Acrescenta uma linha à tua mensagem sobre a falha: a equipa de TI nunca te vai pedir para iniciares sessão através de um link para recuperares a tua caixa de correio, e qualquer mensagem que o faça deve ser reportada.
• A deteção pode ter ficado em parte cega. Entre os serviços indicados como afetados estavam o Safe Links do Defender for Office 365, que podia não conseguir verificar URLs, e os portais do Defender XDR e do Purview. O que chegou ou foi clicado nessa janela merece um segundo olhar quando o serviço voltar.
• Não improvises alterações de acesso. Desligar o MFA ou excluir toda a gente de uma política de Conditional Access para "resolver o início de sessão" não adianta nada quando o problema está nos servidores de correio do fornecedor, e a exceção costuma sobreviver ao incidente. As emergências de início de sessão resolvem-se com o que preparaste antes: políticas de Conditional Access de contingência, em modo report-only, que ativas numa emergência real, e duas ou mais contas de acesso de emergência só na cloud, com FIDO2 ou autenticação baseada em certificados, validadas pelo menos a cada 90 dias.
• Atalhos na sombra. Quando o correio cai, as pessoas reencaminham trabalho para contas pessoais e partilham ficheiros com o que tiverem à mão. Dá-lhes uma alternativa autorizada antes de encontrarem a delas e verifica depois o que saiu pela porta das traseiras.
• Congela as tuas próprias alterações. A Microsoft suspendeu os seus deploys durante o incidente; faz o mesmo. Uma alteração feita durante uma falha baralha o diagnóstico e tira fiabilidade ao teu próprio registo do incidente.

Se usas o Defender for Office 365, esta consulta de advanced hunting lista os URLs clicados a partir do correio, do Teams e das apps do Office dentro da janela do incidente, agrupados para revisão. Ajusta a janela às horas que observaste:

UrlClickEvents
| where Timestamp between (datetime(2026-11-12T16:00:00Z) .. datetime(2026-11-13T12:00:00Z))
| summarize Clicks = count(), Users = dcount(AccountUpn), Actions = make_set(ActionType)
    by Url, ThreatTypes
| order by Users desc

Começa pelos URLs clicados por vários utilizadores e por tudo o que já tenha um veredito de ameaça. Depois confronta o resto com o que as tuas ferramentas dizem hoje: um link que não pôde ser verificado durante a falha pode ter veredito agora.

O correio atrasa, mas e as tuas aplicações?

O correio recebido aguenta bem uma falha, porque o SMTP foi feito para isso. Um servidor de envio que não consegue entregar guarda a mensagem e volta a tentar, e a norma espera que os remetentes continuem a tentar durante pelo menos quatro a cinco dias. É por isso que o correio deste incidente se atrasou em vez de se perder.

As tuas próprias aplicações são outra história. Tudo o que envia através do Microsoft Graph ou de SMTP AUTH (formulários de contacto, faturas, emails de recuperação de password, notificações de alertas) falha no momento em que tenta enviar. Se responde com um erro e segue em frente, a mensagem, e o que o utilizador escreveu, perde-se. Durante este incidente, os pedidos do Graph para correio, calendário e contactos foram indicados como sujeitos a esgotar o tempo de espera.

A correção é banal e barata:

• Primeiro guarda, depois envia. Escreve o envio na tua própria base de dados ou fila, confirma ao utilizador e envia a partir de um worker.
• Volta a tentar com backoff, durante horas e não segundos, e alerta quando a fila crescer.
• Define um timeout em cada chamada ao fornecedor, para que um pedido pendurado não prenda indefinidamente um worker ou um utilizador.
• Não envies alertas operacionais através do tenant que estás a vigiar. Se os alertas de prevenção chegam pelo Outlook, chegam depois da falha.

Vigia o Microsoft 365 a partir de fora do Microsoft 365

O Service health pode enviar-te emails, mas o correio do Microsoft 365 pode ser precisamente o que não consegues ler. Os mesmos incidentes estão disponíveis no Microsoft Graph, por isso podes encaminhá-los para qualquer lado. O script abaixo consulta a API de problemas do service health e publica num webhook de chat: Slack, Mattermost, Google Chat ou qualquer outro que aceite um campo JSON text. Avisa quando há:

• um incidente novo nos serviços que indicares;
• uma mudança de estado ou uma atualização nova num incidente aberto;
• um incidente que fecha;
• falhas do próprio monitor a chegar ao Graph ou ao endpoint de início de sessão em três execuções seguidas, porque numa falha grande isso pode ser a primeira coisa a cair.

Precisa de um registo de aplicação com a permissão de aplicação ServiceHealth.Read.All do Microsoft Graph, concedida por um administrador, e de um client secret. Em produção, uma credencial de certificado é melhor do que um secret; o secret deixa o exemplo mais curto.

#!/usr/bin/env python3
"""Alert on Microsoft 365 service incidents through a channel that does not depend on Microsoft 365.
Python 3.9+, standard library only. Run it every five minutes from cron or a systemd timer.

Needs an app registration with the Microsoft Graph application permission ServiceHealth.Read.All
(admin consent granted) and a client secret. Reads the tenant's service health issues, alerts on
new incidents, on status changes and new posts, and on incidents that close. If Graph or the sign-in
endpoint cannot be reached several runs in a row, that is an alert too: in a large outage, the
monitor's own dependencies may be the first thing to fail.
"""
import html
import json
import os
import re
import sys
import urllib.parse
import urllib.request

TENANT_ID = os.environ["TENANT_ID"]
CLIENT_ID = os.environ["CLIENT_ID"]
CLIENT_SECRET = os.environ["CLIENT_SECRET"]
WEBHOOK_URL = os.environ["WEBHOOK_URL"]  # Slack, Mattermost, Google Chat... not Teams, not email in Microsoft 365
SERVICES = {s.strip().lower() for s in os.environ.get("SERVICES", "").split(",") if s.strip()}
ADVISORIES = os.environ.get("INCLUDE_ADVISORIES") == "1"
STATE_FILE = os.environ.get("STATE_FILE", "/var/lib/m365-health/state.json")
FAILS_BEFORE_ALERT = int(os.environ.get("FAILS_BEFORE_ALERT", "3"))
LOGIN_URL = os.environ.get("LOGIN_URL", "https://login.microsoftonline.com")
GRAPH_URL = os.environ.get("GRAPH_URL", "https://graph.microsoft.com/v1.0")


def request(url, data=None, headers=None):
    req = urllib.request.Request(url, data, headers or {})
    with urllib.request.urlopen(req, timeout=30) as resp:
        return json.load(resp)


def fetch_issues():
    form = urllib.parse.urlencode({
        "grant_type": "client_credentials", "client_id": CLIENT_ID, "client_secret": CLIENT_SECRET,
        "scope": "https://graph.microsoft.com/.default"}).encode()
    token = request(f"{LOGIN_URL}/{TENANT_ID}/oauth2/v2.0/token", form)["access_token"]
    issues, url = [], f"{GRAPH_URL}/admin/serviceAnnouncement/issues"
    while url:  # the list is paged; follow every @odata.nextLink
        page = request(url, headers={"Authorization": f"Bearer {token}"})
        issues += page.get("value", [])
        url = page.get("@odata.nextLink")
    return issues


def relevant(issue):
    if issue.get("isResolved"):
        return False
    if str(issue.get("classification", "")).lower() != "incident" and not ADVISORIES:
        return False
    return not SERVICES or str(issue.get("service", "")).lower() in SERVICES


def latest_post(issue):
    posts = sorted(issue.get("posts") or [], key=lambda p: p.get("createdDateTime", ""))
    if not posts:
        return ""
    text = html.unescape(re.sub(r"<[^>]+>", " ", posts[-1].get("description", {}).get("content", "")))
    return " ".join(text.split())[:400]


def describe(event, issue):
    return (f"[M365] {event}: {issue['id']} | {issue.get('service')} | {issue.get('status')}\n"
            f"{issue.get('title', '')}\n{latest_post(issue)}").strip()


def send(text):
    request(WEBHOOK_URL, json.dumps({"text": text}).encode(), {"Content-Type": "application/json"})


def main():
    try:
        with open(STATE_FILE) as f:
            state = json.load(f)
    except FileNotFoundError:
        state = {"open": {}, "fails": 0, "fail_alerted": False}

    messages = []
    try:
        everything = {i["id"]: i for i in fetch_issues()}
    except Exception as exc:  # sign-in endpoint, Graph or the network
        state["fails"] += 1
        if state["fails"] >= FAILS_BEFORE_ALERT and not state["fail_alerted"]:
            messages.append(f"[M365] Monitor cannot reach Microsoft Graph, {state['fails']} runs in a row: {exc}")
            state["fail_alerted"] = True
        everything = None
    else:
        if state["fail_alerted"]:
            messages.append("[M365] Monitor reaches Microsoft Graph again")
        state["fails"], state["fail_alerted"] = 0, False
        current = {k: i for k, i in everything.items() if relevant(i)}
        for key, issue in current.items():
            mark = f"{issue.get('status')}|{issue.get('lastModifiedDateTime')}"
            if key not in state["open"]:
                messages.append(describe("NEW", issue))
            elif state["open"][key] != mark:
                messages.append(describe("UPDATE", issue))
        for key in sorted(state["open"].keys() - current.keys()):
            closed = everything.get(key, {"id": key, "service": "-", "status": "no longer listed"})
            messages.append(describe("CLOSED", closed))
        state["open"] = {k: f"{i.get('status')}|{i.get('lastModifiedDateTime')}" for k, i in current.items()}

    try:
        for text in messages:
            send(text)
    except Exception as exc:
        print(f"alert delivery failed, state not saved so the next run retries: {exc}", file=sys.stderr)
        return 2
    os.makedirs(os.path.dirname(os.path.abspath(STATE_FILE)), exist_ok=True)
    with open(STATE_FILE + ".tmp", "w") as f:
        json.dump(state, f)
    os.replace(STATE_FILE + ".tmp", STATE_FILE)
    return 1 if everything is None else 0


if __name__ == "__main__":
    sys.exit(main())

Corre-o a cada cinco minutos a partir de uma máquina que não dependa do Microsoft 365, com o secret num ficheiro de ambiente que só a conta de serviço consegue ler:

# /etc/m365-health.env (chmod 600, owned by the account that runs the monitor;
# that account must be able to write the STATE_FILE directory)
TENANT_ID='00000000-0000-0000-0000-000000000000'
CLIENT_ID='11111111-1111-1111-1111-111111111111'
CLIENT_SECRET='your-client-secret'
WEBHOOK_URL='https://chat.example.com/hooks/your-webhook-id'
SERVICES='Exchange Online,Microsoft Teams,SharePoint Online,Microsoft 365 suite'
STATE_FILE='/var/lib/m365-health/state.json'

# crontab of that account: every five minutes
*/5 * * * * set -a; . /etc/m365-health.env; set +a; /usr/bin/python3 /opt/m365-health/m365_health_watch.py

Testámo-lo contra uma simulação do endpoint de início de sessão e da API de problemas, construída a partir do formato de resposta documentado e a reproduzir os IDs deste incidente. Os 15 passos incluíram um incidente que só aparece na segunda página de resultados, um estado enviado como ServiceDegradation num problema e como serviceDegradation noutro (a documentação mostra as duas formas), um webhook em baixo e três execuções falhadas seguidas contra o endpoint de início de sessão e o Graph. Com o webhook em baixo, o script terminou com erro sem guardar o estado, e a execução seguinte entregou o alerta pendente em vez de o perder. Duas cópias estragadas de propósito, uma que comparava a classificação a distinguir maiúsculas e outra que ignorava a segunda página, não viram o incidente do Exchange e falharam o teste. Os alertas tinham este aspeto:

[M365] NEW: EX1550543 | Exchange Online | ServiceDegradation
Users may be unable to access their mailbox through multiple connection methods
Title: Users may be unable to access their mailbox

[M365] UPDATE: EX1550543 | Exchange Online | RestoringService
Users may be unable to access their mailbox through multiple connection methods
We've begun reverting a recent network configuration change & restarting

[M365] Monitor cannot reach Microsoft Graph, 3 runs in a row: HTTP Error 503: Service Unavailable

[M365] Monitor reaches Microsoft Graph again

[M365] CLOSED: EX1550543 | Exchange Online | ServiceRestored
Users may be unable to access their mailbox through multiple connection methods
We've begun reverting a recent network configuration change & restarting

Prepara-te antes da próxima

Não foi o primeiro grande incidente do Microsoft 365 e não vai ser o último. O que convém ter pronto:

• Avisos do Service health que te cheguem. No Service health, Customize e depois Email envia notificações de incidentes novos e de mudanças de estado para até dois endereços por administrador. Faz com que pelo menos um seja um endereço fora do Microsoft 365, instala a app Microsoft 365 Admin nos telemóveis de prevenção e corre um monitor como o de cima.
• Uma lista de contactos e um runbook que consigas ler com o Microsoft 365 em baixo. Se o plano para falhas vive no SharePoint ou no OneNote, ninguém o consegue abrir quando importa. Guarda uma cópia noutro sítio, e os números de telefone em papel.
• Um canal alternativo combinado, criado e testado antes do dia em que precisares dele, com as pessoas que o vão usar já lá dentro.
• Contas de acesso de emergência: pelo menos duas, só na cloud, no domínio onmicrosoft.com, com autenticação resistente a phishing diferente da dos teus administradores habituais, excluídas das políticas de Conditional Access que bloqueiam o início de sessão, com um alerta em cada utilização e testadas pelo menos a cada 90 dias.
• Aplicações que põem em fila em vez de falhar, como descrito acima.
• Um exercício de mesa: "O Exchange Online está em baixo durante um dia de trabalho". Percorre quem dá pela falha, quem decide, o que se diz aos utilizadores e que processos de negócio param. Uma hora à volta de uma mesa encontra as lacunas que, de outra forma, encontrarias ao vivo.

Os backups são outro plano: protegem-te de perder dados, não de não conseguires chegar a eles. Para o lado da perda de dados, vê como montar backups que sobrevivem ao ransomware.

Quando o serviço voltar

• Guarda o relatório pós-incidente a partir do incidente no Service health quando a Microsoft o publicar. O histórico só cobre 30 dias.
• Regista o teu próprio impacto: início e fim tal como os viste, as equipas afetadas, os atalhos usados e o que se perdeu. É esse registo que torna o próximo plano melhor do que este.
• Pede o crédito de serviço se tiveres direito a ele. Os créditos do SLA da Microsoft não são aplicados automaticamente: um administrador tem de submeter o pedido a partir do centro de administração e, para os serviços do Microsoft 365, o pedido tem de chegar até ao fim do mês civil seguinte ao do incidente. Confirma o SLA em vigor para os serviços que compras.
• Remove as exceções temporárias. Qualquer alteração de políticas, regra de reencaminhamento ou link de partilha criado durante a falha é revisto e removido.
• Corre a consulta de hunting e revê os reportes de phishing dessa janela.

O nosso NOC 24/7 junta verificações do fornecedor como esta aos teus próprios alertas e vigia-as a toda a hora, para saberes de uma falha antes dos teus clientes. A nossa equipa de cibersegurança cobre a outra metade: o phishing, as alterações de acesso e a revisão posterior.

Avaliação gratuita da preparação para incidentes

Se esta falha apanhou a tua equipa sem plano, revemo-lo contigo:

• Deteção: como saberias da próxima falha do fornecedor e se esses avisos te chegam com o Microsoft 365 em baixo.
• Resposta: o canal alternativo, as mensagens aos utilizadores, as contas de acesso de emergência e as políticas de acesso de contingência.
• Dependências: que aplicações e processos param quando o correio, o calendário ou o início de sessão não estão disponíveis, e quais deles perdem dados.

Recebes por escrito uma lista das lacunas e a correção para cada uma, sem qualquer compromisso.

Pede a tua avaliação gratuita da preparação para incidentes, ou vê as nossas operações de NOC 24/7.