9 may 2023

El Shadow IT en la huella digital corporativa: la lucha contra el Diógenes digital


El Shadow IT es uno de los problemas más olvidados en las empresas. Con el paso del tiempo y el Diógenes digital, van quedando indexados y accesibles en Internet decenas de servicios y activos que podrían exponer importante información corporativa. Servicios que, de no estar correctamente inventariados y controlados, podrían convertirse en la puerta de entrada a nuestras redes. Este problema se ve acrecentado por la alta burocracia interna y los intentos de saltarse ciertos pasos administrativos con tal de salir antes a producción (¿Os suena la foto?). Desde Zerolynx vemos muy habitualmente cómo determinados departamentos acaban contratando, por ejemplo, hostings externos, para ahorrarse tiempo a la hora de publicar un nuevo servicio que, internamente, les conllevaría pasar por una serie de flujos, auditorías y controles. Obviamente, saltarse estos procesos es una irresponsabilidad que acaba teniendo consecuencias, y para ello la concienciación es una herramienta clave, pero estas cosas acaban ocurriendo y es nuestra responsabilidad luchar contra ello.

Ante este hecho y al ver que era algo muy común en el mercado, decidimos incorporar a nuestro servicio de Huella Digital Corporativa una fase previa de reconocimiento de activos digitales, muy similar a la realizada en los servicios de intrusión por nuestros compañeros del Red Team. En dicha fase, realizamos tanto una detección automatizada de los activos como una labor de identificación manual que nos permite abarcar un plano más amplio y además realizar un primer análisis de dichos activos. 

Durante este reconocimiento de análisis de activos, identificamos cuáles de ellos son vulnerables o susceptibles de serlo. Por ejemplo, aunque podría parecer común el encontrar expuesto un enlace de un subdominio del cliente en cuyas cabeceras aparece la tecnología del servidor, así como la versión y software del servicio utilizado, esto puede suponer un riesgo. Para ilustrarlo con un caso real: hace un tiempo durante el análisis de los activos de un cliente, identificamos y le reportamos interfaz de acceso VPN con versión obsoleta. A los meses del hallazgo, nuestro cliente se puso en contacto con nosotros para que analizásemos un anuncio en Raid Forums sobre un acceso remoto a su compañía y en el cual se observaba que el origen de dicho acceso estaba relacionado con el enlace que previamente le habíamos notificado.

No debemos olvidar que una pieza importante para contribuir a la disminución de la superficie de ataque es la aplicación de medidas de higiene digital. Ante la ingente cantidad de activos digitales que presentan en la actualidad las empresas, puede suceder que no todos ellos estén bajo su control, lo cual da la oportunidad a terceros para obtener un beneficio de ellos. Desde la explotación de las vulnerabilidades, la adquisición de dominios que fueron propiedad de la compañía (una vez se han dejado de renovar) o, incluso, la utilización de estos como medio para realizar ilícitos en su nombre (aprovechando redirecciones desde un sitio aparentemente lícito a otro). Todo esto, con consecuencias como la afectación a su reputación y la provocación de otros daños indirectos, como la pérdida de confianza por parte de proveedores o clientes.

En ocasiones, medir el nivel de riesgo es complejo, pero siempre debemos atender a la magnitud de la evidencia identificada y su probabilidad de ocurrencia. Los analistas sabemos que esta segunda parte es la más complicada. Hoy en día, encontrar individuos motivados a romper los accesos y a entrar en los sistemas de nuestros clientes no es tan complicado. Por ello, pese a que en ocasiones los riesgos que identificamos puedan ser bajos, siempre es recomendable su análisis, mitigación y subsanación por lo que puedan significar el día de mañana.

¡La verdad está ahí fuera!

Noelia Baviera, Analista de Inteligencia


Shadow IT in the Corporate Digital Footprint: The Fight against Digital Diogenes Syndrome


Shadow IT is one of the most neglected problems of companies. As time goes by and as a result of digital Diogenes, dozens of services and assets that could expose important corporate information are becoming indexed and accessible on the Internet. These are services that, if not properly inventoried and controlled, could become the gateway to our networks. This problem is exacerbated by the high internal bureaucracy and attempts to skip certain administrative steps in order to go into production earlier (Does this sound familiar?). From Zerolynx we see very often how certain departments end up contracting, for example, external hosts to save time when publishing a new service that, internally, would involve them going through a series of flows, audits and controls. Obviously, skipping these processes is irresponsible and leads to consequences, so therefore awareness is a key tool. Unfortunately, these things end up happening and it is our responsibility to fight against them.

