Electron App의 메시지 획득 방안에 관한 연구: 협업 툴 잔디, 슬랙, 팀즈 중심으로

A Study on Message Acquisition from Electron Apps: Focused on Collaboration Tools such as Jandi, Slack, and Microsoft Teams

Abstract

코로나19 이후 비대면 근무가 증가함에 따라 협업 툴의 사용이 증가하고 있다. 협업 툴은 다양한 기기에서의 접근성을 보장하기 위해 크로스 플랫폼(cross-platform) 형태로 개발되고 있으며, 이를 위해 Chromium 기반의 오픈소스 프레임워크인 Electron을 사용하는 것이 최신의 개발 경향이다. Electron 오픈소스 프레임워크를 사용하여 개발된 어플리케이션 Electron App의 경우 Chromium 기반 웹 브라우저와 유사한 방식으로 데이터를 저장하므로, 웹 브라우저에서 데이터를 획득하는 방법과 동일한 방법으로 어플리케이션의 데이터를 획득할 수 있다. 본 논문에서는 협업 툴 잔디(jandi), 슬랙(slack), 팀즈(microsoft teams)를 중심으로, 웹 브라우저 저장소(web storage)의 데이터 구조를 분석하고 이를 기반으로 Electron App의 메시지를 획득하는 방안을 제시한다. 잔디는 기존에 개발된 도구를 활용하여 Cache에서 메시지를 획득하였고, 슬랙, 팀즈의 경우 본 논문에서 개발한 메시지 카빙 도구를 이용하여 IndexedDB에서 메시지를 획득하였다.

Collaboration tools are used widely as non-face-to-face work increases due to social distancing after COVID-19. The tools are being developed in a cross-platform manner with 'Electron', an open source framework based on Chromium, to ensure accessibility on multiple devices. Electron Apps, applications built with Electron framework, store data in a manner similar to Chromium-based web browsers, so the data can be acquired in the same way as the data is acquired from a web browser. In this paper we analyze the data structure of web storage and suggest a method to get the message from Electron Apps focused on collaboration tools such as Jandi, Slack, and Microsoft Teams. For Jandi, we get the message from Cache by using previously developed tools, and in the case of Slack and Microsoft Teams, we get the message from IndexedDB by using the message carving tool we developed.

I.서론

코로나 19의 여파로 비대면 근무가 증가함에 따라 기업의 협업툴 도입이 급격하게 증가하고 있다[1]. 이는 기업형 범죄 발생 시 협업 툴에서 주요 증거를 발견할 확률이 높다는 것을 의미한다. 특히, 협업 툴에서 송․수신한 메시지의 경우 공모행위 등 범죄 혐의 입증에 결정적인 증거가 될 가능성이 크다. 그러나 현재까지 협업툴과 관련된 연구는 모바일 기기에서 메시지를 획득하는 것에 초점이 맞추어져, 윈도우 환경의 업무용 PC에서 메시지를 획득하는 방법에 대한 연구는 미흡하다. 따라서 윈도우 환경에서 설치형 어플리케이션 형태로 동작하는 협업툴을 중심으로 메시지를 획득하는 방안에 대한 연구가 필요하다.

본 논문에서는 윈도우 환경에서 설치형 어플리케이션을 통해 협업 툴을 사용하였을 때 메시지 데이터가 저장되는 파일을 식별하고, 해당 파일의 데이터 구조를 분석하여 사용자가 송․수신한 메시지를 획득하였다. 논문의 구성은 다음과 같다. 2장에서는 기존 연구와 한계점을 설명하고, 3장에서는 설치형 어플리케이션 Electron App의 특성을 토대로 연구방법을 정리한다. 4장에서는 잔디(jandi), 슬랙(slack), 팀즈(microsoft teams) 각 협업툴 별로 메시지 데이터가 저장된 파일을 분석하여 메시지를 획득하고 활용 방안을 제시한다. 마지막 5장에서는 결론으로 마무리한다.

II.관련 연구

본 논문의 연구 주제와 관련된 선행연구 및 한계점은 다음과 같다. Slack 및 Discord 메신저에 관한 연구[2]와 협업 툴 아티팩트 분석 및 삭제된 데이터 복구연구[3]에서는 윈도우 환경이 아닌 모바일 기기에서만 메시지를 확인하였다. Windows 에서의 Wire 크리덴셜 획득 및 아티팩트 분석[4]의 경우 윈도우 환경에서 메시지 데이터 구조와 내용을 확인하였다. WhatsApp Web 버전 포렌식 조사[5]에서는 사용자 행위와 관련된 레코드를 발견하였으나 Web 버전만 연구가 진행되었다. 협업 툴의 사용자 행위별 아티팩트 분석연구[6]는 윈도우 환경에서 팀즈의 메시지 데이터 구조 중 일부를 확인하였으나 메시지 획득 시 윈도우 환경이 아닌 모바일 기기의 데이터베이스 파일을 사용하였다.

