Microsoft Edge 저장 비밀번호의 평문 메모리 노출과 대응

브라우저를 잠가도 메모리에 남는 Edge 비밀번호

2026년 4월 말 보안 연구자 @L1v1ng0ffTh3L4N은 Microsoft Edge 비밀번호 관리자의 설계 문제를 공개했다. Edge는 실행과 함께 저장된 비밀번호 전체를 평문으로 메모리에 적재하며, 브라우저가 잠겨 있거나 비활성 상태여도 해당 자격증명이 프로세스 메모리에 암호화되지 않은 채 남는다.

Microsoft는 이를 "의도적인 설계 결정"이라고 설명했지만, 보안 패치나 개선 계획은 발표하지 않았다. 이 문제는 디스크에 암호화해 저장한 비밀번호가 실제 사용 시점에 어떤 방식으로 메모리에 머무르는지를 다시 보게 한다.

테스트에서 확인된 평문 적재

Tom Jøran Sønstebyseter Rønning(온라인 핸들: @L1v1ng0ffTh3L4N)은 Chromium 기반 브라우저를 분석하던 중 Edge의 동작 차이를 발견했다. Klartext-PW-Test라는 테스트 비밀번호를 저장하고 Windows 작업 관리자로 Edge 프로세스의 670MB 메모리 덤프를 만든 뒤, 16진수 편집기로 파일을 검색했다. 비밀번호는 암호화되지 않은 평문 문자열로 바로 확인됐다.

문제의 핵심은 단순히 메모리에 평문이 존재한다는 데서 끝나지 않는다. 일반적인 설계라면 특정 사이트를 방문하거나 자동 완성이 필요한 시점에 해당 자격증명만 복호화한다. 반면 Edge는 브라우저가 시작될 때 저장된 모든 비밀번호를 한꺼번에 메모리에 올린다. 비밀번호 관리자 UI가 Windows Hello 인증을 요구하는 잠금 상태여도 자격증명은 이미 프로세스 메모리에 존재한다.

Chromium 기반 브라우저 사이의 차이

연구자가 시험한 주요 Chromium 기반 브라우저 가운데 이 방식으로 동작한 것은 Edge뿐이었다.

브라우저	비밀번호 복호화 시점	메모리 보존 방식	추가 보호
Google Chrome	필요 시(온디맨드)	사용 후 메모리 소거	App-Bound Encryption
Brave	필요 시(온디맨드)	사용 후 메모리 소거	DPAPI + 앱 바인딩
Firefox	마스터 패스워드 기반	잠금 시 메모리 소거	NSS 암호화
Microsoft Edge	시작 시 전체 로드	세션 종료 전까지 유지	Windows Hello(UI만 보호)

Google은 Chrome 127(2024년 7월)부터 App-Bound Encryption을 도입했다. 쿠키와 비밀번호 암호화 키를 DPAPI로 보호한 뒤 SYSTEM 계정의 DPAPI로 다시 암호화하는 구조다. 키 탈취에 SYSTEM 수준 권한이 필요해 일반 사용자 권한으로 실행되는 인포스틸러 악성코드의 접근을 막는다. Edge는 Chromium 코드베이스를 사용하지만 이 메모리 보안 강화는 적용하지 않았다.

공유 시스템에서 커지는 노출 범위

개별 워크스테이션에서도 영향은 크지만, 터미널 서버와 공유 컴퓨팅 환경에서는 피해 범위가 더 넓어진다. 연구자는 관리자 권한을 가진 공격자가 Edge를 실행 중인 서로 다른 사용자 두 명의 메모리에서, 연결이 끊긴 세션을 포함해 자격증명을 동시에 가져가는 개념 증명(PoC)을 시연했다. 터미널 서버의 관리 권한을 확보한 공격자는 Edge를 실행 중인 모든 사용자의 비밀번호를 수초 내에 탈취할 수 있다.