Given this fact and after verifying that it was something quite common in the market, we decided to incorporate into our Corporate Digital Footprint service a previous phase of recognition of digital assets, remarkably similar to that carried out in the intrusion services by our Red Team colleagues. In this phase, we conduct both an automated detection of the assets and a manual identification task that allows us to cover a broader plan and also carry out a first analysis of said assets. 

During this asset analysis recognition, we identify which of them are vulnerable or susceptible to being vulnerable. For example, although it might seem common to find a link from a client subdomain exposed where the server technology appears in the headers, as well as the version and software of the service used, this can pose a risk. Here is a real case that illustrates what we are talking about: some time ago during the analysis of a client's assets, we identified and reported an VPN access interface with an obsolete version. Within months of the discovery, our client contacted us to discuss an ad in Raid Forums about remote access to their company and noted that the origin of such access was related to the link we had previously notified.

We must not forget that an important key to contribute to the reduction of the attack surface is the application of digital hygiene measures. Given the huge amount of digital assets that companies currently have, not all of them may be under their control, giving the opportunity to third parties to take advantage and obtain profit. From the exploitation of the vulnerabilities, the acquisition of domains that were owned by the company (once they are not renewed) or even the use of these as a means to perform illicit acts on their behalf (taking advantage of redirects from one apparently lawful site to another). All this has consequences such as undermining their reputation and causing other indirect damages, like the loss of trust by suppliers or customers.

Sometimes measuring the level of risk is complex, but we must always take into account the magnitude of the evidence identified and its probability of occurrence. Analysts know that this second part is the most complicated. Nowadays, finding individuals motivated to break access and break into our customers' systems is not that complicated. Therefore, although sometimes the risks we identify may be low, it is always advisable to analyse, mitigate and correct them for what they may mean tomorrow.

The truth is out there!

Noelia BavieraIntelligence Analyst


4 may 2023

El ocaso del análisis DAST



Muchas organizaciones recopilan datos de una infinidad de fuentes, como los usuarios, y luego los almacenan en lagos de datos. En la actualidad, los datos lo son todo, al igual que la capacidad de procesar una gran cantidad de datos en poco tiempo. 

El uso de los datos siempre se realiza a través de APIs. Las API mantienen unidos todos los componentes de la aplicación y los hacen accesibles como uno solo para cualquier tipo de cliente, como un usuario. 

Por supuesto, las API no vinieron solas. La arquitectura monolítica tradicional ha dado paso a otras, como los microservicios. Hoy todo es modular. Los microservicios hacen que cualquier aplicación sea modular para una mejor escalabilidad, mayor flexibilidad y menor time-to-market. 

Los microservicios combinados con las API se consideran el futuro del desarrollo de software. Esto es tan cierto que OWASP lanzó en 2019 una versión adaptada a APIs de su conocido OWASP TOP 10. Por lo tanto, en este escenario, la seguridad de las aplicaciones debe adaptarse a esta nueva forma de crear software y mantenerse al día. 

En la última década, la seguridad para aplicaciones también ha evolucionado en forma de varias pruebas de seguridad automatizadas y especializadas. Sin embargo, esa evolución de los controles de seguridad parece quedarse atrás, como sucede con los análisis dinámicos de seguridad de aplicaciones (DAST).


DAST, un tipo guay 

El análisis DAST surgió como una herramienta de caja negra "bastante" automática para encontrar vulnerabilidades específicas en aplicaciones web en un momento en el que casi las únicas técnicas eran el análisis SAST y el pentesting manual. Los DAST surgieron con la promesa de ayudar al pentester y cubrir algunos de los vacíos en las herramientas SAST, como reducir los falsos positivos y el tiempo de escaneo. 

El proceso de ejecución es muy sencillo: a partir de conjuntos de reglas predefinidos, envía solicitudes HTTP a la aplicación web y verifica ciertas cadenas de texto en las respuestas para ver si existe alguna vulnerabilidad. En pocas palabras, el análisis DAST intenta simular a un pentester. 

