[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3jl66q5uxvqgp":3},{"success":4,"posts":5,"pagination":56,"availableLocales":59},true,[6],{"_id":7,"slug":8,"title":9,"excerpt":10,"content":11,"coverImage":12,"authorName":13,"authorType":14,"publicationKind":15,"category":16,"tags":17,"metaDescription":22,"metaKeywords":23,"isFeatured":28,"publishedAt":29,"createdAt":30,"updatedAt":29,"readTime":31,"viewCount":32,"contentLocale":33,"availableLocales":34,"hasEnglishTranslation":4,"translations":44},"ca1ba9756e09172be1d6dc5a","why-password-change-may-not-end-infostealer-access","Por qué cambiar la contraseña puede no poner fin al acceso obtenido mediante malware de robo de información","Cambiar la contraseña puede dejar utilizable una sesión robada. Conozca cómo se combinan la contención del dispositivo, la invalidación de tokens, los controles de sesión de las aplicaciones y la recuperación de la cuenta.","\u003Cp>Una aplicación web puede mantener una sesión activa después de cambiar la contraseña de la cuenta. Según sus capacidades, un malware de robo de información puede recopilar contraseñas almacenadas, así como cookies de sesión, tokens de autenticación, claves API y otros datos locales. Si esa información ya ha salido del dispositivo, eliminar el malware no la invalida.\u003C\u002Fp>\u003Cp>Una contraseña es un secreto que se presenta durante la autenticación. Un token de acceso permite a una aplicación acceder a determinados recursos, mientras que un token de actualización puede obtener un nuevo token de acceso cuando el protocolo lo permite. Una sesión de aplicación suele mantenerse mediante una cookie o un secreto de sesión independiente, emitido después de la autenticación. Estos mecanismos pueden pertenecer a la misma cuenta, pero no necesariamente comparten un periodo de vigencia ni un mecanismo de revocación.\u003C\u002Fp>\u003Ch2>¿Qué accesos pueden seguir vigentes tras cambiar la contraseña?\u003C\u002Fh2>\u003Cp>Un cambio de contraseña impide los nuevos inicios de sesión que dependen de la contraseña anterior. No se puede dar por hecho que ponga fin a todos los tokens o sesiones de aplicación que sigan siendo válidos. Según la \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Fusers\u002Fusers-revoke-access\">guía de Microsoft sobre la revocación de acceso en una emergencia en Entra\u003C\u002Fa>, bloquear los nuevos inicios de sesión y revocar los tokens de actualización impide que el usuario obtenga nuevos tokens de Entra. Sin embargo, un token de acceso existente puede seguir funcionando hasta que termine su periodo de vigencia predeterminado de una hora. Continuous Access Evaluation puede acortar ese intervalo en los escenarios de Microsoft 365 compatibles; no garantiza la invalidación instantánea de todos los tokens.\u003C\u002Fp>\u003Cp>Una cookie de sesión emitida por una aplicación debe gestionarse por separado. Entra no puede revocar directamente un token de sesión emitido por la propia aplicación. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fsession\u002F\">NIST SP 800-63B-4\u003C\u002Fa> describe la misma separación en los sistemas federados: el proveedor de identidad (IdP) y la parte que confía en él (RP) establecen y terminan sus sesiones de forma independiente. Finalizar la sesión del proveedor de identidad no pone fin, por sí solo, a las sesiones de todas las aplicaciones conectadas.\u003C\u002Fp>\u003Cp>Esa distinción resulta útil para un atacante. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1550\u002F004\u002F\">MITRE ATT&CK documenta\u003C\u002Fa> cómo una cookie de sesión web robada que siga siendo válida y reutilizable puede importarse a un navegador controlado por un atacante. Como la sesión ya está autenticada, algunos flujos de autenticación pueden no exigir un nuevo paso de MFA. Esto describe una capacidad, no demuestra que se haya tomado el control de una cuenta concreta.\u003C\u002Fp>\u003Ch2>Contención del dispositivo y controles de la cuenta\u003C\u002Fh2>\u003Cp>El dispositivo sospechoso se aísla conforme al plan de respuesta a incidentes de la organización, mientras se evalúa la necesidad de preservar las pruebas pertinentes. Si la cuenta tiene privilegios elevados o permite acceder a datos sensibles, el bloqueo de nuevos inicios de sesión y el cierre de las vías de acceso actuales pueden comenzar antes de completar el análisis del dispositivo. Los cambios de contraseña, la recuperación de la cuenta y las tareas administrativas se realizan mediante un dispositivo y un canal de confianza para no exponer las nuevas credenciales al sistema sospechoso.\u003C\u002Fp>\u003Ch3>Datos de acceso almacenados en el dispositivo\u003C\u002Fh3>\u003Cp>La revisión no se limita a las contraseñas guardadas después del periodo en el que se sospecha que se produjo la infección. El inicio de una infección puede ser incierto, y un malware de robo de información puede acceder a credenciales que ya estaban almacenadas en el dispositivo. En función de las pruebas del incidente, la revisión abarca los perfiles de navegador, las cuentas utilizadas o almacenadas localmente, las cookies de sesión, los tokens y las claves API. Limpiar o reconstruir el dispositivo no invalida las contraseñas, los tokens ni las claves que puedan haberse sustraído.\u003C\u002Fp>\u003Ch3>Controles de tokens y sesiones\u003C\u002Fh3>\u003Cp>Se utilizan los controles documentados del proveedor de identidad para bloquear nuevos inicios de sesión, invalidar los tokens de actualización cuando sea posible y terminar las sesiones del IdP. A continuación, se revisan por separado las aplicaciones críticas y se terminan sus propias sesiones mediante los controles de cada aplicación. Un mensaje de “éxito” en una pantalla de administración no demuestra que haya finalizado todo acceso. Siguen siendo importantes el tipo de token, la condición prevista para su caducidad y el momento en que cada aplicación volverá a exigir autenticación.\u003C\u002Fp>\u003Cp>La contraseña y los demás datos de acceso incluidos en el alcance del incidente se sustituyen o invalidan desde un dispositivo de confianza. Que esto incluya una clave API, un token de desarrollador u otra credencial almacenada localmente depende de las pruebas del incidente y del comportamiento del sistema afectado. El objetivo no es restablecer todas las cuentas sin criterio, sino determinar qué contraseñas, tokens, claves o cookies de sesión pueden haber salido del dispositivo y seguir siendo utilizables.\u003C\u002Fp>\u003Ch3>Cambios para mantener el acceso\u003C\u002Fh3>\u003Cp>Un intruso puede añadir una vía para volver a acceder a la cuenta en lugar de depender únicamente de la sesión actual. La \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Fresponding-to-a-compromised-email-account\">guía de Microsoft para responder al compromiso de una cuenta de correo de Microsoft 365\u003C\u002Fa> indica que deben revisarse los métodos de MFA y dispositivos no reconocidos, los consentimientos no deseados a aplicaciones, los roles administrativos no autorizados, el reenvío de correo y las reglas ocultas de la bandeja de entrada. Esa lista es específica de Microsoft 365; los controles equivalentes y sus efectos varían entre proveedores.\u003C\u002Fp>\u003Cp>Un método de MFA no reconocido o sospechoso se elimina o invalida. Si es necesario volver a registrar el método del usuario legítimo, primero se verifica la titularidad mediante un canal de recuperación de confianza y solo se registra un nuevo método controlado por ese usuario. Volver a registrar un método añadido por un atacante mantendría la vía de acceso en lugar de cerrarla.\u003C\u002Fp>\u003Ch2>MFA no revoca una sesión activa\u003C\u002Fh2>\u003Cp>La MFA añade otra barrera al inicio de una nueva sesión con una contraseña robada, pero no invalida por sí sola una cookie reutilizable de una sesión ya autenticada. Los métodos de MFA también ofrecen distintas protecciones. Los \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fauthenticators\u002F\">requisitos de NIST para los autenticadores\u003C\u002Fa> no consideran resistentes al phishing los códigos de un solo uso introducidos manualmente y citan WebAuthn\u002FFIDO2 como ejemplo de autenticación resistente al phishing. Una autenticación más robusta protege los futuros inicios de sesión; una sesión robada que siga siendo válida aún debe terminarse por separado.\u003C\u002Fp>\u003Ch2>Qué pueden demostrar los registros y qué no\u003C\u002Fh2>\u003Cp>Cuando están disponibles, los registros de inicios de sesión y de acciones sensibles correspondientes al periodo del incidente pueden revelar ubicaciones y horarios inusuales, permisos concedidos a aplicaciones y cambios en la cuenta. En el caso de Microsoft 365, el proveedor desaconseja limitar demasiado pronto la búsqueda inicial en los registros de auditoría y recomienda revisar los registros desde el inicio de la actividad sospechosa hasta la remediación. No encontrar ningún evento sospechoso no demuestra que la cuenta esté segura. El resultado solo tiene valor dentro de los límites de la telemetría disponible, el periodo de conservación, las fuentes consultadas y el intervalo de tiempo analizado.\u003C\u002Fp>\u003Cp>Del mismo modo, las pruebas de que una credencial o una cookie quedó expuesta no constituyen, por sí solas, pruebas de un uso no autorizado exitoso ni de una toma de control de la cuenta. La exposición, los intentos de uso observados y la toma de control confirmada siguen siendo situaciones distintas. Las vías de acceso potencialmente válidas requieren una respuesta proporcionada, cuyo alcance se determine según los privilegios de la cuenta, la sensibilidad de los datos y las pruebas disponibles. La \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fleakdata.io\u002Fen\u002Fblog\u002Fwhat-is-a-data-breach-what-to-do-if-your-email-was-leaked\">guía de LeakData para evaluar la situación tras una filtración\u003C\u002Fa> aborda esa distinción más amplia entre la exposición y el uso indebido confirmado.\u003C\u002Fp>\u003Cp>El registro del incidente enumera las sesiones terminadas en el proveedor de identidad y en las aplicaciones, las condiciones previstas para la caducidad de los tokens, los cambios no autorizados que se eliminaron y las lagunas en la revisión de los registros. Así queda claro qué vías de acceso se han abordado y qué incertidumbres persisten.\u003C\u002Fp>\u003Ch2>Referencias\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Fusers\u002Fusers-revoke-access\">Microsoft Learn — Revocar el acceso de un usuario en una emergencia en Microsoft Entra ID\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Fresponding-to-a-compromised-email-account\">Microsoft Learn — Responder al compromiso de una cuenta de correo en Microsoft 365\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fsession\u002F\">NIST SP 800-63B-4 — Gestión de sesiones\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fauthenticators\u002F\">NIST SP 800-63B-4 — Requisitos para los autenticadores\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1550\u002F004\u002F\">MITRE ATT&CK T1550.004 — Cookie de sesión web\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fspecopssoft.com\u002Fblog\u002Finside-infostealer-attacks\u002F\">Specops Software — Cómo funcionan los ataques con malware de robo de información\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>","\u002Fuploads\u002Fblog\u002Finfostealer-sonrasi-parola-degisikligi-neden-yetmeyebilir-dfdf6bda3fb759147214.webp","Equipo de seguridad de LeakData","Organization","blog","güvenlik",[18,19,20,21],"malware de robo de información","respuesta a incidentes","seguridad de las sesiones","identidad y acceso","Cambiar la contraseña puede no cortar el acceso de un malware de robo de información: controles del dispositivo, tokens, sesiones y persistencia.",[24,25,26,27],"respuesta al malware de robo de información","invalidación de tokens","cookie de sesión robada","cambio de contraseña",false,"2026-10-09T16:49:52.841Z","2026-09-16T23:36:22.537Z",7,0,"es",[35,36,37,38,33,39,40,41,42,43],"en","tr","zh","hi","ar","fr","bn","pt","ru",{"en":45,"tr":46,"zh":48,"hi":49,"es":50,"ar":51,"fr":52,"bn":53,"pt":54,"ru":55},{"slug":8},{"slug":47},"infostealer-sonrasi-parola-degisikligi-neden-yetmeyebilir",{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"page":57,"limit":58,"total":57,"pages":57},1,12,[35,36,37,38,33,39,40,41,42,43]]