독일 연방 정보보안청(BSI)은 2024년 12월 비밀번호 관리자 보안 평가에서 Edge 비밀번호 관리자를 대상에서 제외했고, 설계 방식에 관한 우려를 명시했다.

msedge.exe를 대상으로 한 메모리 덤프 경로

LSASS(Local Security Authority Subsystem Service) 메모리 덤프는 Windows 환경에서 오래전부터 쓰인 자격증명 탈취 방식이다. 공격자는 SYSTEM 또는 관리자 권한을 확보한 뒤 mimikatz, procdump.exe, comsvcs.dll, Windows 작업 관리자 등을 이용해 lsass.exe 메모리를 덤프한다. 그 결과에서 NTLM 해시, Kerberos 티켓, 도메인 자격증명을 추출한다.

Edge의 경우 흐름은 유사하지만 대상이 lsass.exe가 아니라 msedge.exe다. 그리고 추출 대상은 NTLM 해시가 아닌 평문 비밀번호 문자열이다.

공격 흐름:
1. 권한 상승 (관리자/SYSTEM 획득)
2. msedge.exe 프로세스 식별
3. 메모리 덤프 생성 (Task Manager / procdump / comsvcs.dll MiniDump)
4. 덤프 파일에서 평문 문자열 추출
5. 전체 비밀번호 목록 획득

물리 메모리 접근도 같은 위험을 만든다

네트워크를 통하지 않더라도 DMA(Direct Memory Access) 공격으로 자격증명을 가져갈 수 있다. Thunderbolt, PCIe, FireWire 등 DMA를 지원하는 물리 포트에 연결된 장치는 OS 제어를 우회해 시스템 메모리를 직접 읽을 수 있다. Edge가 실행 중인 잠긴 노트북이라면 외부 DMA 장치가 메모리를 읽는 것만으로 저장된 비밀번호 전체를 얻을 수 있다.

인포스틸러가 생략할 수 있는 단계

Redline, Raccoon, Vidar 같은 인포스틸러 악성코드는 브라우저 자격증명 탈취를 핵심 기능으로 포함한다. 기존 방식은 브라우저 SQLite 데이터베이스에서 DPAPI로 암호화된 자격증명을 수집한 뒤 CryptUnprotectData API로 복호화하는 과정이었다.

Edge에서는 이 복호화 단계가 필요하지 않다. 악성코드가 msedge.exe 프로세스 메모리를 스캔하면 평문 비밀번호를 직접 수집할 수 있다.

자격증명이 메모리에 머무르는 방식

보안 브라우저가 지향해야 할 자격증명 수명주기와 Edge의 동작은 다음처럼 대비된다.

⤢✕

DPAPI가 보호하는 범위

Windows DPAPI(Data Protection API)는 CryptProtectData와 CryptUnprotectData로 구성된 사용자 계정 기반 암호화 API다. 브라우저는 비밀번호를 디스크에 기록할 때 DPAPI로 암호화하므로 다른 사용자 계정에서는 직접 복호화하기 어렵다.

그러나 같은 사용자 계정 안에서는 DPAPI가 제약 없이 동작한다. 해당 사용자로 실행되는 프로세스는 CryptUnprotectData를 호출해 브라우저 자격증명을 복호화할 수 있다. DPAPI는 디스크 저장소 보호에 적합하지만, 메모리에 이미 올라온 평문을 보호하는 장치는 아니다.

브라우저 자격증명은 다음 원칙에 따라 다뤄져야 한다.

접근 시점 최소 노출(Need-to-Know Memory): 실제 사용 직전에만 자격증명을 복호화한다.
즉시 소거(Secure Erase): 사용 뒤에는 메모리를 0으로 덮어쓰는 방식으로 명시적으로 지운다.
잠금 상태 보호(Lock State Enforcement): UI를 잠글 때 평문 자격증명을 메모리에서 제거한다.
안전한 메모리 할당(Secure Allocation): SecureZeroMemory 또는 유사 API로 민감 데이터의 수명을 관리한다.