No hace falta decir que hay un par de inconvenientes principales:  

  • Falsos positivos. Cualquier número de falsos positivos necesitaría una breve revisión después del escaneo, el llamado triaje. Ese triaje a menudo precisaría de los ojos expertos de un analista de ciberseguridad e, incluso para un experto, lleva un tiempo precioso que puede terminar ralentizando los pasos posteriores al escaneo 
  • Tiempo. Los escaneos tardan tiempo en ejecutarse, generalmente de 30 minutos a 2 horas, o tal vez días, dependiendo del tamaño de la aplicación. Además, el tiempo dependerá de lo buena que sea la configuración. Cuanto mejor sea la configuración, menos tiempo tardará en ejecutarse. Pero conseguir una buena configuración previa al escaneo no es tan fácil y la mayoría de las veces también requiere de un experto en ciberseguridad 


El DAST está muy por detrás del desarrollo de software 

La forma de desarrollar software ha cambiado. El DAST ahora se suele integrar en el pipeline CI/CD y, en entornos de CI/CD, la agilidad y la velocidad son piezas clave. Cualquier compilación e implementación no debe durar más de un par de minutos. 

Esto no sucede con los análisis DAST. Como ya hemos mencionado, los escaneos DAST tardan tiempo en ejecutarse, se necesita tiempo para revisar los hallazgos y tiempo para configurarlos. Pero estos escollos no son los únicos contrarios a la agilidad y la velocidad: 

  • Descubrimiento y crawling. Una de las principales características de las herramientas DAST es su capacidad para buscar y navegar casi todos los recovecos de la aplicación durante el escaneo. Aplicando algunas reglas heurísticas para reescribir direcciones URL y seguir vínculos, las herramientas DAST pueden detectar y rastrear numerosos subdominios y secciones de aplicaciones web. Otra versión de este proceso de descubrimiento consiste en utilizar proxies y recopilar todos los endpoints que se van a analizar. Pero en la actualidad, mientras que la seguridad se está desplazando hacia la izquierda en el SDLC, estas características podrían considerarse una deficiencia porque requieren tiempo. Afortunadamente, la mayoría de las herramientas DAST a lo largo de los años han incluido la posibilidad de especificar en varios formatos qué endpoints de la aplicación se desean escanear 
  • Los desarrolladores usan DAST. Bajo el nuevo paradigma DevSecOps, los desarrolladores pueden usar por su cuenta algunas herramientas presentes en los pipelines, como las herramientas de seguridad, con el objetivo de conseguir una mayor agilidad en proceso de desarrollo de software. Si los desarrolladores por sí mismos pueden revisar los hallazgos de un análisis de seguridad de un análisis DAST, esto supuestamente aceleraría todo el proceso desarrollo. En teoría. En la práctica, los desarrolladores no siempre saben distinguir qué es un falso positivo y qué no lo es, o necesitan invertir más tiempo para hacerlo que un experto en seguridad. Este escenario reduce drásticamente la tolerancia a los falsos positivos de los equipos de DevSecOps y socava la confianza en los controles de seguridad 

Finalmente, el software en sí también ha cambiado. Como dijimos al principio, las APIs y los microservicios son el presente y el futuro, y el DAST está bien adaptado para ellos: 

  • El DAST no identifica ningún contenido generado de forma dinámica en el front-end, lo cual es muy común hoy en día debido al uso extendido de frameworks Javascript, como Angular, React, Next, JQuery, etc 
  • El DAST no detecta algunos tipos de vulnerabilidades habituales en las APIs, como los IDOR/BOLA, porque para ello se requiere contexto de la lógica de negocio de la aplicación, como roles de usuario y privilegios 
  • El DAST también tiene dificultades para pasar a través de algunos muros de protección, como tokens anti-CSRF y varios mecanismos típicos de autenticación / autorización en APIs, como OAuth2, SSO y autenticación multifactor. Aunque es posible superar algunas de estas barreras, sin duda aumentaría el tiempo para preparar el escaneo, y cada aplicación necesita su propia configuración a medida 


¿Cómo usar DAST en 2023 y no morir en el intento? 

