최근 침해사고에서는 공격자가 단순히 시스템에 접근하는 것을 넘어, 내부 데이터베이스를 직접 조회하고 민감 정보를 탈취하는 정황이 빈번하게 확인되고 있다. 특히 공격자가 피해 시스템에 직접 DB 클라이언트 도구를 설치하여 데이터를 유출하는 방식이 늘어나고 있으며, DBeaver, Navicat, sqlcmd와 같은 정상 도구들이 이 과정에 활용되고 있다.

 

이러한 행위는 합법적인 관리자의 행위로 위장되기 쉬워 탐지가 어려우며, 유출 흔적 또한 일부 시스템 로그나 클라이언트 도구의 로컬 기록, SQL 서버의 실행 로그 등을 통해서만 확인된다.

 

또한, DB 클라이언트 도구들은 사용자가 데이터베이스 주소(IP), 포트, 계정 정보(ID/PW) 등을 명시적으로 설정해야 정상 작동하기 때문에, 이러한 도구가 사용됐다는 것은 곧 공격자가 해당 데이터베이스의 접근에 필요한 정보를 모두 확보한 상태라는 점을 의미한다. 이는 이후 정보 수집 및 유출 단계로 이어졌을 가능성을 보여주는 정황으로 해석될 수 있다.

 

본 보고서는 공격자가 침해 시스템에 직접 설치하거나 사용하는 DB 클라이언트 도구들의 특징과 흔적을 분석하고, MS-SQL 환경이 설치된 모의 환경을 기준으로 해당 도구들을 통해 어떤 로그가 남고, 보안 관점에서 어떤 대응과 탐지가 가능한지를 정리한다.

 

도구별 분석

본 보고서에서는 공격자가 활용한 사례가 확인된 DBeaver, Navicat, sqlcmd 도구만 다룬다. 각 도구는 Windows 환경에서 최신 버전으로 테스트가 진행되었으며, 로그 위치나 로그 파일명은 버전 마다 상이할 수 있다.

 

도구	버전
DBeaver	25.0.4
Navicat for Premium	17.2.5
sqlcmd	N/A(LOLBins)

표 1. 테스트에 사용된 도구 버전 정보

 

DBeaver

DBeaver는 다양한 관계형 데이터베이스를 지원하는 오픈소스 도구로, 쿼리 실행, 데이터 조회, 내보내기 기능 등을 제공하는 GUI 기반 애플리케이션이다.

 

그림 1. DBeaver 프로그램 실행 화면

 

시스템 및 로그 흔적

DBeaver를 이용한 데이터 유출 여부는 ‘dbeaver-debug.log’와 ‘.log’  파일을 통해 확인할 수 있다.

 

DBeaver는 내장된 내보내기 기능을 통해 쿼리 결과 또는 전체 테이블을 CSV, Excel, JSON 등 다양한 형식의 파일로 저장할 수 있다. 이러한 내보내기 활동 및 사용자 행위는 debug 로그를 통해 데이터 유출과 관련된 흔적을 추적할 수 있다. debug 로그에는 데이터 내보내기 이력 뿐만 아니라 DBeaver 버전, 설치 경로, 실행 시간, 종료 시간 등이 기록된다.

 

그림 2. DBeaver의 데이터 내보내기 기능

 

• 경로: C:\Users\<사용자이름>\AppData\Roaming\DBeaverData\workspace<버전>\.metadata\dbeaver-debug.log
• 저장 파일 명 패턴: ${table}_${timestamp}

 

debug 로그 내 “Export to the new file” 문자열을 통해 사용자의 데이터 내보내기(export) 흔적을 확인할 수 있으며, 파일명 등 구체적인 내보내기 대상 정보가 함께 기록된다. 또한, 해당 로그가 존재하지 않더라도, 사용자가 언제 어떤 데이터베이스에 접속했는지에 대한 접속 이력이 남아 정상 관리자 외의 사용자가 특정 시간에 민감한 DB에 접근했는지 여부를 확인하는데 활용될 수 있다.

 

그림 3. DBeaver debug 로그에서 확인 가능한 데이터 내보내기 흔적 (dbeaver-debug.log)

 

한편, .log 파일은 DBeaver 실행 중 발생한 시스템 오류 및 예외 정보를 기록하며, DB 접속 실패, 드라이버 로딩 오류, SQL 구문 오류 등의 내용을 포함한다. 이를 통해 공격자가 실제로 DB에 접근했는지 여부, 데이터 유출 시도가 실패했는지 여부 등을 추가적으로 확인할 수 있다.
 

• 경로 : C:\Users\<사용자이름>\AppData\Roaming\DBeaverData\workspace<버전>\.metadata\.log

 

이용된 사례

