비 설치형 서비스를 대상으로 한 클라우드 포렌식 기술 연구: 네이버톡, 디스코드, 폴라리스 오피스를 중심으로

A Study on Cloud Forensics Technology for Non-Installation-Based Services: Focusing on Naver Talk, Discord, and Polaris Office

Abstract

정보통신 기술의 발전으로 비 설치형 클라우드 서비스가 확산되었으나, 데이터가 서버에 저장되는 구조로 인해 서버 측 데이터를 분석 대상으로 삼는 클라우드 포렌식의 필요성이 부각되고 있다. 그러나 지금까지의 연구는 주로 설치형 애플리케이션에 집중되어, 웹 브라우저 기반 서비스에 대한 포렌식 분석은 미비하다. 이에 본 논문은 로컬 저장소 의존도가 낮은 클라우드 기반 메신저와 오피스 응용 프로그램을 대상으로 데이터 수집 및 분석 방법을 제시한다. 네이버톡, 디스코드, 폴라리스 오피스를 사례로 하여 크리덴셜 확보와 서버 API 호출을 통한 데이터 획득 절차를 정리하고, 각 서비스의 데이터 구조를 분석하였다. 또한 메시지 삭제·숨기기·파일 삭제 등 안티 포렌식 기능별 데이터 변화를 규명하고, 서비스별 데이터 획득 도구를 제작하여 실제 환경에서 수집 절차를 검증함으로써 제안한 방법의 실효성을 입증하였다.

Advances in information and communication technology have led to the proliferation of non-installation cloud services. However, because data are stored on servers, the need for cloud forensics that analyzes server-side data is increasing. Prior research has focused mainly on installed applications, leaving forensic analysis of web-based services lacking. This paper proposes a data collection and analysis method targeting cloud-based messenger and office applications with low reliance on local storage. Using Naver Talk, Discord, and Polaris Office as case studies, we outline data acquisition via credential collection and server API calls and analyze each service's data structure. Furthermore, we identify data changes associated with anti-forensic functions, such as message deletion·hiding·file deletion. We also develop data acquisition tools for each service and validate the collection process in real-world environments, demonstrating its effectiveness.

I. 서론

1.1 배경

정보통신 기술은 사용자의 편의성과 경험 개선에 초점을 맞추며 지속적으로 발전해 왔다. 이러한 발전은 다양한 환경에서도 끊김 없이 동일한 서비스를 이용하려는 사용자들의 요구에서 비롯되었다. 그 결과, 프로그램을 설치하지 않고도 웹 브라우저만으로 사용할 수 있는 서비스들이 등장하게 되었고, 사용자 접근성 또한 크게 향상되었다. 오늘날 비 설치형 서비스는 메신저, 오피스 소프트웨어 등 다양한 분야에서 활용되고 있다. 이러한 서비스는 단순한 접근 방식의 차이에 그치지 않고, 데이터의 저장 및 처리 구조에서도 기존 설치형 소프트웨어와 차이를 보인다. 사용자가 데이터를 직접 소유하고 저장하던 방식과 달리, 웹 기반 서비스는 데이터를 서버 측에서 처리하고 저장하는 방식으로 운영되기 때문이다. 이러한 구조적 변화로 인해, 사용자 단말기에 의존하던 기존 디지털 포렌식 방식은 한계가 존재해, 서버 측 데이터를 분석 대상으로 삼는 클라우드 포렌식의 필요성이 점차 부각되고 있다. 이에 따라 다양한 클라우드 포렌식 연구가 진행되었으나, 지금까지의 관련 연구들은 설치형 애플리케이션 또는 설치형 클라우드 연동 프로그램을 중심으로 이루어져 왔으며, 사용자 기기에 남아 있는 파일이나 크리덴셜, API (Application Programming Interface) 통신 기록 등을 분석 대상으로 삼았다. 반면, 웹 브라우저만으로 구동되는 비 설치형 클라우드 서비스에 대한 포렌식 분석은 연구 사례가 부족한 실정이다. 이와 같은 서비스는 로컬에 남는 흔적이 거의 없기 때문에, 기존 방식으로는 유의미한 증거 확보가 어렵다. 따라서 본 논문에서는 비 설치형 메신저 네이버톡, 디스코드와 비 설치형 오피스 소프트웨어 폴라리스 오피스에 대한 데이터를 수집 및 분류하고 안티 포렌식 행위를 분석한 뒤 서비스별로 클라우드 포렌식 절차를 제공해 이후 범죄 수사에 활용할 수 있는 접근 방법을 제시한다. 본 논문의 구성은 다음과 같다. 2장에서는 기존 연구에서 주로 다루어진 설치형 애플리케이션 기반 분석 사례를 정리한 뒤, 비설치형 클라우드 서비스에 대한 연구가 비교적 부족하였음을 바탕으로 본 연구의 필요성을 제시한다. 3장에서는 네이버톡, 디스코드, 폴라리스 오피스를 대상으로 크리덴셜 확보를 통한 서버 접근 방식과 데이터 수집 절차를 제시하고, 서비스별 데이터 구조와 안티 포렌식 기능을 정리한다. 4장에서는 각 서비스별로 제안한 방법론을 적용한 결과를 제시하고, 도구 제작을 통해 실제로 해당 방법으로 재구성 할 수 있는지 검증한다. 마지막으로 5장에서는 결론으로 마무리하였다.

1.2 분석 환경

본 논문은 윈도우 환경에서 웹 브라우저를 이용해 동작하는 인스턴트 메신저인 네이버톡 및 디스코드와 오피스 소프트웨어인 폴라리스 오피스를 대상으로 클라우드 데이터 획득 방법을 분석하였다. 이 과정에서 사용된 분석 도구 및 환경, 분석 대상 협업 도구와 분석에 사용한 소프트웨어는 Table 1.과 같다.

Table 1. Analysis environment and tools

네이버톡, 디스코드, 그리고 폴라리스 오피스는 모두 웹 버전을 대상으로 분석을 수행하였으며, 웹 브라우저로는 크롬을 사용하였다[1]. 각 서비스의 API를 분석하기 위하여 프록시 도구인 Fiddler를 사용했으며[2], 메모리 덤프에는 winPmem[3]을 활용하였고, 덤프 된 메모리로부터 각 서비스의 크리덴셜을 확인하기 위해 HxD를 사용하였다[4].

II. 관련 연구