Llegados a este punto, es bastante tentador pensar que el DAST es inútil, pero no lo es. Muchas de las deficiencias anteriores se pueden subsanar mediante el uso del DAST de otras maneras: 

  • Reutilizar DAST para encontrar resultados fáciles. Algunas vulnerabilidades son fáciles y rápidas de encontrar para cualquier herramienta DAST y tienen una proporción de falsos positivos razonablemente baja. Algunos ejemplos son las cabeceras HTTP inseguras o inexistentes, Cross Site Scripting o incluso algún tipo de SQLi 
  • Probar requisitos de seguridad específicos. Si existe un catálogo de requisitos de seguridad, el análisis DAST podría usarse para ejecutar un conjunto muy específico de pruebas para verificar esos requisitos de alto valor en muchas aplicaciones 
  • Crear plantillas de configuración de antemano. Como hemos mencionado ya, cuanto mejor sea la configuración, menos tiempo tardará en ejecutarse. Sería una buena idea invertir tiempo en preparar configuraciones que se pueden utilizar para escanear varias aplicaciones con características o arquitectura similares. Al hacer esto, con una sola configuración bien hecha, el tiempo de ejecución y los falsos positivos se reducirían considerablemente en futuros escaneos 
  • Evitar escaneos completos. Escanear toda la aplicación podría llevar mucho tiempo y cada paso en pipeline de CI/CD debería durar solo unos segundos o minutos. En su lugar, hay que limitar el alcance del escaneo únicamente a los últimos cambios realizados en la aplicación 
  • Alimentar el DAST con las rutas de la API exactas a escanear. Si la herramienta lo admite (recomendado), probar solo los endpoints de la API que se desea analizar, como los que tienen cambios. Esto permitiría obtener una cobertura de escaneo del 100% gradualmente sin ralentizar el proceso de CI / CD 
  • Ejecutar el DAST de forma asincrónica. Si el escaneo se inicia en una fase del ciclo CI/CD y va a tardar un tiempo, una buena opción sería simplemente ejecutarlo sin esperar a que termine. Más tarde, cuando se complete, el equipo responsable podría revisar los hallazgos o hacer algún triaje 

Aparte de esto, el DAST sigue siendo una herramienta realmente útil para cualquier pentester, ya que es capaz de testear (fuzz) una gran cantidad de parámetros de entrada en numerosas aplicaciones en poco tiempo con una serie de conjuntos de reglas predefinidos que permitan encontrar muchos tipos de vulnerabilidades, como inyecciones y configuraciones erróneas. 


Qué debe tener una herramienta DAST para hacer pruebas de seguridad en APIs 

Al evaluar herramientas DAST o similares para hacer pruebas de seguridad en APIs, puede ser difícil saber qué herramienta es la mejor opción, por lo que a continuación se muestran algunos criterios que se pueden usar: 

  • Fácil de integrar en un pipeline de CI/CD 
  • Permite elegir qué tipo de aplicación se va a escanear: API o web con front-end 
  • Admite varios formatos de especificación de API para especificar las rutas exactas de la API a escanear: colecciones de Postman, OpenAPI / Swagger, introspection de GraphQL, WADL, WSDL, etc. 
  • Permite seleccionar el tipo específico de API que se va a probar: REST, GraphQL, SOAP 
  • Proporciona la capacidad de definir pre y post scripts para generar configuraciones muy precisas para detectar vulnerabilidades de lógica de negocio 


A modo de resumen 

La forma en que se desarrolla el software ha cambiado, al igual que el software en sí. La agilidad y la velocidad son ahora características clave de cualquier SDLC gracias a las ventajas de utilizar pipelines de CI/CD. Las APIs se han convertido en el núcleo de cualquier componente software nuevo, por lo que la generación de aplicaciones seguras depende de la ausencia de vulnerabilidades en las APIs que hay por debajo. 

Las APIs deben probarse y asegurarse a un ritmo muy rápido y, aunque el análisis DAST no es lo más idóneo para eso, es posible modificar la configuración de los escaneos y la forma de integrarlos en los pipelines para analizar APIs mejor y más rápido. 


La IA: una nueva esperanza 

Este post no puede terminar sin hacer mención a la inteligencia artificial. 

La verdad es que cualquier solución DAST podría aprovechar la IA para resolver muchas de las desventajas que se han mencionado en este artículo, y algunas más. Por ejemplo, se podría usar para mejorar el proceso de descubrimiento y navegación a través de la reescritura inteligente de URLs, evitar solicitudes duplicadas o iterativas, disminuir los falsos positivos, detectar vulnerabilidades complejas de la lógica de negocio... 

