☰

Recebendo e-mails vazios de três PCs Windows diferentes desde 12 de janeiro de 2015

tag-icon • tag-icon windows email outlook malware
Recebendo e-mails vazios de três PCs Windows diferentes desde 12 de janeiro de 2015

Problema

E-mails vazios inesperados são enviados por uma fonte desconhecida desde 12 de janeiro de 2015.

Tentativas de resolver o problema

  • eles são todos da empresa onde faço suporte de rede/sistema
  • eles são todos de máquinas com Windows 7
  • todas as máquinas têm o Outlook instalado
  • e-mails sempre têm corpo vazio
  • não tem nada a ver com a interação do usuário. Liguei para eles várias vezes quando o e-mail chegou e eles estavam fazendo coisas normais, como navegar, etc. Às vezes, recebo esses e-mails mesmo quando não há ninguém usando o PC.
  • todos os três PCs começaram a enviar esses e-mails em 12 de janeiro de 2015
  • os horários não estão relacionados (às vezes recebo correspondência mesmo durante a noite)
  • Recebo e-mails apenas quando os PCs estão ligados. Por exemplo, o RobertPC está sempre ligado e recebo e-mails dele apenas nos finais de semana (outros estão desligados)
  • existe algum padrão nos assuntos dos e-mails:

WITT - report Helios pocitac- vindo do WittPC

WITT Lenka report- vindo de Martina PC

WITT - Robert report- vindo de RobertPC

No entanto, observe o hífen faltando no "relatório WITT Lenka". Observe também que a palavra "relatório" está no meio do assunto em "WITT - relatório Helios pocitac", enquanto nas outras duas disciplinas está no final.

Aqui posto o código fonte de dois e-mails. Observe que alterei meu endereço de e-mail para [email protected]e o endereço de e-mail da empresa para company_mail@their_domain.com. A empresa se chama WITT e está relacionada ao nome no assunto.

Delivered-To: [email protected]
Received: by 10.114.12.67 with SMTP id w3csp5070519ldb;
        Mon, 2 Mar 2015 01:54:37 -0800 (PST)
X-Received: by 10.180.105.131 with SMTP id gm3mr34457493wib.11.1425290075184;
        Mon, 02 Mar 2015 01:54:35 -0800 (PST)
Return-Path: <company_mail@their_domain.com>
Received: from ub.wcontact.cz ([217.11.236.196])
        by mx.google.com with ESMTPS id f20si17829519wiw.11.2015.03.02.01.54.34
        for <[email protected]>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 02 Mar 2015 01:54:35 -0800 (PST)
Received-SPF: none (google.com: company_mail@their_domain.com does not designate permitted sender hosts) client-ip=217.11.236.196;
Authentication-Results: mx.google.com;
       spf=none (google.com: company_mail@their_domain.com does not designate permitted sender hosts) smtp.mail=company_mail@their_domain.com
Received: from Martina (136.67.broadband2.iol.cz [83.208.67.136])
    by ub.wcontact.cz (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id t22C0niI025497
    for <[email protected]>; Mon, 2 Mar 2015 13:00:50 +0100
Thread-Topic: WITT Lenka report
thread-index: AdBUzuF6ZasY+IMSR/WHxYqBQw1VZw==
From: <company_mail@their_domain.com>
To: <[email protected]>
Subject: WITT Lenka report
Date: Mon, 2 Mar 2015 10:54:31 +0100
Message-ID: <CEF9D61743624438AFB64DAEE2A1F904@Martina>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609

2º e-mail:

Delivered-To: [email protected]
Received: by 10.114.12.67 with SMTP id w3csp5079020ldb;
        Mon, 2 Mar 2015 02:13:46 -0800 (PST)
X-Received: by 10.180.214.99 with SMTP id nz3mr34911628wic.82.1425291226321;
        Mon, 02 Mar 2015 02:13:46 -0800 (PST)
Return-Path: <company_mail@their_domain.com>
Received: from ub.wcontact.cz ([217.11.236.202])
        by mx.google.com with ESMTPS id lc1si21540226wjc.149.2015.03.02.02.13.44
        for <[email protected]>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 02 Mar 2015 02:13:45 -0800 (PST)
Received-SPF: none (google.com: company_mail@their_domain.com does not designate permitted sender hosts) client-ip=217.11.236.202;
Authentication-Results: mx.google.com;
       spf=none (google.com: company_mail@their_domain.com does not designate permitted sender hosts) smtp.mail=company_mail@their_domain.com
Received: from RobertPC (136.67.broadband2.iol.cz [83.208.67.136])
    by ub.wcontact.cz (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id t22CK1a1025892
    for <[email protected]>; Mon, 2 Mar 2015 13:20:02 +0100
Thread-Topic: WITT - Robert report
thread-index: AdBU0ZFN59bSeq8gS72nD7K9MjemXQ==
From: <company_mail@their_domain.com>
To: <[email protected]>
Subject: WITT - Robert report
Date: Mon, 2 Mar 2015 11:13:47 +0100
Message-ID: <A28D9827680449BB964B51889EE50598@RobertPC>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609

Pergunta

Qual serviço ou aplicativo está enviando esses e-mails ou como rastrear a origem?

Responder1

Isenção de responsabilidade 1: É claro que o Windows já possui uma boa ferramenta de auditoria para lidar com algo assim. Infelizmente, no ambiente Windows, não tenho experiência como administrador de sistemas, apenas como usuário final comum.

Isenção de responsabilidade 2: quando alguém encontrar um problema semelhante a este (e-mail misterioso ou pacote de saída), seria uma boa ideia desconectar esta máquina para análise posterior.

O problema ocorrido aleatoriamente pode ser rastreado usando um bom sistema de registro. Nesse caso, você precisa configurar o login no servidor de e-mail e no PC do usuário final. O PC com Windows deve ter entrada de log sobre carimbo de data/hora, PID e destino de conexão de saída. O servidor Debian deve ter registro sobre o carimbo de data e hora quando o e-mail foi recebido e quem é o remetente e o destinatário do e-mail. Com essas duas informações você pode visualizar qual processo enviou o email para você. É por issosincronização de horário é importante.

No passado, você usou o TCPview para obter uma imagem da atividade do Windows. A má notícia é que o TCPView não pode fazer logs. Então, você tem que olhar nas janelas do TCPview até que o e-mail seja enviado. A outra má notícia é que a transação SMTP pode ser muito rápida, portanto há poucas chances de seus olhos capturarem o evento SMTP.

Baseado emesta resposta do superusuário, podes tentarMonitor de Processopara ajudá-lo a registrar a conexão de rede e seu PID. O programa precisará estar aberto e em execução para registrar os logs, mas se você configurá-lo para salvar os logs em disco à medida que os grava, você poderá revisá-los mais tarde.

Monitor de Processo

Com essas ferramentas você pode executar e verificar o log no final do dia. Não há necessidade de assistir a tela continuamente novamente.

informação relacionada