디스코드와 관련된 다양한 디지털 포렌식 분석 연구가 진행되었다. Megan Davis 외 2인은 Linux 환경에서 디스코드와 슬랙의 메모리 포렌식을 수행하여 RAM으로부터 사용자명, 이메일, 비밀번호, 메시지, 첨부파일 등을 복원할 수 있음을 확인하고, 메모리 포렌식이 중요한 증거 수단이 될 수 있음을 보여 주었다[5]. Khushi Gupta 외 2인은 Google Chrome 브라우저 환경에서 실행된 디스코드를 대상으로 분석을 수행하여 결제 정보, 메시지, 계정 설정, 첨부파일 등을 복구할 수 있음을 제시하였다[6]. 신수민 외 3인은 슬랙과 디스코드를 분석하여 모바일 애플리케이션과 PC 프로그램에서 주요 아티팩트를 정리하고, 이를 바탕으로 포렌식적으로 활용 가능한 시나리오를 제시하였다[7]. 또한 Khushi Gupta 외 2인은 Windows와 Linux 환경에서 디스코드의 아티팩트를 식별하였으며, 로컬 저장소에서는 메시지, 채널, 서버 등의 데이터를, RAM에서는 계정 정보, 비밀번호, 사용자 친구 정보, 위치 정보, 채팅 및 서버 정보를 확인하였고, 네트워크 패킷 캡처를 통해 디스코드 API와의 통신을 추적하였다[8]. Farkhund Iqbal 외 2인은 Windows, macOS, Linux 환경에서 디스코드 애플리케이션의 로컬 아티팩트를 조사하여 캐시로부터 채팅 로그를 복구하고, Local Storage로부터 계정 정보 및 서버 관련 데이터를 확보하였으며, 이를 기반으로 캐시와 Local Storage에서 정보를 추출할 수 있는 ‘DiscFor’라는 도구를 개발하였다[9]. Kyle Moffitt 외 3인은 Windows 10 환경에서 디스코드 데스크톱 애플리케이션을 분석하여 타이핑된 메시지 초안의 평문 사본과 캐시된 사진을 복구할 수 있음을 확인하였다[10]. 협업 도구와 관련된 연구도 진행되었는데, 김영훈 외 1인은 Microsoft Teams에 대해 Windows 및 Android 환경에서 주요 사용자 행위를 정의하고 아티팩트 존재 여부를 검증한 뒤 차분 포렌식을 통해 협업 툴 분석기법 및 수사 시나리오를 제시하였다[11]. 김한결 외 2인은 Windows 환경에서 네이버 웍스를 대상으로 로컬 아티팩트를 식별하고 기능별 데이터를 수집·분류하였으며, 암호화된 데이터베이스를 복호화하고 안티 포렌식 기능에 따른 아티팩트 변화를 분석하였다[12]. Herschel Bowling 외 3인은 Windows 10, Android, iOS 환경에서 Teams의 아티팩트를 수집·분석하여 수작업 조사를 통해 77.6%를 복구할 수 있었으나, Cellebrite UFED와 Magnet AXIOM Examine 도구를 통한 자동 수집에서는 13.8%만 복구되어 자동화의 한계를 지적하였다[13]. 마지막으로 폴라리스 오피스에 대한 연구에서는 이연주 외 2인이 Windows와 macOS 환경에서 폴라리스 오피스 PC 버전 사용 시 남는 아티팩트를 조사하여 데이터베이스와 plist 파일이 중요한 역할을 하며, 이를 통해 사용자의 작업 과정과 과거 이력을 추적할 수 있음을 제시하였다[14]. 기존 연구들은 주로 설치형 애플리케이션 또는 로컬 기반 협업 도구를 중심으로 진행되어, 디스크 저장소·레지스트리·캐시·메모리 등 로컬 아티팩트의 수집과 복구에 초점이 맞추어졌다. 이에 따라 브라우저 기반으로 동작하는 비설치형 클라우드 서비스에 대한 분석은 상대적으로 부족하였다. 이에 본 연구는 기존의 로컬 중심 포렌식에서 확장하여 클라우드 포렌식, 즉 비설치형 클라우드 서비스의 네트워크 통신을 재구성하여 확보한 데이터를 분석 및 분류하고, 각 서비스별 안티 포렌식 행위가 데이터 보존에 미치는 영향을 정리하였다. 마지막으로 웹 기반 클라우드 포렌식의 분석 절차를 제시함으로써, 비설치형 클라우드 서비스를 수사 과정에서 활용할 수 있는 가능성을 제시하였다.

III. 클라우드 데이터 수집 및 분석

본 장에서는 클라우드 기반 메신저와 오피스 응용 프로그램을 대상으로 데이터 수집 및 분석 방법을 제시한다. 로컬 저장이 없는 환경에서 크리덴셜 확보를 통한 서버 접근 방식을 설명하고, 서비스별 데이터 구조와 수집 절차를 비교한다. 또한 각 서비스에서 제공되는 안티 포렌식 기능이 데이터에 미치는 영향을 분석한다.

3.1 크리덴셜 획득

본 절에서는 로컬에 데이터를 저장하지 않는 비설치형 서비스들의 특성을 고려하여, 클라우드 서버에서 데이터를 수집하는 방법을 제시한다. 데이터 수집 방식은 웹 브라우저에서 크리덴셜 정보를 추출하는 방법과 메모리 덤프를 활용하는 방법으로 구분된다.

3.1.1 네이버톡

네이버톡이 웹을 통해 실행 중인 경우, 웹 브라우저의 개발자 도구를 연 후, Application 패널에서 Storage 섹션의 Cookies에 접근한 뒤, Cookies 하위에 위치한 ‘https://ntalk.naver. com’ 도메인의 항목 중 key 값이 ‘NID_AUT’, ‘NID_SES’로 표시된 항목의 Value 값에 Fig. 1과 같이 크리덴셜 데이터가 존재한다.

Fig. 1. Obtaining NaverTalk authentication tokens through developer tool

웹 브라우저에서 확인된 ‘NID_AUT’, ‘NID_SES’ 값은 해당 서비스가 실행 중인 환경의 메모리 덤프에서도 Fig. 2와 같이 동일하게 잔존한다.

Fig. 2. Obtaining NaverTalk authentication tokens through memory dump

3.1.2 디스코드

디스코드가 웹을 통해 실행 중인 경우, 웹 브라우저의 개발자 도구를 연 후, Application 패널에서 Storage 섹션의 Local storage에 접근한 뒤, Local storage 하위에 위치한 ‘https://discord.com’ 도메인의 항목 중 key 값이 ‘token’으로 표시된 항목의 Value 값에 Fig. 3와 같이 크리덴셜 데이터가 존재한다.

Fig. 3. Obtaining Discord tokens through developer tool

웹 브라우저에서 확인된 ‘token’ 값은 해당 서비스가 실행 중인 환경의 메모리 덤프에서도 ‘authorization’이라는 값으로 Fig. 4와 같이 동일하게 잔존한다.

Fig. 4. Obtaining Discord tokens through memory dump

3.1.3 폴라리스 오피스

폴라리스 오피스가 웹을 통해 실행 중인 경우, 웹 브라우저의 개발자 도구를 연 후, Application 패널에서 Storage 섹션의 Cookies에 접근한 뒤, Cookies 하위에 위치한 ‘https://www.polarisoffice.com’ 도메인의 항목 중 key 값이 ‘SID’ 로 표시된 항목의 Value 값에 Fig. 5와 같이 크리덴셜 데이터가 존재한다.

Fig. 5. Obtaining Polaris Office SID through developer tool

웹 브라우저에서 확인된 ‘SID’ 값은 해당 서비스가 실행 중인 환경의 메모리 덤프에서도 Fig. 6와 같이 동일하게 잔존한다.

Fig. 6. Obtaining Polaris Office SID through memory dump

3.2 클라우드 데이터 수집

본 절에서는 클라우드 환경에서 메신저 및 오피스 응용 프로그램의 데이터를 수집하고 분석하는 방법을 제시한다. 네이버톡은 웹소켓 기반의 neotalk을 중심으로 채팅 데이터를 수집하는 절차를 다루며, 디스코드는 token 확보 후 API 재구성을 통한 서버 및 다이렉트 메시지 데이터를 설명한다. 또한 폴라리스 오피스는 SID를 이용한 API 요청으로 사용자 및 파일 정보를 획득하는 과정을 기술한다. 이를 통해 각 서비스의 데이터 구조와 수집 절차를 비교·분석한다.

3.2.1 네이버톡