한편, CCLSolutions[7][8][9]에서는Electron App의 IndexedDB에 관해 연구하고 분석 도구를 개발하였으나, 본 논문의 연구 대상 협업 툴을 분석하는 과정에서 오류가 발생하거나 데이터를 온전히 획득하지 못하였다. Electron 기반 협업프로그램의 취약점에 관한 연구[10]도 존재하나, 메시지 획득에 관한 연구는 진행되지 않았다.

본 논문에서는 윈도우 환경에서 협업 툴 잔디, 슬랙, 팀즈를 중심으로 연구를 진행하고, 이를 바탕으로 Electron App의 메시지를 획득하는 방법을 제시한다.

III.연구 방법

3.1 사전 지식

최근 다양한 기기에서의 접근성을 보장하는 크로스 플랫폼 어플리케이션의 경우 Electron오픈소스프레임워크를 사용하여 개발되고 있으며 이러한 어플리케이션을 Electron App이라한다. 논문작성 시점 기준으로 약 800여 개의어플리케이션이Electron App 형태로 개발되었고 협업툴잔디, 슬랙, 팀즈 또한 Electron App에속한다[15].Electron 프레임워크가 Chromium과Node.js기반의 Web 기술을 이용하므로, ElectronApp은Fig. 1.과 같이 ChromiumWeb Browser와동일하게 웹 브라우저 저장소(web storage)의형태인Cache, IndexedDB, Local Storage, SessionStorage, Cookies에 데이터를 저장한다 [11].프로그램별 파일 경로는 Table 1.과 같다.

Table 1. File Path of Electron App and ChromiumWeb Browser

Fig.1. WebS torage of Electron App and Chromium Web Browser

3.2 파일식별 및 분석

앞서 살펴본 바와 같이 Electron App이 Chromium Web Browser와 데이터를 저장하는 방식이 동일하다는 점에 착안하여, Windows 10 운영체제에서 웹 브라우저 크롬, 마이크로소프트 엣지를 통해협업툴잔디, 슬랙, 팀즈에접속한다음 Web Storage 중 메시지가 저장되는 파일을 식별하고 Electron App에서도 같은 유형의 파일을 분석하였다.

Fig. 2.에서 보는 것처럼 Web Storage에 저장된 데이터는 웹 개발자 도구(web developer tools)를 통해 확인하였고, Cache는 Chrome Cache View[12]를 이용하여 데이터를 추출한 후 확인하였다. 확인 결과는 Table 2.와 같으며 해당 파일들에 대해 HxD[14] 등을 사용하여 세부 데이터 구조를 분석하고 메시지 데이터를 획득하였다.

Fig. 2. Web Developer Tools of Chrome and Microsoft Edge

Table2. File Path where Message Data are stored

IV. 메시지 획득

4.1 잔디(jandi)

4.1.1 team, room

잔디는 팀(team)과 대화방(room)으로 구성되며 대화방은 토픽, 채팅으로 구분된다.Fig.3.에서 보는것처럼 이용자는 팀별로 대화방을 생성하여 메시지, 파일 등을 송·수신한다.

Fig.3. team, room of Jandi

4.1.2 Cache

잔디는 캐시파일에 메시지 데이터를 저장하며 파일 경로는 Table 2.와 같다. 캐시에 저장된 정보는 ChromeCacheView[12]를이용하여확인할 수 있고, 메시지 데이터의 경우 Fig. 4.에서 보는 것처럼 캐시 속성 중 URL 값이“https://i1.j andi.com/message-api/v1/teams/[teamid]/rooms/[room id]/messages?” 형태인JSON 파일에 저장된다. team id는사용자가협업툴사용을 위해 생성한 팀의 고유id 값이고, roomid는 team 내부에 업무협업을 위해생성한 room에 대한 고유 id 값이다. teamid, roomid는 각각 생성된 팀 개수, 팀 내 대화방 개수만큼 생성된다.

Fig.4. Jandi Cache with Chrome Cache View

Fig. 3.과 같은 테스트 환경에서 팀 이름과 대화방 이름을 매핑한 결과는 Table 3.와 같다. Team A와Team B는 각각 6개의 roomid 값을 갖고 있으며 캐시 속성 중 URL에 team id와 room id 값을 매핑하여 상호간의 메시지 전달그룹을 구분한다.

