4. Golden SAML 사용

특히 본 프로젝트에서 핵심이 되는 Golden SAML의 경우 공격인지 정상행위인지 판별할 수 있는 방법은 정상적으로 AD FS에 SAML 인증 과정을 거쳐 legitimate authentication를 수행할 때 로그와 위조한 SAML을 사용해 authentication한 경우를 비교해보면 된다.

Golden SAML 인증을 탐지하기 위해서는 단순하게 Service Provider에서 SAML SSO를 사용하는 모든 로그인 중 도메인에서 4769, 1200, 1202 이벤트와 일치하지 않는 로그인을 탐색하는 수밖에 없다. (Sygnia)

쉽게 말하자면 정상 로그인에서는 저 3개가 하나의 chunk인데 위조된 로그인에서는 1, 2 없이 3만 갑자기 등장하게 되는 것이다. 즉, 로그가 나타나는 흐름과 로그 간 연결성을 파악하는 것이 핵심이다.

	Legitimate Auth	Forged Auth
AD DS	Event ID 4769, 4768	X (단, 공격자가 임의로 남길 수는 있음)
AD FS	Event ID 1202, 1200	X (임의로 남길 수 없음)
AWS	[e-mail] 활용 Log	[e-mail] 활용 Log

4.1. AD DS

• AccountLogon – Kerberos Service Ticket Operations: success and failure on the Domain Controllers for event id 4769. ✅ + 4768 ✅

⇒ 두 Event Log 안 Account Name에 [e-mail] 값 확인

4.2. AD FS

• Event id 1202 – “The Federation Service validated a new credential”. ✅

• Event id 1200 – “The Federation Service issued a valid token”. ✅

⇒ 두 Event Log 안 <UserId> 태그 AD-WAFFLE\aws.admin 값 확인

특히 공격자가 임의로 DS에 Kerberos Request (event ID 4769)를 남길 수는 있지만, ADFS에는 임의로 생성할 수 없다.

4.3. AWS

• Sygnia에서는 ConsoleLogin 또는 AssumeRoleWithSAML 로그를 언급했지만, 실제로 Cloudtrail에서는 관찰되지 않았다.
• 다만 [e-mail] 로 접속하는 경우 뭘 하든 로그가 다 찍히고 있긴 하다. 다시말해 만약 ADFS랑 DC에 해당 [e-mail]를 활용한 흔적이 없고 AWS에만 로그가 나타나는 경우 Golden SAML 공격을 시도한 것이라 판단할 수 있다.

• 이러한 로직은 Deception 시스템 뿐만 아니라 Golden SAML 공격이라면 적용되는 flow이다. 다만 많은 Test case를 거치지 않았기 때문에 정상 로그인을 허위로 잡을 수도 있어, 추가 확인이 필요하다.