Cleartext Passwords in MS Edge? In 2026?

    Published: 2026-05-05. Last Updated: 2026-05-05 11:35:17 UTC
    by Rob VandenBrink (Version: 1)
    0 comment(s)

    Yup, that is for real.

    For me, this started with a post in X at hxxps://x.com/intcyberdigest/status/2051406295828250963?s=61 , which highlighted research by @L1v1ng0ffTh3L4N that found exactly this issue.  Edge stores all of your browser passwords in clear text, even if you haven't used them in this session, y'know, just in case.

    I figured, it couldn't be that easy, right?  But like so many things, yes, yes it was.

    To reproduce this

    • Open Edge.  Don't browse anywhere, just open it
    • Flip out to Task Manager, search for Edge, then expand that task
    • Highlight the "browser" sub-task, right click, and choose "Create Memory Dump"

     

    Navigate to where the DMP file is stored.  

    If you haven't used strings before, you're in for a treat.  Strings is of course just part of most Linux distros, but you can easily get a copy for Windows as part of MS Sysinternals, at https://learn.microsoft.com/en-us/sysinternals/downloads/strings


    Now let's look for passwords!  You could use strings and look for known credentials, just search for a known password and you will certainly find it.  Or you can take advantage of the format of the saved data:

    <url of the site><protocol>< ><userid>< >password>

    So, searching for "<tld><protocol>", which in most cases is "comhttps" (no spaces) will find most of them, and they'll all be in one nicely formatted group no less.  The command for that will be:

    strings -n 8 msedge.DMP | find "comhttps"

    looking a bit down in the output (since comhttps does match more stuff in the memory dump than just the credential list), I see:

    As you can see, Edge isn't  my primary browser, but I do use it a fair bit for Azure work.  And yes, this is a real session, so I cropped/blurred out sensitive accounts and of course passwords.

    It really is that easy.

    And the ironic thing?  To view these same credentials in the browser, there's a whole security theatre process where Edge wants your biometrics as proof before disclosing even the userid and site names - you know, "for security".  All the while, the whole shot is in clear text, free for the looking ..

    Also as noted in the X post, Microsoft classifies this as "intended behaviour".  I'm not sure what manager or lawyer decided that, hopefully it wasn't anyone in their security team.

    Anyway, if the intent of this is to get me to use Firefox or Chrome, it's working!!

    Have you seen a similar "strong front door / open window" security example in your forensics, please share in the comments (keeping any NDA's etc in mind of course)

    ===============
    Rob VandenBrink
    rob@coherentsecurity.com

    0 comment(s)

    SSL.com rotates their root certificate today

    Published: 2026-05-05. Last Updated: 2026-05-05 11:28:35 UTC
    by Rob VandenBrink (Version: 1)
    0 comment(s)

    I just got an email from SSL.com last night, they are rotating  out their root certificate today (May 5,2026).  This is normal, business as usual stuff for a CA, but certificates get used for all kinds of things, and sometimes they aren't used like they should be, so sometimes hiccups happen.

    If you are using them for basic cert+website stuff, there's no need to worry.  But if you go past that basic implementation, you should read their note to make sure that this change won't be affecting any of your services.  Even if you don't use ssl.com, it's a good read, as every certificate expires, which means that everyone's root cert rotates out eventually - so forewarned if forearmed and all that ..

    In particular (from the email):

    • If you have pinned trust anchors, custom trust stores, or certificate validation logic tied to the 2016 roots, please audit those configurations promptly to avoid disruptions.
    • Use cross-certificates. If you need backward compatibility with the 2016 root hierarchy during the transition, cross-certificates can bridge the gap.
    • Migrate to dedicated Client Certificates. These are purpose-built for client authentication and are unaffected by Google Chrome's upcoming server authentication requirements, which impact SSL/TLS certificates with the ClientAuth EKU.

    Their full post is here:

    https://www.ssl.com/article/what-ssls-root-migration-means-for-you    

    ===============
    Rob VandenBrink
    rob@coherentsecurity.com

    Keywords:
    0 comment(s)
    ISC Stormcast For Tuesday, May 5th, 2026 https://isc.sans.edu/podcastdetail/9918

      Comments


      Diary Archives