¿Creéis que es posible que la IA se convierta en el fuego que revivirá al fénix del DAST? 


Ernesto Rubio, Consultor de Ciberseguridad 

The Downfall of DAST Security Testing


Many organizations gather data from a variety of sources, such as the users, and then store it in data lakes afterwards. Data is everything these days, as is the ability to process a huge pile of data in a short time.

The use of data is always done through APIs. APIs hold all application components together and make them accessible as one for any type of client, like a user.

Of course, APIs did not come alone. The traditional monolithic architecture has given way to others, like microservices. Everything is modular these days. Microservices make any application modular and composable for better scalability, greater flexibility, and shorter time-to-market.

Microservices combined with APIs are considered the future of software development. This is so true that OWASP released in 2019 an API-adapted version of its well-known OWASP TOP 10. So, in this scenario, application security needs to both adapt to this new way of making software and keep up with it.

In the last decade, application security has also evolved as well in the form of several automated and specialized security tests. However, the evolution of security controls seems to lag behind, and this is the case of Dynamic Application Security Testing (DAST).


DAST, a nice guy

DAST came out as a "fairly" automatic black box tool to find specific web application vulnerabilities at a time when almost the only techniques were SAST analysis and manual pentesting. DASTs emerged with the promise of assisting the pentester, and filling some of the gaps in SAST tools, such as reducing false positives and reducing scanning time.

The running process was very simple: From some predefined rulesets, it sends HTTP requests to the web application and watches out for certain strings in the responses to see if there is any vulnerability. In other words, DAST attempts to simulate a pentester.

Needless to say, that there are a couple of main drawbacks: 

  • False positives. Any number of false positives would need some short of review after the scan, the so-called triage. That triage often would need the expert eyes of a cybersecurity analyst, and even for an expert it takes some precious time that may end up slowing down the post-scan steps.
  • Time. Scans take time to run, usually from 30 minutes to 2 hours, or maybe days depending on the application's size. Also, time will depend on how good the configuration is. The better the configuration, the less time it will take to run. But setting up a good pre-scan configuration is not that easy and most of the times requires a cybersecurity expert.


DAST is far behind Software Development

The way of developing software has changed. DAST is now commonly integrated in a CI/CD pipeline, and in CI/CD environments agility and speed are the cornerstones. Any build-and-deployment pipeline shouldn't last longer than just a few minutes.

This does not seem a feature of DAST. As it was mentioned before, DAST scans takes time to run, time to review the findings, and time to configure. But these pitfalls are not the only ones that are the opposite of agility and speed:

  • Discovery & Crawling. One of the great features of DAST is its ability to search and crawl almost every part of the application during scanning. By applying some heuristic rules for rewriting URLs and following links, DAST tools can discover and crawl many subdomains and sections of web applications. Another version of this discovery process is by proxing the traffic and collecting the endpoints to be scanned. But in modern times, while security is shifting to the left in the SDLC, these features could be considered a shortcoming because it takes time. Luckily, most of the DAST tools across the years have included the possibility of specifying what endpoints of the application you want to scan in various formats.
  • Developers use DAST. Under the new *DevSecOps* paradigm, developers can use some tools present in the pipelines on their own, like security tools. This is intended for providing more agility to the software development process. If developers by themselves can review the findings of a security analysis like DAST, this would supposedly speed up the whole development. In theory. In practice, developers struggle to distinguish what is a false positive from what is not, or they need to invest more time to do it than a security expert. This scenario reduces drastically the tolerance to false positives of DevSecOps teams and undermine the trust in security testing.

Finally, the software itself has changed too. As stated at the beginning, APIs and microservices are the present and the future, and DAST is not well adapted to them:

  • DAST cannot discover any dynamic generated content in a web front-end, which is very common today due to the extended use of javascript frameworks, like Angular, React, Next, JQuery, etc.
  • DAST is not able to detect some kinds of usual vulnerabilities in APIs, like IDOR/BOLA, because it requires context of the business logic of the application, like user roles and privileges.
  • DAST also struggles to pass through some protection walls, like anti-CSRF tokens and several typical authentication/authorization mechanisms in APIs, like OAuth2, SSO and multi factor authentication. Although it is possible to overcome some of these barriers, it most certainly would increase the time to prepare the scan, and every application needs its own configuration.