Table3. URL Format of JSON files in JandiC ache

4.1.3 메시지 획득 방안

잔디에서 메시지를 획득하는 과정은 다음과 같다. ➊ Fig. 4.와 같이 ChromeCacheView를 통해 잔디의 캐시 정보를 확인하고 URL 속성으로 정렬한다. ➋ Table 3.의 URL Format을 참고하여 Fig. 5.에 도식된 것처럼 캐시 내 JSON 파일을 team id, room id를 구분하여 추출한다. ➌ 추출된 JSON 파일은 JSON To CSV Converter[13]를 이용하여 CSV형태로 변환한다. ➍ 엑셀프로그램을 통해 CSV파일을 로드한다.➎ 로드된 데이터들을 순차적으로 병합하고 날짜필드로 정렬하면 Fig. 5.와 같이 팀별로 특정 대화방에서송·수신한 메시지 내용, 첨부파일명, 작성자, 작성시각 등을 확인할 수 있다. 단, 직접적인 팀명, 대화방명, 작성자명은 확인할 수 없으며 그에 대응되는 고유식별자인 teamId, roomId, writerId 정보만이 확인 가능하다. 또한, fileUrl을 통한 첨부파일의 직접접근도 제한된다.

Fig.4. Jandi Cache with Chrome Cache View

Fig. 5. Message Acquisition Process of Jandi

4.2 슬랙(Slack)

4.2.1 workspace, channel

슬랙은 워크스페이스(workspace)와 채널(channel)로 구성되며 DM(Direct Message)은 채널 중 하나이다. 슬랙의 워크스페이스, 채널, DM은 각각 잔디의 팀, 토픽, 채팅에 대응되며 같은 기능을 담당한다.

4.2.2 IndexedDB

슬랙은 IndexedDB 중 Blob 파일에 메시지 데이터를 저장하며 파일 경로는 Table 2.와 같다. 웹 개발자 도구(web developer tools)를 이용하여 웹 브라우저의 IndexedDB에 저장된 정보를 확인할 수 있고, Fig. 7.에서 보는 것처럼 IndexedDB 하위reduxPersistenceStore에서 메시지를 확인하였다. 메시지는 workspace id와 channel id를 구분자로 하여 워크스페이스 내 채널별로 저장된다. worksp ace id와 channel id는 웹 브라우저를 통해 슬랙 접속 시 URL에서 “https://app.slack.com/client/ [workdspace id]/[channel id]”의 형태로 확인할 수 있다.

4.2.3 메시지 속성

슬랙의 메시지 속성 정보는 Fig. 7.과 같이 웹 개발자 도구를 통해 확인 가능하고, 속성 간 순서는 Fig. 6.와 같이 HxD[14]를 통해 Blob 파일의 Hex 값을 분석하여 파악할 수 있다. 슬랙의 메시지 속성을 정리하면 Table 4.와 같으며 중요 속성정보는 음영 처리 하였다. 메시지 속성 중 ts, thread_ts 속성은 Unix Timestamp 형태로 저장되며, ts 속성은 메시지 작성 시간을, thread_ts 속성은 메시지가 댓글에 해당할 경우 원글의 작성 시간을 의미한다. text 속성에는 메시지 내용이 저장되며 영문 메시지는 ASCII, 한글 메시지는 UTF-16으로 인코딩되어 저장된다. files, channel, user 속성에는 각각 파일, 채널, 작성자의 고유 식별자가 저장된다.

Fig.6. Hex Data of Slack Message

Table 4. Slack Message Attribute

Fig.7. Slack with Web Developer Tools

4.2.4 메시지 획득 방안

슬랙의 메시지는 메시지 속성 정보를 기반으로 카빙(carving) 기법을 통해 획득한다. IndexedDB 의Blob 파일을대상으로Hex 값 단위에서 메시지 데이터와 동일한 패턴을 보이는 데이터를 추출하고 메시지 속성 정보로 데이터를 해석하면 메시지 내용을 획득할 수 있다.

