☰

Получение пустых писем с трех разных ПК с Windows с 12 января 2015 г.

tag-icon • tag-icon windows email outlook malware
Получение пустых писем с трех разных ПК с Windows с 12 января 2015 г.

Проблема

Неожиданные пустые электронные письма отправляются неизвестным источником с 12 января 2015 года.

Попытки решить проблему

  • они все из компании, где я занимаюсь сетевой/системной поддержкой
  • они все с машин с Windows 7
  • на всех машинах установлен Outlook
  • электронные письма всегда имеют пустое тело
  • это не имеет никакого отношения к взаимодействию пользователя. Я звонил им несколько раз сразу после того, как пришло письмо, и они занимались обычными делами, например, просматривали веб-страницы и т. д. Иногда я получаю эти письма, даже когда никто не пользуется ПК.
  • все три ПК начали отправлять эти письма 12 января 2015 г.
  • время не связано (иногда я получаю почту даже ночью)
  • Я получаю почту только когда ПК включены. Например RobertPC всегда включен и я получаю почту только с него по выходным (остальные выключены)
  • В темах писем прослеживается некоторая закономерность:

WITT - report Helios pocitac- от WittPC

WITT Lenka report- от Мартины ПК

WITT - Robert report- от RobertPC

Однако обратите внимание на отсутствие дефиса в "WITT Lenka report". Также обратите внимание, что слово "report" находится в середине темы в "WITT - report Helios pocitac", тогда как в двух других темах оно находится в конце.

Здесь я размещаю исходный код двух писем. Обратите внимание, что я изменил свой адрес электронной почты на [email protected]и адрес электронной почты компании на company_mail@their_domain.com. Компания называется WITT и это связано с именем в теме.

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-й адрес электронной почты:

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

Вопрос

Какой сервис или приложение отправляет эти электронные письма или как отследить источник?

решение1

Отказ от ответственности 1: Конечно, в Windows уже есть хороший инструмент аудита, чтобы справиться с чем-то подобным. К сожалению, в среде Windows у меня нет опыта работы системным администратором, только обычный конечный пользователь.

Отказ от ответственности 2: Если кто-то сталкивается с подобной проблемой (загадочное электронное письмо или исходящий пакет), будет хорошей идеей отключить это устройство для дальнейшего анализа.

Случайно возникшую проблему можно отследить с помощью хорошей системы журналирования. В этом случае вам необходимо настроить журналирование на вашем почтовом сервере и ПК конечного пользователя. ПК с Windows должен иметь запись журнала о временной метке, PID и цели исходящего соединения. Сервер Debian должен иметь запись журнала о временной метке, когда получено электронное письмо, а также о том, кто является отправителем и получателем электронного письма. С помощью этих двух сведений вы можете просмотреть, какой процесс отправил вам электронное письмо. Вот почемусинхронизация времени важна.

В прошлом, вы использовали TCPview для получения картины активности Windows. Плохая новость в том, что TCPView не может вести журнал. Поэтому вам придется смотреть в окна TCPview до тех пор, пока письмо не будет отправлено. Другая плохая новость в том, что транзакция SMTP может быть очень быстрой, поэтому маловероятно, что ваши глаза зафиксируют событие SMTP.

На основеэтот ответ Суперпользователя, можешь попробоватьМонитор процессачтобы помочь вам регистрировать сетевое подключение и его PID. Программа должна быть открыта и запущена, чтобы записывать журналы, но если вы настроите ее на сохранение журналов на диске по мере их записи, вы всегда сможете просмотреть их позже.

Монитор процесса

С помощью этих инструментов вы можете запустить и проверить журнал в конце дня. Нет необходимости снова и снова смотреть на экран.

Связанный контент