How to do DAST in 2023 and not die trying?

At this point, it is quite tempting to think that DAST is useless, but it is not. Many of the above shortcomings can be overcome by using DAST in some other ways:

  • Repurpose DAST to find the low-hanging fruit. Some vulnerabilities are easy and quick to find for any DAST tool and have a reasonably low false positives ratio. Some examples are insecure or missing HTTP Headers, Cross Site Scripting or even some kind of SQLi.
  • Test for specific security requirements. If a catalogue of security requirements exists, DAST could be used to try a very specific set of tests to verify those high-value requirements across many applications.
  • Create configuration templates beforehand. As stated before, the better the configuration, the less time it will take to run. It would be a nice idea to invest a bit of time in preparing some configurations that may be used to scan many applications with similar features or architecture. By doing this, with a single proper configuration, the execution time and false positives would be considerably reduced in future scans.
  • Avoid full scans. Scanning the entire application could be very time consuming, and each step in a CI/CD pipeline should be take just a few seconds or minutes. Instead, narrow the scope of the scan to just the changes recently made to the application.
  • Feed the DAST with the exact API routes to scan. If the tool supports it (recommended), always instruct the scanner to test only the API endpoints you want to scan, such as those that have any changes. This would allow to get a 100% scan coverage gradually without slowing down the CI/CD process.
  • Run DAST asynchronously. If the scan is launched in a CI/CD step and is going to take a while, a good option would be to simply execute it without waiting for it to finish. Later, when it is completed, the corresponding team would be able to review the findings or do some triage.

Apart from this, DAST still remains as a really handy tool to any pentester since it is capable of fuzzing a vast amount of input parameters on many applications in no time with some pre-defined rule sets, which allow finding many types of vulnerabilities, like injections and misconfigurations.


What to look for in a DAST tool for API Security Testing

When evaluating DAST or similar tools for API Security Testing, it can be challenging to know which tool is the best choice, so below are some criteria that you can use:

  • Easy to integrate in a CI/CD pipeline.
  • Allows to choose what kind of application to be scanned: API or web with front-end.
  • Supports several API specification formats to specify the exact API routes to scan: Postman collections, OpenAPI/Swagger, GraphQL introspection, WADL, WSDL, etc.
  • Enables to select the specific type of API about to be tested: REST, GraphQL, SOAP.
  • Provides the capability to define pre- and post-to generate fine-tune configurations for detecting business logic vulnerabilities.


To recap

The way software is developed has changed, and so has software itself. Agility and speed are now key features of any SDLC thanks to the advantages of using CI/CD pipelines. APIs have become the core of any new piece of software, so delivering secure application depends on the absence of vulnerabilities in the underlying APIs.

APIs must be secured very quickly, and although DAST is not well suited for that, it is possible to alter the configuration of the scans and form of integrating them into pipelines to scan APIs better and faster.


AI: A New Hope

This post cannot end without mentioning Artificial Intelligence. The truth is that any security solution could leverage AI to solve plenty of the gaps of DAST: improve discovery, crawling and URL rewriting, prevent duplicated or iterative requests, decrease false positives, detect complex business logic vulnerabilities...

Perhaps, AI will become the fire that will revive the DAST phoenix. What do you think?


Ernesto Rubio, Cybersecurity Analyst


3 may 2023

8 IAs (+2 combos) con las que generar imágenes para nuestras charlas hacker

Muy buenas a todos.

En cyber, como en muchos otros campos, precisamos contar con un buen acceso a bancos de imágenes, videos y demás recursos visuales con los que enriquecer nuestras presentaciones o los informes del día a día, entre otros documentos a destacar. En el post de hoy he querido recopilar algunas herramientas basadas en IA que se están popularizando últimamente para la generación de contenidos visuales. Hay tantos proyectos que cuesta probar todos los que suenan más interesantes, por lo que he aprovechado para compartir con vosotros algunos de los que mejor nos están funcionando (más una sorpresa que os he dejado para el final :P).

Empezaré por uno de los más grandes, el proyecto del propio Bing de Microsoft, el cual se apoya en Dall-E. Se accede a través de Bing, y nos permite generar imágenes en cuestión de segundos. Por ejemplo, he generado una serie de fotografías de un lince saltando sobre un candado:



