ВЗЛОМ ПОЧТЫ

Хакеры могли читать чужую почту Gmail «через ChatGPT». Что известно 8 сентября 2026 года исследователи Check Point Research опубликовали разбор уязвимости, из-за которой ИИ-ассистент по ошибке позволял одним пользователям Gmail читать почту других. 📬 Как это работало Эксперты в июне 2026 года нашли скрытый канал между контейнерами разных аккаунтов ChatGPT. Сами контейнеры не имели доступа в интернет и не могли обращаться друг к другу напрямую — но использовали общий внутренний JFrog Artifactory для загрузки зависимостей. Через запись и чтение свойств объектов злоумышленник мог передать «задачу» в чужую сессию. Исследователи назвали это «общим буфером обмена». В демонстрации ChatGPT отвечал на безобидный запрос пользователя, одновременно читал данные из подключённого Gmail и отправлял результат в контейнер другого аккаунта. В чате жертва при этом не видела ничего подозрительного. 🕵️ Кто был в зоне риска • те, кто открывал подготовленный общий чат и писал в него обычное сообщение; • те, кто вставлял вредоносный промпт; • пользователи кастомных GPT со скрытой инструкцией. Статус К моменту публикации отчёта межаккаунтный канал уже закрыли. OpenAI подтвердила, что проблемный экземпляр Artifactory вывели из эксплуатации. На 10 сентября 2026 года он недоступен. ✅ Что сделать сейчас 🔹 проверить приложения, подключённые к ChatGPT, и отозвать лишние разрешения; 🔹 включить режим Always ask для интеграций, где он есть; 🔹 осторожно относиться к чужим общим диалогам и кастомным GPT при подключённых рабочих сервисах; 🔹 обращать внимание, если ассистент сам обращается к Gmail без вашей просьбы. Главный урок: изоляцию ИИ-агентов ломают не только сетевые соединения, но и общие данные во внутренней инфраструктуре. А подключение почты к ИИ даёт ему доступ к её содержимому в рамках выданных разрешений — помните об этом. Источник: CNews, исследование Check Point Research #кибербезопасность #ИИ #Gmail #ChatGPT #утечка

Наша работа это Ваша безопасность

Как взламывают почту: 5 приёмов, которые стоит знать каждому Почтовый ящик — это ключ от всей вашей цифровой жизни: пароли, банки, соцсети, переписка. Вот что используют атакующие 👇 1. 🎣 Фишинг. Письмо «от банка» или «от коллег» со ссылкой на фейковый вход. Вы сами вводите пароль — и он уходит злоумышленнику. 2. 🔑 Подбор и credential stuffing. Прогон базы утечек по вашему адресу. Один и тот же пароль на разных сайтах = взлом почты «в подарок». 3. 📱 Перехват кода (SIM-swap / push-bombing). Восстановление доступа через телефон: оформляют дубликат SIM или засыпают уведомлениями, пока вы в спешке не нажмёте «Подтвердить». 4. 🕵️ Социальная инженерия. Звонок в техподдержку провайдера от вашего имени с просьбой «сбросить пароль». Люди верят голосу больше, чем письму. 5. 🍪 Кража сессии. Вредонос в браузере или фишинговая страница вытаскивает cookies — вход остаётся активным без пароля и 2FA. Что делать: ✅ Отдельный пароль только для почты + менеджер паролей ✅ 2FA через приложение или ключ, а не SMS ✅ Не переходить по ссылкам из писем — только вручную на сайт ✅ Проверить утечки (haveibeenpwned) и сменить пароль, если нашли ✅ Настроить «код восстановления» и не отвечать на звонки «от поддержки» Помните: настоящий сервис никогда не просит пароль по почте или телефону. #кибербезопасность #защитаданных #фишинг

