Представьте ситуацию: ваша компания отправляет клиенту легитимный счет на оплату в формате PDF напрямую из программы 1С:Комплексная автоматизация или другой учетной системы. На вашей стороне в папке «Исходящие» почтового клиента и в самой базе данных всё выглядит идеально — реквизиты верные, получатель правильный. Однако клиент производит оплату, деньги уходят, но до вашей организации так и не доходят. Выясняется, что клиент получил тот же самый счет, с тем же перечнем товаров и логотипом, но с измененными реквизитами совершенно другой (сторонней) организации. При этом размер файла и хэш-сумма документа изменились, хотя визуально подмена незаметна.
В этой статье мы подробно разберем, как технически реализуется подобная схема мошенничества, известная в сфере информационной безопасности как BEC (Business Email Compromise — компрометация деловой переписки), выясним причины ее возникновения и определим пошаговый алгоритм защиты бизнеса от подобных инцидентов.
Многие пользователи ошибочно полагают, что в подобной ситуации виноват «вирус внутри 1С» или локальное вредоносное ПО на компьютере бухгалтера. На самом деле, механизмы проведения таких атак гораздо глубже и чаще связаны с инфраструктурой передачи данных.
Проанализируем основные сценарии, с которыми сталкиваются современные компании:
company.com на companny.com). Они перехватывают переписку и ведут общение от лица вашего менеджера. Когда дело доходит до отправки счета, оригинальный файл PDF перехватывается, редактируется в графическом или текстовом редакторе и отправляется с поддельного домена.Важно четко разграничивать уязвимости почтового обмена и локальные угрозы внутри операционной системы бухгалтера:
1c_to_kl.txt (используется для выгрузки платежных поручений из 1С в Клиент-Банк). Вирус на лету подменяет расчетные счета в текстовом файле на этапе импорта.Если ваш клиент заявляет, что получил измененный счет, выполним следующие шаги для поиска точки компрометации:
Шаг 1. Анализ сырых заголовков письма (EML/MSG).
Попросите клиента прислать полученное письмо в исходном («сыром») формате со всеми служебными заголовками. Откройте его в текстовом редакторе и проанализируйте параметры Received. Выясните, с какого именно IP-адреса и сервера физически было отправлено это письмо. Если IP-адрес отправителя не совпадает с адресом вашего почтового сервера, имела место отправка со стороннего сервера (спуфинг или использование домена-двойника).
Шаг 2. Проверка правил пересылки в почтовом сервисе.
Проверьте настройки почтовых ящиков менеджеров, выставляющих счета. Зайдите в веб-интерфейс почты и убедитесь в отсутствии скрытых правил пересылки сообщений (Forwarding) на внешние подозрительные адреса.
Шаг 3. Сверка контрольных сумм (MD5/SHA-256).
Для детального анализа вы можете использовать механизмы платформы 1С для фиксации хэш-суммы отправляемого файла. Рассмотрим пример кода на встроенном языке 1С, который позволяет рассчитать контрольную сумму счета перед отправкой:
Функция ПолучитьКонтрольнуюСуммуФайла(ПутьКФайлу) Экспорт
Хэширование = Новый ХэшированиеДанных(ХэшФункция.SHA256);
ДвоичныеДанные = Новый ДвоичныеДанные(ПутьКФайлу);
Хэширование.Добавить(ДвоичныеДанные);
Возврат Строка(Хэширование.ХэшСумма);
КонецФункции
Зафиксировав хэш-сумму в логах системы 1С при отправке, вы сможете сравнить ее с хэш-суммой файла, полученного клиентом. Если хэш-суммы различаются, файл однозначно подвергся модификации в процессе доставки.
Для минимизации рисков финансовых потерь мы рекомендуем внедрить комплекс мер, сочетающий технические настройки и организационные регламенты.
Самый надежный способ полностью исключить риск подмены реквизитов — отказаться от отправки счетов через обычную незащищенную электронную почту. При использовании ЭДО (например, 1С-ЭДО) каждый документ подписывается Квалифицированной электронной подписью (КЭП). Любое изменение содержимого файла сделает подпись недействительной, а сам документ передается по зашифрованным каналам оператора ЭДО напрямую в информационную базу вашего контрагента.
Если использование почты неизбежно, системный администратор обязан настроить защитные записи на DNS-сервере вашей компании:
p=reject, чтобы почтовые серверы получателей гарантированно блокировали любые поддельные письма от вашего имени.Для предотвращения атак локальных вирусов-клиперов на стороне бухгалтера откажитесь от промежуточных файлов обмена 1c_to_kl.txt. Используйте технологию 1С:ДиректБанк. В этом случае отправка платежных поручений в банк и получение выписок происходят напрямую из интерфейса 1С по защищенным каналам связи с банком (через веб-сервисы), что полностью исключает возможность перехвата и модификации файлов на жестком диске.
Даже самые современные технические средства бессильны против социальной инженерии, если сотрудники не проявляют бдительность. Внедрите в регламент работы бухгалтерии и отдела закупок строгое правило: любое изменение платежных реквизитов контрагента должно быть подтверждено по альтернативному каналу связи. Если в почту пришло уведомление об изменении банка или расчетного счета, менеджер обязан позвонить партнеру по телефону, указанному в оригинальном договоре (но не по телефону из нового подозрительного счета!), и устно подтвердить изменения перед совершением транзакции.