네이버톡은 크게 공개톡, neotalk, 그리고 talktalk으로 구성되어 있다. 공개톡은 동일한 관심사를 가진 다수가 참여할 수 있는 채팅 서비스로, 로그인 없이 이용할 수 있으며 일반 메신저의 오픈채팅 기능과 유사하다. 반면 neotalk과 talktalk은 로그인이 필요한 메신저 서비스이다. 두 서비스는 모두 메신저 기능을 제공하지만 활용 목적과 통신방식에서 차이가 있다. 서비스의 활용 목적을 기준으로 보면, neotalk은 오픈채팅·그룹톡·1:1 DM 등 일반 메신저와 유사한 기능을 제공하는 네이버톡의 일반 대화방이며, talktalk은 상점·판매자와의 상담 및 주문·배송 관련 대화에 특화된 서비스이다. 한편 통신 방식의 측면에서는, talktalk이 HTTP 기반 폴링(Polling)을 사용하여 서버에 일정 주기로 계속 요청을 보내 통신하는 반면, neotalk은 웹소켓(WebSocket)을 사용하여 변경 사항을 실시간으로 처리한다. 본 논문에서는 일반 메신저와 유사한 기능을 제공하는 neotalk에 초점을 맞추어, 그 채팅 데이터를 획득하기 위한 방법을 기술한다. neotalk의 채팅 데이터를 수집하려면 먼저 NID_AUT와 NID_SES라는 두 개의 쿠키 값, 웹소켓 통신에 사용되는 사용자 식별자인 UID(memberKey), 채팅방의 고유 식별자인 CID(channelId), 그리고 인증 토큰인 accTkn (accessToken)을 확보해야 한다. UID와 accTkn은 “https://apis.naver.com/noc-web/noc-view-api/v1/env”에 HTTP GET 요청 시 Header에 NID_SES와 NID_AUT 값을 포함해 보내면, 응답 JSON의 memberKey 및 accessToken 항목에서 확인할 수 있다. CID 또한 “https://talks.naver.com/api/mytalk/my”에 HTTP GET 요청 시 Header에 NID_SES와 NID_AUT 값을 포함해 보내면, 응답 JSON의 channelId에서 확인할 수 있다. 이후 채팅 데이터를 획득하기 위한 웹 소켓 통신이 수행한다. 각 단계는 Table 2.와 같이 진행된다.

Table 2. Websocket communication for obtaining chat data from Naver Talk

웹소켓 서버 주소는 기본적으로 “wss://kr-ss1.chat.naver.com/chat”이며, 이 외에도 kr-ss2,kr-ss3, kr-ss4또한 사용할 수 있다. 웹소켓 통신 과정은 크게 초기 연결 절차와 그 이후의 데이터 요청·응답 과정으로 나눌 수 있다. 초기 연결 절차에서는 서버와 클라이언트 간에 필요한 식별자와 인증 정보가 교환되며, 이어지는 요청에서는 대화 내용이나 감정 데이터 등 구체적인 채팅 데이터를 획득하게 된다. 이때 중요한 점은 첫 번째 요청에 대한 응답에 두 번째 요청에 활용되는 sid 값이 포함된다는 것이다. 이러한 절차가 정상적으로 진행되면 최종적으로 CID값에 해당하는 채팅방의 대화 내용을 JSON 형식으로 응답받을 수 있다. 또한, 가져올 메시지의 개수를 지정하기 위해 recentMessageCount라는 값을 함께 전송할 수 있다. recentMessageCount에 임의의 양의 정숫값을 전송 시 가장 최근 메시지부터 역순으로 N+1개가 반환된다. 따라서 값이 0을 입력하면 가장 최신 메시지 1개만 반환되고, 값이 3일 때는 최신 메시지부터 역순으로 4개의 메시지가 반환된다. 응답으로 온 JSON 데이터는 Table 3.와 같다.

Table 3. Contents of the messageList sub-kit value

ChannelId 키값은 채팅방의 고유 ID를 나타내며, 이는 API 요청 시 사용되는 CID 값과 동일한 값을 가진다. UserId 키값은 사용자의 고유한 ID를 의미하며, API 요청 시 사용되는 uid 값과 동일한 값을 가진다. 또한 UserId는 선택한 채팅방의 유형이나 프로필 설정에 영향받지 않는다. 기본 프로필이나 익명 프로필을 선택해도 UserId는 항상 동일하기 때문에, 일관된 사용자 추적이 가능하다. profile 키값은 1대1 채팅방에서 name과 profile이라는 내부 키값을 가지며, 각 키에 프로필 명과 사진 URL이 저장되지만. 그룹 채팅에서는 profile 키값이 null 값으로 존재한다. MessageNo 키값은 채팅방 내 메시지의 순서를 나타내며, 방이 개설되었음을 알리는 시스템 메시지가 1로 설정되고 이후 순차적으로 증가한다. 그리고 Content 키값에는 메시지의 내용이 저장된다. MemberCount 키값은 채팅방의 멤버 수를 나타내며, 멤버가 추가될 때마다 증가하게 된다. MessageTypeCode 키값은 메시지의 유형을 나타내며, 101은 채팅방 개설이나 새로운 멤버의 입장을 의미하고, 110은 권한 부여를 나타내며, 1은 일반 메시지, 11은 사진 첨부 메시지, 19는 투표 기능 메시지를 의미한다. MessageStatusType 키값은 메시지의 상태를 나타내는데, “NORMAL”은 시스템 알림, 일반 메시지, 투표 내용 등을 포함한 모든 종류의 메시지에 기본적으로 부여되는 상태이다. 반면, “RECLAIM”은 사용자가 5분 이내에 본인의 메시지를 삭제한 경우에 부여되고, “HIDDEN”은 방장이나 부방장이 5분 이후에 본인을 포함한 다른 사람의 메시지를 삭제한 경우에 나타난다. Extras 키 값은 순수 문자열로만 이루어진 메시지 전송에서는 값이 존재하지 않지만, 사진 첨부 메시지, 시스템 알림, 투표 등의 다양한 메시지에서는 해당 특징에 따른 정보를 포함한다. Extras 키값은 기본적으로 순수 문자열로만 이루어진 일반 메시지에서는 존재하지 않는다. 그러나 예외적으로 순수 문자열 메시지라 하더라도 다른 메시지에 대한 답장일 경우에는 extras에 replyOriginMessage가 포함되어, 답장 대상 메시지의 번호, 내용, 발신자 정보 등이 기록된다. 이 외에도 사진이나 파일 첨부, 시스템 알림, 투표와 같이 부가적인 기능이 수반되는 메시지의 경우, extras는 해당 기능을 설명하는 구조화된 데이터를 포함한다. Emotion 키값은 메시지에 공감이 표시된 경우에만 존재한다. 메시지에 공감이 표시된 경우 emotionTypeCodeList는 공감의 종류를 나타내며, count는 공감의 개수를 의미한다. 이 기능은 카카오톡에서 하트나 엄지손가락으로 공감을 표시하는 방식과 유사하다. CreateTime 키값은 메시지가 전송된 시간을 나타내고, UpdateTime 키값은 메시지가 수정된 시간을 나타낸다. 초기에는 createTime과 동일한 값을 가지지만, 삭제가 발생하면 삭제된 시간으로 변경된다. 마지막으로, ReadCount 키값은 메시지를 읽은 사람의 수를 나타내며, 기본값은 1로 설정된다. 이후 누군가 메시지를 읽으면 1씩 증가하며, ‘이 사람 메시지 숨기기’ 기능을 이용해도 읽음 수는 증가하게 된다.

3.2.2 디스코드

디스코드는 크게 서버와 다이렉트 메시지로 구분된다. 서버는 다수의 사용자가 공통의 주제나 목적을 중심으로 모이는 공간으로, 그 안에는 채팅 채널과 음성 채널이 존재한다. 채팅 채널은 일반적인 메신저의 오픈채팅 기능과 유사하며, 음성 채널은 실시간 음성 통화 및 영상 통화 기능을 제공한다. 다음으로 다이렉트 메시지는 일반 메신저의 1:1 채팅과 유사한 기능을 가지며, 텍스트 기반 메시지 전송뿐만 아니라 음성 및 영상 통화도 지원한다. 정리하면, 디스코드는 구조적으로 서버와 다이렉트 메시지로 구분되고, 기능적으로는 텍스트 기반 채팅과 음성 기반 대화로 나눌 수 있다. 이중 텍스트 기반 채팅은 사용자의 활동과 행위를 직접적으로 반영하는 중요한 포렌식 증거가 되므로, 본 논문은 서버 내 채팅 채널과 다이렉트 메시지에서 생성되는 채팅 데이터를 대상으로 데이터 획득 방법을 기술한다.