7. Организационный слой: люди и процессы Регулярные учения по фишингу с разбором, а не наказанием; точечное обучение для групп риска (финансы, HR, руководство, ассистенты). Runbook реагирования на компрометацию ящика: изоляция сессий и отзыв токенов, сброс пароля и MFA, удаление правил переадресации, криминалистика почтовых логов, уведомление контрагентов. Владение почтовым доменом в реестре критичных активов: кто может править DNS и DMARC, мониторинг изменений зон. Телеметрия и аудит: хранение почтовых метаданных и административных событий, расследование по Message-ID. 8. Российская специфика Реестр российского ПО: для госсектора и объектов КИИ средства защиты почты (шлюзы, DLP, SIEM) должны быть из реестра; это влияет на выбор SEG и почтовой платформы. Требования по локализации и защите ПДн (152-ФЗ): маршрутизация почты и облачные антиспам-сервисы не должны выводить персональные данные за пределы, если это нарушает требования; шифрование каналов и хранения. ГОСТ-криптография и отечественные сертификаты: для корпоративного TLS и подписи почты на ряде объектов применяются отечественные алгоритмы и Удостоверяющие центры. Импортозамещение ящиков: при миграции с иностранных платформ на отечественные (VK WorkSpace, МойОфис, Почта Mail для организаций и др.) пересматриваются SPF/DKIM/DMARC, коннекторы и политики условного доступа — «переезд» часто ломает выравнивание доменов и открывает окна для спуфинга. 9. Чек-лист зрелости почтовой защиты Отправитель и домен  DMARC в p=reject по всем доменам и поддоменам, включая неиспользуемые (с p=reject и SPF-«пустой» политикой).  DKIM 2048+ бит, SPF без лишних include/a/mx (лимит 10 DNS-lookup).  MTA-STS в enforce, запрет plaintext-SMTP.  Мониторинг спуфинга и DNS-репутации домена. Доступ  ФФ2FA, устойчивая к фишингу (FIDO2), для всех админов и групп риска как минимум.  Legacy-аутентификация отключена, SMTP-AUTH по паролю запрещён.  Реестр и allowlist OAuth-приложений, отзыв consent'ов владением. Содержимое и поведение  SEG + sandbox + URL-реврайтинг; DLP на исходящей.  Алерты на новые правила пересылки и аномальные входы.  Контроль реквизитов платежей по второму каналу. Процессы  Регулярные фишинг-учения; runbook реагирования на компрометацию ящика.  Аудит изменений DNS/DMARC; хранение почтовых метаданных.  Для Госсектора/КИИ: средства защиты из реестра российского ПО, соответствие 152-ФЗ. 10. Заключение Универсальной «таблетки» от почтовых атак не существует: фишинг, BEC, кража учётных данных, злоупотребление OAuth и спуфинг домена требуют разных контуров. Работающая модель защиты — эшелонированная: криптографическое подтверждение отправителя (SPF/DKIM/DMARC/MTA-STS) закрывает подделку домена; устойчивая к фишингу аутентификация и условный доступ — компрометацию ящика; шлюзовая фильтрация, песочница и DLP — содержимое; поведенческие алерты и аудит — «тихие» действия внутри ящика; обучение и процессы реагирования — человеческий фактор. Начинать стоит с DMARC-цикла и отключения фишингуемой аутентификации: эти два шага снимают основную массу типовых инцидентов.