Chrome의 App-Bound Encryption과 Edge의 격차

Chrome 127부터 적용된 App-Bound Encryption은 DPAPI가 사용자 계정 범위에 묶인 한계를 보완한다. 암호화 키가 Chrome 애플리케이션의 신원에 바인딩되고 SYSTEM 계정 DPAPI로 이중 보호되므로, 다른 사용자 프로세스나 악성코드가 CryptUnprotectData를 호출해도 키를 얻을 수 없다.

따라서 인포스틸러가 사용자 권한만으로 브라우저 비밀번호를 탈취하는 기존 경로를 사실상 차단한다. Edge 역시 Chromium 코드베이스를 공유하지만, 같은 보호를 채택하지 않은 점이 현재 격차의 원인이다.

Credential Guard가 다루지 않는 브라우저 비밀번호

Windows Defender Credential Guard는 VBS(가상화 기반 보안)로 NTLM 해시와 Kerberos TGT 등 도메인 자격증명을 격리된 LSA 프로세스(LSAIso.exe)에 보관한다. Windows 11 22H2 이상의 도메인 조인 시스템에서는 기본 활성화된다.

다만 Credential Guard는 웹 브라우저 비밀번호를 보호하지 않는다. Microsoft 공식 문서는 웹사이트 로그인 같은 일반 자격증명은 응용 프로그램이 평문 비밀번호를 필요로 하므로 보호 대상이 아니라고 명시한다. Credential Guard는 OS 수준의 도메인 인증 자격증명에 특화돼 있으며, 브라우저 비밀번호 관리자의 메모리 보안은 브라우저 벤더가 책임져야 할 영역이다.

Edge 비밀번호 관리자에 대한 조직의 통제

Edge 내장 비밀번호 관리자를 쓰는 환경이라면 저장된 비밀번호를 내보낸 뒤 삭제하고, 1Password, Bitwarden, KeePass 같은 전용 비밀번호 관리자로 이전하는 방안을 검토할 수 있다. Windows Defender Exploit Guard의 Code Integrity Guard, Arbitrary Code Guard를 Edge에 적용해 외부 프로세스의 메모리 접근을 제한하는 정책도 대상이 된다.

EDR 탐지 규칙에는 MiniDump 호출과 비정상적인 프로세스 메모리 접근 패턴을 포함할 수 있다. 특히 터미널 서버에서는 Edge 사용 정책을 즉시 검토하고, 자격증명 저장 기능을 그룹 정책으로 비활성화할 필요가 있다.

레지스트리 경로: HKLM\SOFTWARE\Policies\Microsoft\Edge
정책 키: PasswordManagerEnabled (DWORD) = 0
         PasswordManagerBlocklist (REG_SZ) = *

이 그룹 정책은 Edge 비밀번호 관리자를 전사적으로 끌 수 있다. LSASS 보호와 비슷하게 msedge.exe에 대한 OpenProcess 접근을 제한하는 커널 수준 보호(PPL-like 매커니즘)도 완화책이 될 수 있지만, Microsoft가 이를 구현했다는 공식 발표는 없다.

편의 기능과 메모리 보안의 경계

비밀번호를 시작 시점에 모두 메모리로 적재하는 방식이 "성능 최적화"를 위한 의도적 결정이라 해도, CWE-316(메모리 내 민감 정보 평문 저장) 기준에서는 보안 결함에 해당한다. App-Bound Encryption으로 브라우저 자격증명 보호를 강화한 Chrome과 비교하면 Microsoft의 "의도적 설계"라는 설명은 설득력이 약하다.

개인과 기업 모두 Edge 내장 비밀번호 관리자에 대한 의존도를 낮추고, 메모리 보안 원칙을 따르는 전용 비밀번호 관리자로 전환하는 것이 현재 가능한 실질적 대응책이다.