디스코드의 채팅 데이터를 수집하려면 먼저 token값을 확보해야 한다. 이후 token값을 포함하여 관련 HTTP API를 호출하면 사용자 정보, 특정 유저 정보, 사용자의 친구 목록, 특정 유저 프로필 사진, 다이렉트 메시지 채널 목록, 사용자가 속한 서버 목록, 서버 내 채널 목록, 채널 내 메시지 조회 등을 응답으로 반환한다. 수집에 활용한 HTTP API 요청 URL은 Table 4.와 같다.

Table 4. Classifying request and response data for data acquisition from Discord

디스코드의 사용자 정보, 특정 유저 정보 그리고 사용자의 친구 목록에 해당하는 URL에 필요한 파라미터를 포함하여 HTTP API 요청을 전달한 결과, 응답으로 온 데이터는 Table 5.와 같다.

Table 5. Classification of response data related to Discord user information, specific user information, and the user’s friends list.

응답 데이터에는 공통적으로 id, username, avatar, global_name과 같은 키가 포함된다. 이 때 응답 유형별로 추가로 포함되는 키는 다음과 같다. 사용자 정보에는 bio와 email이, 특정 유저 정보에는 bio가, 친구 목록 정보에는 nickname이 각각 추가로 포함된다. 다만, 응답 구조에 따라 이러한 키의 위치가 달라진다. 개인 사용자 정보 조회 결과에서는 공통적으로 존재하는 키값들이 최상위에 위치하는 반면, 특정 사용자 정보와 친구 목록 응답에서는 동일한 값들이 모두 user라는 하위 키 아래에 포함된다. 이러한 구조적 차이가 존재하더라도 실제로 지칭하는 정보의 의미는 동일하다. 각 키의 역할을 살펴보면, 먼저 id는 해당 유저의 고유 식별 값을 의미하며, username값은 고유 유저명으로 주로 친구 요청을 위한 고유 식별자로 사용된다. avatar는 프로필 사진에 대한 고유 식별 값이고, global_name은 디스코드 내에서 다른 사용자가 인식하는 이름이다. 즉, username은 유저를 구별할 수 있는 고유한 값으로 중복될 수 없지만, global_name은 DM이나 서버에서 메시지를 보낼 때 확인할 수 있는 이름이다. 따라서 global_name은 다른 사용자가 별명을 부여하지 않았다는 전제하에 DM, 서버, 친구 요청에서 보이는 이름이 된다. 또한 bio는 유저가 작성하는 자기소개말로, 카카오톡의 상태 메시지와 유사한 역할을 한다. 마지막으로 nickname은 사용자가 특정 유저에게 직접 부여한 별명으로, 해당 값이 존재하는 경우 DM이나 서버에서 표시되는 이름은 global_name이 아니라 nickname이 우선적으로 반영된다. 추가적으로, id와 avatar는 데이터 식별 용도뿐만 아니라 프로필 사진 요청 URL을 보낼 시에 활용된다. 프로필 사진 요청 URL인 ‘/users/@me/relationships/[user_id]/[avatar].webp?size=160’에서 user_id 자리에 id 값을, avatar 자리에 avatar 값을 대입하여 요청을 전송하면 해당 사용자의 프로필 이미지를 webp 형식으로 획득할 수 있다.

디스코드의 다이렉트 메시지 채널 목록, 사용자가 속한 서버 목록 그리고 서버 내 채널 목록에 해당하는 URL에 필요한 파라미터를 포함하여 HTTP API 요청을 전달한 결과, 응답으로 온 데이터는 Table 6.와 같다.

Table 6. Classifying response data related to group and private chat rooms in Discord

먼저 다이렉트 메시지 채널 목록 응답에는 사용자 정보, 특정 유저 정보, 친구 목록 응답에서 확인된 id, username, avatar, global_name과 동일한 키가 포함된다. 다만 이 값들은 recipients라는 상위 키의 하위에 존재한다는 구조적 차이가 있다. 이미 앞선 응답에서 설명한 것과 동일하게, 여기서도 id는 유저 고유 ID, username은 고유 유저명, avatar는 프로필 사진을 식별하는 값, global_name은 디스코드에서 표시되는 이름을 의미한다. 다음으로 서버 목록 응답에는 id와 name이 포함되며, 각각 서버의 고유 식별 값과 서버의 이름을 나타낸다. 마지막으로 서버 내 채널 목록 응답에는 id, type, guild_id, name, parent_id가 포함된다. 이 중 id는 채널의 고유 식별 값이고, type은 채널의 유형을 구분하는 값으로 4, 2, 0, 1의 네 가지가 존재한다. type=4는 서버 내 채널 중 채널 분류용 인덱스 채널로 채팅방 역할이 아닌 채널들을 분류하는 역할을 하는 채널이며, type=2는 서버 내 채널 중 음성 채널, type=0은 서버 내 채널 중 메시지를 주고 받는 채팅 채널, type=1은 다이렉트 메시지 채널을 의미한다. parent_id는 채널 간의 상하위 관계를 드러내는 값으로, 상위 채널의 고유 식별 값을 의미하며 앞서 언급된 type과 연결되는 값이다. type=2 또는 0인 채널은 각각 음성 또는 채팅방의 역할을 하고 있기 때문에 이 채널들은 type 4를 가진 채널의 하위에 속한다. 따라서 type=2 또는 0인 채널은 parent_id에 본인이 속해있는 상위 채널의 식별 값을 가지고 있으며 type 4를 가진 채널은 parent_id가 null을 가진다. 다음으로 name은 해당 채널의 이름을 의미하며, guild_id는 해당 채널이 속해있는 서버의 식별 값을 의미한다.

서버 내 채널 메시지와 DM 채널 메시지에 해당하는 URL에 필요한 파라미터를 포함하여 HTTP API 요청을 전달한 결과는 Table 7.과 같으며, 두 응답은 기본적으로 동일한 JSON 구조를 가진다.

Table 7. Classification of response data related to server-side channel message queries and DM channel message queries