공격자는 피해 시스템에 RDP로 접근한 후, 웹 브라우저에서 DBeaver를 검색하고 설치했다. 이후, 기본 저장 파일 명인 ‘${table}_${timestamp}.txt’ 형식으로 데이터를 추출했다. 이 과정에서 공격자가 실행한 일부 쿼리는 .log 파일을 통해 확인할 수 있었다. 접근 권한이 없어서 실행되지 않은 쿼리, SQL 구문 오류로 인해 실패한 시도 등이 기록되어 있었으며, 이를 통해 공격자가 여러 차례 테스트 작업을 수행했음을 확인할 수 있다.

 

그림 4. 공격자가 DBeaver 프로그램을 설치한 이력

 

그림 5. 접근 권한이 없어 실행되지 않은 쿼리 (.log)

 

그림 6. 문법 오류로 인해 실행되지 않은 쿼리 (.log)

 

Navicat

Navicat은 PremiumSoft 사에서 개발한 소프트웨어로, 다양한 데이터 베이스를 지원하고 SQL 쿼리, 데이터 내보내기 등 기능을 제공한다. 해당 도구는 상용 도구 이지만, 14일 체험판을 제공하고 있어 공격자들이 많이 사용하고 있다. 이번 도구 테스트에서는 Navicat 17 버전이 사용됐다.

 

그림 7. Navicat 실행 화면

 

시스템 및 로그 흔적

Windows 환경에서 Navicat을 사용할 경우, 데이터 내보내기(Export) 작업에 대한 내역은 기본 로그 파일에 저장되지 않는다. 만약, Export 설정을 저장한 ‘.nexptmssql’ 형식의 프로필 파일이 존재한다면, 해당 파일을 통해 Export 수행 여부를 간접적으로 추정할 수 있다. 해당 파일에는 대상 테이블 및 쿼리 결과 등이 포함되며, XML 기반 구조로 저장되어 있다. ‘TargetName’, ‘TargetfilePath’는 각각 Export한 테이블 이름과 위치에 대한 정보가 포함되어 있다.

 

그림 8. Navicat에서 확인할 수 있는 Export 이력 (.nexptmssql)

 

• 경로 : C:\Users\Administrator\Documents\Navicat\SQL Server\Servers\<서버명>\<DB명>\<스키마명>\
• 저장 파일명 : <파일명>.nexptmssql

 

반면, Linux 환경에서는 LogExport.txt 파일을 통해 export한 내역을 확인할 수 있다. 하지만 해당 로그는 누적되지 않아 실행할때 마다 덮어 씌워지므로 장기간의 활동 내역을 추적하거나, 공격자의 과거 활동을 식별할 때 주의가 필요하다.

 

• 경로: . /home/your_username/.config/navicat/Premium/Logs
• 저장 파일명: LogExport.txt

 

이용된 사례

공격자는 리버스 터널링 환경이 구축된 시스템에 RDP를 이용해 접근했다. 공격자는 접근한 이후, DB에 접근하기 위해 navicat 17 버전을 설치하고 SELECT 구문을 이용해 사용자 정보가 저장되어 있는 테이블의 행 갯수를 조회했다. 이후, Export 기능을 이용해 <DB명>.mdb 파일 형태로 테이블 내 데이터를 저장하고 외부로 유출을 수행했다.

 

그림 9. LogHistory.txt에서 확인된 테이블 조회 이력

 

그림 10. LogExport.txt에서 확인된 테이블 추출 이력

 

sqlcmd

sqlcmd는 Microsoft SQL Server에서 제공하는 명령줄 기반의 데이터베이스 관리 도구로, SQL Server 환경 구성 시 기본적으로 설치된다. 또한, LoLBins(Living off the Land Binaries)로 분류되어, 공격자가 악용할 수 있는 정상 실행 파일 중 하나이다. 공격자들은 MS-SQL 환경을 대상으로 정보 유출할 때 sqlcmd를 이용해 SQL 쿼리 명령을 전달하고 테이블 조회 및 데이터베이스 백업 등 행위를 수행한다.

 

시스템 및 로그 흔적

sqlcmd를 이용해 데이터베이스 및 테이블을 백업하기 위해서는 자격증명 정보가 필요하다. 필요하다. MS-SQL은 Windows 인증(로컬 계정)과 SQL 인증(sa 계정) 두 가지 인증 방식을 이용하며 인증 방식에 따라 사용되는 sqlcmd 명령 옵션의 차이가 있다.

 

옵션	기능
-S	SQL Server의 주소와 포트를 지정
-U	SQL Server 로그인 계정 설정 (SQL 인증)
-P	패스워드 설정
-d	연결할 데이터베이스 이름
-Q	실행할 SQL 쿼리 지정
-s	컬럼 구분자 설정
-E	Windows 계정 인증

