☰

시나리오 1 – 발신자 SPF가 잘못 구성됨

tag-icon • tag-icon email malware
시나리오 1 – 발신자 SPF가 잘못 구성됨

때때로 나는 명백한 악의적인 페이로드(예: 유해한 매크로가 포함된 Word 문서)가 포함된 전자 메일을 받습니다.

나는 이러한 이메일에 대해 걱정하지 않습니다. 나는 알아볼 수 있지만, 보낸 것으로 의심되는 사람은 모두 내가 아는 같은 회사의 직원이라는 것을 알았습니다. 어쨌든 보낸 사람 주소는 환상적입니다.

그래서 내 질문은: 무엇이 더 가능성이 높습니까? 상대방의 사서함이 해킹되어 남용되었다는 것입니까, 아니면 내 사서함이 해킹되었다는 것입니까?

알 수 있는 방법이 있나요?

답변1

확실히 말하기는 어렵지만 이것이 가장 가능성이 높은 시나리오라고 생각합니다.

  • 보낸 사람의 도메인 이름에는SPF도메인에 대한 이메일을 보낼 수 있는 IP 주소를 제한하는 기록입니다.

내 경험에서 가능성을 내림차순으로 내 머리 꼭대기에 있는 다른 가능한 시나리오는 다음과 같습니다.

  • 보낸 사람의 이메일 계정이나 이메일 서버가 손상되어 서버에 알려진 연락처로 스팸을 보내고 있습니다.
  • 보낸 사람의 도메인 이름에는 적절한 SPF 기록이 있지만 메일 서버의 스팸 방지 소프트웨어는 스푸핑된 이메일을 확인하지 않습니다.
  • 귀하의 메일 서버 또는 계정이 손상되었으며 맬웨어 배포자가 귀하의 연락처 목록을 사용하여 귀하의 받은 편지함에 맬웨어 이메일을 배치하고 있습니다.

시나리오 1 – 발신자 SPF가 잘못 구성됨

귀하가 다음 항목에 표시했기 때문에 이것이 가장 가능성이 높은 시나리오입니다.귀하의 질문에 대한 업데이트보낸 사람의 이메일 주소가 "공상"입니다. 스푸핑 발신자는 대상 도메인의 실제 사서함을 반드시 알지 못할 수도 있습니다.

징후

누군가로부터 이메일을 받았지만 그 사람이 이메일 전송을 거부했습니다. 보낸 메시지 폴더나 보내는 서버의 이메일 로그에 일치하는 기록이 표시되지 않을 수도 있습니다.

원인

보낸 사람의 도메인 이름에는 스푸핑을 방지하는 SPF(Sender Policy Framework) 레코드가 없습니다.

진단

다음 명령을 사용하여 도메인의 SPF 레코드를 확인할 수 있습니다 example.com.

nslookup -type=TXT example.com

example.com발신자의 도메인 이름으로 바꿉니다 . 다음과 같은 기록을 볼 수 있습니다.

"v=spf1 +a +mx +ip4:127.0.0.1 -all"

위의 예에서,

  • +a도메인 A 레코드의 IP 주소가 이 도메인을 대신하여 이메일을 보낼 수 있도록 허용하는 것을 의미합니다.
  • +mx이는 도메인의 MX 레코드를 확인하고 해당 도메인에서도 이메일을 보낼 수 있도록 허용하는 것을 의미합니다.
  • +ip4:127.0.0.1IP 주소가 127.0.0.1이 도메인에 대한 이메일을 보낼 수 있도록 허용하는 것을 의미합니다.
  • -all이 도메인에 대한 이메일 전송에서 다른 모든 IP 주소를 거부한다는 의미입니다.

발신자의 SPF 레코드에 SPF가 없는 경우 -allSPF를 검증하는 수신 메일 서버는 누구든지 보낼 수 있는 스푸핑된 이메일을 수락할 수 있습니다.

Received:수신한 악성 메일의 헤더를 보면 실제 메일을 보낸 사람을 확인할 수 있습니다 . 헤더 Received:는 이메일이 통과한 각 메일 서버의 역순으로 되어 있지만, 메일 서버에서 추가하지 않은 헤더는 스푸핑될 수 있다는 점에 유의하세요. 메일 게이트웨이에 의해 추가된 첫 번째 Received:헤더는 이메일의 출처를 보여줍니다. 예:

Received: from mail-eopbgr810054.outbound.protection.outlook.com ([40.107.81.54]:59584 helo=NAM01-BY2-obe.outbound.protection.outlook.com)
    by example.deltik.org with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
    (Exim 4.91)
    (envelope-from <[email protected]>)
    id 1gUudZ-00BGJx-L7
    for [email protected]; Thu, 29 Nov 2018 06:49:21 -0600

위의 예에서 이메일은 스팸 발신자의 도메인에 대한 40.107.81.54SPF 레코드( ) 검사를 통과한 에서 왔 으므로 이메일이 수락되었습니다."v=spf1 include:spf.protection.outlook.com -all"luxurylifestylereport.net

또는 이메일 서버 로그에 액세스할 수 있는 경우 거기에서 이메일의 원본을 읽을 수 있습니다.

해결

발신자의 포스트마스터는 스패머가 이메일 도메인을 스푸핑하는 것을 방지하기 위해 해당 도메인에 대한 SPF 레코드를 구성해야 합니다. 이것은 당신이 할 수 있는 일이 아닙니다.

우체국 담당자가 이 문제를 해결할 때까지 스팸 방지 설정을 조정하여 악성 첨부 파일이나 스팸 콘텐츠가 포함된 이메일을 차단할 수 있습니다.

시나리오 2 – 보낸 사람의 이메일이 손상됨

이 문제가 가끔 발생한다고 말씀하셨기 때문에 이 시나리오는 가능성이 낮지만, 다른 사람이 과거에 이 문제를 발견하고 보고했어야 합니다.

징후

이메일 헤더에서 이메일이 보낸 사람의 도메인에 이메일을 보내도록 허용된 IP 주소에서 발송되었음을 확인할 수 있습니다.

원인

해당 IP 주소의 메일 서버 또는 이를 통해 메일을 보내는 서버가 손상되었습니다. 또한 해커는 보낸 사람이 알고 있는 연락처 사본을 발견하고 관련 있는 사람을 찾기 위해 해당 이메일을 보내려고 할 수도 있습니다.

진단

시나리오 1과 동일한 프로세스

해결

보낸 사람의 포스트마스터는 해당 이메일 시스템을 중지하고 보안을 유지해야 합니다. 이것은 당신이 할 수 있는 일이 아닙니다.

우체국 담당자가 이 문제를 해결할 때까지 스팸 방지 설정을 조정하여 악성 첨부 파일이나 스팸 콘텐츠가 포함된 이메일을 차단할 수 있습니다.

시나리오 3 – 수신 메일 서버가 SPF 레코드를 확인하지 않음

스패머는 이미 스푸핑으로부터 자신을 보호하고 있는 도메인의 이메일을 스푸핑하려고 리소스를 낭비하는 것을 원하지 않기 때문에 이 시나리오는 가능성이 낮습니다. 아마도 다른 도메인 이름으로부터도 스푸핑된 메일을 많이 받게 될 것입니다.

징후

누군가로부터 이메일을 받았지만 그 사람이 이메일을 보내지 않았다는 것을 증명할 수 있습니다. 실제로 누구나 도메인의 SPF 레코드가 올바르게 구성되었는지 확인할 수 있지만 귀하가 받은 이메일은 도메인의 SPF 레코드에 의해 금지된 IP 주소에서 온 것입니다.

원인

귀하의 이메일 서버는 스푸핑된 이메일을 필터링하지 않습니다.

진단

시나리오 1과 동일한 과정이지만 발신자의 IP 주소가 SPF 검사에 실패한 것을 확인할 수 있습니다.

해결

SPF 유효성 검사를 구성하는 방법은 이메일 서버 설명서를 참조하세요.

시나리오 4 – 수신자 이메일 계정이 손상됨

자신이 손상되었다는 사실을 숨기고 이메일 주소의 좋은 평판을 이용해 다른 사람에게 스팸을 보내는 것이 더 수익성이 높기 때문에 이 시나리오는 가능성이 낮습니다. 또한 악의적인 주체는 소스 이메일 주소를 다양화할 가능성이 높습니다.

징후

수신 이메일 로그에 표시된 이메일이 표시되지 않거나 수신된 이메일의 헤더가 의미가 없습니다.

원인

누군가 실제로 이메일을 보내지 않고 이미 손상된 이메일 계정에 맬웨어 이메일을 넣어서 귀하에게 더 많은 액세스 권한을 얻으려고 합니다. IMAP 프로토콜을 통해 이메일을 추가할 수 있습니다.

진단

인식할 수 없는 인증이 있는지 메일 서버 로그를 확인하세요.

해결

이메일 계정의 비밀번호를 변경하세요.

관련 정보