응답에는 공통적으로 ‘type’, ‘components 하위의 id’, ‘content’, ‘timestamp’, ‘edited_timestamp’ ‘author 하위의 id, username, global_name’, ‘referenced_message 하위 id’,‘sticker_items 하위 id, name’, ‘message_reference 하위 message_id’, ‘mentions 하위의 id, username, global_name’, 그리고 첨부파일 관련 키인 ‘attachment 하위 content_type, id, title, filename, url, size, width, height’가 포함된다. 공통적으로 등장한 키 중 type은 메시지의 유형을 나타내는 값으로, 0은 일반 메시지, 3은 통화 관련 메시지, 7은 사용자가 채팅방에 입장한 경우의 메시지, 19는 다른 메시지에 대한 답장을 의미한다. 이때 type=19의 답장은 단순 @를 붙여 상대방을 멘션하는 것이 아닌 답장할 메시지에 우클릭해 답장 기능을 사용했을 때만 19로 표시되며, 단순 @로 멘션은 일반 메시지로 분류된다. 추가적으로 '손을 흔들어 인사해 보세요!' 기능도 답장 기능에 포함되어 type=19로 표현된다. components 하위의 id는 메시지의 고유 식별 값을 의미하며, content는 메시지 본문을 의미한다. 이때 일반적인 텍스트 메시지 뿐 아니라 디스코드 내 기능인 GIF 이미지도 이 content에 포함된다. 또한 @로 상대방을 멘션 했을 경우 UI에는 ‘@멘션된 상대방의 표시되는 유저명’, 즉 global_name이 표시되지만, JSON 상에는 ‘@멘션된 상대방의 고유 식별자’, 즉 id 값이 기록된다. timestamp는 메시지가 전송된 시점을 의미하며, edited_timestamp는 메시지가 수정된 시간을 의미하고, author 하위의 id, username,global_name은 각각 메시지를 보낸 사람의 고유식별 값, 고유 유저명, 디스코드 상에서 표시되는 이름을 의미한다. referenced_message 하위 id는 스티커 메시지의 고유 식별 값을 의미하며, sticker_items 하위 id와 name은 각각 디스코드 스티커 자체의 의 고유 식별자와 이름을 의미한다. 디스코드의 스티커는 카카오톡의 이모티콘과 유사한 기능을 한다. message_reference 하위 message_id는 답장 대상 메시지의 고유 식별 값 또는 스티커 답장의 고유 식별 값으로, 답장 메시지에만 존재한다. mentions 하위의 id, username, global_name은 각각 멘션된 혹은 답장 대상 유저의 정보인 고유 식별 값, 고유 유저명, 표시되는 유저명을 의미하며, type=19일 때에는 답장 대상의 정보를, 일반 메시지에서의 멘션일 경우에는 멘션된 대상의 정보를 나타낸다. attachments 하위의 첨부파일 관련 키들은 각각 다음과 같은 의미를 가진다. content_type은 첨부된 파일의 확장자를 나타내며, 이미지, 비디오, Microsoft Office 문서 확장자 등 일부 확장자만 식별이 가능하다. 그러나 한글전용 확장자인 .hwpx는 확인되지 않았으며, 일부 한글 파일 첨부 시에는 값이 존재하지 않는 경우도 있었다. 이어서 id, title, filename은 첨부파일의 고유 식별 값, 파일명, 한글이 제거된 파일명과 확장자를 의미한다. 이때 실제 파일명을 확인하기 위해서는 두 값을 조합해야 하는데, 이는 title이 한글이 포함된 원본 파일명을 보여주지만 확장자를 포함하지 않는 반면, filename은 확장자를 표시하되 파일명에서 한글이 제거되어 있기 때문이다. 본 연구에서는 이러한 특성을 고려하여 첨부파일의 실제 파일명을 복원하기 위해 title과 filename 값을 결합하는 방식을 사용하였다. 구체적으로 filename에서 마지막 점 이후의 문자열을 추출하여 확장자를 획득한 뒤, 이를 title 값 뒤에 연결하는 규칙을 적용하였다. 예를 들어 title이 “1대다수_hangul”이고 filename이 “1_hangul.hwpx”인 경우, 최종 복원 파일명은 “1대다수_hangul.hwpx”로 구성된다. 마지막으로 url, size, width, height는 첨부파일의 다운로드 링크, 첨부파일의 크기, 이미지나 동영상을 첨부했을 경우 해당 미디어의 가로 및 세로 크기를 의미한다. 또한 url의 다운로드 링크는 의미하며 일정 시간이 지나면 만료된다. 이와 같이 서버 내 채널 메시지와 DM 채널 메시지는 대부분 동일한 구조와 키를 공유하지만, 세부적으로는 채팅 환경의 차이로 인해 특정 값이나 키에서 차이를 보인다. 구체적으로 이러한 차이는 채팅 환경의 특성에 따라 값의 유형에서 나타나기도 하고, 특정 키의 존재 여부에서 확인되기도 한다. 먼저 값의 유형 측면에서는 type 키에서 차이가 드러난다. 앞서 언급했듯 type은 네 가지 유형을 가지지만, 서버 내 채널에서는 음성 채널이 별도로 존재하기 때문에 DM 채널 메시지에서만 type=3이 나타나고, 반대로 1:1 대화인 DM 채널에서는 type=7이 나타나지 않는다. 다음으로 키의 존재 여부 측면에서는 call 하위 ended_timestamp와 participants가 대표적이다. 이는 각각 통화 종료 시각과 참여자 ID를 의미하는데, DM 채널에는 통화 기능이 존재하기 때문에 포함되지만, 서버 내 채널에는 음성 채널이 존재하므로 해당 키는 나타나지 않는다. 결론적으로 두 환경은 동일한 구조를 공유하면서도, 환경적 차이에 의해 값의 유형과 키의 포함 여부에서 상이한 양상을 보인다.

3.2.3 폴라리스 오피스

본 연구에서는 메신저 서비스 외의 클라우드 기반 응용 프로그램을 분석 대상으로 확장하기 위해 오피스 소프트웨어인 폴라리스 오피스를 선정하였다. 폴라리스 오피스는 클라우드형, PC 평생 소장형, 모바일 클라우드형, iOS 모바일 평생형 등으로 구분되며, 이 중 My Polaris Drive를 사용할 수 있는 것은 클라우드형과 웹 기반 서비스 등 로그인 기반 제품군에 한정된다. My Polaris Drive는 Windows, Mac, Android, iOS, 웹 등 다양한 환경에서 동일 계정으로 접근할 수 있는 통합 저장소이자 폴라리스 오피스 생태계의 중심으로, 문서 동기화 및 공유를 지원한다. 또한 클라우드 저장소의 특성상 접근 기록과 삭제 흔적이 남기 때문에 포렌식 분석 측면에서 중요한 의미를 갖는다. 따라서 본 연구에서는 My Polaris Drive에 초점을 맞추어, 저장된 문서 관련 데이터를 획득하기 위한 방법을 기술한다.

My Polaris Drive 데이터를 수집하려면 먼저 SID 값을 확보한다. 이후 SID를 포함하여 관련 HTTP API를 호출하면 사용자 정보, 최근 사용 파일 목록, 폴더 내 전체 파일 목록, 휴지통 내 파일 목록, 파일 다운로드 결과 등을 응답으로 반환한다. 수집에 활용한 HTTP API 요청을 전달하면 URL은 Table 8.과 같다.

Table 8. Classification of request and response data for data acquisition from My Polaris Drive

사용자 정보 조회에 사용한 URL은 이메일, 사용자명, 사용자 고유 ID, 가입 일시 등을 응답으로 반환한다. 최근 사용한 파일 목록 URL과 폴더 내 전체 파일 목록 URL에는 파일명, 파일 고유 ID 등의 정보가 포함되어 있다. 이때 최근 사용 파일 목록은 가장 최근에 사용된 파일의 정보만 제한적으로 가져온다. 파일 다운로드 URL은 파일의 고유 ID를 URL 경로에 포함해 요청하며, 응답 본문으로 파일 데이터가 전송된다. 휴지통 URL은 폴라리스 오피스의 휴지통에 보내진 파일 항목 목록을 반환하며, 마지막으로 사용자 정보에 해당하는 URL에 필요한 파라미터를 포함하여 HTTP API 요청을 전달한 결과 응답으로 온 데이터는 Table 9.과 같다.

Table 9. Classification of response data related to user information in My Polaris Drive

먼저 adLocale 값은 해당 지역을 의미하며, 한국의 경우 ‘KR’로 표기된다. driveUsage 값은 현재 드라이브에 저장된 문서의 용량을 나타내며 바이트 단위이다. email은 사용자의 이메일이자 ID이며, fileCount는 드라이브에 저장된 항목 중 폴더를 제외한 파일의 개수를 나타낸다. fullName은 사용자의 이름을 의미하고, userID는 유저의 고유 ID, timeRegist는 가입 날짜를 유닉스 타임스탬프 형식으로 나타낸 값이다. 이후 birthYear부터 jobDetail까지는 userDetailDTO 객체의 하위 속성값들이다. 이 중, birthYear 값은 사용자의 출생 연도를 나타내며 나이를 확인할 수 있다. gender 값은 성별을 나타내며, ‘M’은 남성, ‘F’는 여성으로 구분된다. jobCode 값은 회원 정보 내 직업을 선택할 수 있는 드롭다운 목록에서 선택한 사용자의 직업 범주를 의미한다. jobDetail 값은 회원 정보 페이지의 직업 선택 드롭다운에서 ‘기타’를 선택한 경우, 추가 입력 필드에 사용자가 직접 입력한 값을 의미한다. 전체 파일 목록에 해당하는 URL에 필요한 파라미터를 포함하여 HTTP API 요청을 전달한 결과 응답으로 온 데이터는 Table 10.과 같다.