Se ve un estilo muy marcado si no afinamos algo más el prompt, pero para ser una primera generación el resultado es asombroso.

La segunda de la que os hablaré, y probablemente una de las principales hoy en día, es midjourney.com, que con esa misma entrada por consola nos generaría algo como lo siguiente en una primera iteración:



Nosotros utilizamos Midjourney como herramienta profesional, y nos ahorra mucho trabajo a la hora de generar recursos visuales para las presentaciones. Los resultados son verdaderamente increíbles y por un coste mensual realmente bajo (para un uso profesional).

La tercera que os listaré es playgroundai.com. No consigue tan buenos resultados como Midjourney, o, al menos, yo no he logrado sacarle el mismo partido, pero permite crear imágenes razonablemente bien construidas sin coste, y, eso sí, es más polivalente que otros proyectos, permitiéndote subir imágenes en las que inspirarte, jugar con el tamaño, excluir partes, jugar con la calidad/detalle, etc.


El cuarto proyecto que quería mostraros en este listado es pixlr.com, un proyecto que a mi personalmente me gusta mucho para generar ilustraciones. Por ejemplo, a continuación os muestro una ilustración VS una imagen realista generadas a partir de la misma entrada de datos:



El estilo de la ilustración me muy buena, y puliéndola levemente puede convertirse en un contenido profesional.

La quinta IA que quería mostraros hoy es craiyon.com. Esta IA genera imágenes de muy buena calidad. Sin embargo, la IA que interpreta la entrada de datos no es la mejor de todas, y para obtener el resultado esperado hace falta pegarse un rato con el prompt, como podréis ver a continuación (si veis el taxi por algún sitio... me decís :P):



El sexto proyecto que quería mostraros es dreamstudio.ai. Me gusta la calidad de las imágenes generadas... pero el resultado obtenido no encaja perfectamente con lo solicitado. 



Y lo vais a ver rápidamente si lo comparamos con los resultados obtenidos con esa misma entrada en Midjourney, que parece ser la única que "entiende" el significado de "conducir":



Todas estas imágenes las podéis animar con convert.leiapix.com. Por mostraros un ejemplo sencillo, he animado la imagen del tipo que decora la parte superior de nuestro blog (por cierto, generada con Midjourney). Parece que cobra cierta vida... 


Y para aquellos que quieran generar contenidos visuales pero con un fin más publicitario, puede serles de utilidad otro tipo de proyectos como flair.ai. Como resumen rápido, se trata de una herramienta online para construir composiciones con las que anunciar productos. Está muy enfocada a tiendas y fabricantes, y funciona especialmente bien con contenidos realistas. 


De las 8 que hemos visto, nosotros nos quedaríamos con Midjourney y con Bing, pero la clave de todas estas IAs es sin duda el "saber preguntar", pidiendo lógicamente lo que queremos diseñar (mejor, en inglés), marcándole un estilo visual, utilizando otras imágenes que nos gusten como base, y aplicando variaciones, como puedan ser, por ejemplo, eliminar cierto objeto. Trabajar con IAs es realmente sencillo, pero conseguir resultados profesionales que haya que retocar "poco" para cerrarlos, requiere algo de práctica.

P.D. No quería despedirme sin compartiros 2 cosas más. En primer lugar, una última IA como combo, porque... no hay una charla hacker que se precie sin sus memes correspondientes (si no, Daniel González y Elías Grande no me lo iban a perdonar... :P). La web supermeme.ai os permitirá generar memes en imagen o gif, desde más de 100 idiomas y en cuestión de segundos:



Con supermeme ya no hará falta que os guardéis en Telegram cada meme que os encontréis por Internet..., y Dani y Elías ya no tendrán excusa para preparar esa charla de memes que siempre dicen que van a hacer y nunca hacen... :)

Y, como segundo combo, y aunque no es exactamente un proyecto basado en IA, os dejo el enlace a futureailab.com, un portal donde están manteniendo un índice de aplicaciones basadas en IA, en el que podréis aplicar filtros por temática para localizar lo que estéis buscando:

¡Espero que os haya gustado la recopilación! Os iremos compartiendo de vez en cuando nuevos proyectos que suenen interesantes y a los que podáis sacar buen partido en vuestro día a día.

¡Saludos!