본 논문에서는 위의 과정을 자동화한 Python v3.7기반의메시지카빙도구¹⁾를개발하였다.개발 과정은 다음과 같다. ➊ Table 4.의 메시지 속성에 대한 정규 표현식을 사용하여 메시지 데이터 패턴과 동일한 패턴을 보이는데 이 터를 탐색한다. ➋ 데이터탐색 후에는 Table 4.에서 음영 처리한 주요 메시지 속성 thread_ts, files, ts, channel, user, text에해당하는값들에대해서만데이터를추출한다. ➌ Unix Timestamp 형식으로 저장된 ts, thread_ts 속성에 대해서는 Date 변환함수를 사용하여 시간 정보를 획득하고, text 속성에 저장된 메시지의 경우 영문은ASCII, 한글은 UTF-16으로디코딩하여 해석한다. ➍ 한편, 메시지 데이터 이외에도 files, user, channel 속성에는 고유식별자가 저장되는데, 이에 대응되는 정보를 얻기 위한 데이터를 추가로 획득한다. 획득 방법은 앞서 기술한 메시지 데이터를 획득하는 방법과 동일하며 탐색을 위한 속성 정보만이 다르다. ➎ 메시지 내용을 비롯하여 획득한 데이터는 CSV 파일에 순차적으로 행 단위로 저장한다. ➏ 엑셀 프로그램으로 CSV 파일을 로드할 경우 Fig. 8.과 같이 팀, 사용자, 채널, 첨부파일, 메시지 관련 정보를 확인할 수 있다.

Fig.8. Slack Message Acquisition through a Developed Carving Tool

4.3 팀즈(MicrosoftTeams)

4.3.1 conversation

팀즈는 전화번호를 인증한 하나의 계정 당 복수의 대화방(conversation)을 생성할 수 있으며 대화방에서 메시지, 파일 등을 송·수신한다.

4.3.2 IndexedDB

팀즈는IndexedDB중LevelDB 파일에 메시지 데이터를 저장하며 파일 경로는 Table 2.와 같다. 웹개발자도구(web developer tools)를 이용하여 웹 브라우저의 IndexedDB에 저장된 정보를 확인할 수 있고, Fig. 9.에서 보는 것처럼 IndexedDB 하위 replychains에서 메시지 내용을 확인하였다. 메시지는 conversation id를 구분자로 하여 대화방 별로 저장되며, conversation id는 웹브라우저를 통해 팀즈 접속시 URL에서 “https://teams.live.com/_#/conversations/[co nversationid]?”의 형태로 확인할 수 있다.

Fig. 9. Microsoft Teams with Web Developer Tools

4.3.3 메시지 속성

팀즈의 메시지 속성 정보는 Fig. 9.와 같이 웹 개발자 도구를 통해 확인 가능하고, 속성 간 순서는 Fig. 10.와 같이 HxD[14]를 통해 LevelDB 파일의Hex 값을분석하여파악할수 있다. 메시지 속성은 Table 5.와 같으며 메시지 분석에 있어 중요한 속성은 음영 처리 하였다. 메시지가 전달되는 대화방은 conversationId를 기준으로 구분되고, 메시지는 clientmessageid를 고유 식별자로 가진다. 메시지 내용과 첨부파일은 content, attachments 속성에 저장되고, 작성자의 이름과 사용자 ID는 imdisplayname과 creator 속성에 저장된다. 시간 정보는 3가지 속성 composetime, originalarrivaltime, clientArrivalTime에 저장되며 각각 발신, 수신, 사용자 확인 시간을 의미한다.

Fig. 10. Hex Data of Microsoft Teams Message

4.3.4 메시지 획득 방안

팀즈의 메시지는 슬랙과 마찬가지로 메시지 속성 정보를 기반으로 카빙(carving) 기법을 통해 획득한다. IndexedDB의 LevelDB 파일을 대상으로 Hex값 단위에서 메시지 데이터와 동일한 패턴을 보이는 데이터를 추출하고 속성 정보에 따라 데이터를 해석하면 메시지 내용을 획득할 수 있다.

본 논문에서는 위의 과정을 자동화한 Pythonv3.7기반의 메시지 카빙 도구²⁾를 개발하였다. 개발 과정은 다음과 같다. ➊ Table 5.의 메시지 속성에 대한 정규 표현식을 사용하여 메시지 데이터 패턴과 동일한 패턴을 보이는 데이터를 탐색한다. ➋ 데이터 탐색 후에는 Table 5.에서 음영 처리한 주요 메시지 속성 content, clientmessageid, imdisplayname,composetime, originalarrivaltime, clientArrivalTime, conversationId, parentMessageId, creator, attachments에 해당하는 값들에 대해서만 데이터를 추출한다. ➌ text 속성에 저장된 메시지의 경우 영문은 ASCII, 한글은 UTF-16으로 디코딩하여 해석하고, attachments 속성에 저장된 데이터의 경우 하위 속성 objectId, itemId, title에 따라 재해석한다. ➍ 메시지 내용을 비롯하여 획득한 데이터는 CSV 파일에 순차적으로 행단위로 저장한다. ➎엑셀 프로그램으로 CSV파일을 로드하면 Fig. 11.에서 보는 것처럼 메시지내용, 작성자, 수발신 시간, 대화방, 첨부파일명 등의 정보를 확인할 수 있다.