Table 10. Response data classification related to the full list of files in My Polaris Drive

먼저 parentId는 부모 폴더의 ID를 의미하며, 현재 파일이 어떤 폴더 하위에 위치해 있는지 알 수 있다. 단 삭제된 폴더는 모두 루트 폴더의 ID로 고정된다. 이후 fileId부터 userId까지는 directoryInfo 객체의 하위 속성값들이다. 이 중, fileId는 파일 혹은 폴더의 고유 ID를, fileName은 이름을 나타내며, 파일일 경우 ‘파일명.확장자’, 폴더일 경우 ‘폴더명’ 형식이다. 드라이브 최상위 폴더는 ‘drive'로 표기된다. fileType은 객체의 종류를 나타내며, 일반 파일은 ‘FILE’, 폴더 및 드라이브는 ‘DIR’로 구분된다. size는 파일의 용량을 나타내며 바이트 단위이고, 폴더일 시 0으로 표시된다. lastModified는 마지막으로 수정한 시간을 유닉스 타임스탬프 형식으로 나타낸다. fileRevision은 파일의 개정 횟수를 나타내는 값으로 1부터 시작하며, 파일의 내용이 편집되었을 때 카운트가 올라간다. lastModifiedRevision은 파일의 마지막 수정된 개정 버전을 나타내는 값이다. 예를 들어 폴라리스의 웹 툴 기능인 문서편집 기능으로 문서를 편집한 후 저장하였을 때 카운트가 올라간다. hide와 deletedTime은 파일을 삭제할 시값이 각각 true와 파일을 삭제한 시간을 유닉스 타임스탬프 형식으로 나타낸다. starred는 중요 문서 표시한 파일에만 true로 나타나며, shared는 공유한 문서에 true로 값을 나타낸다. lastAccessTime은 파일에 마지막으로 접근한 시점을 유닉스 타임스탬프 형식으로 기록한다. 파일을 열었더라도 로딩이 완료되지 않은 경우에는 값이 갱신되지 않지만, 로딩이 완료되어 파일의 내용을 확인할 수 있을 때는 해당 값이 갱신된다. path는 폴라리스 드라이브 내 경로를 의미하며, 최상위 폴더의 경로는 ‘PATH://drive/’이다. 예를 들어 ‘새 폴더’라는 하위 폴더에 파일이 존재할 경우 경로는 ‘PATH://drive/새 폴더/’가 된다. 마지막으로 userId는 해당 파일 또는 폴더를 생성한 사용자의 고유 ID를 의미한다.

3.3 안티 포렌식 행위에 따른 클라우드 데이터 변화 분석

본 절에서는 클라우드 환경에서 제공되는 안티 포렌식 기능과 그에 따른 데이터 변화를 분석한다. 네이버톡은 메시지 숨기기와 삭제하기 기능을 통해 UI와 서버 데이터의 차이를 보인다. 디스코드는 메시지 수정과 삭제 기능을 제공하여 로그에는 흔적이 남지만 원본 내용은 확인이 불가능하다. 폴라리스 오피스는 파일 삭제와 영구 삭제 기능을 제공하며, 휴지통 단계에서는 여전히 데이터 확보가 가능하다.

3.3.1 네이버톡

네이버톡에는 ‘이 사람 메시지 숨기기’와 ‘삭제하기’라는 두 가지의 안티 포렌식 기능이 존재한다. 먼저, 특정 메시지에 대해 ‘이 사람 메시지 숨기기’ 기능을 사용할 경우 해당 메시지뿐만 아니라, 그 사용자가 지금까지 전송한 모든 메시지가 채팅방 화면에서 사라진다. 이 효과는 24시간 동안만 유지되며 해당 채팅방에 한정되고, 취소할 수 없다. 그러나 이러한 숨김은 단순히 사용자 인터페이스(UI) 상에서만 적용되는 것이므로, HTTP GET 요청을 통해 대화 내용을 획득할 경우 해당 메시지의 content 키값은 여전히 존재한다. 반면, ‘삭제하기’ 기능을 사용할 경우 선택한 메시지의 내용은 “삭제된 메시지입니다.”라는 문구로 대체된다. 삭제된 메시지는 숨김 처리 기능과는 달리, 별도로 숨길 수 없다. 또한 해당 메시지는 서버에서도 삭제되므로, HTTP GET 요청을 통한 대화 내용 획득 시 extras와 content 키값은 비어 있는 값으로 표시된다. 이때 메시지의 수정 시간을 나타내는 UpdateTime 값은 삭제 시각으로 변경된다. 추가적으로 MessageStatusType값이 “RECLAIM”으로 설정된 경우는 사용자가 5분 이내에 자신의 메시지를 삭제한 경우이며, “HIDDEN”으로 설정된 경우는 방장이나 부방장이 특정 사용자의 메시지를 삭제한 경우에 해당한다. 따라서 content 값이 존재하지 않고, 동시에 MessageStatusType이 특정 상태로 기록되며, UpdateTime 값이 CreateTime 값과 다른 경우 해당 메시지가 삭제된 것으로 판단할 수 있다.

채팅방 유형 및 권한 그리고 안티 포렌식 기능별로 분류한 내용은 Table 11.과 같다. 먼저, 1:1 채팅의 경우 방장이나 부방장과 같은 권한 구조가 존재하지 않는다. 이 환경에서는 사용자가 본인이 작성한 메시지만 삭제할 수 있으며, 삭제는 전송 후 5분 이내에만 가능하다. 해당 메시지가 삭제되면 데이터베이스 상에서는 extras와 content 값이 공란으로 표시되고, UpdateTime은 삭제된 시각으로 변경된다. 사용자 인터페이스(UI)에서는 말풍선 내 메시지가 “삭제된 메시지입니다.”라는 문구로 대체되며, 이때 MessageStatusType 값은 “RECLAIM”으로 설정된다. 반면, 숨기기 기능은 제공되지 않는다. 단체 채팅에서 권한이 없는 사용자는 두 가지 상황으로 나눌 수 있다. 첫째, 상대방의 메시지에 대해 ‘이 사람 메시지 숨기기’ 기능을 적용할 수 있다. 이 경우 해당 사용자가 작성한 모든 메시지는 24시간 동안 현재 채팅방에서만 숨겨지며, 이는 UI 상에서만 반영될 뿐 데이터베이스의 content 값은 그대로 존재한다. 둘째, 본인이 작성한 메시지를 삭제할 경우에는 1:1 채팅과 동일하게 전송 후 5분 이내에만 가능하다. 이때 역시 extras와 content 값은 공란으로 처리되고, UpdateTime은 삭제된 시각으로 변경되며, UI에서는 “삭제된 메시지입니다.”로 표시된다. MessageStatusType은 “RECLAIM”으로 설정된다. 숨기기 기능은 지원되지 않는다. 반면, 단체 채팅에서 방장과 부방장 같이 권한이 있는 사용자는 보다 강력한 제어 권한을 가진다. 상대방의 메시지를 삭제할 수 있으며, 이 경우 데이터베이스 상에서는 extras와 content 값이 공란으로 처리되고, UpdateTime은 삭제된 시각으로 변경된다. UI 상에서는 삭제와 동시에 숨김 처리가 이루어지며, MessageStatusType 값은 “HIDDEN”으로 변경된다. 따라서 삭제와 숨김 기능을 따로 적용 할 수 없다. 또한 권한이 있는 사용자는 특정 상대방의 메시지에 대해 ‘이 사람 메시지 숨기기’ 기능을 사용할 수 있으며, 이 경우 해당 사용자의 모든 메시지가 24시간 동안 해당 채팅방에서만 숨겨진다. 한편, 권한이 있는 사용자가 본인의 메시지를 삭제할 경우에도 동일하게 extras와 content 값이 공란 처리되고, UpdateTime은 삭제된 시각으로 변경된다. UI에서는 삭제와 동시에 숨김 처리가 이루어지며, MessageStatusType 값은 “HIDDEN”으로 기록된다. 그러나 이 경우에는 별도의 숨기기 기능을 적용할 수 없다.

