피싱 조사
이 문서에서는 조직 내에서 피싱 공격을 식별하고 조사하는 방법에 대한 지침을 제공합니다. 단계별 지침은 정보를 보호하고 추가 위험을 최소화하는 데 필요한 수정 작업을 수행하는 데 도움이 됩니다.
이 문서에는 다음과 같은 섹션이 포함되어 있습니다.
- 필수 구성 요소: 조사를 시작하기 전에 완료해야 하는 특정 요구 사항을 다룹니다. 예를 들어 설정해야 하는 로깅, 역할 및 사용 권한이 필요합니다.
- 워크플로: 이 조사를 수행하기 위해 따라야 하는 논리적 흐름을 표시합니다.
- 검사 목록: 흐름도의 각 단계에 대한 작업 목록을 포함합니다. 이 검사 목록은 고도로 규제된 환경에서 완료된 항목을 확인하거나 자신을 위한 품질 게이트로 유용할 수 있습니다.
- 조사 단계: 이 특정 조사에 대한 자세한 단계별 지침을 포함합니다.
필수 조건
다음은 피싱 조사를 진행하기 전에 완료해야 하는 일반 설정 및 구성입니다.
계정 세부 정보
조사를 진행하기 전에 사용자 이름, UPN(사용자 계정 이름) 또는 손상된 것으로 의심되는 계정의 이메일 주소가 있어야 합니다.
Microsoft 365 기본 요구 사항
감사 설정 확인
Exchange Online PowerShell에서 다음 명령을 실행하여 기본적으로 사서함 감사가 켜져 있는지 확인합니다.
Get-OrganizationConfig | Format-List AuditDisabled
False 값은 개별 사서함의 AuditEnabled 속성 값에 관계없이 조직의 모든 사서함에 대해 사서함 감사가 사용하도록 설정되어 있음을 나타냅니다. 자세한 내용은 기본적으로 사서함 감사가 켜져 있는지 확인하세요.
메시지 추적
메시지 추적 로그는 메시지의 원래 원본과 의도한 받는 사람을 찾는 데 도움이 되는 귀중한 구성 요소입니다. Exchange Online PowerShell의 Get-MessageTrace cmdlet 또는 EAC(Exchange 관리 센터)에서 https://admin.exchange.microsoft.com/#/messagetrace 메시지 추적 기능을 사용할 수 있습니다.
참고 항목
메시지 추적은 전자 메일 및 공동 작업>Exchange 메시지 추적 아래의 Microsoft Defender 포털에서도 https://security.microsoft.com 사용할 수 있지만 EAC의 메시지 추적에 대한 통과 링크일 뿐입니다.
메시지 추적 기능의 몇 가지 구성 요소는 설명이 필요하지만 Message-ID는 전자 메일 메시지의 고유 식별자이며 철저한 이해가 필요합니다. 관심 있는 전자 메일의 메시지 ID 를 가져오려면 원시 전자 메일 헤더를 검사해야 합니다.
감사 로그 검색
통합 감사 로그를 검색하여 Microsoft 365 조직의 사용자 및 관리자의 모든 활동을 확인합니다.
로그인 로그 및/또는 감사 로그가 외부 시스템으로 내보내지나요?
대부분의 Microsoft Entra ID 로그인 및 감사 데이터는 30일 또는 90일 후에 덮어쓰기되므로 Microsoft Sentinel, Azure Monitor 또는 SIEM(외부 보안 정보 및 이벤트 관리) 시스템을 사용하는 것이 좋습니다.
역할 및 권한이 필요합니다.
Microsoft Entra ID 내 사용 권한
조사를 수행하는 계정은 보안 읽기 권한자 이상인 것이 좋습니다.
Microsoft 365의 권한
Microsoft Defender 포털 또는 Microsoft Purview 규정 준수 포털 보안 읽기 권한자 역할은 관련 로그를 검색할 수 있는 충분한 권한을 부여해야 합니다.
사용할 역할에 대해 잘 모르는 경우 Exchange cmdlet을 실행하는 데 필요한 권한 찾기를 참조하세요.
엔드포인트에 대한 Microsoft Defender
MDE(엔드포인트용 Microsoft Defender)가 있는 경우 이 흐름에 사용해야 합니다. 자세한 내용은 신호 공유 및 기계 학습을 사용하여 피싱을 처리하는 것을 참조 하세요.
시스템 요구 사항
하드웨어 요구 사항
시스템에서 PowerShell을 실행할 수 있어야 합니다.
소프트웨어 요구 사항
클라우드 환경을 조사하는 데 필요한 PowerShell 모듈은 다음과 같습니다.
Graph용 Azure AD PowerShell 모듈. 설치 지침은 Graph용 Azure Active Directory PowerShell 설치를 참조 하세요.
MSOnline(v1) Azure AD 모듈에 이전 cmdlet이 필요한 경우 Microsoft Entra ID(MSOnline)를 참조하세요.
Exchange Online PowerShell 모듈: 설치 지침은 Exchange Online PowerShell 모듈 설치 및 유지 관리를 참조 하세요.
Microsoft Entra 인시던트 대응 PowerShell 모듈: 설치 지침은 Microsoft Entra 인시던트 대응 PowerShell 모듈을 참조 하세요.
워크플로
다음도 가능합니다.
검사 목록
이 검사 목록은 조사 프로세스를 평가하고 조사 중에 단계가 완료되었는지 확인하는 데 도움이 됩니다.
| 초기 피싱 이메일 검토 | |
| 이 전자 메일을 받은 사용자 목록 가져오기 | |
| 사용자가 사서함에 액세스했던 최신 날짜 가져오기 | |
| 위임된 액세스가 사서함에 구성되어 있는가? | |
| 사서함에 전달 규칙이 구성되어 있나요? | |
| Exchange 메일 흐름 규칙 검토(전송 규칙) | |
| 전자 메일 메시지 찾기 | |
| 사용자가 전자 메일을 읽거나 열었나요? | |
| 누가 같은 이메일을 받았습니까? | |
| 이메일에 첨부 파일이 포함되어 있는가? | |
| 첨부 파일에 페이로드가 있었나요? | |
| 보낸 사람의 실제 원본에 대한 전자 메일 헤더 확인 | |
| 공격자/캠페인에 대한 IP 주소 확인 | |
| 사용자가 전자 메일에서 링크를 선택했나요? | |
| 전자 메일이 열린 엔드포인트는 무엇인가요? | |
| 첨부 파일 페이로드가 실행되었나요? | |
| 대상 IP 또는 URL이 터치되었거나 열렸나요? | |
| 악성 코드가 실행되었나요? | |
| 페더레이션 시나리오에 대한 계정으로 발생한 로그인은 무엇인가요? | |
| 관리되는 시나리오에 대한 계정으로 발생한 로그인은 무엇인가요? | |
| 원본 IP 주소 조사 | |
| 발견된 디바이스 ID 조사 | |
| 각 앱 ID 조사 |
피싱 및 기타 인시던트 플레이북 검사 목록을 Excel 파일로 다운로드할 수도 있습니다.
조사 단계
이 조사를 위해 샘플 피싱 전자 메일 또는 전자 메일의 일부가 있습니다. 예를 들어 보낸 사람의 주소, 전자 메일의 제목 또는 조사를 시작할 메시지의 일부가 있을 수 있습니다. 또한 필수 구성 요소 섹션에서 권장 하는 대로 모든 설정을 완료하고 사용하도록 설정했는지 확인합니다 .
전자 메일을 받은 사용자/ID 목록을 가져옵니다.
첫 번째 단계로 피싱 이메일을 받은 사용자/ID 목록을 가져와야 합니다. 이 단계의 목적은 나중에 더 많은 조사 단계를 반복하는 데 사용할 잠재적인 사용자/ID 목록을 기록하는 것입니다. 이 조사 중에 수행해야 하는 단계의 개략적인 흐름 다이어그램은 워크플로 섹션을 참조하세요.
이 플레이북에서는 잠재적인 사용자/ID 목록을 기록하려는 방법에 대한 권장 사항을 제공하지 않습니다. 조사 크기에 따라 Excel 책, CSV 파일 또는 데이터베이스를 사용하여 더 큰 조사를 수행할 수 있습니다. 지정된 테넌트에서 ID 목록을 가져오는 방법에는 여러 가지가 있으며, 다음은 몇 가지 예입니다.
Microsoft Purview 규정 준수 포털 콘텐츠 검색 만들기
표시기를 사용하여 콘텐츠 검색을 만들고 실행합니다. 지침은 콘텐츠 검색 만들기를 참조하세요.
검색 가능한 전자 메일 속성의 전체 목록은 검색 가능한 전자 메일 속성을 참조 하세요.
다음 예제에서는 2022년 4월 13일부터 2022년 4월 14일 사이에 사용자가 수신했으며 제목 줄에 "action"과 "required"라는 단어가 포함된 메시지를 반환합니다.
(Received:4/13/2022..4/14/2022) AND (Subject:'Action required')
다음 예제 쿼리는 보낸 chatsuwloginsset12345@outlook.com 메시지를 반환하고 제목 줄에 "계정 정보 업데이트"라는 정확한 구를 포함합니다.
(From:chatsuwloginsset12345@outlook.com) AND (Subject:"Update your account information")
자세한 내용은 조직에서 메시지를 검색하고 삭제하는 방법을 참조하세요.
Exchange Online PowerShell에서 Search-Mailbox cmdlet 사용
Exchange Online PowerShell의 Search-Mailbox cmdlet을 사용하여 관심 있는 대상 사서함에 대해 특정 쿼리를 수행하고 관련 없는 대상 사서함에 결과를 복사할 수도 있습니다.
다음 예제 쿼리는 Jane Smith 사서함에서 제목에 청구서라는 문구가 포함된 전자 메일을 검색하고 결과를 "조사"라는 폴더의 IRMailbox에 복사합니다.
Search-Mailbox -Identity "Jane Smith" -SearchQuery "Subject:Invoice" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" LogLevel Full
이 예제 명령에서 쿼리는 제목에 "InvoiceUrgent"라는 문구가 포함된 전자 메일의 모든 테넌트 사서함을 검색하고 결과를 "Investigation"라는 폴더의 IRMailbox에 복사합니다.
Get-Mailbox | Search-Mailbox -SearchQuery 'InvoiceUrgent vote' -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full
자세한 구문 및 매개 변수 정보는 Search-Mailbox를 참조 하세요.
위임된 액세스가 사서함에 구성되어 있는가?
다음 스크립트를 사용하여 위임된 액세스가 사서함 https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/DumpDelegatesandForwardingRules.ps1에 구성되어 있는지 확인합니다.
이 보고서를 만들려면 모든 사용자 목록을 가져오는 작은 PowerShell 스크립트를 실행합니다. 그런 다음 Get-MailboxPermission cmdlet을 사용하여 테넌트에서 모든 사서함 대리자의 CSV 파일을 만듭니다.
특이한 이름이나 권한 부여를 찾습니다. 비정상적인 항목이 표시되면 사서함 소유자에게 문의하여 합법적인지 확인합니다.
사서함에 대해 전달 규칙이 구성되어 있나요?
식별된 각 사서함에서 사서함 전달(SMTP( 단순 메일 전송 프로토콜) 또는 전자 메일 메시지를 외부 받는 사람에게 전달하는 받은 편지함 규칙(일반적으로 새로 만든 받은 편지함 규칙)을 확인해야 합니다.
사서함 전달에 대한 모든 사서함을 확인하려면 Exchange Online PowerShell에서 다음 명령을 실행합니다.
Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited | Format-Table -Auto MicrosoftOnlineServicesID,ForwardingSmtpAddress,DeliverToMailboxAndForward | Export-csv C:\Temp\Forwarding.csv -NoTypeInformation지정된 날짜 사이에 사서함에 만들어진 받은 편지함 규칙을 확인하려면 Exchange Online PowerShell에서 다음 명령을 실행합니다.
Search-UnifiedAuditLog -StartDate 12/16/2021 -EndDate 03/16/2022 -ResultSize 5000 -RecordType exchangeadmin -Operations New-InboxRule | Export-csv NoTypeInformation -Path c:\temp\Inboxrulesoutput.csvEAC(Exchange 관리 센터)에서 자동 전달 메시지 보고서를 사용할 수도 있습니다. 자세한 내용은 Exchange Online의 자동 전달 메시지 보고서를 참조하세요.
참고:
- 비정상적인 대상 위치 또는 모든 종류의 외부 주소 지정을 찾습니다.
- 제목에 청구서라는 단어가 있는 모든 메일과 같이 조건에 비정상적인 키워드가 있는 전달 규칙을 찾습니다. 사서함 소유자에게 문의하여 합법적인지 확인합니다.
받은 편지함 규칙 검토
조사와 근접한 타임스탬프를 고려하여 받은 편지함 규칙의 제거를 확인합니다. 예를 들어 Exchange Online PowerShell에서 다음 명령을 사용합니다.
Search-UnifiedAuditLog -StartDate 12/16/2021 -EndDate 03/16/2022 -Operations Remove-InboxRule | Export-CSV NoTypeInformation -Path c:\temp\removedInboxRules.csv
Exchange 메일 흐름 규칙 검토(전송 규칙)
조직에서 Exchange 메일 흐름 규칙(전송 규칙이라고도 함) 목록을 가져오는 방법에는 두 가지가 있습니다.
- Exchange 관리 센터 또는 Exchange Online PowerShell에서 지침은 메일 흐름 규칙 보기 또는 수정을 참조하세요.
- Exchange 관리 센터의 Exchange 전송 규칙 보고서입니다. 자세한 내용은 Exchange Online의 Exchange 전송 규칙 보고서를 참조하세요.
새 규칙을 찾거나 수정된 규칙을 찾아 메일을 외부 도메인으로 리디렉션합니다. 규칙 수는 알고 있어야 하며 상대적으로 작아야 합니다. 감사 로그 검색을 수행하여 규칙을 만든 사용자와 규칙을 만든 위치를 확인할 수 있습니다. 비정상적인 항목이 표시되면 작성자에 문의하여 합법적인지 확인합니다.
사용자가 사서함에 액세스했던 최신 날짜 가져오기
Microsoft Defender 포털 또는 Microsoft Purview 규정 준수 포털 통합 감사 로그로 이동합니다. 드롭다운 목록의 활동 아래에서 Exchange 사서함 활동별로 필터링할 수 있습니다.
손상된 사용자를 나열하는 기능은 Microsoft Defender 포털에서 사용할 수 있습니다.
이 보고서는 사서함이 불법적으로 액세스되고 있음을 나타낼 수 있는 활동을 보여줍니다. 여기에는 생성되거나 받은 메시지, 이동 또는 삭제된 메시지, 복사 또는 제거된 메시지, 대신 보내기 또는 다른 이름으로 보내기를 사용하여 보낸 메시지 및 모든 사서함 로그인이 포함됩니다. 데이터에는 날짜, IP 주소, 사용자, 수행된 활동, 영향을 받는 항목 및 확장된 세부 정보가 포함됩니다.
참고 항목
이 데이터를 기록하려면 사서함 감사 옵션을 사용하도록 설정해야 합니다.
여기에 포함된 데이터의 양이 상당할 수 있으므로 위반될 경우 큰 영향을 미칠 수 있는 사용자에 대한 검색에 집중합니다. 하루 중 홀수 시간 또는 비정상적인 IP 주소와 같은 비정상적인 패턴을 찾고 많은 양의 이동, 제거 또는 삭제와 같은 패턴을 찾습니다.
사용자가 이메일을 읽거나 열었는가?
여기에는 두 가지 주요 사례가 있습니다.
- 사서함이 Exchange Online에 있습니다.
- 사서함은 온-프레미스 Exchange(Exchange 하이브리드)에 있습니다.
Exchange Online 사용자가 전자 메일을 열나요?
Exchange Online PowerShell의 Search-Mailbox cmdlet을 사용하여 관심 있는 대상 사서함에 대해 특정 검색 쿼리를 수행하고 관련 없는 대상 사서함에 결과를 복사합니다.
다음 예제 쿼리는 Janes Smith의 사서함에서 제목에 청구서라는 문구가 포함된 전자 메일을 검색하고 조사라는 폴더의 IRMailbox에 결과를 복사합니다.
Search-Mailbox -Identity "Jane Smith" -SearchQuery "Subject:Invoice" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" LogLevel Full
다음 샘플 쿼리는 제목에 InvoiceUrgent라는 문구가 포함된 전자 메일의 모든 테넌트 사서함을 검색하고 조사라는 폴더의 IRMailbox에 결과를 복사합니다.
Get-Mailbox | Search-Mailbox -SearchQuery 'InvoiceUrgent vote' -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full
사용자가 Exchange 하이브리드에서 전자 메일을 열나요?
Get-MessageTrackingLog cmdlet을 사용하여 메시지 추적 로그에 저장된 메시지 배달 정보를 검색합니다. 예를 들어 다음과 같습니다.
Get-MessageTrackingLog -Server Mailbox01 -Start "03/13/2022 09:00:00" -End "03/15/2022 17:00:00" -Sender "john@contoso.com"
자세한 구문 및 매개 변수 정보는 Get-MessageTrackingLog를 참조 하세요.
누가 같은 이메일을 받았습니까?
여기에는 두 가지 주요 사례가 있습니다.
- 사서함이 Exchange Online에 있습니다.
- 사서함은 온-프레미스 Exchange(Exchange 하이브리드)에 있습니다.
워크플로는 이 문서의 앞부분에서 전자 메일 섹션을 받은 사용자/ID의 목록 가져오기에 설명된 것과 기본적으로 동일합니다.
Exchange Online에서 전자 메일 찾기
Search-Mailbox cmdlet을 사용하여 관심 있는 대상 사서함에 대해 특정 검색 쿼리를 수행하고 관련 없는 대상 사서함에 결과를 복사합니다.
이 샘플 쿼리는 모든 테넌트 사서함에서 제목 InvoiceUrgent가 포함된 전자 메일을 검색하고 조사라는 폴더의 IRMailbox에 결과를 복사합니다.
Get-Mailbox | Search-Mailbox -SearchQuery "Subject:InvoiceUrgent" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full
온-프레미스 Exchange에서 전자 메일 찾기
Get-MessageTrackingLog cmdlet을 사용하여 메시지 추적 로그에 저장된 메시지 배달 정보를 검색합니다. 예를 들어 다음과 같습니다.
Get-MessageTrackingLog -Server Mailbox01 -Start "03/13/2018 09:00:00" -End "03/15/2018 17:00:00" -MessageSubject "InvoiceUrgent"
자세한 구문 및 매개 변수 정보는 Get-MessageTrackingLog를 참조 하세요.
이메일에 첨부 파일이 포함되어 있는가?
여기에는 두 가지 주요 사례가 있습니다.
- 사서함이 Exchange Online에 있습니다.
- 사서함은 온-프레미스 Exchange(Exchange 하이브리드)에 있습니다.
메시지에 Exchange Online에 첨부 파일이 포함되어 있는지 확인합니다.
사서함이 Exchange Online에 있는 경우 다음 두 가지 옵션이 있습니다.
- 클래식 Search-Mailbox cmdlet 사용
- New-ComplianceSearch cmdlet 사용
Search-Mailbox cmdlet을 사용하여 관심 있는 대상 사서함에 대해 특정 검색 쿼리를 수행하고 관련 없는 대상 사서함에 결과를 복사합니다. 예를 들어 다음과 같습니다.
Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery attachment:trojan* -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full
자세한 구문 및 매개 변수 정보는 Search-Mailbox를 참조 하세요.
다른 옵션은 New-ComplianceSearch cmdlet을 사용하는 것입니다. 예를 들어 다음과 같습니다.
New-ComplianceSearch -Name "Investigation" -ExchangeLocation "Research Department" -ContentMatchQuery "from:pilar@contoso.com AND hasattachment:true"
자세한 구문 및 매개 변수 정보는 New-ComplianceSearch를 참조하세요.
메시지에 온-프레미스 Exchange에 첨부 파일이 포함되어 있는지 확인합니다.
참고 항목
Exchange Server 2013에서 이 절차에는 CU12(누적 업데이트 12) 이상이 필요합니다. 자세한 내용은 문서를 참조하십시오.
Search-Mailbox cmdlet을 사용하여 메시지 추적 로그에 저장된 메시지 배달 정보를 검색합니다. 예를 들어 다음과 같습니다.
Search-Mailbox -Identity "Jane Smith"-SearchQuery AttachmentNames:attachment_name -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full
자세한 구문 및 매개 변수 정보는 Search-Mailbox를 참조 하세요.
첨부 파일에 페이로드가 있었나요?
첨부 파일에서 잠재적인 악성 콘텐츠를 찾습니다. 예를 들어 PDF 파일, 난독 제거된 PowerShell 또는 기타 스크립트 코드가 있습니다.
위협 방지 상태 보고서의 전자 메일 > 맬웨어별 데이터 보기에는 조직에 대한 맬웨어가 포함된 것으로 검색된 수신 및 발신 메시지 수가 표시됩니다. 자세한 내용은 위협 방지 상태 보고서: 전자 메일 > 맬웨어별 데이터 보기를 참조하세요.
보낸 사람의 실제 원본에 대한 전자 메일 헤더 확인
메시지 추적 기능의 많은 구성 요소는 설명이 필요하지만 메시지 ID에 대해 철저히 이해해야 합니다. Message-ID는 이메일 메시지의 고유 식별자입니다.
관심 있는 메일의 Message-ID를 얻으려면 원시 이메일 헤더를 검사해야 합니다. Microsoft Outlook 또는 웹용 Outlook(이전의 Outlook Web App 또는 OWA)에서 이 작업을 수행하는 방법에 대한 지침은 Outlook에서 인터넷 메시지 헤더 보기를 참조 하세요.
전자 메일 헤더를 볼 때 가독성을 위해 MXToolbox 또는 Azure에서 제공하는 전자 메일 헤더 분석기에 헤더 정보를 복사하여 붙여넣습니다.
헤더 라우팅 정보: 라우팅 정보는 컴퓨터 간에 전송되는 전자 메일의 경로를 제공합니다.
SPF(Sender Policy Framework): 스푸핑을 방지/탐지하는 데 도움이 되는 이메일 유효성 검사입니다. SPF 레코드에서 도메인을 대신하여 전자 메일을 보낼 수 있는 IP 주소 및 도메인을 확인할 수 있습니다.
SPF = Pass: SPF TXT 레코드는 보낸 사람에게 도메인을 대신하여 보낼 수 있다고 결정했습니다.
- SPF = 중립
- SPF = 실패: 정책 구성은 메시지 보낸 사람 IP의 결과를 결정합니다.
- SMTP 메일: 합법적인 도메인인지 확인
SPF에 대한 자세한 내용은 Microsoft 365에서 SPF를 사용하여 스푸핑을 방지하는 방법을 참조 하세요.
공통 값: 다음은 가장 일반적으로 사용 및 표시된 헤더와 해당 값에 대한 분석입니다. 이 정보는 유용한 정보이며 위협 탐색기의 검색 필드에서 사용할 수 있습니다.
- 발신자 주소
- 주제
- 메시지 ID
- 보낼 주소
- 반환 경로 주소
인증-결과: 이메일이 전송될 때 이메일 클라이언트가 인증한 내용을 찾을 수 있습니다. SPF 및 DKIM 인증을 제공합니다.
원래 IP: 원래 IP를 사용하여 IP가 차단 목록에 있는지 확인하고 지리적 위치를 가져올 수 있습니다.
SCL(스팸 신뢰도 수준): 들어오는 전자 메일이 스팸인지 여부를 결정합니다.
- -1: 안전한 보낸 사람, 안전한 받는 사람 또는 안전한 나열된 IP 주소(신뢰할 수 있는 파트너)로부터 대부분의 스팸 필터링을 무시합니다.
- 0, 1: 메시지가 검사되고 정리된 것으로 확인되었기 때문에 비스팜
- 5, 6: 스팸
- 7, 8, 9: 높은 신뢰도 스팸
SPF 레코드는 DNS 데이터베이스 내에 저장되며 DNS 조회 정보와 함께 번들로 제공됩니다. nslookup 명령을 사용하여 도메인에 대한 SPF(Sender Policy Framework) 레코드를 수동으로 확인할 수 있습니다.
명령 프롬프트를 엽니다(실행 > cmd 시작>).
명령을 공백으로
nslookup -type=txt"입력한 다음 도메인/호스트 이름을 입력합니다. 예시:nslookup -type=txt domainname.com
참고 항목
-all(거부 또는 실패 - 일치하지 않는 항목이 있으면 이메일을 전달하지 않음), 권장됩니다.
Microsoft 365의 사용자 지정 도메인에서 DKIM을 사용할 수 있는지 확인
DKIM(도메인 키 식별 메일)을 추가하려는 모든 도메인에 대해 두 개의 CNAME 레코드를 게시해야 합니다. DKIM을 사용하여 사용자 지정 도메인에서 보낸 아웃바운드 전자 메일의 유효성을 검사하는 방법을 참조하세요.
도메인 기반 메시지 인증, 보고 및 규칙 확인(DMARC)
이 기능을 사용하여 Microsoft 365에서 아웃바운드 전자 메일의 유효성을 검사할 수 있습니다.
공격자/캠페인에 대한 IP 주소 확인
이전 조사 단계에서 식별된 IP 주소를 확인하거나 조사하려면 다음 옵션을 사용할 수 있습니다.
- VirusTotal
- 엔드포인트에 대한 Microsoft Defender
- 공용 원본:
- Ipinfo.io - 지리적 위치를 얻을 수 있는 무료 옵션이 있음
- Censys.io - 인터넷의 수동 스캔이 알고있는 것에 대한 정보를 얻을 수있는 무료 옵션이 있습니다.
- AbuseIPDB.com - 일부 지리적 위치를 제공하는 무료 옵션이 있습니다.
- Bing 및 Google에 문의 - IP 주소에서 검색
URL 평판
SmartScreen 기술을 사용하는 모든 Windows 10 디바이스 및 Microsoft Edge 브라우저를 사용할 수 있습니다.
다음은 몇 가지 타사 URL 평판 예제입니다.
IP 주소 및 URL을 조사할 때 출력 또는 결과에 따라 IP 주소를 찾아서 IOC(손상 지표) 또는 기타 지표와 상호 연결하고 악의적 사용자의 원본 목록에 추가합니다.
사용자가 전자 메일에서 링크를 선택했나요?
사용자가 전자 메일의 링크를 클릭한 경우(목적에 관계없이) 일반적으로 이 작업을 수행하면 디바이스 자체에서 새 프로세스가 생성됩니다. 이 작업을 수행한 디바이스에 따라 디바이스별 조사를 수행해야 합니다. 예를 들어 Windows와 Android 및 iOS를 비교합니다. 이 문서에서는 Windows 기반 디바이스에 대한 몇 가지 세부 정보와 함께 일반적인 접근 방식을 설명했습니다. MDE(엔드포인트용 Microsoft Defender)를 사용하는 경우 iOS 및 곧 Android에도 사용할 수 있습니다.
엔드포인트용 Microsoft Defender 사용하여 이러한 이벤트를 조사할 수 있습니다.
VPN/프록시 로그 프록시 및 VPN 솔루션의 공급업체에 따라 관련 로그를 확인해야 합니다. SIEM 또는 Microsoft Sentinel에 이벤트를 전달하는 것이 가장 좋습니다.
엔드포인트용 Microsoft Defender 사용하는 것이 가장 좋은 시나리오입니다. 위협 인텔리전스 및 자동화된 분석을 사용하여 조사에 도움을 줄 수 있기 때문입니다. 자세한 내용은 엔드포인트용 Microsoft Defender 경고를 조사하는 방법을 참조하세요.
경고 프로세스 트리는 경고 심사 및 조사를 다음 수준으로 가져와 동일한 실행 컨텍스트 및 기간 내에서 발생한 집계된 경고 및 주변 증거를 표시합니다.
Windows 기반 클라이언트 디바이스 프로세스 만들기 이벤트 옵션을 사용하도록 설정했는지 확인합니다. 이상적으로는 명령줄 추적 이벤트도 사용하도록 설정해야 합니다.
조사 전에 위에서 언급한 감사 이벤트를 사용하도록 설정한 Windows 클라이언트에서 감사 이벤트 4688을 확인하고 전자 메일이 사용자에게 전달된 시간을 확인할 수 있습니다.
전자 메일이 열린 엔드포인트는 무엇인가요?
이 작업은 이전 조사 단계 와 유사합니다. 사용자가 전자 메일에서 링크를 선택했나요?
연결된 페이로드가 실행되었나요?
이 작업은 이전 조사 단계 와 유사합니다. 사용자가 전자 메일에서 링크를 선택했나요?
대상 IP/URL을 터치했거나 열었는가?
이 작업은 이전 조사 단계 와 유사합니다. 사용자가 전자 메일에서 링크를 선택했나요?
악성 코드가 실행되었나요?
이 작업은 이전 조사 단계 와 유사합니다. 사용자가 전자 메일에서 링크를 선택했나요?
계정으로 어떤 로그인이 발생합니까?
계정에서 발생한 다양한 로그인을 확인합니다.
페더레이션 시나리오
감사 로그 설정 및 이벤트는 운영 체제(OS) 수준 및 ADFS(Active Directory Federation Services) 서버 버전에 따라 다릅니다.
다른 서버 버전에 대해서는 다음 섹션을 참조하세요.
Server 2012 R2
기본적으로 보안 이벤트는 Server 2012 R2에서 감사되지 않습니다. 팜의 각 ADFS 서버에서 이 기능을 사용하도록 설정해야 합니다. ADFS 관리 콘솔에서 페더레이션 서비스 속성 편집을 선택합니다.
또한 OS 감사 정책을 사용하도록 설정해야 합니다.
명령 프롬프트를 열고 관리자 권한으로 다음 명령을 실행합니다.
auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
자세한 내용은 문제 해결을 위해 ADFS 서버를 구성하는 방법을 참조 하세요.
다음에서 ADFS PowerShell 모듈을 다운로드할 수도 있습니다.
Server 2016 이상
기본적으로 Windows Server 2016의 ADFS는 기본 감사를 사용하도록 설정되어 있습니다. 기본 감사를 통해 관리자는 단일 요청에 대해 5개 이하의 이벤트를 볼 수 있습니다. 그러나 다음 명령을 사용하여 감사 수준을 높이거나 낮출 수 있습니다.
Set-AdfsProperties -AuditLevel Verbose
자세한 내용은 Windows 서버의 ADFS에 대한 향상된 감사 기능을 참조 하세요.
Microsoft Entra Connect Health가 설치된 경우 위험한 IP 보고서도 확인해야 합니다. 실패한 로그인 활동 클라이언트 IP 주소는 웹 애플리케이션 프록시 서버를 통해 집계됩니다. 위험한 IP 보고서의 각 항목은 지정된 임계값을 초과하는 실패한 AD FS 로그인 활동에 대한 집계된 정보를 표시합니다.
자세한 내용은 위험한 IP 보고서를 참조하세요.
Server 2012 R2
이벤트 ID 342 – ADFS 관리자 로그의 "사용자 이름 또는 암호가 잘못되었습니다."
실제 감사 이벤트의 경우 보안 이벤트 로그를 확인해야 하며 원본을 ADFS 감사로 사용하여 클래식 감사 실패에 대한 이벤트 ID가 411인 이벤트를 찾아야 합니다. 또한 성공적인 인증에서 이벤트 ID 412를 찾습니다.
이벤트 ID 411 - SecurityTokenValidationFailureAudit 토큰 유효성 검사에 실패했습니다. 자세한 내용은 내부 예외를 참조하세요.
이벤트를 해당 이벤트 ID 501과 연관시켜야 할 수 있습니다.
Server 2016 이상
실제 감사 이벤트의 경우 보안 이벤트 로그를 확인해야 하며, 성공적인 인증 이벤트에 대한 이벤트 ID 1202 및 실패에 대한 1203을 찾는 이벤트를 찾아야 합니다.
이벤트 ID1202의 예:
이벤트 ID 1202 FreshCredentialSuccessAudit 페더레이션 서비스에서 새 자격 증명의 유효성을 검사했습니다. 자세한 내용은 XML을 참조하세요.
이벤트 ID 1203의 예:
이벤트 ID 1203 FreshCredentialFailureAudit 페더레이션 서비스가 새 자격 증명의 유효성을 검사하지 못했습니다. 오류 세부 정보는 XML을 참조하세요.
OS 수준당 ADFS 이벤트 ID의 전체 목록을 가져오려면 GetADFSEventList를 참조하세요.
관리되는 시나리오
조사 중인 하나 이상의 사용자에 대한 Microsoft Entra 로그인 로그를 확인합니다.
- Microsoft Entra 관리 센터 > 로그인 화면으로 이동합니다.
- 로그인 활동 확인
- GitHub에서 PowerShell 함수 확인
Microsoft Entra 관리 센터에서 로그인 화면으로 이동하여 이전 조사 단계에서 찾은 기간에 대한 표시 필터를 추가/수정하고 이 이미지와 같이 사용자 이름을 필터로 추가합니다.
Graph API를 사용하여 검색할 수도 있습니다. 예를 들어 사용자 속성을 필터링하고 lastSignInDate와 함께 가져옵니다. 특정 사용자를 검색하여 이 사용자의 마지막 로그인 날짜를 가져옵니다.
예를 들어 https://graph.microsoft.com/beta/users?$filter=startswith(displayName,'Dhanyah')&$select=displayName,signInActivity
또는 PowerShell 명령을 Get-AzureADUserLastSignInActivity 사용하여 개체 ID를 대상으로 하는 사용자에 대한 마지막 대화형 로그인 작업을 가져올 수 있습니다. 이 예제에서는 출력을 실행 디렉터리의 날짜 및 타임스탬프 CSV 파일에 씁니다.
Get-AzureADUserLastSignInActivity -TenantId aaaabbbb-0000-cccc-1111-dddd2222eeee -UserObjectId aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb -CsvOutput
또는 AzureADIncidentResponse PowerShell 모듈에서 다음 명령을 사용할 수 있습니다.
Get-AzureADIRSignInDetail -UserId johcast@Contoso.com -TenantId aaaabbbb-0000-cccc-1111-dddd2222eeee -RangeFromDaysAgo 29 -RangeToDaysAgo 3
원본 IP 주소 조사
Microsoft Entra 로그인 로그 또는 ADFS/페더레이션 서버 로그 파일에서 찾은 원본 IP 주소를 기반으로 트래픽이 발생한 위치를 자세히 조사합니다.
관리형 사용자
관리되는 시나리오의 경우 원본 IP 주소를 기반으로 로그인 로그 및 필터를 살펴보기 시작해야 합니다.
또는 AzureADIncidentResponse PowerShell 모듈에서 다음 명령을 사용할 수 있습니다.
Get-AzureADIRSignInDetail -IpAddress 1.2.3.4 -TenantId aaaabbbb-0000-cccc-1111-dddd2222eeee -RangeFromDaysAgo 29 -RangeToDaysAgo 3 -OutGridView
결과 목록을 살펴보면 디바이스 정보 탭으로 이동합니다. 사용된 디바이스에 따라 다양한 출력이 표시됩니다. 다음은 몇 가지 예입니다.
예제 1 - BYOD(관리되지 않는 디바이스):
예제 2 - 관리 디바이스(Microsoft Entra 조인 또는 Microsoft Entra 하이브리드 조인):
DeviceID가 있는지 확인합니다. OS와 브라우저 또는 UserAgent 문자열도 찾아야 합니다.
CorrelationID, 요청 ID 및 타임스탬프를 기록합니다. CorrelationID 및 타임스탬프를 사용하여 결과와 다른 이벤트의 상관 관계를 지정해야 합니다.
페더레이션된 사용자/애플리케이션
페더레이션 로그인 시나리오에 제공된 것과 동일한 절차를 따릅니다.
DeviceID, OS 수준, CorrelationID, RequestID를 찾아서 기록합니다.
식별된 DeviceID 조사
이 단계는 Microsoft Entra ID에 알려진 디바이스에만 관련됩니다. 예를 들어 이전 단계에서 하나 이상의 잠재적인 디바이스 ID를 찾은 경우 이 디바이스에서 자세히 조사할 수 있습니다. DeviceID 및 디바이스 소유자를 찾아 기록합니다.
각 AppID 조사
로그인 로그 및 테넌트 또는 페더레이션 서버 구성의 앱 구성으로 시작합니다.
관리되는 시나리오
이전에 찾은 로그인 로그 세부 정보에서 기본 정보 탭에서 애플리케이션 ID를 확인합니다.
애플리케이션(및 ID)과 리소스(및 ID)의 차이점을 확인합니다. 애플리케이션은 관련된 클라이언트 구성 요소인 반면 리소스는 Microsoft Entra ID의 서비스/애플리케이션입니다.
이 AppID를 사용하면 이제 테넌트에서 조사를 수행할 수 있습니다. 예를 들어 다음과 같습니다.
Get-MgApplication -Filter "AppId eq '00001111-aaaa-2222-bbbb-3333cccc4444'"
Id AppId DisplayName
3af6dc4e-b0e5-45ec-8272-56f3f3f875ad 00001111-aaaa-2222-bbbb-3333cccc4444 Claims X-Ray
이 정보를 사용하면 엔터프라이즈 애플리케이션 포털에서 검색할 수 있습니다. 모든 애플리케이션으로 이동하고 특정 AppID를 검색합니다 .
추가 인시던트 대응 플레이북
이러한 다른 유형의 공격을 식별하고 조사하기 위한 지침을 검토합니다.