Документы Office с макросами, ISO/CAB-архивы, ярлыки (.lnk/.url), эксплуатирующие уязвимости клиенты. Цель — закрепиться на машине и получить доступ к почтовому клиенту и сохранённым сессиям. 2.7 Атаки на канальную доставку и доверие к домену Открытые ретрансляторы и скомпрометированные SMTP-хосты для рассылки спама от имени вашего домена. Спуфинг домена для ударов по контрагентам. Порча репутации домена массовым спамом, чтобы легитимная почта开始 уходить в спам. 2.8 Внутренние угрозы и «тихие» правила Злоумышленник (или украденный аккаунт) создаёт правило «пересылать копию всех писем на внешний ящик», скрывает переписку с конкурентом в папке RSS/LRSS, настраивает автоответчик-приманку. Эти действия видны не в логах содержимого, а в административных событиях — и часто не контролируются. 3. Как атаки складываются в цепочку Реальный инцидент — это почти всегда последовательность: разведка → первоначальный доступ (фишинг/утёкший пароль) → закрепление (правило переадресации, OAuth-приложение) → эскалация → действие (BEC, кража данных, выход в домен). Защита строится по принципу эшелонирования: каждый этап цепочки должен быть заблокирован независимо, чтобы компрометация одного контроля не приводила к успеху атаки. 4. Защита: криптографическое подтверждение отправителя Это ядро почтовой безопасности. Настройка по стандарту DMARC (RFC 7489) опирается на два предшествующих механизма и один последующий. Механизм Стандарт Что доказывает Где настраивается SPF RFC 7208 письмо отправлено разрешённым сервером домена DNS-запись TXT DKIM RFC 6376 письмо не изменено и подписано закрытым ключом домена DNS-запись TXT + подпись на шлюзе DMARC RFC 7489 политика домена + выравнивание домена + адреса для отчётов DNS-запись TXT MTA-STS RFC 8460 обязательный TLS и подлинность сервера получателя DNS + HTTPS-файл политики BIMI / VMC отраслевой стандарт верифицированный логотип и высокая дисциплина DMARC сертификат VMC + DNS Практика внедрения DMARC — это управляемый переход, а не разовое действие: p=none — только сбор отчётов (rua/ruf), ничего не отбрасывается; изучаем, кто реально отправляет от имени домена (включая «серые» сервисы рассылки). p=quarantine — несоответствующие письма уходят в спам; проверяем побочные эффекты. p=reject — подделка домена отклоняется. Это целевое состояние. Ужесточение: aspf/s=pct, fo (условия соответствия), политика поддоменов sp, отказ от уязвимого Forwarded traffic (AKIM/ARC для пересылок). Отдельно: сигнатурные списки блокировки (DNSBL/IP reputation) и требование TLS для входящей/исходящей почты (запрет plaintext-SMTP), иначе канальная защита неполна. 5. Защита: доступ к ящикам и приложениям ФФ2FA, устойчивая к фишингу: аппаратные ключи FIDO2/WebAuthn и сертификаты вместо SMS/push-кодов. Это главный ответ наcredential phishing, push-bombing и перехват сессий. Условный доступ (Conditional Access): политика входа по контексту — устройство, география, риск-скоринг, тип клиента. Блокировка legacy-аутентификации (SMTP-AUTH по паролю, POP/IMAP с паролем). Единый вход и жизненный цикл токенов: отзыв consent'ов, ротация и сокращение TTL, запрет «бессрочных» SMTP-паролей, реестр подключённых OAuth-приложений с allowlist. Защита паролей: отказ от повторного использования, проверка паролей по базам утечек (в корпоративном контексте — с соблюдением требований к обработке данных). 6. Защита: содержимое и поведение Шлюзовая фильтрация (SEG) с антиспамом, антифишингом и антивредоносом; песочница (sandbox) для подозрительных вложений и URL-реврайтинг с проверкой при клике. DLP на исходящей почте — контроль утечек реквизитов, персональных и коммерческих данных. Защита от BEC: контроль изменения реквизитов платежей по «второму каналу» (звонок по известному номеру), маркировка внешних писем ([EXTERNAL]), запрет авто-пересылки на внешние домены. Поведенческий контроль почтового ящика: алерты на новые правила пересылки, подозрительные входы, аномальный объём удалений/отправок. Отключение небезопасного: автозагрузка удалённых изображений, рендеринг HTML без изоляции, макросы из интернета по умолчанию заблокированы.

Электронная почта под прицелом: методы атак и средства защиты Электронная почта остаётся главным каналом деловой коммуникации и одновременно — точкой входа большинства успешных атак на организации. Почта привлекательна для злоумышленников по трём причинам: она доверена пользователям по умолчанию, её протоколы проектировались в эпоху, когда аутентификация отправителя не была приоритетом, и в переписке концентрируются учётные данные, финансы и персональные данные. Эта статья разбирает типовые методы компрометации почтовых систем и аккаунтов и, главное, меры защиты, которые закрывают каждый из этих векторов.