Table 11. Summary of Naver Talk’s Anti-Forensic Behavior

3.3.2 디스코드

디스코드에는 ‘메시지 수정하기’와 ‘메시지 삭제하기’라는 두 가지의 안티 포렌식 기능이 존재한다. 먼저 ‘메시지 수정하기’는 사용자가 보낸 메시지의 내용을 수정하는 기능이다. 수정된 파일은 UI 상에서는 ‘수정됨’ 이라고 표시되며, content값이 수정된 내용으로 변경되고 edited_timestamp 값이 null에서 수정된 시간으로 변경된다. 이 경우 수정 이전의 메시지 내용은 확인할 수 없지만, 메시지가 언제 수정되었는지는 기록을 통해 파악할 수 있다. 다음으로 ‘메시지 삭제하기’는 보낸 메시지를 삭제하는 기능으로, 이렇게 삭제된 메시지는 더 이상 HTTP API 요청을 통해 획득할 수 없으며, 서버상에서도 삭제가 된다.

3.3.3 폴라리스 오피스

My Polaris Drive에는 ‘파일 삭제’와 ‘영구 삭제’라는 두 가지의 안티 포렌식 기능이 존재한다. 먼저 ‘파일 삭제’는 삭제하길 원하는 폴더나 파일을 클릭한 후 우클릭해 삭제 버튼을 누르면 휴지통으로 이동되는 기능이다. 휴지통으로 이동된 파일은 hide 값이 true로 변경되고 deletedTime이 0에서 삭제한 시간의 유닉스 타임스탬프값으로 변경된다. 이렇게 이동된 파일이나 폴더는 1년 후에 자동으로 영구 삭제가 된다. 따라서 그전에 삭제를 원한다면 ‘영구 삭제’ 기능을 사용해야 한다. ‘영구 삭제’ 기능은 휴지통 내에서 완전히 삭제하고자 하는 폴더나 파일에 우클릭한 후 영구 삭제 버튼을 누를 시 완전히 삭제하는 기능이다. 이렇게 삭제된 파일은 더 이상 HTTP API 요청을 통해 획득할 수 없으며, 서버상에서도 삭제가 된다. 즉 ‘파일 삭제’ 기능만 이용하여 파일이나 폴더를 삭제할 시 완전한 삭제가 되지 않기 때문에 해당 기능만 이용한 안티 포렌식을 진행했을 시에는 파일 확보가 가능하다. 먼저 ‘휴지통의 파일 목록’ 데이터를 확보할 수 있는 URL에 HTTP API 요청을 전달해 휴지통 내 항목 정보를 확보한다. 여기서 각 항목의 fileId를 추출한 뒤, ‘파일 다운로드’용 URL에 fileId를 포함하여 HTTP API 요청을 전달하면 ‘파일 삭제’ 안티 포렌식 행위를 한 파일을 획득할 수 있다. 그러나 휴지통에 폴더가 포함된 경우에는 위 방식만으로는 확보할 수 없다. 휴지통 목록 응답에는 폴더 내부, 즉 삭제된 폴더의 하위 파일 및 폴더 정보가 포함되어 있지 않기 때문에 해당 폴더를 곧바로 ‘파일 다운로드’로 내려받으면 내부 파일이 포함되지 않은 빈 디렉터리 구조만 생성된다. 이런 경우에는 휴지통 내 기능인 ‘복원’ 기능을 통해 원래 위치로 되돌린 뒤, 드라이브에서 해당 폴더의 하위 항목을 조회하고 순차적으로 다운로드해야 실제 데이터를 확보할 수 있다.

IV. 클라우드 포렌식 절차 및 검증

본 절에서는 네이버톡, 디스코드, 폴라리스 오피스를 대상으로 클라우드 데이터 수집 절차를 실제 환경에서 검증한 결과를 다룬다. 네이버톡의 경우 쿠키와 인증 토큰 확보를 통해 웹소켓 기반 채팅 데이터를 수집하고 채팅방 화면을 재현하였다. 디스코드는 token을 활용해 API 요청을 통해 사용자·서버·채널 정보를 획득하고 대화 내용을 복구하였다. 폴라리스 오피스는 SID 기반으로 사용자 정보, 폴더 및 휴지통 구조를 단계적으로 확보하고 파일 다운로드까지 수행하였다. 또한 서비스 별 도구를 제작하여 해당 절차를 통해 재구성 할 수 있는지 검증해 제안한 방법론의 실효성과 적용 가능성을 확인하였다.

4.1 네이버톡

네이버톡의 크리덴셜 확보는 우선 웹 환경에서 실행 중인 네이버톡의 주요 쿠키값(NID_AUT, NID_SES)을 획득하는 것으로 시작한다. 이 값은 웹 환경에서 실행 중인 네이버톡을 대상으로 웹 브라우저의 개발자 도구를 통해 직접 추출하거나, 서비스가 동작 중인 환경의 메모리 덤프를 분석하여 확보할 수 있다. 다음 단계로, 채팅 데이터 수집에 필요한 사용자 식별자인 UID, 채팅방의 고유 식별자인 CID, 인증 토큰인 accTkn 를 확보한다. 이를 위해 Table 12.에 해당하는 API에 앞서 획득한 쿠키값을 HTTP GET 요청의 헤더에 포함하여 전송하고, 응답으로 반환되는 JSON 데이터에서 해당 값을 추출한다.

Table 12. URL by ‘Value to be Obtained’

마지막으로 확보한 UID, CID, accTkn을 이용해 웹소켓 서버와 연결을 구성한다. 연결에 사용되는 서버 주소는 wss://kr-ss1.chat.naver.com/chat이다. 이를 통해 실시간으로 전송되는 채팅 데이터를 JSON 형식으로 수집할 수 있다. 수집된 데이터는 단순 로그 분석에 그치지 않고, Fig. 7 및 Fig. 8같이, 확보된 토큰의 사용자가 참여한 채팅방 목록과 대화 내용을 실제 서비스 UI와 유사한 형태로 재구성하여 확인할 수 있다.

Fig. 7. Reconstruction of Naver Talk chat room list contents

Fig. 8. Reconstructing conversations in Naver Talk chat room

본 연구에서는 이를 검증하기 위해 전용 도구를 활용한 데이터 수집 방법이 실제 환경에서 실질적으로 동작할 수 있음을 보여준다.

4.2 디스코드

디스코드의 데이터 수집은 먼저 token값을 확보하는 것에서 시작된다. 이 값은 웹 환경에서 실행중인 디스코드를 대상으로 웹 브라우저의 개발자 도구를 통해 직접 추출하거나, 서비스가 동작 중인 환경의 메모리 덤프를 분석하여 확보할 수 있다. 확보된 token값은 이후 사용자 정보, 특정 유저 정보, 사용자의 친구 목록, 특정 유저 프로필 사진, 다이렉트 메시지 채널 목록, 사용자가 속한 서버 목록, 서버 내 채널 목록, 채널 내 메시지 조회 등 다양한 API 요청에 포함되어 데이터 획득의 핵심 매개체로 활용된다.

