Amazon OpenSearch Ingestion now supports a unified ingestion endpoint that can accept all three OpenTelemetry observability signals — logs, metrics, and traces — through a single pipeline. Previously, customers who wanted to ingest all three OpenTelemetry data types had to create and manage three separate pipelines, one for each signal type. With this launch, a single pipeline can now receive any combination of OpenTelemetry signals, simplifying pipeline architecture and reducing operational overhead.
Customers can now build centralized observability pipelines that consolidate logs, metrics, and traces in one place, making it easier to correlate signals and gain a holistic view of application health. Teams operating at scale can reduce the number of pipelines they manage, lowering infrastructure costs and simplifying access control, monitoring, and lifecycle management. This also makes it easier to adopt OpenTelemetry incrementally as teams can begin with one signal type and add others over time without any pipeline reconfiguration.
The unified ingestion endpoint for OpenTelemetry data is supported in all regions that Amazon OpenSearch Ingestion is currently available. Customers can get started by using the new unified OpenTelemetry source in their pipeline configuration via the AWS Management console or using the AWS CLI and point their OpenTelemetry clients to the new unified endpoint.
Amazon OpenSearch Ingestion now supports a unified ingestion endpoint that can accept all three OpenTelemetry observability signals — logs, metrics, and traces — through a single pipeline. Previously, customers who wanted to ingest all three OpenTelemetry data types had to create and manage three separate pipelines, one for each signal type. With this launch, a single pipeline can now receive any combination of OpenTelemetry signals, simplifying pipeline architecture and reducing operational overhead. Customers can now build centralized observability pipelines that consolidate logs, metrics, and traces in one place, making it easier to correlate signals and gain a holistic view of application health. Teams operating at scale can reduce the number of pipelines they manage, lowering infrastructure costs and simplifying access control, monitoring, and lifecycle management. This also makes it easier to adopt OpenTelemetry incrementally as teams can begin with one signal type and add others over time without any pipeline reconfiguration. The unified ingestion endpoint for OpenTelemetry data is supported in all regions that Amazon OpenSearch Ingestion is currently available. Customers can get started by using the new unified OpenTelemetry source in their pipeline configuration via the AWS Management console or using the AWS CLI and point their OpenTelemetry clients to the new unified endpoint. To learn more and get started, visit the Amazon OpenSearch Ingestion documentation.
We’re excited to announce Amazon GameLift Servers DDoS Protection, a new feature that helps game developers protect session-based multiplayer games that utilize Amazon GameLift Servers to help improve overall game session resiliency. DDoS Protection is designed to defend against denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks, providing proactive, User Datagram Protocol (UDP)-based traffic protection–without the need for manual byte matching, and with negligible latency added.
Amazon GameLift Servers DDoS Protection co-locates a relay network directly alongside your game servers. The relay authenticates client traffic using access tokens so that only authorized traffic reaches the server. The feature also enforces per-player traffic limits to help prevent disruptions, even from seemingly legitimate sources. Game developers can use DDoS Protection to protect against targeted disruptions to specific players or entire game sessions. Check out the Amazon GameLift Servers release notes to get started through the console or API, with sample code provided for popular game engines including Unreal Engine and native C++.
Amazon GameLift Servers DDoS Protection is available at no additional cost to Amazon GameLift Servers customers and is initially available in the following regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo), Pacific (Seoul).
We’re excited to announce Amazon GameLift Servers DDoS Protection, a new feature that helps game developers protect session-based multiplayer games that utilize Amazon GameLift Servers to help improve overall game session resiliency. DDoS Protection is designed to defend against denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks, providing proactive, User Datagram Protocol (UDP)-based traffic protection–without the need for manual byte matching, and with negligible latency added.
Amazon GameLift Servers DDoS Protection co-locates a relay network directly alongside your game servers. The relay authenticates client traffic using access tokens so that only authorized traffic reaches the server. The feature also enforces per-player traffic limits to help prevent disruptions, even from seemingly legitimate sources. Game developers can use DDoS Protection to protect against targeted disruptions to specific players or entire game sessions. Check out the Amazon GameLift Servers release notes to get started through the console or API, with sample code provided for popular game engines including Unreal Engine and native C++.
Amazon GameLift Servers DDoS Protection is available at no additional cost to Amazon GameLift Servers customers and is initially available in the following regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo), Pacific (Seoul).
Amazon Lightsail now lets you deploy OpenClaw, a private self-hosted AI assistant, on your own cloud infrastructure in a simple and secure manner.
Every Lightsail OpenClaw instance ships with built-in security controls, pre-configured and ready to use. Sandboxing isolates each agent session for improved security posture. One-click HTTPS access puts the OpenClaw dashboard in your browser securely, without requiring manual TLS configuration. Device pairing authentication ensures only your authorized devices can connect to your assistant. Automatic snapshots back up your configuration continuously, so you never lose your setup. Amazon Bedrock serves as the default model provider for Lightsail OpenClaw, and you can swap models or connect to Slack, Telegram, WhatsApp, and Discord as per your requirements.
Amazon Lightsail is available in 15 AWS Regions including US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (London), Asia Pacific (Tokyo), and Asia Pacific (Jakarta). To get started, visit the Lightsail console. For pricing and other details, visit the Amazon Lightsail pricing and quick start documentation pages.
Amazon Lightsail now lets you deploy OpenClaw, a private self-hosted AI assistant, on your own cloud infrastructure in a simple and secure manner. Every Lightsail OpenClaw instance ships with built-in security controls, pre-configured and ready to use. Sandboxing isolates each agent session for improved security posture. One-click HTTPS access puts the OpenClaw dashboard in your browser securely, without requiring manual TLS configuration. Device pairing authentication ensures only your authorized devices can connect to your assistant. Automatic snapshots back up your configuration continuously, so you never lose your setup. Amazon Bedrock serves as the default model provider for Lightsail OpenClaw, and you can swap models or connect to Slack, Telegram, WhatsApp, and Discord as per your requirements. Amazon Lightsail is available in 15 AWS Regions including US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (London), Asia Pacific (Tokyo), and Asia Pacific (Jakarta). To get started, visit the Lightsail console. For pricing and other details, visit the Amazon Lightsail pricing and quick start documentation pages.
Amazon OpenSearch Ingestion now supports Amazon Managed Service for Prometheus as a sink, making it possible to build fully managed, end-to-end metrics ingestion pipelines without any custom forwarding infrastructure. With this launch, customers can now manage their entire metrics ingestion workflow using the same pipeline infrastructure they already use for logs and traces.
Customers can now choose the right destination for each observability signal — sending logs and traces to Amazon OpenSearch Service for powerful full-text search, log analytics, and trace correlation, while routing metrics to Amazon Managed Service for Prometheus for time-series storage and analysis. This flexibility allows teams to build purpose-fit observability pipelines that leverage the strengths of each service without compromising on data fidelity or analytical capability. Amazon OpenSearch Ingestion’s built-in data transformation and enrichment capabilities allow customers to prepare and refine metrics before they land in Amazon Managed Service for Prometheus, improving data quality and consistency. Once metrics are in Amazon Managed Service for Prometheus, customers can query them using Prometheus Query Language to analyze trends, configure alerting rules to get notified when metrics cross defined thresholds, and visualize their data using Amazon Managed Grafana for rich, customizable views of infrastructure and application health.
The feature is supported in all regions that Amazon OpenSearch Ingestion and is currently available. Customers can get started by using the new sink for Amazon Managed Service for Prometheus in their pipeline configuration via the AWS Management console or using the AWS CLI and start ingesting metrics into their Amazon Managed Service for Prometheus workspace.
Amazon OpenSearch Ingestion now supports Amazon Managed Service for Prometheus as a sink, making it possible to build fully managed, end-to-end metrics ingestion pipelines without any custom forwarding infrastructure. With this launch, customers can now manage their entire metrics ingestion workflow using the same pipeline infrastructure they already use for logs and traces.
Customers can now choose the right destination for each observability signal — sending logs and traces to Amazon OpenSearch Service for powerful full-text search, log analytics, and trace correlation, while routing metrics to Amazon Managed Service for Prometheus for time-series storage and analysis. This flexibility allows teams to build purpose-fit observability pipelines that leverage the strengths of each service without compromising on data fidelity or analytical capability. Amazon OpenSearch Ingestion’s built-in data transformation and enrichment capabilities allow customers to prepare and refine metrics before they land in Amazon Managed Service for Prometheus, improving data quality and consistency. Once metrics are in Amazon Managed Service for Prometheus, customers can query them using Prometheus Query Language to analyze trends, configure alerting rules to get notified when metrics cross defined thresholds, and visualize their data using Amazon Managed Grafana for rich, customizable views of infrastructure and application health.
The feature is supported in all regions that Amazon OpenSearch Ingestion and is currently available. Customers can get started by using the new sink for Amazon Managed Service for Prometheus in their pipeline configuration via the AWS Management console or using the AWS CLI and start ingesting metrics into their Amazon Managed Service for Prometheus workspace.
To learn more and get started, visit the Amazon OpenSearch Ingestion documentation.
Hacer música con MIDI acaba de recibir un gran impulso en Windows 11
Por: Pete Brown y Gary Daniels.
MIDI 2.0 (¡y MIDI 1.0 mejorado!) llega a Windows 11
A veces, quienes no son músicos asocian MIDI sólo con archivos .mid o con los bancos de sonido General MIDI de finales de los años 80. Pero es mucho más que eso. Para los músicos, MIDI es esencial para todo: desde la sincronización de instrumentos hasta el control de iluminación y efectos en el escenario, la secuenciación, la creación de beats y más. MIDI es el pegamento que hace posible la música electrónica.
MIDI 1.0
En el NAMM Show de 1983, Roland y Sequential Circuits presentaron un nuevo estándar digital abierto entre compañías para conectar dos o más instrumentos musicales, lo que marcó el inicio de una era de producción musical electrónica a través de la utilización de MIDI, tal como lo hemos conocido y amado durante décadas.
La especificación inicial de MIDI era bastante simple: mensajes cortos de 1 a 3 bytes a través de un cable serial DIN que funcionaba a una velocidad de alrededor de un milisegundo por mensaje, encadenados de modo que un acorde de cinco notas tardaba cerca de 5 ms en enviarse, una velocidad bastante aceptable dada la tecnología de bajo costo disponible en ese momento.
Con los años, MIDI se ha ampliado para incluir funciones como el estándar General MIDI para instrumentos deterministas en reproducción musical, SMF (Standard MIDI File, o archivo de música “.mid”), expresión más rica mediante el estándar MPE (MIDI Polyphonic Expression), identificación básica de dispositivos mediante SysEx, nuevos transportes como USB, Bluetooth LE, RTP e incluso TRS (cables de audio tip-ring-sleeve).
A pesar de la ubicuidad de MIDI 1.0, MIDI puede ser aún mejor si se considera todo lo que hemos aprendido desde 1983. MIDI 1.0 carece de mecanismos estandarizados bidireccionales para descubrimiento automático de capacidades y parches disponibles en un dispositivo MIDI. La velocidad de nota y muchos otros parámetros de control están limitados a un rango de 0–127 sin usar RPN/NRPN o SysEx. MIDI 1.0 no soporta por completo la expresión rica por nota sin usar la mayoría o todos los canales disponibles para MPE. No contiene buenas provisiones para articulación orquestal. Y MIDI 1.0 carece de buenos estándares para identificar un controlador o fuente de sonido como, por ejemplo, un piano u órgano, y proporcionar mapeos de control estándar y curvas de velocidad que simplemente funcionen. Y, por supuesto, a veces tiene límites de velocidad heredados del estándar original del cable DIN de 31,250 bits por segundo.
Cualquier músico que haya usado un controlador MIDI o software compatible con MIDI conoce bien estas características y limitaciones de MIDI 1.0.
La llegada de MIDI 2.0
En 2020, la Asociación MIDI publicó la primera versión del UMP (Universal MIDI Packet) y la especificación del Protocolo MIDI 2.0. La especificación tuvo actualizaciones clave en 2022/2023 para mejorar el soporte de descubrimiento y mecanismos de fallback, e incluir recomendaciones de Microsoft y otras compañías miembro.
MIDI 2.0 ofrece de manera nativa comunicación bidireccional, descubrimiento automático de dispositivos y configuración de protocolo, velocidades sin límite, controladores de alta resolución (sin la limitación 0–127 ni necesidad de mensajes múltiples), articulación por nota, dispositivos autodescriptivos y una separación entre protocolo y transporte que facilita adoptar nuevos transportes como Network MIDI 2.0 conforme surjan.
A pesar de las limitaciones de MIDI 1.0, y de todos los plugins y soluciones en DAWs para rodearlas, MIDI 1.0 se ha convertido en el estándar más importante en la producción musical, y no desaparecerá. En un futuro MIDI 2.0, es todavía muy importante que cada sistema operativo tenga soporte robusto y estable para MIDI 1.0.
Anuncio de disponibilidad general de Windows MIDI Services, con soporte para MIDI 1.0 y 2.0
¡Nos emociona anunciar que Windows 11 ahora soporta tanto MIDI 1.0 como MIDI 2.0 mediante Windows MIDI Services!
Hemos trabajado en MIDI durante varios años, para reescribir por completo décadas de código MIDI 1.0 en Windows para soportar MIDI 2.0 y hacer que MIDI 1.0 sea increíble. Esta nueva pila combinada se llama “Windows MIDI Services”.
Los componentes principales de Windows MIDI Services están integrados en Windows 11, desplegándose mediante un proceso de habilitación por fases en las versiones para minoristas compatibles. Esto incluye toda la infraestructura necesaria para llevar más funciones a las apps existentes de MIDI 1.0, y también soportar apps que usen MIDI 2.0 mediante el nuevo Windows MIDI Services App SDK.
Todas sus aplicaciones actuales compatibles con MIDI 1.0 ahora funcionan aún mejor, ¡sin necesidad de actualizaciones!
Nuevas funciones principales de Windows MIDI Services
Windows MIDI Services ofrece muchas funciones solicitadas y, lo que es importante, nos prepara para ofrecer aún más de lo que quieres en el futuro. El enfoque de esta versión es asegurar que MIDI 1.0 funcione sin problemas en Windows, mientras se integra la infraestructura para MIDI 2.0.
Usar un dispositivo MIDI desde múltiples apps
La solicitud número uno: permitir que múltiples apps usen el mismo puerto/dispositivo MIDI al mismo tiempo (“multi‑client”). Antes, esto solo era posible con drivers personalizados.
Ahora, todos los puertos MIDI 1.0 y endpoints MIDI 2.0 son multicliente, sin importar el controlador o API utilizados. En la mayoría de los casos, los controladores MIDI específicos de cada fabricante ya no son necesarios ni recomendados, aunque funcionarán si son controladores de streaming del kernel.
El multicliente está disponible para todas las aplicaciones y dispositivos MIDI 1.0 y MIDI 2.0.
Personalizar sus terminales MIDI
La segunda mayor petición para MIDI fue proporcionar mejores nombres de puertos MIDI 1.0. Con esta versión, ustedes tienen control sobre los nombres:
Utilicen nombres clásicos de API, lo que brinda compatibilidad hacia atrás con los nombres de puertos almacenados en DAWs y archivos de música. Esto es el predeterminado y evita que tengan que reconectar puertos en apps y DAWs.
Utilicen nombres de estilo nuevo, a menudo proporcionados por dispositivos que permiten cambiar de nombre puertos MIDI a bordo o con software de configuración. (Estos nombres utilizan las cadenas USB iJack cuando se proporcionan.)
Crear nombres personalizados por completo para puertos MIDI 1.0 y endpoints MIDI 2.0.
Hemos llevado la personalización aún más allá, al añadir metadatos adicionales para los endpoints, incluidas imágenes y descripciones personalizadas, todo configurado a través de la app de Configuración MIDI, disponible pronto como parte de una descarga opcional.
Por último, para aplicaciones que usan WinRT MIDI 1.0, la API MIDI 1.0 introducida con Windows 10, los nombres que se devuelven para los dispositivos a través de esa API ahora reflejan los nombres elegidos para la clásica API midi «WinMM» (o «MME»), una petición muy solicitada desde la introducción de esta API.
Conectar apps con loopback integrado y MIDI app‑to‑app
Otro comentario que hemos escuchado es que el MIDI de aplicación a aplicación debería estar integrado y debería ser compatible tanto en PCs x64 como en Arm64.
Los Servicios MIDI de Windows ahora incluyen soporte integrado para loopback, de modo que las aplicaciones pueden comunicarse entre sí, sin importar si la API o SDK que utilicen. Incluso las páginas WebMIDI en el navegador pueden funcionar con sus terminales de loopback, todo ello sin drivers o instalaciones adicionales. Cuando ejecuten por primera vez la aplicación MIDI y Ajustes de Músico (Musician Settings), se les pedirá que completen su configuración MIDI, incluido, de manera opcional, añadir un conjunto de terminales estándar de loopback.
Para ir más allá de simples loopbacks, también incluimos de forma nativa la capacidad de que una aplicación sea un «dispositivo» MIDI 2.0 completo, con soporte para conceptos MIDI 2.0, negociación y descubrimiento de protocolos. Como otros endpoints MIDI 2.0, estos se traducen en automático y se ponen a disposición de las APIs clásicas MIDI 1.0 a nivel MIDI 1.0.
Pueden crear sus propias terminales de loopback a través de la app MIDI Settings en la próxima descarga de Windows MIDI Services Tools. Los loopbacks están disponibles para todas las aplicaciones MIDI 1.0 y MIDI 2.0, sin ningún controlador adicional.
Usar cualquier dispositivo con cualquier app que tenga traducción y escalado MIDI 2.0 automático
Dispositivos MIDI 2.0 UMP de alta resolución como el Yamaha Montage M y MODX, Roland A88 mk2, Waldorf Quantum e Iridium, Studiologic SL mk2 y más en modo MIDI 2.0 pueden ser usados por cualquier aplicación compatible con MIDI 1.0 o MIDI 2.0 en Windows, con aplicaciones que usan el nuevo SDK teniendo acceso a datos de alta resolución, nuevos tipos de mensajes, marcas de tiempo entrantes y salientes/programación, y otras funciones MIDI 2.0, y aplicaciones compatibles con MIDI 1.0 que detectan los valores reducidos. Nos encargamos de toda la traducción de protocolos y escalado de valores necesarios dentro del Servicio MIDI, así que no tienen que preocuparse por el tipo de dispositivo al que se conectan, ni por sus capacidades o protocolos.
La traducción y escalado es un proceso automático en el servicio, y está disponible para todas las aplicaciones MIDI 1.0 y MIDI 2.0.
Consigan una sincronización más estricta de los mensajes con marcas de tiempo y mensajes programados
El tiempo preciso de los mensajes MIDI siempre ha sido una prioridad para los usuarios MIDI. Para permitir que las aplicaciones proporcionen mejor sincronización al enviar mensajes, ahora soportamos marcas de tiempo tanto para mensajes entrantes como salientes, con una precisión de menos de un microsegundo (1/1.000.000 de segundo). Además, los mensajes salientes pueden programarse para enviarse al conductor en una hora específica dictada por la marca de tiempo.
Seguiremos con los ajustes del algoritmo para esta función a través de actualizaciones posteriores, con el objetivo de hacer que el tiempo sea lo más preciso y determinista posible en todos los dispositivos MIDI.
Las marcas de tiempo y la programación de mensajes están disponibles para las aplicaciones que utilizan el nuevo SDK de la aplicación de Servicios MIDI de Windows.
Usar dispositivos nuevos con el nuevo controlador USB de clase MIDI 1.0 y MIDI 2.0
Hemos mantenido el controlador de usbaudio.sys antiguo y corregido algunos pequeños bugs para hacerlo aún mejor. Al mismo tiempo, hemos incorporado el usbmidi2.sys de drivers USB MIDI 2.0 desarrollado por AmeNote y proporcionado por AMEI. Este nuevo controlador, desarrollado bajo la guía de Microsoft, sigue las mejores prácticas para la gestión de energía, tiene un canal de comunicación más rápido hacia el nuevo servicio MIDI y soporta tanto dispositivos MIDI 1.0 como MIDI 2.0.
Por defecto, la mayoría de los dispositivos MIDI 1.0 usarán todavía el controlador antiguo para garantizar la compatibilidad, pero pueden asignarse de manera manual al nuevo controlador si/cuando se desee.
Todas estas nuevas características combinadas le dan a Windows 11 una fantástica pila unificada MIDI 1.0 y MIDI 2.0 que es ideal para los músicos hoy en día y durante los próximos 40+ años.
Herramientas y scripting MIDI
En los próximos meses, lanzaremos el actualizado paquete MIDI App SDK Runtime and Tools, que incluye la Consola MIDI, la app de Configuración MIDI, proyecciones PowerShell para scripting MIDI y mucho más.
Estas herramientas facilitan la creación de terminales de loopback, la personalización de los nombres de terminal y puertos MIDI, y mucho más.
Desarrollado de manera abierta, con socios y la comunidad
Con Windows MIDI Services, adoptamos un enfoque abierto en el desarrollo, con trabajo en GitHub, con una licencia de código abierto permisiva. Esto permitió que la comunidad de desarrolladores y músicos siguiera el ritmo y contribuyera, y aseguró que todo el proceso fuera transparente.
No podríamos haber hecho esto sin la aportación directa y la implicación de nuestros socios y clientes, en especial en GitHub y Discord. Empresas asociadas de hardware y software, así como miembros interesados de la comunidad, contribuyeron todas a las pruebas de dispositivos y software, prototipos, corrección de errores y mejoras de funcionalidades.
En particular, queremos destacar a AMEI (Asociación de la Industria de la Electrónica Musical de Japón) por su increíble trabajo en pruebas y por la donación del controlador USB MIDI 2.0 desarrollado por AmeNote.
También queremos agradecer a todos los demás socios implicados en el desarrollo y las pruebas, incluidos Yamaha, Roland, Steinberg, Bremmers Audio, PACE/JUCE y muchos más.
Cómo proporcionar comentarios
Nos encantaría seguir escuchando de ustedes.
Los desarrolladores o cualquier persona con GitHub pueden abrir los problemas o contribuir directamente en GitHub a través de nuestro repositorio. Aquí también es donde cualquiera puede consultar nuestra lista actualizada de problemas conocidos.
Estamos entusiasmados por mejorar la creación musical en Windows en 2026 y más allá, y por ayudar a impulsar la adopción del MIDI 2.0.
Más de MIDI
Tenemos más planes para músicos y usuarios de audio profesional, para empezar por el controlador USB de baja latencia en la bandeja con soporte ASIO en vista previa a finales de este año (y también de código abierto en su totalidad), nuevos transportes para MIDI 1.0 y MIDI 2.0 como BLE MIDI 1.0, BLE MIDI 2.0, Network MIDI 2.0, un patch bay virtual para enrutamiento MIDI mejorado, y más. Todos estos están en nuestra lista de pendientes. Consulten GitHub y Discord para seguir el proceso y recibir alertas cuando se lleguen estos dispositivos.
MIDI de red 2.0
En Music China el año pasado, la Asociación MIDI habló sobre uno de los nuevos transportes con los que estamos más avanzados: Network MIDI 2.0. Los PCs con Windows 11 y soporte para Network MIDI 2.0 de vista previa estuvieron en las mesas de demostración allí, en SuperBooth en Berlín y en el NAMM Show 2026.
Sigan el ritmo
Pueden seguir el progreso en nuestro servidor de Discord y en el repositorio público de GitHub, donde se desarrollan todas estas funciones. ¡Gracias por acompañarnos en este camino y por ayudar a que Windows sea increíble para los músicos!
Pete Brown es presidente de la Junta Ejecutiva de la MIDI Association (el organismo de estándares MIDI) y co-desarrolló Windows MIDI Services junto a Gary.
Gary Daniels es arquitecto principal y desarrollador de Servicios MIDI para Windows, y trabaja en el equipo de audio de Core OS.
Defender las puertas: Cómo una coalición global interrumpió la 2FA de Tycoon, un motor principal del acceso inicial y la suplantación online a gran escala
Por: Steven Masada, asesor jurídico general adjunto, Unidad de Crímenes Digitales de Microsoft.
Un solo correo fue suficiente. Un empleado hizo clic en lo que parecía una solicitud rutinaria de inicio de sesión. Entre bastidores, los atacantes pasaron las credenciales, pasaron los controles de seguridad, se hicieron pasar por un usuario de confianza y accedieron a sistemas críticos. En otros casos, intrusiones similares retrasaron nóminas, redirigieron facturas, robaron datos sensibles, bloquearon redes enteras, interrumpieron la atención a pacientes y tensionaron presupuestos ya ajustados en escuelas y servicios críticos.
Esos ataques fueron impulsados por Tycoon 2FA. Hoy, Microsoft, Europol y socios del sector han anunciado una acción coordinada para interrumpir el servicio responsable de decenas de millones de correos electrónicos fraudulentos que llegan a más de 500.000 organizaciones cada mes en todo el mundo.
Interrumpir una operación global de phishing
Activa al menos desde 2023, la 2FA de Tycoon permitió a miles de ciberdelincuentes hacerse pasar por usuarios reales y obtener acceso no autorizado a cuentas de correo electrónico y servicios online, incluidos Microsoft 365, Outlook y Gmail. A diferencia de los kits tradicionales de phishing, Tycoon 2FA fue diseñado para superar protecciones de seguridad adicionales, incluida la autenticación multifactor, que permite a los ciberdelincuentes iniciar sesión como usuarios legítimos sin activar alertas, incluso en cuentas protegidas.
Bajo una orden judicial del Tribunal de Distrito de EE. UU. para el Distrito Sur de Nueva York, y por primera vez en coordinación con el Programa de Extensión de Inteligencia Cibernética (CIEP, por sus siglas en inglés) de Europol, Microsoft incautó 330 dominios activos que alimentaban la infraestructura central de Tycoon 2FA, incluidos paneles de control y páginas de inicio de sesión fraudulentas. El marco CIEP unió a socios del sector público y privado para pasar de solo compartir inteligencia a una acción coordinada y transfronteriza, para acelerar la interrupción y limitar daños futuros.
Poner esta infraestructura fuera de línea corta una importante cadena de toma de cuentas y ayuda a proteger a personas y organizaciones de ataques posteriores como robo de datos, ransomware, compromiso de correos electrónicos empresariales y fraude financiero.
La escala y el impacto real de Tycoon 2FA
A mediados de 2025, la 2FA de Tycoon representaba cerca del 62 por ciento de todos los intentos de phishing que Microsoft bloqueó, incluidos más de 30 millones de correos electrónicos en un solo mes. Eso situó a Tycoon 2FA entre las mayores operaciones de phishing del mundo.
A pesar de las defensas extensas, el servicio está vinculado a unas 96.000 víctimas distintas de phishing en todo el mundo desde 2023, incluidos más de 55.000 clientes de Microsoft.
Las organizaciones sanitarias y educativas fueron las más afectadas. Más de 100 miembros de HealthISAC, un grupo global de compartición de amenazas para el sector sanitario y co-demandante en este caso, fueron objeto de phishing exitoso. Solo en Nueva York, al menos dos hospitales, seis escuelas municipales y tres universidades se enfrentaron a intentos de o a compromisos exitosos a través de Tycoon 2FA. Estos incidentes tuvieron consecuencias tangibles: interrupción de operaciones, desviación de recursos y retraso en la atención a los pacientes.
Por qué el 2FA de Tycoon era tan peligroso
Tycoon 2FA combinó plantillas de phishing convincentes, páginas realistas y captura en tiempo real de credenciales y códigos de autenticación en un paquete fácil de usar que escaló con rapidez. Al reducir la barrera técnica de entrada, permitió a delincuentes con poca experiencia llevar a cabo campañas sofisticadas de suplantación.
Con cada víctima exitosa de phishing, los atacantes podían actuar con el mismo nivel de confianza que los usuarios legítimos, moviéndose de manera lateral entre sistemas, acceder a datos sensibles y abusar de las conexiones de inicio de sesión sin activar alarmas. La investigación de Microsoft Threat Intelligence ofrece más detalles sobre cómo operaba la 2FA de Tycoon.
El panel de control de clientes de Tycoon 2FA.
Este cambio refleja una tendencia más amplia en el cibercrimen: la identidad, no la infraestructura, se ha convertido en el objetivo principal. Una sola cuenta comprometida puede ahora desbloquear sistemas bancarios, portales sanitarios, aplicaciones de trabajo y cuentas en redes sociales.
Dentro de la economía de la suplantación
Tycoon 2FA funcionaba como un negocio dentro del ecosistema más amplio de suplantación bajo demanda. El desarrollador principal, Saad Fridi, que se cree está radicado en Pakistán, trabajó junto a socios responsables de marketing, pagos y soporte técnico.
Los ciberdelincuentes solían usar Tycoon 2FA junto con otros servicios ilícitos. Mientras que Tycoon 2FA capturaba credenciales y tokens de sesión, otros servicios gestionaban la entrega masiva de correos electrónicos, la distribución de malware, el alojamiento y la monetización de accesos. Por ejemplo, RedVDS, interrumpido por Microsoft en enero de 2026, proporcionó ordenadores virtuales económicos, que los ciberdelincuentes combinaron con Tycoon 2FA para llevar a cabo campañas de phishing. Juntos, estos diferentes servicios crearon un ecosistema interconectado para ataques basados en identidad. Interrumpir un componente puede tener efectos en cascada en toda la economía del cibercrimen.
La presión sostenida transforma el mercado
Durante los últimos 18 meses, la Unidad de Crímenes Digitales de Microsoft ha atacado múltiples servicios que permiten la suplantación y el acceso inicial, incluidas extensas operaciones de interrupción de Lumma Stealer, RaccoonO365, Fake ONNX (también conocida como «Caffeine») y RedVDS.
Cuando las herramientas utilizadas de manera amplia se ven interrumpidas, los atacantes se ven obligados a adaptarse, a menudo al recurrir a alternativas como la 2FA de Tycoon. Este patrón de sustitución muestra cómo la presión sostenida impide que un servicio individual se mantenga dominante mientras aumenta de manera progresiva el coste y el riesgo de ciberdelitos.
Estos esfuerzos han provocado arrestos en Egipto y Nigeria, cortes totales de servicios, pérdida de infraestructuras y daños reputacionales para operadores fuera del alcance de las fuerzas del orden. Solo RedVDS perdió más del 95 por ciento de su infraestructura desde enero de 2026, lo que degradó de manera significativa su capacidad para apoyar campañas de suplantación masiva y otras estafas en línea.
A medida que aumentaba la presión, muchos operadores endurecieron los controles de acceso, se retiraron a canales cerrados o cerraron por completo para evitar acciones legales. En el caso de Tycoon 2FA, Microsoft no pudo comprar el acceso al servicio; el operador rechazó los intentos de nuestros investigadores, lo que requirió de un intermediario de confianza. De hecho, el operador de Tycoon 2FA y el ahora inutilizado desarrollador de RaccoonO365 se comunicaron entre sí, lo que destaca la interdependencia del ecosistema y cómo las interrupciones en una zona influyen en la actividad en otras.
Correspondencia que sugiere interacciones entre los operadores de RaccoonO365 y Tycoon 2FA.
Las amenazas globales requieren acción global
El cibercrimen opera a través de las fronteras, y una respuesta eficaz debe hacer lo mismo. Disrupting Tycoon 2FA abarcó múltiples jurisdicciones, lo que subraya por qué la presión sostenida y coordinada es esencial, en especial a medida que el cibercrimen se vuelve más escalable mediante la automatización y la IA.
Microsoft Threat Intelligence, uniéndose a muchos investigadores de seguridad, identificó la 2FA Tycoon como una de las amenazas más significativas para ataques basados en identidad. La Unidad de Crímenes Digitales de Microsoft consultó con Europol, que también rastreó al actor basándose en inteligencia proporcionada por TrendAI. A través del CIEP, Europol convocó a los socios para actuar. Microsoft trabajó con socios industriales para impulsar una disrupción coordinada de infraestructuras, mientras que las autoridades policiales de Letonia, Lituania, Portugal, Polonia, España y Reino Unido realizaron incautaciones de infraestructuras y llevaron a cabo otras medidas operativas vinculadas a Tycoon 2FA.
Socios de la industria, incluidos Proofpoint, Intel 471 y eSentire, ampliaron la visibilidad mediante telemetría, inteligencia de amenazas y análisis de foros de criminales. Cloudflare ayudó al eliminar infraestructuras fuera de la jurisdicción estadounidense, mientras que HealthISAC cuantificó los impactos en las organizaciones sanitarias. SpyCloud aportó datos clave de victimología, Resecurity facilitó el acceso a la 2FA de Tycoon y Coinbase ayudó a rastrear el movimiento de fondos robados. Por último, la Fundación Shadowserver apoyó notificaciones a más de 200 equipos informáticos de respuesta a emergencias en todo el mundo, ayudando a limitar más daños.
Ninguna organización podría haber reunido todo esto por sí sola.
Página de inicio que aparece en dominios confiscados.
Sostener la presión, juntos
Detener el ciberdelito basado en la identidad requiere acción por parte de individuos, organizaciones y gobiernos. La autenticación multifactor, el escrutinio de mensajes inesperados, los controles de sesión sólidos y el intercambio coordinado de amenazas reducen el riesgo. La aplicación temprana también importa; evita que pequeñas intrusiones se conviertan en daño sistémico. Microsoft seguirá con la aplicación de las lecciones aprendidas con la 2FA de Tycoon y las interrupciones anteriores para fragmentar la economía de la suplantación, limitar la escala y hacer que el cibercrimen sea más arriesgado y menos rentable.
The post Defender las puertas: Cómo una coalición global interrumpió la 2FA de Tycoon, un motor principal del acceso inicial y la suplantación online a gran escala appeared first on Source LATAM.
Amazon SageMaker Unified Studio now supports metadata and context sync across Atlan, Collibra, and Alation. These integrations synchronize catalog metadata between Amazon SageMaker Catalog and each partner platform, giving teams a consistent view of their data and AI assets regardless of which tool they use day to day. Organizations can maintain aligned glossary terms, asset descriptions, and ownership information across platforms without manual reconciliation.
All three integrations synchronize key metadata elements including projects, assets, descriptions, glossary terms, and their hierarchies. With the Collibra integration, you can synchronize metadata in both directions between SageMaker Catalog and the partner platform, so updates you make in one are reflected in the other. Also, you can manage SageMaker Unified Studio data access requests from Collibra. With the Atlan and Alation integration, you can ingest metadata from SageMaker Catalog into Alation with additional enhancements coming soon. You set up these integrations by setting up a connection to SageMaker Unified Studio from within Atlan and Alation, while the Collibra integration is available as an open-source solution on GitHub.
Amazon SageMaker Unified Studio now supports metadata and context sync across Atlan, Collibra, and Alation. These integrations synchronize catalog metadata between Amazon SageMaker Catalog and each partner platform, giving teams a consistent view of their data and AI assets regardless of which tool they use day to day. Organizations can maintain aligned glossary terms, asset descriptions, and ownership information across platforms without manual reconciliation.
All three integrations synchronize key metadata elements including projects, assets, descriptions, glossary terms, and their hierarchies. With the Collibra integration, you can synchronize metadata in both directions between SageMaker Catalog and the partner platform, so updates you make in one are reflected in the other. Also, you can manage SageMaker Unified Studio data access requests from Collibra. With the Atlan and Alation integration, you can ingest metadata from SageMaker Catalog into Alation with additional enhancements coming soon. You set up these integrations by setting up a connection to SageMaker Unified Studio from within Atlan and Alation, while the Collibra integration is available as an open-source solution on GitHub.
To learn more, visit the Amazon SageMaker Unified Studio documentation. For implementation details, see the Atlan blog post, Collibra blog post , and Alation blog post.
Amazon SageMaker Unified Studio now supports AWS Glue 5.1 for Visual ETL, notebook, and code-based data processing jobs. With AWS Glue 5.1 in Amazon SageMaker Unified Studio, data engineers and data scientists can run jobs on Apache Spark 3.5.6 with Python 3.11 and Scala 2.12.18, and use updated open table format libraries including Apache Iceberg 1.10.0, Apache Hudi 1.0.2, and Delta Lake 3.3.2.
You can use AWS Glue 5.1 in Amazon SageMaker Unified Studio when creating data processing jobs by selecting Glue 5.1 from the version dropdown in job settings. This applies to Visual ETL jobs, notebook jobs, and code-based jobs, so you can take advantage of the latest Spark runtime and open table format libraries across all your data processing workflows.
AWS Glue 5.1 in Amazon SageMaker Unified Studio is available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Stockholm), Europe (Frankfurt), Europe (Spain), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Malaysia), Asia Pacific (Thailand), Asia Pacific (Mumbai), and South America (Sao Paulo).
To learn more, visit the Amazon SageMaker Unified Studio documentation. For details on what’s included in AWS Glue 5.1, including updated open table format support and access control capabilities, see the AWS Glue documentation.
Amazon SageMaker Unified Studio now supports AWS Glue 5.1 for Visual ETL, notebook, and code-based data processing jobs. With AWS Glue 5.1 in Amazon SageMaker Unified Studio, data engineers and data scientists can run jobs on Apache Spark 3.5.6 with Python 3.11 and Scala 2.12.18, and use updated open table format libraries including Apache Iceberg 1.10.0, Apache Hudi 1.0.2, and Delta Lake 3.3.2.
You can use AWS Glue 5.1 in Amazon SageMaker Unified Studio when creating data processing jobs by selecting Glue 5.1 from the version dropdown in job settings. This applies to Visual ETL jobs, notebook jobs, and code-based jobs, so you can take advantage of the latest Spark runtime and open table format libraries across all your data processing workflows.
AWS Glue 5.1 in Amazon SageMaker Unified Studio is available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Stockholm), Europe (Frankfurt), Europe (Spain), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Malaysia), Asia Pacific (Thailand), Asia Pacific (Mumbai), and South America (Sao Paulo).
To learn more, visit the Amazon SageMaker Unified Studio documentation. For details on what’s included in AWS Glue 5.1, including updated open table format support and access control capabilities, see the AWS Glue documentation.
Today, AWS announces the ability to remotely connect from Kiro IDE to Amazon SageMaker Unified Studio. This new capability allows data scientists, ML engineers, and developers to leverage their Kiro setup – including its spec-driven development, conversational coding, and automated feature generation capabilities – while accessing the scalable compute resources of Amazon SageMaker. By connecting Kiro to SageMaker Unified Studio using the AWS toolkit extension, you can eliminate context switching between your local IDE and cloud infrastructure, maintaining your existing agentic development workflows within a single environment for all your AWS analytics and AI/ML services.
SageMaker Unified Studio, part of the next generation of Amazon SageMaker, offers a broad set of fully managed cloud interactive development environments (IDE), including JupyterLab and Code Editor based on Code-OSS (Open-Source Software). Starting today, you can also use your customized local Kiro setup – complete with specs, steering files, and hooks – while accessing your compute resources and data on Amazon SageMaker. Since Kiro is built on Code-OSS, authentication is secure via IAM through the AWS Toolkit extension, giving you access to all your SageMaker Unified Studio domains and projects. This integration provides a convenient path from your local AI-powered development environment to scalable infrastructure for running workloads across data processing, SQL analytics services like Amazon EMR, AWS Glue, and Amazon Athena, and ML workflows – all with enterprise-grade security including customer-managed encryption keys and AWS IAM integration.
This feature is available in all Regions where Amazon SageMaker Unified Studio is available. To learn more, refer to the SageMaker user guide.
Today, AWS announces the ability to remotely connect from Kiro IDE to Amazon SageMaker Unified Studio. This new capability allows data scientists, ML engineers, and developers to leverage their Kiro setup – including its spec-driven development, conversational coding, and automated feature generation capabilities – while accessing the scalable compute resources of Amazon SageMaker. By connecting Kiro to SageMaker Unified Studio using the AWS toolkit extension, you can eliminate context switching between your local IDE and cloud infrastructure, maintaining your existing agentic development workflows within a single environment for all your AWS analytics and AI/ML services.
SageMaker Unified Studio, part of the next generation of Amazon SageMaker, offers a broad set of fully managed cloud interactive development environments (IDE), including JupyterLab and Code Editor based on Code-OSS (Open-Source Software). Starting today, you can also use your customized local Kiro setup – complete with specs, steering files, and hooks – while accessing your compute resources and data on Amazon SageMaker. Since Kiro is built on Code-OSS, authentication is secure via IAM through the AWS Toolkit extension, giving you access to all your SageMaker Unified Studio domains and projects. This integration provides a convenient path from your local AI-powered development environment to scalable infrastructure for running workloads across data processing, SQL analytics services like Amazon EMR, AWS Glue, and Amazon Athena, and ML workflows – all with enterprise-grade security including customer-managed encryption keys and AWS IAM integration.
This feature is available in all Regions where Amazon SageMaker Unified Studio is available. To learn more, refer to the SageMaker user guide.
Policy in Amazon Bedrock AgentCore is now generally available, providing organizations with centralized, fine-grained controls for agent-tool interactions. Policy operates outside your agent code, enabling security, compliance, and operations teams to define tool access and input validation rules without modifying agent code. Teams can author policies using natural language that automatically converts to Cedar, the AWS open-source policy language. Policies are stored in a policy engine and attached to an AgentCore Gateway, which intercepts agent-tool traffic and evaluates each request against the policies before allowing or denying tool access. Policy helps ensure agents operate within defined parameters while maintaining organizational visibility and governance.
Policy in AgentCore is available in thirteen AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), and Europe (Stockholm).
Policy in Amazon Bedrock AgentCore is now generally available, providing organizations with centralized, fine-grained controls for agent-tool interactions. Policy operates outside your agent code, enabling security, compliance, and operations teams to define tool access and input validation rules without modifying agent code. Teams can author policies using natural language that automatically converts to Cedar, the AWS open-source policy language. Policies are stored in a policy engine and attached to an AgentCore Gateway, which intercepts agent-tool traffic and evaluates each request against the policies before allowing or denying tool access. Policy helps ensure agents operate within defined parameters while maintaining organizational visibility and governance.
Policy in AgentCore is available in thirteen AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), and Europe (Stockholm).
Learn more about Policy in AgentCore through the documentation, and get started with the AgentCore Starter Toolkit.