Важно: материал носит обучающий и защитный характер. Здесь описаны механизмы атак на концептуальном уровне и способы их нейтрализации, а не пошаговые инструкции по взлому чужих систем.

1. Почему почта уязвима по конструкции Базовый протокол отправки писем SMTP (RFC 5321) исторически позволял указать любой адрес отправителя — поле From является текстовым и само по себе ничем не подтверждается. Аутентификация в SMTP (RFC 4954 AUTH) защищает от отправки «от чужого имени» между клиентом и его сервером, но не между доменами. Из этого архитектурного «греха» выросла целая экосистема надстроек доверия: SPF, DKIM, DMARC, MTA-STS и др. (см. раздел 4). Дополнительные факторы риска: Широкая поверхность входа: веб-почта, мобильные клиенты, протоколы IMAP/POP3/ActiveSync, API и OAuth-приложения, автоматические переадресации. Человеческий фактор: письмо — это сообщение, которое пользователь сам открывает и читает; социальная инженерия обходит технические периметры. Наследие интеграций: устаревшие скрипты, «серые» IP, открытые ретрансляторы, SMTP-без-шифрования. 2. Основные методы атак 2.1 Фишинг и целевой фишинг (spear-phishing) Массовые или точечные письма, имитирующие легитимный сервис или коллегу, с целью выłudить учётные данные или заставить совершить действие (открыть вложение, перейти по ссылке, выполнить платёж). Целевой фишинг опирается на разведку: имя, должность, переписку, календарь жертвы. Механика. Подделывается доверие: похожий домен (typosquatting: examp1e.com, example.co), отображаемое имя («Бухгалтерия» с адресом на стороннем домене), украденный шаблон письма. Часто используется «цепочка» — редирект через скомпрометированный сайт или легитимный сервис сокращения ссылок, чтобы скрыть финальный адрес. 2.2 Компрометация деловой переписки (BEC, Business Email Compromise) Атака без вложений и вредоносных ссылок: злоумышленник получает контроль над реальным почтовым ящиком (или правит отображаемое имя), входит в существующую переписку и от имени руководителя или контрагента меняет реквизиты платежа. Ущерб от BEC измеряется миллионами долларов на инцидент, потому что письмо приходит из «доверенного» ящика и обходит антиспам по содержимому. 2.3 Кража и перехват учётных данных Credential stuffing: подбор пар логин/пароль, «утёкших» из других сервисов. Работает там, где нет MFA и нет контроля аномальных входов. Фарминг и подмена DNS: перенаправление браузера на фишинговый портал почтового провайдера. Клипборд-логеры и инфостилеры (вредонос, установленный на машине пользователя): перехватывают пароли, куки сессий, данные 2FA из буфера и браузера. Перехват сессии: кража cookie/токена авторизации позволяет войти без пароля и второго фактора. 2.4 Злоупотребление OAuth и «приложениями» Вместо пароля злоумышленник выманивает согласие на доступ: «подтвердите аккаунт» ведёт на страницу авторизации легитимного провайдера, где пользователь сам выдаёт токен приложению с правами на чтение/отправку почты. Дальше почта читается и отправляется «изнутри», без пароля жертвы. Отдельный риск — избыточные права подключённых приложений и забытые токены. 2.5 Перебор и атаки на второй фактор (MFA fatigue / push-bombing) Серия push-уведомлений или OTP «до победного»: пользователь из раздражения подтверждает вход. Отдельный класс — SIM-swap: перехват SMS-кода через социнженерию оператора связи. 2.6 Вредоносные вложения и макросы

23

3

321

323,,

321

123

сегодня

Выход первой статьи об иб

Тут будут публиковаться статьи по информационной безопасности, и не только. Подписывайтесь