먼저 사용자 정보의 경우 ‘사용자 정보’ URL에 token 값을 포함하여 요청하면 확인할 수 있으며, 친구 목록 또한 동일하게 ‘사용자의 친구 목록’ URL에 token 값을 넣어 요청하여 획득할 수 있다. 특정 유저 정보는 친구 목록에서 추출한 id 값을 ‘특정 유저 정보’ URL에 token과 함께 추가하여 얻을 수 있으며, 특정 유저 프로필 사진은 해당 유저의 id와 avatar 값을 ‘프로필 사진’ URL에 포함해 요청함으로써 획득된다. DM 채널 목록과 서버 목록 역시 각 URL에 token 값을 포함하여 요청할 수 있으며, 서버 내 채널 목록은 서버 목록에서 얻은 채널 id를 함께 추가해 요청해야 한다.

마지막으로 채널 내 메시지 조회는 DM 채널 목록과 서버 내 채널 목록에서 확인한 채널 id를 이용하여, 해당 id와 token 값을 함께 요청에 포함해 획득할 수 있다. 이러한 일련의 데이터 획득 절차를 도구를 통해 시각적으로 재구성한 결과는 Fig. 9 및 Fig. 10과 같다. 이와 같이 본 연구에서는 도구를 통해 데이터 수집 과정을 실제로 검증하여 사용자 정보, 서버 및 DM 채널의 구조, 그리고 채널 내 대화 내용을 재현할 수 있었다. 이로써 디스코드의 데이터 수집 절차 역시 실효성이 있음을 입증하였다.

Fig. 9. Reconstructing Discord's server list and friends list

Fig. 10. Reconstructing conversations in Discord's server

4.3 폴라리스 오피스

폴라리스 오피스의 클라우드 스토리지인 My Polaris Drive의 데이터 수집은 쿠키 기반 인증값인 SID 확보에서 시작된다. 이 값은 웹 환경에서 실행 중인 폴라리스 오피스를 대상으로 웹 브라우저의 개발자 도구를 통해 직접 추출하거나, 서비스가 동작 중인 환경의 메모리 덤프를 분석하여 확보할 수 있다.

확보된 SID는 이후 사용자 정보, 최근 사용 파일, 전체 폴더 목록 등 다양한 API 요청에 포함되어 데이터 획득의 핵심 매개체로 활용된다. 먼저 사용자 정보의 경우 ‘사용자 정보’ URL에 SID값을 넣어 요청을 보낼 시 획득할 수 있다. 다음으로 폴더 구조 분석의 경우, ‘폴더 내 전체 파일 목록’에서 얻은 데이터 중 fileType이 DIR인 JSON 항목의 fileId를 추출한다. 이 fileId를 다시 ‘폴더 내 전체 파일 목록’ URL에 SID와 함께 추가하여 요청을 반복하면, 루트 폴더 하위에 존재하는 모든 폴더 및 그 내부 파일 목록까지 단계적으로 확보할 수 있다.

그리고 휴지통 폴더 구조 분석은 ‘휴지통의 파일 목록’ URL에 SID와 루트 폴더의 fileId를 추가하여 요청을 보내면, 휴지통에 보관된 파일 목록을 획득할 수 있다. 마찬가지로, 이 응답에서도 fileType이 DIR인 항목의 fileId를 추출하여 다시 ‘휴지통의 파일 목록’ URL에 포함하면, 휴지통 내부의 폴더 트리 전체와 그 안의 파일 목록을 확보할 수 있다.

마지막으로 파일 확보의 경우, 이전 과정을 통해 확보한 모든 fileId를 정리한 뒤, ‘파일 다운로드’ URL의 마지막 부분에 각 fileId를 포함하고 SID를 함께 넣어 요청을 반복 전송하면, My Polaris Drive 내에 존재하는 모든 파일을 실제로 다운로드할 수 있다. 이러한 데이터 획득 절차를 도구를 통해 시각적으로 재구성한 결과 Fig. 11 및 Fig. 12과 같았다. 이를 통해 My Polaris Drive의 사용자 정보와 파일 구조, 개별 파일까지 직접 확인할 수 있었다. 나아가 파일 다운로드까지 가능함을 검증함으로써, 제안한 절차가 실제 클라우드 환경에서도 충분히 적용 가능하다는 점을 보여주며, 실제 클라우드 데이터 수집을 위해 활용될 수 있는 가능성을 제시한다. 또한 본 연구에서는 상기 절차를 통해 획득한 파일이 실제 클라우드에 저장된 원본 파일과 동일한지를 검증하기 위하여 해시 기반 무결성 검증 실험을 추가로 수행하였다. 실험 대상 파일은 PDF, DOCX, TXT, PNG, GIF, HWPX, JPG 등 서로 다른 형식의 파일로 구성하였으며, 다양한 파일 유형에서도 동일한 결과가 도출되는지를 확인하고자 하였다.

Fig. 11. Reconstructing My Polaris Drive‘s file list in Polaris Office

Fig. 12. Reconstructing My Polaris Drive’s Data acquisition process in Polaris Office

먼저 로컬 PC 환경에서 각 확장자 별 테스트 파일을 생성한 뒤 My Polaris Drive에 업로드하였다. 이후 공식 웹 인터페이스의 다운로드 기능을 이용하여 해당 파일들을 획득하고 SHA-256 해시값을 산출하여 기준값을 생성하였다. 동일한 파일에 대하여 본 연구에서 구현한 API 기반 수집 도구를 이용해 다시 다운로드를 수행한 후 SHA-256 해시값을 계산하고 두 결과를 비교하였다. 다음 단계에서는 삭제 및 복원 과정이 파일 내용에 영향을 미치는지를 확인하기 위하여, 동일한 파일들을 Polaris Drive의 휴지통으로 이동시킨 뒤 API 기반 도구를 이용하여 복원 과정을 포함한 다운로드를 수행하고 SHA-256 해시값을 산출하였다. 이후 웹 인터페이스에서 휴지통 복원 기능을 이용해 파일을 복구한 뒤 다시 공식 다운로드 기능을 통해 파일을 획득하고 해시값을 계산하였다. 총 네 가지 방식, 즉 웹 인터페이스를 통한 다운로드, API 기반 도구를 통한 다운로드, 휴지통 이동 후 API 복원 절차를 포함한 다운로드, 휴지통 복원 후 웹 인터페이스를 통한 다운로드로 획득한 파일들에 대해 SHA-256 해시값을 비교한 결과, 모든 파일에서 동일한 해시값이 산출되었다. 또한 파일 크기 역시 모든 경우에서 동일하게 나타났으며, 파일 내용의 변형이나 손상은 확인되지 않았다.

이를 통해 My Polaris Drive에서 공식 웹 인터페이스와 API 기반 도구를 이용하여 수집한 파일은 삭제 및 복원 과정을 거치더라도 바이트 단위에서 동일함을 확인하였으며, 본 연구에서 제안한 수집 절차가 실제 클라우드 환경에서도 원본 데이터를 훼손하지 않고 정확히 확보할 수 있음을 입증하였다.

V. 결론

본 연구는 비 설치형 서비스인 네이버톡, 디스코드, 클라우드 오피스를 대상으로 클라우드 포렌식의 관점에서 주요 데이터의 수집 및 분석 과정을 다루었다. 로컬 저장소에 흔적이 남지 않는 비 설치형 서비스의 특성을 고려하여, 크리덴셜 확보와 서버 API 호출을 통한 데이터 획득 절차를 체계화하고 서비스 별 데이터 구조를 심층적으로 분석하였다. 또한 메시지 삭제, 숨기기, 파일 삭제 등 안티 포렌식 기능별 데이터 변화를 추적하고, 서비스별 맞춤형 데이터 획득 도구를 제작하여 실제 환경에서 수집 절차를 검증하였다. 본 연구 결과는 인증 토큰 확보 이후의 디지털 수사 과정에서 클라우드 기반 메신저와 오피스 응용 프로그램에 대한 데이터 수집 및 분석 절차를 보완하는 유용한 접근법으로 활용될 수 있을 것으로 기대한다.