Fig. 11. Microsoft Teams Message Acquisition through a Developed Carving Tool

Table 5. Microsoft Teams Message Attribute

4.4 메시지 삭제

본 논문에서 메시지 삭제를 실험한 결과 잔디, 슬랙, 팀즈세협업툴모두메시지삭제이후복구가 어려운 것으로 확인하였다. 잔디, 슬랙은 삭제 이후 삭제된 메시지와 관련된 흔적을 발견할 수 없었으며, 팀즈의 경우 Fig.11.에서 보는 것처럼 메시지 속성 관련 정보는 남아있었으나 속성에 저장되는데이터가 초기화되어 삭제 전 메시지를 확인할 수 없었다. 그러나, 메시지 삭제를 하지 않은 사용자가 다른 사용자의 삭제행위 이후 협업 툴에 접속하지 않는다면, 해당 삭제내역이 반영되지 않으므로 삭제 전 메시지를 확인할 수 있었다.

4.5 활용 시나리오

본 항에서는 시나리오를 바탕으로 연구 결과를 활용할 수 있는 방안을 제시한다. 실제 발생 가능한 상황을 가정하여 모바일 기기 압수 제한, 메시지 삭제, 비밀번호 제출 거부 3가지 시나리오로 구성하였다.

4.5.1 모바일 기기 압수 제한

(사건 개요)

A사에서 기업형 범죄가 발생하여 동사 사무실을 압수수색 중이다. 혐의자들은 범죄공모에 협업 툴 잔디를 사용하였고, 영장에 기재된 압수수색의 범위는 혐의자들의 업무용 PC로 제한되었다.

(증거 획득)

피압수자의 참여하에 동의를 얻어 압수 대상 업무용 PC에 로그인하고 Table 2.의 경로에 있는 Cache 파일을 압수한다. 이후, Chrome Cache View[12], JSON TO CSV Converter[13]를 사용하여 메시지를 획득하고, 범죄 관련성이 있는 내용만을 최종적으로 선별한다.

4.5.2 메시지 삭제

(사건 개요)

B사는 협업 툴 슬랙을 도입하여 운용하고 있으며 임직원들은 PC, 모바일 기기 모두에서 슬랙을 이용하고 있다. B사를 압수수색하던 중 현장에 나타나지 않던 혐의자 중 한 명이 범죄 행위를 은닉하고 증거를 인멸하기 위해 자신의 모바일 기기를 이용하여 슬랙에 있는 메시지를 삭제하였다.

(증거 획득)

압수수색 시작과 동시에 압수 대상 PC들의 네트워크를 차단하여 원격 조작을 방지한다. 이후, Table 2.의 경로에 있는 IndexedDB 파일을 압수하고, 본 논문에서 개발한 메시지 카빙 도구를 이용하여 삭제 행위 발생 전 메시지를 획득한다.

4.5.3 비밀번호 제출 거부

(사건 개요)

협업 툴 팀즈를 사용한 혐의자들의 PC를 압수수색중이다. 그러나 혐의자 중 일부는 PC 비밀번호 제출을 거부하고 있다. PC에 디스크 암호화 등의 보안정책은 설정되어 있지 않다.

(증거 획득)

Windows To Go³⁾ 방식으로 혐의자의 PC를 부팅하고 Table 2.의 경로에 있는 IndexedDB 파일을 압수한다. 이후, 본 논문에서 개발한 메시지 카빙 도구를 이용하여 메시지를 획득하고, 범죄 관련성이 있는 내용만을 최종 선별한다.

V.결론

본 논문에서는 윈도우 환경에서 협업툴잔디, 슬랙, 팀즈를 중심으로 설치형 어플리케이션인Electron App의 메시지를 획득하는 방안에 대해 연구하였다. Electron 오픈소스 프레임워크가 Web기술을 기반으로 하므로, Electron App의 경우 웹 브라우저 저장소(web storage)와 같은 형태로 데이터를 저장한다는 점에 착안하여 메시지 데이터가 저장되는 파일을 식별하였다. 잔디는Cache파일에 슬랙과 팀즈는 IndexedDB 파일에 메시지를 저장하였으며, 해당 파일들에 대한 상세 분석과정을 거쳐 메시지를 획득하였다. 메시지 획득 과정에서 Cache는 기존에 개발된 분석도구를 활용하였고 IndexedDB는 본 논문에서 개발한 메시지 카빙도구를 이용하였다. 본 논문에서 제시한 방법을 활용할 경우 향후 PC 압수수색 과정에서 주요 증거인 메시지를 획득하는 데 도움이 될 것으로 기대한다.