Cuando vemos algún estudio interesante traemos aquí información acerca de esos métodos de extraer información que se basan en el comportamiento (físico, normalmente) de nuestros aparatos. Lo que se denomina canales laterales. En este caso, en Invisible Ears at Your Fingertips: Acoustic Eavesdropping via Mouse Sensors, presentan un artículo donde detallan la idea de usar los sensores ópticos de un ratón, por su precisión y velocidad de respuesta, para detectar las vibraciones sonoras de la superficie donde se apoyan y usarlos para espiar al usuario.

Modern optical mouse sensors, with their advanced precision and high responsiveness, possess an often overlooked vulnerability: they can be exploited for side-channel attacks. … We demonstrate that audio signals can induce subtle surface vibrations detectable by a mouse’s optical sensor.

Al final, se trata de hacer que el ratón se comporte como un micrófono: estos traducen las ondas sonoras en señales eléctricas por efecto del movimiento que provocan los cambios de presión sonora en la membrana.

Microphones convert sound waves into electrical signals through diaphragm vibrations caused by air pressure changes.

En el caso de los ratones, sus sensores ópticos pueden detectar vibraciones en la superficie de manera similar a como lo hacen las membranas de los micrófonos.

… their sensors can detect surface vibrations similar to how a microphone’s diaphragm captures sound waves

Adicionalmente, hace falta que el equipo ejecute algún tipo de programa que capture la información para procesarla posteriormente y extraer el sonido. La conclusión es que el ataque es factible y que, en algunos casos, se puede conseguir extraer sonido de calidad razonable.

Se pueden consultar más detalles y ver una demostración en Mic-E-Mouse. Covert Eavesdropping through Computer Mice.

De vez en cuando nos encontramos con ese meme donde aparece toda la infraestructura de internet apoyada en una pequeña columna: un simple desarrollador, mal financiado y no siempre con la motivación suficiente para seguir manteniendo su proyecto.

En Maintainers of last resort, Filippo Valsorda nos habla de Geomys, una organización de desarrolladores de software libre que se ocupa de algunos proyectos (fundamentalmente desarrollados en Go) y a la que se puede contratar para tener acceso a su conocimiento y experiencia en ellos.

Our retainer clients engage us both to get access to our expertise, and so that the critical dependencies they rely on are professionally maintained.

Además, en algunas ocasiones también ejercen de «batallón de choque» cuando se produce algún incidente en otro proyecto que carece de mantenimiento.

Beyond our portfolio, we sometimes act as maintainers of last resort when critical, security-relevant Go projects go unmaintained.

Interesante.

Hasta ahora hemos oído hablar de cómo se usa la IA para mejorar las oportunidades de los ataques tipo phishing con mejores traducciones, mensajes más convincentes y todo eso. En Experimental PromptLock ransomware uses AI to encrypt, steal data nos contaban un caso que va un poco más allá, porque PromptLock sería una demostración de la posibilidad de usar una IA para generar los programas de ataque:

The malware uses OpenAI’s gpt-oss:20b model through the Ollama API to dynamically generate the malicious Lua scripts from hard-coded prompts.

Por lo que nos dicen se trata simplemente de una ‘demo’ o una prueba de concepto.

The cybersecurity company believes that PromptLock is a proof-of-concept or work in progress, and not an active ransomware in the wild.

El proyecto parece tener varios ‘padres’.

After ESET published details about PromptLock, a security researcher claimed that that the malware was their project and somehow it got leaked.

#ESETResearch has discovered the first known AI-powered ransomware, which we named #PromptLock. The PromptLock malware uses the gpt-oss:20b model from OpenAI locally via the Ollama API to generate malicious Lua scripts on the fly, which it then executes 1/6 https://t.co/wUZS7Fviwi

— ESET Research (@ESETresearch) August 26, 2025

Y también, uno académico, sobre el que se puede leer en Large language models can execute complete ransomware attacks autonomously, NYU Tandon research shows.

Researchers from the NYU Tandon School of Engineering have reached out to point out that PromptLock seems to have been directly derived from their project, called “Ransomware 3.0.” They also published a blog post explaining the connection here.

Muchas veces se habla de que corremos mucho riesgo al confiar nuestra presencia digital (y más, la comunicación digital, dirección de correo…) aservicios externos (gratuitos o no). La solución que suele proponerse es que vale la pena que contratemos nuestro propio dominio, ya que siempre podremos hacer que apunte a nuestro proveedor de cada momento. El problema del que no se habla tanto es lo que puede suceder si perdemos ese dominio por cualquier motivo (dejamos de pagar, cambiamos a otro, …).

En Preventing Domain Resurrection Attacks hablaban justamente de eso relacionado con el proyecto PyPI, que es un repositorio de proyectos escritos en Python y en el que muchos programadores confían.

El problema tiene que ver con el registro en el sitio, que va ligado a una dirección de correo.

PyPI user accounts are linked to email addresses. Email addresses are tied to domain names; domain names can expire if unpaid, and someone else can purchase them.

Y el problema puede aparecer si el dominio de una de estas direcciones cambia de manos, el nuevo propietario podrá usar las cuentas que considere oportuno, entre ellas alguna de las que existía anteriormente, asociada a algún proyecto.

