개발자 도구 · Base64 인코더 및 디코더
의심스러운 Base64 PowerShell 명령을 실행하지 않고 디코딩하는 방법
· 그것이 중요한 이유
베이스64 보안
공격자는 Base64를 사용하여 일반 검사로부터 스크립트를 숨깁니다. 이 게시물에서는 -EncodedCommand 페이로드를 실행하지 않고 디코딩하는 방법, UTF-8 디코더에서 출력이 이상하게 보일 수 있는 이유 및 찾아야 할 사항을 보여줍니다.
2,000 문자 인수가 있는 예약된 작업 — 인코딩된 명령이 나타나는 위치와 이것이 위험 신호인 이유
시스템 관리자는 의심스러워 보이는 2,000 문자 -EncodedCommand 인수가 포함된 예약된 작업을 발견했습니다. 작업은 높은 권한을 가진 서비스 계정으로 실행됩니다.
명령을 PowerShell에 붙여넣고 실행하여 그 기능을 확인하려는 유혹은 위험합니다. 명령이 악의적인 경우 이를 실행하면 시스템이 손상됩니다. 더 안전한 접근 방식은 Base64를 로컬로 디코딩하고 실행 여부를 결정하기 전에 출력을 텍스트로 읽는 것입니다. 이 게시물에서는 PowerShell 명령을 실행하지 않고 안전하게 디코딩하는 방법, 표준 UTF-8 디코더에서 출력이 왜곡되어 보일 수 있는 이유, 명령이 안전한지 의심스러운지 평가하기 위해 찾아야 할 사항에 대해 설명합니다.
디코드하고 실행하지 않음 — 분석을 안전하게 유지하는 규칙과 브라우저 전용 디코더가 적합한 이유
중요한 통찰력은 PowerShell이 UTF-8이 아닌 -EncodedCommand에 대해 UTF-16LE 인코딩을 사용하므로 다른 모든 바이트는 표준 도구가 null 종결자로 해석하는 0이라는 것입니다. 의심스러운 코드를 분석하는 규칙은 간단합니다. 즉, 디코딩하고 실행하지 마십시오. 이는 Base64로 인코딩된 명령, 압축 스크립트, 신뢰할 수 없는 소스의 스크립트 및 익숙하지 않은 인코딩 체인에 있는 모든 것에 적용됩니다. 스크립트를 실행하면 돌아올 수 없습니다. 일단 실행되면 시스템이 변경되고 액세스 권한이 부여되며 데이터가 유출됩니다.
스크립트를 텍스트로 디코딩하고 읽으면 되돌릴 수 없는 단계 전에 스크립트를 평가할 수 있습니다. 두 번째 규칙은 로컬로 실행되고 네트워크 요청을 하지 않는 도구를 사용하는 것입니다. 브라우저 기반 디코더는 휴대가 가능하고 추가 소프트웨어가 필요하지 않으며 의심스러운 페이로드를 서버에 업로드하지 않고도 장치에 보관할 수 있다는 점에서 이상적입니다. 도구가 원격 디코더 서비스에 게시되는 종류인 경우에는 사용하지 마십시오. 그러면 페이로드가 해당 서비스에 노출됩니다. PowerShell -EncodedCommand 매개 변수는 디코딩 시 PowerShell 스크립트가 포함된 Base64 문자열을 허용합니다.
디코딩된 바이트가 UTF-8 텍스트와 다르게 보이는 이유 — 이 UTF-8 텍스트 도구에 해석을 요청하는 대신 16진수로 된 UTF-16LE 바이트 패턴을 검사하십시오.
그러나 PowerShell은 이에 대해 UTF-8 인코딩을 사용하지 않습니다. UTF-16LE(리틀 엔디안 UTF-16)를 사용합니다. UTF-16에서 모든 ASCII 문자는 2바이트로 표시됩니다. 즉, 문자 코드 뒤에 0바이트가 옵니다. 문자 A는 16진수로 41 00입니다. 문자 B는 42 00입니다. Hello와 같은 문자열은 UTF-16LE 바이트에서 48 00 65 00 6C 00 6C 00 6F 00로 표시됩니다. Base64로 인코딩된 경우 결과에는 모든 0을 포함하여 모든 바이트의 인코딩된 형식이 포함됩니다. 표준 UTF-8 디코더를 사용하여 디코딩하면 잘못된 텍스트가 생성되거나 UTF-8가 null 바이트를 문자열 종결자로 처리하기 때문에 첫 번째 0바이트가 잘립니다.
출력은 Hello 대신 H e l o처럼 보이며 임의의 문자가 있거나 텍스트가 누락된 것 같습니다. 실제 사례는 문제와 해결책을 보여줍니다. PowerShell 명령이 간단한 문자열 Write-Host Hello를 인코딩한다고 가정합니다. PowerShell UTF-16LE는 이를 모든 0을 포함하는 바이트로 인코딩하고, Base64는 바이트를 인코딩하여 VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA와 같은 긴 문자열을 생성합니다. 이 문자열을 브라우저의 Base64 인코더 및 디코더에 복사하고 디코드를 클릭하세요. 기본 디코더는 결과를 UTF-8 텍스트로 해석하려고 시도하고 포함된 0으로 인해 손상되거나 잘린 출력을 생성합니다.
작업된 예: 무해한 샘플 인코딩 명령 디코딩 — 인터리브된 0바이트 이후의 텍스트 읽기
해결책은 대신 16진수 보기를 사용하는 것입니다. 16진수 보기로 전환하면 바이트가 표시됩니다. 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00. 해당 바이트를 UTF-16LE 쌍으로 읽으면 W-r-i-t-e---K-o-s-h---H-e-l-l-o-가 생성됩니다. 경험이 있으면 UTF-16LE 16진수를 직접 읽거나 파일에 바이트를 쓰고 로컬에서 실행되는 PowerShell 또는 Python 스크립트를 사용하여 디코딩할 수 있습니다.
실용적인 접근 방식은 패턴을 기록하고 PowerShell이 UTF-16LE를 사용한다는 점을 기억하는 것입니다. 브라우저에서 PowerShell -EncodedCommand를 디코딩했는데 출력이 잘못된 것처럼 보이는 경우 텍스트 보기 대신 16진수 보기를 살펴보세요. 16진수 보기에는 각 바이트가 개별적으로 표시됩니다. 모든 ASCII 문자는 사이에 0이 있는 2바이트로 나타납니다. 바이트가 New-AdminAccount, 역DNS 조회 또는 보안 자격 증명 내보내기와 같은 악성 명령을 설명하는 경우 해당 명령은 의심스럽습니다. 바이트가 디렉토리 목록이나 간단한 스크립트와 같이 무해한 내용을 설명하는 경우 해당 명령은 문제가 없을 가능성이 높습니다.
중첩된 인코딩 및 압축 — Base64 내부의 Base64 및 텍스트로 읽을 수 없는 gzip 스트림
16진수 보기는 일반 텍스트보다 읽기 어렵지만 손상된 UTF-8 출력에서 추측하는 것보다 안전합니다. 중첩된 인코딩 및 압축은 악성코드 분석을 더욱 복잡하게 만듭니다. PowerShell 명령은 다른 Base64 문자열을 Base64로 인코딩하거나 gzip으로 스크립트를 압축한 다음 결과를 Base64로 인코딩할 수 있습니다. 중첩된 시나리오에서는 외부 Base64를 디코딩하고 결과를 읽고 그 자체가 base64임을 발견합니다. 그것도 해독하고 읽을 수 있는 텍스트나 해석할 수 없는 바이너리 형식을 찾을 때까지 계속하세요. Gzip 및 기타 압축 형식은 16진수 보기에 표시되는 매직 바이트(gzip의 경우 1F 8B)로 시작됩니다.
Base64를 디코딩하고 16진수 보기가 1F 8B로 시작하는 경우 바이트는 압축 해제가 필요한 압축 스트림입니다. Base64 인코더 및 디코더는 16진수를 표시하므로 아무것도 실행하지 않고도 이러한 패턴을 식별할 수 있습니다. 압축되거나 추가로 인코딩된 페이로드는 난독화 레이어를 추가하므로 의심스럽습니다.
사고 보고서에 기록할 내용 — 페이로드 자체가 아닌 디코딩된 텍스트, 소스 및 해시
합법적인 명령에는 여러 인코딩 단계가 필요한 경우가 거의 없습니다. 사고 보고서를 위한 결과 기록에는 규율과 정확성이 필요합니다. 분석한 정확한 Base64 문자열, 어디서 발견했는지, 언제 발견했는지 기록해 보세요. 디코딩하여 의심스러운 명령을 발견한 경우 명령을 설명하되 아직 보고서에 전체 스크립트를 포함하지 마십시오. 스크립트가 복잡하거나 길 수도 있습니다.
결과를 확인하고 추적할 수 있도록 디코딩된 스크립트의 해시(SHA-256)를 포함합니다. 명령이 명백히 악의적이거나 알려진 악용 기술을 사용하는 경우 조치를 취하기 전에 사고 대응 및 보안 팀을 참여시키십시오. 명령이 수행하는 작업을 확인하기 위해 직접 명령을 실행하지 마십시오. 사고 대응자가 테스트를 위해 이를 실행해야 하는 경우 손상이 포함된 샌드박스 환경에서 수행합니다. 당신의 임무는 안전한 거리에서 위험을 해독하고 평가하는 것입니다. 이 문서에서는 맬웨어 분석, 샌드박스 환경 또는 공격 속성의 전체 범위를 다루지 않습니다.
여기서 다루지 않는 내용 — 샌드박스 실행, 맬웨어 분석 도구 및 속성
이는 보안 전문가 및 사고 대응 팀을 위한 주제입니다. 여기서 범위는 인코딩된 PowerShell 명령을 실행하지 않고 안전하게 디코딩하는 데 좁게 초점을 맞추고 있으므로 스크립트를 읽고 추가로 조사할 가치가 있는지 평가할 수 있습니다. Base64 인코딩은 보호가 아닌 난독화입니다. 인코딩과 디코더가 있는 사람은 누구나 스크립트를 추출할 수 있습니다. 공격자는 Base64를 사용하여 분석에서 의도를 숨기는 것이 아니라 기본적인 탐지를 회피하고 우연한 검사를 방지합니다. 원격 스크립트를 가져와 실행하는 디코딩된 PowerShell 명령은 사용자가 직접 디코딩하든 보안 도구를 사용하든 악성입니다.
의심스러운 명령을 해독한 후 실질적인 다음 단계는 해당 팀에 이를 보고하는 것입니다. 자체 시스템인 경우 해당 작업이 의도적으로 생성되었는지, 누구에 의해 생성되었는지 확인하세요. 생성 날짜와 이를 예약한 계정을 확인하세요. 작업이 승인되지 않은 경우 해당 작업을 비활성화하고 포렌식을 위한 세부 정보를 보존하고 공격자가 어떻게 작업을 생성할 수 있는 권한을 얻었는지 조사하세요. 명령에 네트워크 요청이나 레지스트리 변경, 예약된 작업 생성과 같은 지속성 메커니즘이 포함되어 있다면 이는 거의 악성일 가능성이 높습니다.
요약: Base64는 보호가 아닌 난독화입니다. Base64 인코더 및 디코더가 페이로드가 시스템을 떠나지 않고도 로컬로 디코딩하는 방법입니다.
합법적인 관리 기능을 수행하고 생성 세부 사항이 정상이라면 보안 정책이나 더 큰 자동화 도구와의 통합과 관련된 이유로 우연히 인코딩되는 합법적인 관리 스크립트일 수 있습니다. 어느 쪽이든 실행하지 마십시오. 디코딩된 텍스트에 대한 평가를 통해 결정을 내리세요. 의심스러운 Base64 PowerShell 명령을 안전하게 디코딩하는 과정은 간단합니다. Base64 인코더 및 디코더를 사용하면 문자열을 업로드하거나 실행하지 않고도 문자열을 디코딩할 수 있습니다. 바이트가 무엇을 나타내는지 이해하려면 16진수 보기를 살펴보세요.
UTF-16LE 패턴(인터리브된 0바이트)이 표시되면 PowerShell이 UTF-16LE를 사용한다는 점을 기억하고 그에 따라 읽어보세요. 네트워크 요청, 권한 상승 또는 지속성 메커니즘과 같은 의심스러운 패턴을 식별하십시오. 원본 Base64 문자열 및 해당 해시를 포함하여 사건 보고서에 대한 세부 정보를 정확하게 기록하십시오. 명령을 직접 실행하지 마십시오. 통제된 환경에서 사고 대응 담당자에게 맡기십시오. 로컬 디코딩과 일반 텍스트 평가를 신뢰하고 이를 바탕으로 다음 조치를 취하세요.