Si bien podría haber probado ciegamente la instancia de Exchange Online, esto probablemente habría resultado en 0 hallazgos de alto impacto. Suponiendo que Microsoft sepa lo que están haciendo, es poco probable que hubiera encontrado una vulnerabilidad de ejecución remota de código de alto impacto sin acceder al código fuente.
A menudo, los métodos heredados y / o las nuevas funciones permanecen ocultos en una interfaz de usuario y este era mi enfoque principal (y la oportunidad de obtener acceso remoto) que simplemente no se puede encontrar desde una perspectiva de caja negra.

Desde una vista de alto nivel, Exchange Server expone una serie de API web, así como una interfaz remota de PowerShell para usuarios y administradores. Algunas de las API en realidad representan gran parte de la misma funcionalidad para los endpoints de backend. Por ejemplo, el Panel de control de Exchange (/ ecp) es una aplicación web simple de asp.net que implementa una serie de controladores de asp.net que en su mayoría envuelven la ejecución de cmdlet en la interfaz remota de powershell (/ powershell).

Como estaba apuntando a Exchange Online, no importaba si tenía una vulnerabilidad de ejecución remota de código antes o después de la autenticación. El impacto, con respecto a Exchange Online, habría sido el mismo ya que se puede crear un inquilino malicioso con facilidad y aplicar los permisos necesarios. Esta es la diferencia fundamental entre las tecnologías basadas en la nube y los entornos locales que se pasa por alto con demasiada frecuencia. ¡Su modelo de amenazas es diferente en la nube!

Más info: https://srcincite.io/blog/2021/01/12/making-clouds-rain-rce-in-office-365.html

Saludos.