공격자는 AWS SSM 에이전트를 원격 액세스 트로이 목마로 전환할 수 있습니다.

Feb 16, 2024

Mitiga 연구진은 공격자가 AWS Elastic Compute Cloud(EC2) 인스턴스(가상 서버)는 물론 비 EC2 시스템(예: 온프레미스 엔터프라이즈 서버 및 가상 서버)에 대한 지속적인 원격 액세스를 얻는 데 사용할 수 있는 새로운 공격 후 기술을 문서화했습니다. 머신 및 다른 클라우드 환경의 VM).

이 "토지 생활" 기술의 성공 여부는 다음에 달려 있습니다.

“SSM 에이전트를 제어한 후 공격자는 데이터 절도, 파일 시스템 암호화(랜섬웨어), 암호화폐 채굴을 위한 엔드포인트 리소스 오용, 네트워크 내의 다른 엔드포인트로 전파 시도 등의 악의적인 활동을 모두 위장하여 수행할 수 있습니다. Mitiga 연구원인 Ariel Szarf와 Or Aspir는 합법적인 소프트웨어인 SSM Agent를 사용하는 것이 중요하다고 설명했습니다.

연구원들은 두 가지 다른 시나리오를 시도했으며 두 가지 모두에 필요한 액세스 수준이 높습니다. 첫 번째 시나리오에서 위협 행위자는 대상 Linux 시스템에 대한 루트 액세스 또는 대상 Windows 시스템에 대한 관리자 권한을 요구하는 반면, 두 번째 시나리오에서는 대상 Linux 시스템에서 루트가 아닌 권한이 있는 사용자 또는 관리자로 실행할 수 있어야 합니다. 대상 Windows 시스템.

“[첫 번째 시나리오에서] 공격은 다른 AWS 계정과 함께 '하이브리드' 모드에서 작동하도록 SSM 에이전트를 등록하여 원래 SSM 에이전트 프로세스를 '하이재킹'하고 ID 소비를 위해 메타데이터 서버를 선택하지 않도록 강제합니다. 그런 다음 SSM 에이전트는 공격자가 소유한 AWS 계정으로 명령을 전달하고 실행합니다.”라고 설명했습니다.

두 번째 시나리오에서 공격자는 Linux 네임스페이스를 사용하거나 Windows에서 특정 환경 변수를 설정하여 또 다른 SSM 에이전트 프로세스를 실행합니다. “악성 에이전트 프로세스는 공격자의 AWS 계정과 통신하므로 원래 SSM 에이전트는 원래 AWS 계정과 계속 통신하게 됩니다.”

그리고 위협 행위자가 AWS 계정을 사용하여 에이전트를 관리하는 것을 선호하지 않는 경우에는 그렇게 할 필요가 없습니다. SSM 트래픽을 공격자가 제어하는 ​​서버(예: AWS 서버를 통하지 않고)로 라우팅하는 데 악용될 수 있는 SSM 기능이 있습니다. ).

SSM 에이전트를 원격 액세스 트로이 목마로 전환하면 공격자가 설치된 보안 솔루션에 발각되지 않고 엔드포인트를 손상시킬 수 있습니다. C&C 통신은 합법적인 것처럼 보이며 별도의 공격 인프라를 개발할 필요가 없으며 SSM 에이전트를 사용하여 지원되는 기능을 통해 엔드포인트를 조작할 수 있습니다.

SSM 에이전트가 일부 인기 있는 Amazon 머신 이미지에 사전 설치되어 이미 많은 기존 EC2 인스턴스에 설치 및 실행되고 있다는 사실은 적의 잠재적 표적 풀을 넓힌다고 연구원들은 지적했습니다.

다행히도 이 기술의 사용을 감지할 수 있는 방법이 있습니다. 여기에는 새로운 인스턴스 ID, 특정 명령의 사용, AWS 계정의 SSM 에이전트에 대한 연결 끊김, 새로운 프로세스 및 Sessions Manager와 관련된 의심스러운 작업을 감시하는 방법이 포함됩니다. Amazon CloudTrail 로그에 있습니다.

연구원들은 기업 시스템 관리자에게 다음을 권고합니다.

“우리는 위협 행위자들이 아직 그렇게 하지 않는다면 실제 공격에서 이를 악용할 것이라고 굳게 믿습니다. 그렇기 때문에 진화하는 위협으로부터 시스템을 보호하려면 오용과 관련된 위험을 이해하고 완화하는 것이 중요합니다.”라고 지적하며 AWS 보안 팀은 원래 AWS로부터 명령 수신을 제한하는 솔루션도 제공했다고 지적했습니다. Systems Manager용 Virtual Private Cloud(VPC) 엔드포인트를 사용하는 계정/조직.

“EC2 인스턴스가 퍼블릭 EIP 주소나 NAT 게이트웨이를 통해 퍼블릭 네트워크에 액세스하지 않고 프라이빗 서브넷에 있는 경우에도 VPC 엔드포인트를 통해 System Manager 서비스를 구성할 수 있습니다. 이렇게 하면 EC2 인스턴스가 원래 AWS 계정 또는 조직 내의 보안 주체에서 발생하는 명령에만 응답하도록 할 수 있습니다. 이 제한 사항을 효과적으로 구현하려면 VPC 엔드포인트 정책 문서를 참조하세요.