Powershell: obtener la temperatura de la placa base en grados celsius.

¿Se puede obtener la temperatura de la placa base en Windows sin necesidad de apps externas y sin tener que entrar al a BIOS? Se puede con PowerShell.

Lo primero que tenemos que hacer es ejecutar PowerShell con permisos de administrador. Luego si ejecutamos este comando podríamos obtener un array con un par de lecturas de la temperatura de nuestra placa base en ese momento:

$(Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi").CurrentTemperature

Pero claro, esto no nos da la temperatura en grados celsius, ni siquiera en kelvin realmente. Si queremos ver esos datos tenemos que operar: si dividimos ese valor entre 10 obtendremos la temperatura en grados kelvin, después para convertir de kelvin a celsius habría que restar 273.15 grados. Estas operaciones podemos meterlas directamente en el comando que ejecutamos para no tener que andar haciendo cálculos manuales. Ojo, porque el objeto al que llamamos nos devuelve un array, para poder operar yo voy a acceder al primer elemento de la respuesta y forzar la conversión a entero para poder trabajar sin problema. Nos quedaría tal que así:

[int]($(Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi").CurrentTemperature[0])/10-273.15

Voy a recalcar que esta temperatura es la de la placa base y no la del procesador, que generalmente suele ser más alta.

Ciberseguridad: consejos a la hora de usar conexiones con el protocolo RDP

El protocolo de acceso a escritorio remoto (en adelante RDP) ha formado parte de Windows desde hace años, apareciendo originalmente para Windows XP. Cuando nos conectamos por RDP tenemos un equipo que hace de servidor, al que nos conectaremos, y el resto de equipos serán clientes. Aunque es una forma muy cómoda de trabajar también hay que señalar que con el paso de los años se ha quedado bastante obsoleto en términos de seguridad: carece de encriptación y es muy sensible a los ataques por fuerza bruta. Cuando durante el confinamiento de marzo-mayo de 2020 muchas empresas se lanzaron a teletrabajar sin un plan claro, dada la urgencia, se abusó de estas conexiones y muchas sufrieron problemas de seguridad (recuerdo haber leído un artículo en Twitter allá sobre el 18 de marzo donde ya se remarcaba la cantidad de escritorios remotos vulnerables que se podían localizar en España). Los delincuentes intentar servirse de conexións RDP vulnerables para instalar ransomware, spyware o practicar el cryptojacking.

Fotografía genérica de un app de seguridad.
Photo by Pixabay on Pexels.com

¿Cómo podemos usar RDP de forma segura?

Vamos a plantear varios puntos. El primero ¿necesitamos conexión vía RDP para trabajar? En muchos casos es más seguro implementar soluciones de trabajo a través de portales en la nube, claro que también requiere de una inversión en desarrollo (que se verá compensada en el largo plazo por la mejora en productividad y en seguridad).

En caso de que realmente necesitemos esta conexión vamos con el siguiente punto ¿Está nuestro software actualizado? Este es un punto recurrente en todas las entradas sobre ciberseguridad, pero es importante recordar que un equipo desactualizado suele ser más vulnerable ante cualquier tipo de ataque. No olvides descargar siempre las actualizaciones de seguridad del sistema operativo.

Los ataques más comunes contra los escritorios remotos son ataques de fuerza bruta y en muchos casos se sirven de un diccionario de usuarios y contraseñas, por lo que es recomendable no utilizar nombres genéricos para los usuarios (tipo Admin, Administrador, Administrator, etc.) dificultando así el trabajo del atacante, además de complementarlo con una política de contraseñas robustas. A día de hoy depender solo de la contraseña puede no ser suficiente, por lo que sería recomendable utilizar alguna solución para realizar una autenticación de dos factores, ya sea a través de datos biométricos, de una clave generada al momento que se envíe al usuario o del uso de un dispositivo externo para la validación. Otra buena política es bloquear el acceso de un usuario a través de este protocolo tras un número determinado de intentos fallidos de conexión. También es importante definir bien los permisos de los usuarios para limitar qué pueden y qué no pueden hacer según el trabajo que vayan a desempeñar. Un último consejo es no dejar «usuarios zombies«, cuántos más usuarios tenga el servidor más posibilidades tendrá el atacante de intentar entrar, por lo que si un usuario deja de utilizarse lo mejor será eliminarlo del sistema.

Una de las mejores soluciones que tenemos para hacer más robusta nuestra seguridad en los accesos a un servidor por RDP es utilizar una VPN: por un lado nos dará un cifrado para nuestras comunicaciones, cosa de la que carece el protocolo RDP, y por otro podremos limitar el acceso al servidor y permitirlo solo a través de dicha VPN, lo que reduce enormemente las posibilidades de un ataque. Lo ideal es conectarse a través de una VPN, pero si por lo que sea no disponéis de una entonces al menos no utilicéis el puerto por defecto, el 3389, para la conexión. Cambiando este puerto se logra reducir un poco el número de ataques automatizados, aunque no es una solución ideal pues el atacante podría simplemente buscar los puertos a la escucha. También se puede implementar un filtrado por IP en el cortafuegos, pero es algo que solo recomendaría para empresas que cuenten con una IP fija, para el teletrabajo no acaba de ser una solución práctica pues la mayoría de conexiones domésticas utilizan direcciones IP dinámicas.

Cifrar la tarjeta SD en nuestro teléfono

Cuando ayer hablaba de apps de ciberseguridad para Android comentaba entre otras buenas prácticas de seguridad la idea de cifrar la tarjeta SD del dispositivo. Me habéis preguntado cómo se hace esto y por qué habría que hacerlo.

El por qué es simple: si alguien te roba tu teléfono puede que no sea capaz de desbloquearlo si lo has protegido con un patrón, datos biométricos, código pin, etc. pero si saca la tarjeta SD y la mete en otro dispositivo entonces podrá ver todo lo que hay en ella. ¿Ventajas de cifrarla? Mayor seguridad, si te roban el teléfono esos datos están protegidos, acceder a ellos es muy difícil, puede que no imposible pero sí muy complicado ¿Contras? Dos: una pequeña pérdida de rendimiento cuando accedas a la tarjeta que será más o menos significativa según la potencia del teléfono y, sobre todo, que una vez cifrada si se te estropea el teléfono no voy a decir que sea imposible recuperar esos datos, pero estás en la misma situación que el atacante: es complicado.

¿Cómo se cifra una tarjeta SD en Android?

Bueno, como siempre con Android dependemos mucho del fabricante y de la versión del sistema operativo. Como algo genérico diré que esa opción siempre va a estar en los ajustes del teléfono, donde deberemos buscar los que sean relativos a seguridad y dentro de los mismos deberíamos encontrar alguna referencia a la tarjeta SD.

Por ejemplo, en mi actual teléfono Samsung con Android 11 habría que ir a los Ajustes, allí a Datos Biométricos y Seguridad y dentro de ese menú ya aparece una opción que es Cifrar Tarjeta SD. Esto no era exactamente igual en mi anterior teléfono, un Huawei con Android 10, en el que para cifrar la tarjeta SD habría que ir a Ajustes, allí pulsar en Seguridad, dentro de ese menú ir a Ajustes adicionales, después apretar sobre Cifrado y credenciales y finalmente Cifrar tarjeta de memoria. Como véis esta opcion estará en el apartado de seguridad del teléfono, pero según el fabricante estará más accesibe o menos. En todo caso, seguramente en la web del fabricante del teléfono tendréis un manual de instrucciones de vuestro dispositivo en el que vendrán detalladas las instrucciones concretas para hacerlo en ese modelo.

Obtener nuestra IP externa desde el terminal de Linux usando el comando dig

Bueno, si ya vimos ayer cómo obtener nuestra IP externa desde el PowerShell de Windows y anteriormente desde Linux con cURL y con wget, hoy vamos a ver unha tercera forma de hacer esto desde Linux: con el comando dig (acrónimo de Domain Information Groper).

Para este ejemplo nos serviremos del servicio de OpenDNS, aunque también podría hacersce con otros como el de Google, Cloudflare o el de Ipify que usamos ayer. Básicamente tendríamos que usar este comando:

dig +short myip.opendns.com @resolver1.opendns.com

¿Y si queremos usarlo en un script? Pues basta con meter la respuesta que capturamos en una variable:

miDirIp="$(dig +short myip.opendns.com @resolver1.opendns.com)"

Conocer nuestra IP externa desde línea de comandos en Windows, usando PowerShell

En el pasado vimos cómo podíamos descubrir nuestra IP externa desde línea de comandos en Linux, sirviéndonos tanto de cURL como del comando wget. Como ahora ya todos sabéis que soy un apaniaguado del Tito Bill vamos a ver cómo hacerlo con el PowerShell de Microsoft.

Como siempre, cuando se trata de la IP externa, tenemos que recurrir a un servicio web externo. Hay un buen montón de opciones para esto, pero por comodidad (comodidad para mí, porque ya tengo las pruebas hechas con ese) recurriremos a https://api.ipify.org

En PowerShell podemos usar el cmdlt Invoke-WebRequest para lanzar peticiones http y https a una web y recoger su respuesta. Si llamamos al api que os ponía arriba obtendremos nuestra IP.

Invoke-WebRequest -uri "https://api.ipify.org/"

¿Y ya está? Pues no, porque eso nos devolverá como texto plano además de la IP el status de la respuesta y las cabeceras, por lo que aunque podemos leer la IP sería incómodo trabajar con ella. Pero por suerte el cmdlt nos permite filtrar y obtener solo el valor que nos interesa. Tal que así:

(Invoke-WebRequest -uri "https://api.ipify.org").content

De esa forma sí que obtendríamos solo la línea con el valor de la IP, ya que accedemos únicamente al contenido de la respuesta, al valor de content. Si quisiéramos meter el valor de la IP en una variable para trabajar con un script podríamos hacerlo tal que así:

$miDirIP = (Invoke-WebRequest -uri "https://api.ipify.org/").Content

Linux: matar procesos usando Kill, Pkill y Killall

Linux nos da tres opciones para matar procesos desde el terminal: kill, pkill y killall.

Antes de ver los tres comandos es importante recordad un punto: un usuario normal solo puede matar sus procesos, no los procesos del sistema o los de otro usuario. Un usuario root en cambio sí puede matar cualquier proceso, tanto del sistema como de otro. Realmente, a pesar de sus nombres, estos tres comandos no están pensados exclusivamente para matar procesos, sino que les pueden enviar todo tipo de señales, aunque sí es cierto que matar procesos es el comportamiento por defecto.

El comando kill nos permite matar un proceso identificándolo por su número identificador (PID), la sintaxis básica es kill -señal PID. El valor de la señal varía entre 64 posibilidades, siendo las que permiten matar procesos estas tres: SIGHUP (que se abrevia también con el valor numerico 1), SIGKILL(que se abrevia con el valor numérico 9) o SIGTERM(que se abrevia con el valor numérico 15). Si no ponemos ningún valor el tomado por defecto será 15, que es el más seguro pues no permite que se mate un proceso que esté en ejecución sino que espera a que termine y lo mata en ese momento, mientras que el valor 9 sería el más inseguro y contundente, mata al proceso incluso aunque esté ocupado. En el ejemplo siguiente veremos como matar un proceso que, por ejemplo, tenga el id 2015, primero con el valor por defecto y luego con la opción -9 o SIGKILL (las dos últimas sería la misma instrucción pero con distinta sintaxis):

kill 2015
kill -SIGKILL 2015
kill -9 2015

También podemos matar varios procesos en la misma instrucción. Imaginemos que queremos matar los procesos 2015, 2022 y 3049, solo tenemos que listarlos tras la instrucción kill separados por un espacio:

kill 2015 2022 3049

Si no queremos estar listando los procesos para poder ver sus PID podemos también matar un proceso por su nombre. Eso lo puedes hacer con el comando killall, que lo que hará será matar todos los procesos que coincidan con el nombre del comando. Imagina que quieres matar el proceso de mysql en tu servidor Linux, de esta forma lo harías, pero ojo porque si tienes varias instancias las mataría todas. Las señales para killall son distintas de las de kill, puedes listarlas ejecutando killall -l aunque coincide que el valor -9 también es el que podemos usar para matar el proceso de forma forzosa.

killall -9 mysql

Finalmente nos queda pkill, un comando que fue creado originalmente para el sistema operativo Solaris y cuyo funcionamiento es similar al de killall, la diferencia es que en este caso no necesitamos saber todo el nombre del proceso pues podemos usar exprexiones regulares para definir qué proceso queremos parar. Igual que en el ejemplo anterior veamos cómo terminaríamos el proceso de mysql, con el parámetro -e para que la consola nos informe de que lo ha eliminado.

pkill -e mysql

Crear un certificado autofirmado con OpenSSL

Ya habíamos hablado anteriormente de OpenSSL, vamos a ver hoy cómo podríamos generar un certificado autofirmado. Vamos a generarlo con cifrado SHA512 y con clave RSA de 4096 bits, que se llamarán micerautofirm.key y micert.pem (el nombre lo podeís poner vosotros).

openssl req -x509 -sha512 -nodes -newkey rsa: 4096 -keyout micerautofirm.key -out micert.pem

Este certificado autofirmado tiene validez por un mes. Si queréis uno para más tiempo podéis utilizar el parámetro -days y pasarle un entero con el número de días. Por ejemplo, para un año:

openssl req -x509 -sha512 -nodes -days 365 -newkey rsa: 4096 -keyout micerautofirm.key -out micert.pem

Script de PowerShell para enviar un correo con Gmail

Un compañero necesitaba un script de PowerShell que enviase un correo con un texto concreto desde su dirección de email a otra dirección fija, pero no lograba que funcionase correctamente utilizando su cuenta de Gmail. En su día por aquí, ya hace años, hablamos sobre cómo enviar correos desde una cuenta de Gmail usando PHPMailer, así que durante la hora de comer le he echado una mano y he hecho algo sirviéndome del cmdlet Send-MailMessage:

$username   = 'tucorreo@gmail.com'
$password   = 'tupassword'
$secstr     = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$brocolharum = @{
    from       = "tucorreo@gmail.com"
    to         = "correoquerecibe@gmail.com"
    subject    = "Danger Danger, high voltage!"
    smtpserver = "smtp.gmail.com"
    port       = "587"
    body       = "Si te estás leyendo esto me debes un capuccino con licor de avellana"
    credential = New-Object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr
    usessl     = $true
    verbose    = $true
    DeliveryNotificationOption = "OnFailure"
}

Send-MailMessage @brocolharum

Se trata de un ejemplo muy básico, después podéis adaptarlo a vuestras necesidades.

VPN: ¿Qué es? ¿Para qué sirve? ¿Para qué no sirve?

Siguiendo con la serie de entradas sobre ciberseguridad vamos a hablar hoy sobre conexiones VPN, ya que seguramente has visto en los últimos tiempos muchos anuncios de distintas empresas que ofrecen este servicio. Antes de que lo preguntes, no te recomiendo usar ninguna gratuita, al menos si tu intención es usarla para mejorar tu seguridad.

Tablet navegando a través de VPN
Photo by Dan Nelson on Pexels.com

Empezando por lo básico ¿Qué es una VPN? VPN es el acrónimo de Virtual Private Network (Red Virtual Privada en castellano) y nombra a una tecnología que nos permite unir varios equipos como si estuvieran en una red interna (LAN), pero a través de una red pública como internet. Lo que generalmente ves anunciado cuando te ofertan una VPN son servicios de empresas, que te venden una aplicación para que navegues a través de su configuración VPN con tráfico cifrado y de sus servidores, que para darte mayor seguridad funcionarán como servidores proxy.

¿Para qué sirve una VPN?

Uno de los usos más habituales de esta tecnología es acceder remotamente a la red de una organización como si se estuviera trabajando conectado a la red local. Pensemos en un empleado que teletrabaje y necesite acceder a una serie de documentos que están en un servidor de la empresa, mediante una VPN podría acceder a ellos aunque esté en la otra punta del planeta. También podría servirnos para acceder al NAS de nuestra casa si estamos de viaje, conectándonos desde nuestro hotel. Para este uso muchas empresas no contratan un servicio externo y simplemente configuran una VPN en su red y sus servidores, para que sus trabajadores puedan acceder remotamente de forma segura.

Las VPN suelen tener un cifrado fuerte, así que también son una buena alternativa para añadir una capa de seguridad a mayores si estamos navegando en una red abierta que no sea muy confiable (la wifi de un bar o de un aeropuerto, por ejemplo). Si tienes que acceder a una web que requiere autenticación (usuario y contraseña, por ejemplo la web de tu banco) y estás conectado a una de estas wifis, el uso de una VPN ayudará a evitar que un delincuente pueda capturar nuestros datos de navegación o incluso que pueda redirigirnos a una web fraudulenta, todo eso gracias a la capa de cifrado y a la configuración de las DNS de la VPN, es lo que se llama túnel de datos.

Portátil usando VPN
Photo by Stefan Coders on Pexels.com

Otro de los usos habituales de una VPN es saltarse bloqueos regionales. A veces un contenido on-line no está disponible en nuestro país, puede ser por una cuestión de censura (el gobierno del país no quiere que sus ciudadanos accedan a esa información) o puede ser por una cuestión de negocio (se trata de un producto comercial y sus derechos no están disponibles en el país), pero el resultado es que no podemos acceder a dichos datos. Cuando una web se bloquea para una región la responsabilidad del bloqueo recae en los proveedores de Internet ¿Cómo funciona esto? Al usar estos servicios de VPN nuestra salida a internet se hace a través de un servidor proxy, explico con más detalles: cuando navegamos de forma normal nuestro equipo se comunica con el router, que pide a nuestro proveedor que nos haga llegar la información que solicitamos y este es el que decide si nos la envía o no. Si navegamos a través de una VPN lo que hacemos es decirle a nuestro proveedor que nos conecte al servidor proxy de dicha VPN, generalmente las empresas nos darán a elegir varios servidores en distintos países, y en este caso es el servirdor quien pedirá a su proveedor de internet esa información que luego nos enviará cifrada. Como la petición no se hace desde nuestra IP, sino desde el servidor proxy a través del que navegamos, estaríamos sometido a los bloqueos regionales del proveedor del país donde se encuentra ese servidor y no de los del nuestro. Por ejemplo, cuando no había Netflix en España había gente que se hacía una cuenta en el Netflix de EEUU, si intentaba acceder sin VPN recibían un mensaje informándoles de que el servicio no se encontraba disponible en su país, en cambio si usaban una VPN que tuviera en servidor en los EEUU podían acceder como si estuvieran allí.

¿Para qué NO sirve una VPN?

En algunos anuncios de servicios VPN he leído «Aumenta tu velocidad de conexión«, así en letras grandes que harán pensar al potencial cliente que si contratan esa VPN su conexión a internet será más rápida. Todo lo contrario, las VPN no aumentan la velocidad sino que la ralentizan al tener que cifrar los datos y al tener que pasar la información por más nodos. Tampoco es que estos anuncios sean un timo, normalmente la letra pequeña suele aclarar que lo de «Aumenta tu velocidad…» se refiere a que es más rápida que otras VPN de la competencia (las VPN gratuitas suelen ser especialmente lentas).

A muchos os sorprenderá pero otra cosa para la que no sirve una VPN es para garantizar nuestro anonimanto en la red. La mayoría de los anuncios prometen eso, «navega de forma anónima«, pero esto no es realmente así, o más bien no es es exactamente así. Como ya comentamos antes, al navegar a través de una VPN nuestras peticiones hacia internet salen desde el servidor de la misma y la comunicación con dicho servidor desde nuestro equipo está cifrada, lo cual tiene varios efectos: como ya comentamos antes, nuestro proveedor no puede saber qué estamos viendo en Internet, también nos protege de ser espiados dentro de nuestra propia red y además hará que el servicio al que accedamos no pueda ver nuestra IP y los datos que pueden sacarse de ella (como proveedor de internet o ubicación), pues lo que verá será la IP del servidor proxy al que nos conectamos. Lo citado es todo el «anonimato» que nos puede dar la VPN, tenemos que ser conscientes de varios puntos: la VPN no nos da ninguna garantía ante cookies de rastreo, para eso tendríamos que recurrir mejor a las pestañas de navegación anónimas de nuestro navegador. Además, el servidor de la VPN puede registrar nuestro tráfico, la privacidad en una VPN no viene por el diseño y las medidas técnicas de la misma sino por sus políticas de empresa y por las obligaciones legales, muchas VPN gratuitas se financian vendiendo esos datos de navegación de sus usuarios y en caso de requerimiento judicial pueden identificar a un usuario. Comento a mayores que he visto a gente usar una VPN para luego entrar en su cuenta de Youtube o Facebook creyendo que de esa forma esos servicios no pueden saber qué hacen, otro error, con tu cuenta conectada estarán registrando tu actividad por mucha VPN que uses.

¿Merece la pena contratar una?

Pues depende ya de cada usuario valorar si merece la pena contratarla. Desde luego una VPN es una buena herramienta para el teletrabajo, en algunos casos incluso esencial. También nos da un extra de seguridad si tenemos que conectarnos habitualmente, por el motivo que fuere, a través de redes poco confiables. Si lo que buscas es anonimato en ese caso la VPN, como ya hemos visto, no te lo garantiza. Si hacemos caso a Snowden lo mejor sería combinar VPN+Red TOR para esto. Como ya hemos comentado antes, algunos servicios gratuitos son muy lentos y comercian con los datos de navegación de los usuarios, así que lo más recomendable si quieres una VPN es un servicio de pago.

Ciberseguridad: Troyanos Keyloggers, Backdoors y Stealers ¿Qué son?

«De tu cólera nacerá Europa, pero para que nazca Europa, tú tienes que morir en Troya«. Como vamos a hablar de Troyanos empiezo citando una frase de La Cólera de Santiago García, uno de los mejores guionistas de tebeos españoles y una obra flipante con un dibujo de Javier Olivares tremendo, pero aunque me encante charlar de tebeos y aunque la obra de Homero sea fundamental en el desarrollo de la cultura literaria europea y occidental no serán La Odisea o La Ilíada lo que hoy nos ocupe, aunque tenga un poco que ver.

Decía que tienen un poco que ver porque este tipo de malware originalmente se denominaba Trojan Horse (Caballo de Troya, después abreviado a simplemente Trojan), en referencia a la estrategia de Odiseo para tomar la ciudad: camuflar a sus soldados dentro de una estatua y dejarla como regalo. Al igual que aquellos griegos, los troyanos se ocultan dentro de un software en apariencia legítima para infectar a tu equipo, algo de lo que ya hemos hablado en las entradas sobre rogueware o sobre apps maliciosas. Se dice que el primer troyano conocido, si nos fiamos del libro At the Abyss: An Insider’s History of the Cold War de Tomas C.Reed (ex-asesor de Reagan en materia de seguridad nacional), fue uno introducido por la CIA en 1982 en un software canadiense diseñado para controlar el sistema de un gasoducto y que se esperaba que fuese robado por espías rusos para usarlo en el gasoducto transiberiano, que proveería gas a varios países europeos y al que EEUU se oponía por su antagonismo hacia la URSS y también por su tradicional alianza con la monarquía marroquí. El resultado de dicho ataque informático habría sido una enorme explosión seguida de un gran incendio, sin víctimas mortales humanas directas pero con terribles efectos sobre la economía soviética, dejando inhabilitado el gaseoducto durante meses. Añado que la CIA no ha confirmado en ningún momento la historia de Reed ni figura en documentos desclasificados, mientras que desde el lado ruso hay división de opiniones sobre si hubo o no sabotaje.

Fotografía genérica con comandos
Photo by Negative Space on Pexels.com

Generalmente las infecciones por troyanos suelen producirse por descargar ficheros que nos llegan en correos maliciosos o por utilizar software descargado de fuentes no fiables. Como siempre recomiendo y repito porque soy un viejo cascarrabias: tened cuidado antes de abrir nada que se reciba por correo/mensajería instantánea, preguntad al remitente siempre antes de abrir nada. Descargad el software siempre desde el sitio del fabricante. Tener un antivirus actualizado nos ayudará a prevenir muchos de los ataques también, aunque no pueda garantizar una protección del 100% si se trata de una vulnerabilidad nueva sí nos ayudará contra amenazas ya conocidas.

Keyloggers, backdoors y stealers:

Sobre el ramsonware, el malware que secuestra tus ficheros cifrándolos, ya hablamos largo y tendido en su propio artículo, así que no me explayaré y veamos los otros tres tipos de troyanos más habituales:

  • Keyloggers: un keylogger es un programa que captura todas las señales que el equipo recibe del teclado, almacenándolas en un fichero y enviándolas en algún momento al atacante. Su principal utilidad es descubrir pares de usuarios y contraseñas entre los textos tecleados. Os comentaré que este tipo de ataque además de a través de un troyano también se puede realizar mediante un hardware específico. Si descubrimos que hemos sido infectados por uno lo mejor es que, tras limpiar el equipo con un anti-malware, cambiemos nuestras contraseñas por si acaso, también es interesante tener activada la autenticación en dos pasos en nuestros servicios web para evitar que puedan acceder solo con la contraseña.
  • Backdoors: una backdoor, puerta trasera en castellano, es un software que da acceso remoto a nuestro equipo a un atacante si que seamos conscientes de ello. Esto le permitirá hacer cualquier tarea sirviéndose de nuestro equipo.
  • Stealers: un stealer, en castellano ladrón, es un software diseñado para robar información almacenada en nuestro equipo, como puedan ser credenciales de acceso a algún servicio web, números de tarjeta de crédito, etc. Los consejos que os daré si habéis sido infectados son los mismos que con el keylogger, tras desinfectar el equipo con algún anti-malware el cambio de contraseñas será fundamental. De nuevo insisto en la autenticación de dos factores para tener un extra de protección ante el robo de contraseñas.