Интернационализированные доменные имена (IDN) позволяют регистрировать адреса на национальных алфавитах — кириллице, китайских иероглифах, арабской графике. В офисных документах такие ссылки выглядят привычно, но за видимым текстом может скрываться совершенно другой адрес. Статья объясняет, как работает кодировка Punycode, почему стандартные средства Office не показывают истинный URL, какие инструменты помогут извлечь и проверить подозрительные ссылки, и как построить процесс верификации, чтобы не стать жертвой фишинга или скрытой перенаправляющей атаки.
- Суть проблемы: что такое IDN и почему это важно для офисных файлов
- Как IDN-ссылки хранятся в популярных форматах
- Microsoft Office (OOXML: .docx, .xlsx, .pptx)
- OpenDocument (.odt, .ods, .odp)
- Устаревшие бинарные форматы (.doc, .xls, .ppt)
- Инструментарий для извлечения и анализа ссылок
- Командная строка и скрипты (массовая обработка)
- Графические и онлайн-инструменты (разовый анализ)
- Специализированные сканеры документов
- Пошаговый процесс диагностики подозрительного файла
- Таблица: сравнение методов извлечения ссылок по форматам
- Признаки подозрительной IDN-ссылки: чек-лист для быстрой оценки
- Типичные ошибки при диагностике и как их избежать
- Сценарии реагирования: что делать после обнаружения
- Профилактика: как снизить риск на уровне организации
- Расширенная диагностика: JavaScript, QR-коды и скрытые объекты
- Пример разбора реального инцидента (обобщённый)
- Чек-лист для внедрения в процесс безопасности
- Практический итог: от теории к действию
Суть проблемы: что такое IDN и почему это важно для офисных файлов
IDN (Internationalized Domain Names) — это домены, содержащие символы вне базового набора ASCII (латиница, цифры, дефис). Для работы в DNS они преобразуются в ASCII-совместимую форму через алгоритм Punycode: префикс xn-- и закодированная последовательность. Например, пример.рф в DNS хранится как xn--e1afmkfd.xn--p1ai.
В офисных файлах (Word, Excel, PowerPoint, PDF, ODT) гиперссылка состоит из двух частей: видимого текста (что видит пользователь) и целевого URL (куда ведёт переход). Автор документа может написать в тексте банк.рф, а в свойствах ссылки указать xn--b1aew.xn--p1ai или даже xn--80ak6aa92e.com (визуально похожий на кириллицу, но в зоне .com). При наведении курсора Office показывает целевой URL, но часто в усечённом или декодированном виде, что затрудняет обнаружение подмены.
Основные сценарии опасности:
- Атаки гомографов (homograph attacks): использование символов разных алфавитов, выглядящих идентично (кириллическая «а» U+0430 vs латинская «a» U+0061). Домен хроросбанк.рф (с кириллическими «х», «о», «р») визуально неотличим от латинского, но ведёт в другую зону.
- Скрытая перенаправляющая ссылка: видимый текст — легитимный сайт, реальный URL — фишинговый или вредоносный ресурс.
- Обфускация через Punycode: длинные закодированные строки (xn--…) скрывают истинное назначение, особенно если пользователь не привык их читать.
- Эксплуатация доверия к внутренним документам: вредоносная ссылка в корпоративном отчёте, прайс-листе или регламенте воспринимается как безопасная.
Стандартные средства Office (наведение курсора, диалог «Изменить ссылку») часто декодируют Punycode обратно в Unicode для удобства чтения, что маскирует подмену. Для надёжной диагностики нужно извлечь «сырой» URL в кодировке Punycode и сравнить его с визуальным представлением.
Как IDN-ссылки хранятся в популярных форматах
Понимание внутреннего устройства форматов помогает выбрать правильный инструмент извлечения.
Microsoft Office (OOXML: .docx, .xlsx, .pptx)
Файлы — это ZIP-архивы с XML-структурой. Гиперссылки хранятся в файлах отношений (_rels/*.rels) и в теле документа (word/document.xml, xl/worksheets/sheet1.xml). Атрибут Target содержит URL в исходной форме — именно так, как его ввёл автор. Если автор вставил Punycode, он там и останется. Если вставил Unicode — Office может сохранить его как UTF-8 или преобразовать в Punycode при сохранении, поведение зависит от версии и настроек.
Ссылки в PDF — это аннотации типа /Link с действием /URI. URI хранится в виде строки, часто уже в Punycode, если создаватель PDF корректно обработал IDN. Однако некоторые генераторы PDF записывают Unicode напрямую, что создаёт проблемы при парсинге.
OpenDocument (.odt, .ods, .odp)
Также ZIP-архивы с XML. Ссылки находятся в content.xml (атрибут xlink:href). Обычно сохраняются в UTF-8, но при экспорте в PDF/Office могут конвертироваться.
Устаревшие бинарные форматы (.doc, .xls, .ppt)
Сложнее для парсинга без специализированных библиотек (olefile, libolecf). Ссылки хранятся в потоках OLE. Для разового анализа проще конвертировать в современный формат через LibreOffice в headless-режиме.
Инструментарий для извлечения и анализа ссылок
Выбор инструмента зависит от объёма файлов, глубины анализа и автоматизации.
Командная строка и скрипты (массовая обработка)
- oletools (oleid, olevba, oledir): набор утилит для анализа OLE/OOXML. oleid находит все встроенные объекты и ссылки, показывает «сырые» URL.
- pdfx / pdf-parser (Didier Stevens): извлечение URI из PDF-аннотаций, включая JavaScript-действия.
- python-docx, openpyxl, python-pptx, odfpy: библиотеки для программного доступа к XML-частям. Позволяют написать скрипт, пробегающий по всем Target/xlink:href и выводящий пары «видимый текст — целевой URL».
- exiftool: универсальный экстрактор метаданных, находит URL в свойствах файла и во встроенных объектах.
Графические и онлайн-инструменты (разовый анализ)
- Office-встроенный редактор ссылок (Ctrl+K): показывает целевой URL, но может декодировать Punycode. Полезно для быстрой проверки единичных ссылок.
- URLhaus, VirusTotal, URLVoid: проверка извлечённых URL на репутацию. Не анализируют сам файл, но подтверждают/опровергают вредоносность адреса.
- IDN/Punycode конвертеры (verisignlabs.com, punycoder.com): ручная перекодировка Unicode ↔ Punycode для сравнения.
- Homograph detection tools (dnstwist, urlcrazy): генерация похожих доменов для проверки, не зарегистрирован ли «двойник» легитимного адреса.
Специализированные сканеры документов
- MalwareBazaar, Hybrid Analysis, ANY.RUN: песочницы, исполняющие файл и фиксирующие сетевую активность (включая переходы по ссылкам при открытии).
- Corporate DLP/EDR решения: часто имеют модули «Content Disarm & Reconstruction» (CDR), удаляющие или переписывающие ссылки при прохождении через шлюз.
Пошаговый процесс диагностики подозрительного файла
- Изолируйте файл. Не открывайте в основной среде. Используйте виртуальную машину, песочницу или отдельный стенд без доступа к корпоративной сети.
- Извлеките все URL автоматически. Пример однострочника на Python для .docx:
import zipfile, xml.etree.ElementTree as ET, sys
with zipfile.ZipFile(sys.argv[1]) as z:
for name in z.namelist():
if name.endswith(‘.rels’) or name in (‘word/document.xml’,’xl/worksheets/sheet1.xml’,’ppt/slides/slide1.xml’):
data = z.read(name)
root = ET.fromstring(data)
ns = {‘r’: ‘http://schemas.openxmlformats.org/officeDocument/2006/relationships’}
for rel in root.findall(‘.//r:Relationship’, ns) if ‘rels’ in name else root.findall(‘.//{*}hyperlink’):
tgt = rel.get(‘{http://schemas.openxmlformats.org/officeDocument/2006/relationships}Target’) or rel.get(‘{http://schemas.openxmlformats.org/officeDocument/2006/relationships}id’)
if tgt: print(tgt) - Нормализуйте извлечённые URL. Приведите все к Punycode (ASCII). Сравните с видимым текстом ссылки (если извлекли и его). Расхождения — признак подмены.
- Проверьте на гомографы. Прогоните домен через dnstwist —registered или онлайн-аналог. Если найдены похожие зарегистрированные домены — риск высок.
- Оцените репутацию. Отправьте URL в VirusTotal / URLhaus / AbuseIPDB. Обратите внимание на: возраст домена, SSL-сертификат (Let’s Encrypt на фишинге — частый признак), IP-хостинг (bulletproof, тор-ноды), наличие в списках фишинга.
- Проверьте цепочку перенаправлений. curl -I -L покажет все 301/302/307, конечный хост и заголовки. Часто IDN-ссылка ведёт на легитимный сайт, который редиректит на вредоносный.
- Зафиксируйте выводы. Сохраните: файл (хэш SHA-256), извлечённые URL (в Punycode и Unicode), видимый текст, результаты репутационных проверок, скриншоты редиректов. Это понадобится для инцидента и обучения фильтров.
Таблица: сравнение методов извлечения ссылок по форматам
| Формат | Простейший способ (GUI) | Автоматизация (CLI/скрипт) | Особенности IDN |
|---|---|---|---|
| .docx / .xlsx / .pptx | Ctrl+K в Office, «Изменить ссылку» | python-docx / openpyxl / python-pptx, oletools | Target в .rels — «сырой» ввод автора; document.xml может содержать декодированный Unicode |
| Панель «Ссылки» в Adobe/Acrobat, pdfinfo | pdf-parser.py, pdfx, pymupdf (fitz) | URI в аннотации /Link → /A → /URI; часто уже в Punycode | |
| .odt / .ods / .odp | Правка → Гиперссылки в LibreOffice | odfpy, распаковка + парсинг content.xml | xlink:href в UTF-8; при экспорте в PDF конвертируется |
| .doc / .xls / .ppt (бинарные) | Только через Office / LibreOffice | libreoffice —headless —convert-to docx:xlsx:pptx + далее как OOXML | Конвертация может изменить кодировку URL — проверяйте до и после |
Признаки подозрительной IDN-ссылки: чек-лист для быстрой оценки
- Домен в Punycode (xn--) в зоне, где это нетипично (например, xn--80asehdb.com вместо ожидаемого bank.ru).
- Смешанные скрипты в одной метке: рауpal.com (кириллица + латиница). RFC 5890 рекомендует отклонять такие домены, но браузеры и почтовые клиенты часто их отображают.
- Визуальный текст ссылки — известный бренд, целевой URL — другой домен (даже если тоже IDN).
- Длинная поддоменная цепочка с IDN на предпоследнем уровне: security.xn--p1ai.phishersite.com — пользователь видит «security.рф», но зона — phishersite.com.
- Использование редких TLD (.xyz, .top, .cf, .ga, .ml) в сочетании с IDN — частый признак массовой регистрации для фишинга.
- Отсутствие или невалидный SSL-сертификат на конечном хосте после редиректов.
- Ссылка ведёт на IP-адрес, а не на домен, но видимый текст — доменное имя.
Типичные ошибки при диагностике и как их избежать
- Доверяете только наведению курсора. Office декодирует Punycode в Unicode для отображения. Визуально «банк.рф» может быть и xn--b1aew.xn--p1ai (легитимно), и xn--80ak6aa92e.com (подмена). Всегда смотрите «сырой» URL в XML/PDF-структуре.
- Игнорируете редиректы. Ссылка ведёт на легитимный сайт, но тот делает 302 на фишинг. Проверяйте полную цепочку curl -L или песочницу.
- Проверяете только домен, а не полный URL. Параметры запроса (?redirect=evil.com, ?token=…) могут менять поведение страницы. Извлекайте и анализируйте полный URI.
- Не учитываете контекст документа. Ссылка на xn--80aswg.xn--p1ai в документе «Прайс-лист поставщика ООО Ромашка» может быть легитимным сайтом поставщика на .рф. Сравнивайте с ожидаемыми доменами организации.
- Используете онлайн-конвертеры для корпоративных данных. Не загружайте конфиденциальные файлы в публичные сервисы. Разворачивайте инструменты локально.
Сценарии реагирования: что делать после обнаружения
Сценарий А: Подтверждённый фишинг / вредоносная ссылка
- Заблокируйте домен/URL на периметре (DNS-фильтр, прокси, EDR).
- Расследуйте, кто получил документ (почтовый шлюз, общая папка, мессенджер).
- Отправьте файл в SOC / на анализ в песочницу для выявления полезной нагрузки (макросы, эксплойты, QR-коды с такими же URL).
- Проведите точечное обучение получателей: покажите конкретный пример, как выглядела подмена.
- Добавьте IOC (Indicator of Compromise) в SIEM: хэш файла, домен, IP, URL.
Сценарий Б: Подозрительная, но не подтверждённая ссылка (новый домен, нет репутации)
- Добавьте в «серый список» прокси/DNS — блокируйте с логированием, не прерывая работу.
- Запросите у отправителя (если внутренний) подтверждение легитимности.
- Настройте мониторинг DNS-запросов к этому домену в корпоративной сети.
- Через 24–48 часов перепроверьте репутацию — часто новые фишинговые домены попадают в базы за сутки.
Сценарий В: Легитимный IDN-домен партнера/клиента
- Добавьте домен в allow-list корпоративного резолвера/прокси, чтобы не ломать бизнес-процессы.
- Зафиксируйте в базе знаний: «Домен xn--… (визуально партнёр.рф) — легитимный, используется в договорах/счетах».
- Настройте DLP/EDR на пропуск этого URL без алерта, но с логированием.
Профилактика: как снизить риск на уровне организации
- CDR (Content Disarm & Reconstruction) на почтовом шлюзе и веб-прокси. Технология удаляет все активные элементы (ссылки, макросы, встроенные объекты) и пересобирает файл. Ссылки либо удаляются, либо заменяются на безопасные текстовые представления с пометкой «Ссылка удалена политикой безопасности».
- Политика «только plain-text ссылки во входящих документах». Настройте DLP на поиск гиперссылок во вложениях и принудительное преобразование в текст при прохождении входящей почты.
- Обучение сотрудников распознаванию Punycode. Простое правило: если в строке браузера или при наведении видите xn-- — это IDN. Если ожидаете латиницу — повод насторожиться.
- Мониторинг регистраций гомографов бренда. Автоматизированный запуск dnstwist по списку корпоративных доменов раз в неделю с алертом на новые зарегистрированные похожие IDN.
- Жёсткая политика макросов и ActiveX. Часто IDN-ссылка — только часть атаки: макрос скачивает полезную нагрузку при клике. Блокировка макросов из интернета (настройка Office «Disable all macros except digitally signed») снижает вектор.
Расширенная диагностика: JavaScript, QR-коды и скрытые объекты
Ссылки могут быть не только в явных гиперссылках. Проверяйте также:
- JavaScript в PDF: действие /JS или /JavaScript может формировать URL динамически (конкатенация строк, Base64). pdf-parser.py —search javascript находит такие скрипты.
- QR-коды на страницах: извлекайте изображения (binwalk -e, pdfimages) и декодируйте (zbarimg, онлайн-ридеры). QR часто ведёт на тот же IDN-домен.
- Встроенные OLE-объекты: Excel-лист внутри Word, Visio внутри PowerPoint — у каждого свой набор ссылок. Рекурсивно распаковывайте вложения.
- Поля формы (Form Fields) и закладки: в Word закладка (w:bookmarkStart) может ссылаться на внешний URL через гиперссылку на закладку.
- Метаданные файла: свойства «Гиперссылка базы» (Hyperlink Base), «Комментарии», «Тема» иногда содержат URL.
Пример разбора реального инцидента (обобщённый)
Поступил файл Счёт_№123.docx от якобы известного поставщика. В теле — таблица с товарами, внизу ссылка «Скачать оригинал счёта в PDF». Наведение в Word показывает https://xn--80asehdb.xn--p1ai/invoice.pdf. Сотрудник не заметил xn-- и кликнул.
Диагностика:
- Распаковка .docx → word/_rels/document.xml.rels → Target=»https://xn--80asehdb.xn--p1ai/invoice.pdf».
- Punycode декодируется как пример-сайта.рф (визуально похоже на домен поставщика пример-сайта.рф, но последняя буква «а» — кириллическая).
- dnstwist показывает: легитимный домен xn--e1afmkfd.xn--p1ai (все буквы кириллица), фишинговый xn--80asehdb.xn--p1ai (смешанные скрипты) зарегистрирован 3 дня назад.
- curl -L → 302 на http://185.xxx.xxx.xxx/malware.exe (без SSL, прямой IP).
- Файл заблокирован, домен добавлен в блок-лист, сотрудник проинформирован, рассылка о инциденте разослана отделу закупок.
Ключевой вывод: визуальное сходство доменов на разных скриптах — основной вектор атаки. Автоматическое извлечение Punycode и сравнение с эталонными доменами партнёров позволило бы заблокировать письмо на шлюзе.
Чек-лист для внедрения в процесс безопасности
- [ ] Настроен автоматический парсинг вложений на почтовом шлюзе (извлечение URL, нормализация в Punycode).
- [ ] Интегрирован репутационный сервис (VirusTotal API, URLhaus, локальная база IOC).
- [ ] Развёрнут CDR или политика удаления гиперссылок для входящих внешних файлов.
- [ ] Еженедельный запуск dnstwist по корпоративным доменам с алертом в SIEM.
- [ ] Обучающий материал для сотрудников: «Как выглядит Punycode в строке браузера и при наведении в Word/Outlook».
- [ ] Инструкция аналитику SOC: пошаговый порядок действий при алерте на IDN-ссылку (извлечение → нормализация → репутация → редиректы → вердикт).
- [ ] База эталонных доменов партнёров/клиентов (в Punycode и Unicode) для автоматического сопоставления.
Материал носит информационный характер и не заменяет профессиональную экспертизу в области информационной безопасности. При обнаружении подозрительной активности, связанной с IDN-доменами в корпоративных документах, обратитесь к специалистам SOC / CERT вашей организации. Репутационные базы и инструменты сканирования могут давать ложные срабатывания или пропускать свежие угрозы; решения о блокировке доменов и файлах принимайте на основе комплексной оценки рисков.
Практический итог: от теории к действию
Диагностика IDN-доменов в офисных файлах — это не разовая проверка, а повторяемый процесс: извлечение «сырого» URL в Punycode, нормализация, проверка на гомографы и репутацию, анализ цепочки редиректов, принятие вердикта и обновление защитных периметров. Начните с внедрения автоматического парсера вложений на почтовом шлюзе — это закроет 80% векторов доставки. Параллельно настройте мониторинг гомографов ваших брендов и обучите ключевых пользователей (бухгалтерия, закупки, руководство) распознавать префикс xn-- как сигнал «проверь дважды». Регулярная отработка инцидентов на учебных примерах формирует мышление, которое срабатывает быстрее любого технического фильтра.