표 2. 공격자가 MS-SQL 백업 시 활용하는 주요 옵션

 

기능	명령어 예시
Windows 자격증명 인증	sqlcmd -S localhost -E -Q “BACKUP DATABASE [Test] TO DISK=’C:\Test.bak’ WITH INIT”
SQL 자격증명 인증	sqlcmd -S 192.168.0.1,1433 -U sa -P password -Q “BACKUP DATABASE [Test] TO DISK=’C:\Backup\Test.bak’ WITH INIT”

표 3. MS-SQL 인증 방식에 따른 sqlcmd 명령어 예시

 

Windows 인증을 받는 경우에는 -E 옵션을 사용하며, 별도의 자격증명 없이 현재 Windows 세션의 사용자로 인증을 수행한다. 다만, 권한 상승 등으로 인해 명령 프롬프트가 SYSTEM 권한으로 동작할 경우에는 Windows 자격증명 인증을 수행할 수 없어, sqlcmd 명령을 성공할 수 없다.

 

그림 11. SYSTEM 권한으로 sqlcmd 명령 실행 시 확인되는 인증 실패 로그

 

sqlcmd 명령으로 BACKUP 쿼리를 이용해 데이터베이스를 백업할 경우에는 MS-SQL의 주요 로그인 trc 로그와 Error 로그에서 백업 수행 이력을 확인할 수 있다.

 

• 경로 : C:\Program Files\Microsoft SQL Server\MSSQLXX.<InstanceName>\MSSQL\Log
• 저장 파일명 : ERRORLOG.*/ log_*.trc

 

그림 12. sqlcmd 명령을 이용해 데이터베이스 백업시 확인되는 trc 로그

 

그림 13. sqlcmd 명령을 이용해 데이터베이스 백업시 확인되는 Error 로그

 

이용된 사례

공격자는 MS-SQL 서버에 대한 제어권을 획득한 이후, 배치 스크립트 파일을 생성했다. 배치 스크립트 내에는 sqlcmd를 사용해 테이블 정보를 조회하고 저장하는 명령이 명시되어 있다. 공격자는 관리자 권한으로 해당 배치 파일을 실행해 데이터베이스 내 테이블 정보를 [테이블명].dat 형태로 저장하고 외부로 유출했다. 다만, SELECT 구문으로 테이블 조회 결과를 파일로 저장하는 경우에는 MS-SQL 관련 로그에서 이력을 확인할 수 없으나, SRUM 아티팩트에서 sqlcmd.exe 프로세스가 다수의 데이터를 통신한 이력이 확인됐다. 이는 데이터 조회 과정에서 통신한 이력으로 판단된다.

 

그림 14. 공격자가 sqlcmd 명령 이용에 사용한 배치 파일 내용

 

그림 15. sqlcmd 네트워크 통신 이력

 

결론

공격자는 앞서 언급된 도구 외에도 침해 후 데이터베이스 내의 데이터 조회를 위해 다양한 DB 클라이언트 도구를 이용할 수 있다. 특히 DB 클라이언트 도구는 정상적인 운영 과정에서도 사용되기 때문에, 이러한 도구의 사용 여부를 Anti-Virus 제품을 통해 탐지하는 것은 현실적으로 어렵다.

 

침해사고 대응 관점에서는 위에서 설명한 시스템 및 로그 흔적을 분석해 공격자가 어떤 데이터에 접근했는지, 어떤 정보가 유출되었는지를 신속히 파악하고 대응하는 것이 핵심이다. 만약 조직 내부에서 DB 클라이언트 도구의 사용이 필요하지 않은 환경이라면, EDR 등 행위 기반 보안 솔루션을 활용하여 해당 도구의 생성 및 실행 이력을 탐지하는 것이 필요하다. 또한, 인프라 내 DB 로그를 주기적으로 점검하여 DB 및 테이블 백업 이력이 있는지 확인하는 것도 효과적인 탐지 방법 중 하나이다.

 

더불어, DBMS가 제공하는 접근 제어 기능을 적극 활용하는 것도 중요하다. 데이터베이스 계정은 사용자별로 필요한 권한만 최소한으로 부여하고, 특정 관리자 IP에서만 접속 가능하도록 제한해야 한다.

 

마지막으로, DB 접속 계정 정보(자격증명)를 이메일로 공유하거나, 엑셀 또는 텍스트 파일에 저장하는 행위는 공격자에게 쉽게 탈취당할 수 있으므로 엄격히 금지해야 한다. 이러한 취약한 관리 방식은 대량의 정보 유출로 이어질 수 있으므로, 초기부터 철저히 예방하는 것이 중요하다.