For older accounts prior to the 2FA requirement date, having an email address domain expire could lead to account takeover, which is what we’re attempting to prevent, as well as minimize potential exposure if an email domain does expire and change hands, regardless of whether the account has 2FA enabled.

Para remediarlo, en PyPI hacen verificaciones sobre el estado de registro del dominio (dicho de forma muy simplificada) y cuando se produzca la caducidad considerarán las direcciones de correo asociadas como no verificadas.

After an initial bulk check period that took place in April 2025, PyPI will check daily for any domains in use for status changes, and update its internal database with the most recent status.

El problema es que sólo agentes muy preocupados (y suficientemente grandes) pueden invertir recursos en este tipo de soluciones, así que veremos de vez en cuando cómo puede afectar esto en distintas situaciones.

Ya había productos de ciberseguridad que decían utilizar la IA para protegernos antes de la explosión de la IA generativa: algunos CISOs apoyaban estas aproximaciones y otros las miraban con escepticismo. Sin embargo, ahora ya parece fuera de toda duda que la IA debe incluirse en el arsenal defensivo de cualquier empresa. En A CISO’s Guide to Vetting AI Security Vendors dan algunas recomendaciones sobre la elección de proveedores, basándose en tres pilares.

• ¿Resuelven algún problema importante?

Pillar 1: The Problem — Are You Solving Anything That Matters?

Se basa en un par de preguntas interesantes: ¿qué problema está resolviendo esta IA?

“What specific pain is your AI solving?”

Y la respuesta debería ser concreta, fácil de entender…

A vendor who can give you a concrete, understandable example of their product’s value actually understands the problem.

¿Realmente es necesaria la IA para eso?

“Why is AI necessary here? How is it superior to simpler methods?”

Esta es una pregunta que deberíamos estar haciéndonos en todos los ámbitos, claro: leí en algún sitio (y trato de seguirlo) que no deberíamos utilizar IA si lo podemos resolver con un programa ‘normal’. O, como dice en el texto, a veces un centenar de expresiones regulares puede producir mejores resultados que un modelo malo al que llaman IA.

Many times, a hundred regular expressions can produce better results than a poorly implemented model, but the vendor just calls it “AI.”

• ¿Realmente funciona?

Pillar 2: The Proof — Does It Actually Work?

En este caso, la primera pregunta sería ¿Cuáles son los datos de entrada de tu modelo? ¿Qué algoritmo utilizas?

“What are the inputs to your model? What algorithms are you using?”

Se trata de conocer cómo funciona el producto.

También sobre la calidad, ¿qué tasas de falsos positivos y falsos negativos tiene el modelo?

“What are your model’s false positive and false negative rates?”

Se trata de hablar de precisión y sensibilidad (recall): si no pueden darnos esa información es porque probablemente no la conocen, no les interesa, o no es muy buena.

Any serious AI vendor tracks precision and recall. If they can’t give you hard numbers, that’s a red flag. Ask for them in the context of a real customer deployment, not a lab test.

¿Cómo maneja el modelo las amenazas que nunca antes se han visto?

“How does your system handle a threat it has never seen before?”

No debemos olvidar que algunas IAs (LLMs, en particular) proporcionarán respuestas aleatorias en esos casos.

If you pass an LLM a complex attack with multiple TTPs it hasn’t seen before, it might have low confidence and just spit out random MITRE ATT&CK categories.

• ¿Cómo impactará esto en mi equipo?

Pillar 3: The Practicality — How Will This Impact My Team?

La primera pregunta sería ¿cuál es el verdadero coste de tener esta solución?

“What is the true cost of ownership?”

No se trata de hablar solo del coste de la licencia sino de otros aspectos (el propio funcionamiento, ¿va incluido en la suscripción o aparecerá en mi factura de operaciones en la nube?

This isn’t just the license fee. If the product is feeding massive amounts of data into an LLM, who pays the inference cost? Is it included in your subscription, or is that going to show up on my cloud bill?

Pero también el coste para las personas: ¿cuánto tiempo necesitarán para validar las alertas y resultados que ofrezca la herramienta?

Even more importantly, what is the cost of my team’s time? If my analysts have to spend their days validating the AI’s output, I haven’t saved them work; I’ve just shifted it.

Otra pregunta interesante estaría relacionada con la corrección de errores: ¿si encontramos fallos podemos hacer que la IA aprenda para que no los vuelva a cometer?

“Can my analysts correct the AI’s mistakes, and does it learn from them?”

La última pregunta tendría que ver con la explicabilidad y el cumplimiento: ¿cómo proporciona el sistema la información para los auditores?

“How does your system provide ‘explainability’ for auditors or the board? I need to see detailed decision logs, confidence scores, and visualization tools.”

Complementa el escrito con las señales de alarma (red flags) que incluyen las típicas que hemos visto en otros contextos:

• Nuestro producto es propietario y no podemos darte detalles.

“Our AI is proprietary and we can’t share details.” Transparency is non-negotiable.

• No hacemos seguimiento de la tasa de falsos positivos.

“We don’t track false positive rates.” If they don’t measure accuracy, they can’t improve.

• Funciona sin tener que tocar nada.

“It works out of the box with no tuning.” Real-world environments always require configuration.

Buena lista de recomendaciones.