web – PT ESC / Wed, 30 Sep 2026 19:20:11 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 /wp-content/uploads/2026/09/cropped-cropped-large_icon-32x32.png web – PT ESC / 32 32 «Чего не отвечаете?», или История о том, как угнать Telegram-аккаунт без регистрации и смс /why-arent-you-answering-or-the-story-of-how-to-hijack-a-telegram-account-without/ Thu, 13 Mar 2025 16:18:22 +0000 /%d1%87%d0%b5%d0%b3%d0%be-%d0%bd%d0%b5-%d0%be%d1%82%d0%b2%d0%b5%d1%87%d0%b0%d0%b5%d1%82%d0%b5-%d0%b8%d0%bb%d0%b8-%d0%b8%d1%81%d1%82%d0%be%d1%80%d0%b8%d1%8f-%d0%be-%d1%82%d0%be%d0%bc/ 😐 «Чего не отвечаете?», или История о том, как угнать Telegram-аккаунт без регистрации и смс

Недавно мы написали статью о наиболее популярных методах кражи учетных записей в Telegram.

😑 В статье рассматриваются такие схемы, как:

• Распространение фишинговых сообщений о получении Premium-подписки.
• Отправка сообщений с просьбой помочь в голосовании.
• Получение кода авторизации под видом сотрудников техподдержки, правоохранительных органов и т. п.
• Выпуск дубликата сим-карты.
• Копирование файлов с активными пользовательскими сессиями.

Из того, что особенно интересно:

🖥 Рассматриваются нюансы для официальных десктопных версий и веб-клиентов приложений.

🔜 Кража сессий при копировании tdata, (appstore, stable — для macOS) с ключами авторизации устройства (authorization key) остается незаметной для пользователя (отсутствует информация о дополнительной сессии в списке активных устройств).

☝️ Конфиденциальная информация, которая интересует злоумышленников, чаще всего хранится в каталогах:

Для Windows: C:\Users\<Имя пользователя>\AppData\Roaming\TelegramDesktop\tdata

Для Linux: /home/<Имя пользователя>/.local/share/TelegramDesktop/tdata

Для macOS, клиент версии Telegram for Mac: HDD/Users/<Имя пользователя>/Library/Application Support/Telegram Desktop/tdata

Для macOS, клиент версии Telegram for macOS: HDD/Users/<Имя пользователя>/Library/GroupContainers/6N38VWS5BX.ru.keepcoder.Telegram/appstore (stable, если устанавливали через DMG-файл)

🌐 При использовании веб-версий украсть учетную запись можно имея физический доступ к устройству.

Для Google Chrome злоумышленники копируют содержимое каталогов:

Windows: C:\Users\<Имя пользователя>\AppData\Local\Google\Chrome\User Data\Default

Linux: /home/<Имя пользователя>/.config/google-chrome/Default

macOS: HDD/Users/<Имя пользователя>/Library/Application Support/Google/Chrome/Default

💻 Нет разницы, в какой операционной системе злоумышленник использует украденную информацию: tdata с Windows может применяться для авторизации как на Linux, так и на macOS. Это также работает с веб-версиями.

🔗 При переходе по ссылке https://web.telegram.org/ из приложения на компьютере или мобильном устройстве генерируется токен доступа к содержимому учетной записи — возможно войти в веб-версию Telegram. Попробуйте сами!

📝 Даются рекомендации, как выявить нелегитимные сессии и обезопасить себя от рассмотренных атак.

Полный текст статьи читайте на Хабре.

#dfir #macos #win #linux #web
@ptescalator

]]> Бесконечная череда переходов /endless-series-of-transitions/ Fri, 25 Oct 2024 18:10:30 +0000 http://localhost:8080/%d0%b1%d0%b5%d1%81%d0%ba%d0%be%d0%bd%d0%b5%d1%87%d0%bd%d0%b0%d1%8f-%d1%87%d0%b5%d1%80%d0%b5%d0%b4%d0%b0-%d0%bf%d0%b5%d1%80%d0%b5%d1%85%d0%be%d0%b4%d0%be%d0%b2/ Бесконечная череда переходов ♾️

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

Часто киберпреступники используют один уровень перенаправления с легитимного ресурса на вредоносный. Но нам посчастливилось разобрать кейс, где злоумышленник использовал сразу пять последовательных — и, самое главное, разнообразных — техник перенаправления на вредоносный ресурс.

1️⃣ Перенаправление через TikTok

Ссылка начинается с конструкции:


https://www.tiktok.com/link/v2?aid=1988&lang=en&scene=bio_url&target=


TikTok дает возможность поместить в описание профиля (параметр bio_url) ссылки на внешние ресурсы, и перенаправление на них производится по приведенному выше URL-адресу. Кстати, aid=1988 видим не только в рамках исследования этого кейса, но и в отчетах других вендоров. Единственный необязательный параметр в этом запросе — lang, но, видимо, он, так же как и ID, перекочевал и образовал устойчивый префикс в фишинговых кейсах. Это наводит на мысль добавить его в качестве шаблона для средств защиты.

Итак, TikTok вместо смешных рилсов переправляет нас на…

2️⃣ Google AMP 

https://www.google.ca/url?q=amp/s/<phishing_url>


Google AMP — средство ускоренного просмотра веб-страниц, поддерживающих ряд специально созданных для этого ускорения ограничений. Примечательно, что страница загружается не с самого домена, на котором она размещена, а из кэша Google. Собственно, первая интересующая нас веб-страница вполне удовлетворяет этим требованиям, поскольку содержит всего несколько строк JavaScript-кода.

3️⃣ Первый подозрительный домен

Содержит следующий код:


<script type="text/javascript">
    var firstBase64Url = "aHR0cHM6Ly94LmNvbQ==";
    var secondBase64Url = "<Ещё один вредоносный ресурс>";
 
    // Load the first URL for a few seconds
    setTimeout(function() {
      window.open(atob(firstBase64Url), '_blank');
    }, 2000); // 2000 milliseconds = 2 seconds
 
    // After the specified time, load the second URL
    setTimeout(function() {
      window.location.href = atob(secondBase64Url) + "?qrc=" + window.location.hash.substr(1);
    }, 2000); // 2000 milliseconds = 2 seconds
  </script>


При выполнении, когда истекает тайм-аут в 2 секунды, открывается новая вкладка с firstBase64Url (как несложно проверить, это https://x.com/, еще один легитимный ресурс), а в открытой вкладке происходит перенаправление на secondBase64Url. Обе техники — открытие новой браузерной вкладки и включение тайм-аута — нужны для усложнения анализа веб-краулерами.

4️⃣ Переход на secondBase64Url

На данном этапе нам встречается использование Cloudflare Turnstile — встраиваемой мини-капчи, не требующей перевода трафика через Cloudflare (пример интерфейса на скриншоте 1). При ручном анализе кода этой страницы мы уже можем распарсить еще один URL-адрес, но, чтобы все-таки совершить переход на него, надо учиться проходить эту капчу.

5️⃣ Традиционный 3XX код ответа страницы

Здесь все просто: на предыдущем этапе URL из кода через стандартный ответ 302 перенаправляет на конечную фишинговую страницу сбора паролей, имитирующую окно авторизации Microsoft Outlook. Ее интерфейс в окне браузера представлен на скриншоте 2.

💁‍♂️ Советы:

• При анализе фишингового URL-адреса стоит обратить внимание на покрытие обнаруженных техник против переходов (включение пауз, капч, открытие новых вкладок) имеющимися средствами защиты информации: если используемое СЗИ при автоматическом переходе по ссылке не умеет их обходить, то полезным может оказаться просто их детектирование и блокировка соответствующего почтового сообщения.

• Если вы (как пользователь) нажали на подобную ссылку — обратите внимание, насколько часто менялся URL в адресной строке браузера и сколько дополнительных действий было сделано вами и на стороне браузера.


#tip #phishing #web
@ptescalator]]> Фишинговая легитимность /phishing-legitimacy/ Thu, 19 Sep 2024 11:36:53 +0000 http://localhost:8080/%d1%84%d0%b8%d1%88%d0%b8%d0%bd%d0%b3%d0%be%d0%b2%d0%b0%d1%8f-%d0%bb%d0%b5%d0%b3%d0%b8%d1%82%d0%b8%d0%bc%d0%bd%d0%be%d1%81%d1%82%d1%8c/ Фишинговая легитимность 😂
В рамках анализа одного из фишинговых писем мы заметили, как злоумышленники попытались разместить фишинговый контент на странице домена telegra․ph.

Их задумка, вероятно, состояла не в использовании «обширного» функционала сервиса для публикации контента, а в репутации самого домена. И это может сработать, ведь с учетом вполне легитимного наполнения данных WHOIS, SSL-сертификата, а также веб-категории домена telegra․ph у различных агрегаторов эта страница при анализе получит минимум нейтральный статус.

Все это натолкнуло нас на мысль рассмотреть некоторые кейсы использования легитимных сервисов в фишинговых кампаниях, встречающиеся на практике.

1️⃣ Собственно, Telegraph.

Это анонимная блог-платформа известного разработчика. Функционал минималистичен, отсутствуют элементы управления, а текст публикуется с использованием только двух уровней заголовков: Title и сам текст.

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

В каком-то смысле подобный стиль страницы напоминает текстовое электронное письмо, с той лишь разницей, что непосредственно вредоносная ссылка прячется от автоматизированных средств анализа еще за одним уровнем перехода.

2️⃣ Онлайн-среды разработки.

Онлайн-среда разработки, поддерживающая HTML, JavaScript, да еще и с функцией совместной разработки и публикации (вроде JSFiddle), может использоваться для доставки вредоносов или внедрения в цепочку сложных и разнообразных техник редиректа.
Вот, например, размещенный на JSFiddle код с загрузкой png-картинки, исполняющийся без дополнительных действий:


a = document.createElement('a');
document.body.appendChild(a);
a.download = name;
a.href = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAOCAYAAAAmL5yKAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAABWSURBVDhPY0xISPh//0UOA7mAiVyNMH2jBjAwkBQGjD9KGBTEJ6OEO0kG2NvbMwCjnXwDsEU5SS5ANuDhjRCGJbPFSQsDdBfIyMhQZgDIQLK9QLWkDABPsQw5I+5qmAAAAABJRU5ErkJggg==";
a.click();


Проблема подобных ссылок с онлайн-IDE понятна: под них легко придумать фишинговое содержание письма («я разработчик, вот мое портфолио с проектами»), а репутация их доменов не даст сработок у средств анализа.

Кроме того, для анализа содержимого страницы потребуются продвинутые средства, позволяющие эмулировать переходы по страницам или загрузку контента путем выполнения JavaScript-кода.

3️⃣ IPFS.

Известный протокол распределенного хранения файлов стал популярным инструментом среди злоумышленников. Точнее, не сам протокол, а так называемые IPFS-шлюзы — онлайн-сервисы, предоставляющие доступ к файлам, размещенным с использованием этой технологии без специальных клиентов. Они являются своего рода прокси для доступа к размещенным в подобном хранилище HTML-страницам, что позволяет злоумышленнику не заморачиваться с хостингом страницы.

Кроме того, файл с IPFS-хранилища невозможно удалить: IPFS-хостинг может лишь повесить заглушку о вредоносном содержимом запрашиваемого файла, при этом самому хостингу, чтобы найти такой контент в хранилище, требуется время и ресурсы.

✋ Чтобы защититься от подобной эксплуатации легитимных сервисов, при защите периметра можно использовать средства защиты, проверяющие контент веб-содержимого URL-ссылок перед вынесением вердикта. А при получении подобных ссылок на личную почту или в мессенджере лучше перестраховаться и проверить их в нескольких сервисах, показывающих репутацию индикаторов компрометации.

#web #ti #tip
@ptescalator]]> Форму авторизации видишь? Нет. Вот и я не вижу. А она есть 🤔 /do-you-see-the-authorization-form-no-neither-do-i-but-its-there/ Thu, 04 Jul 2024 15:58:03 +0000 /%d1%84%d0%be%d1%80%d0%bc%d1%83-%d0%b0%d0%b2%d1%82%d0%be%d1%80%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d0%b8-%d0%b2%d0%b8%d0%b4%d0%b8%d1%88%d1%8c-%d0%bd%d0%b5%d1%82-%d0%b2%d0%be%d1%82-%d0%b8-%d1%8f-%d0%bd/ Форму авторизации видишь? Нет. Вот и я не вижу. А она есть 🤔

В ходе недавнего расследования одного из инцидентов мы столкнулись с эксплуатацией злоумышленниками уязвимости в CMS Bitrix, связанной со множеством доступных эндпойнтов для аутентификации.

Несмотря на то, что данная уязвимость не является новой, ей все еще подвержено немалое количество веб-сайтов.

Многие администраторы закрывают доступ к странице /bitrix/admin, при этом не догадываясь, что есть еще ряд скриптов, использующих компонент prolog_admin_before.php, благодаря которому можно получить доступ к форме авторизации 🤕

Среди них можно выделить:


— /bitrix/components/bitrix/desktop/admin_settings.php
— /bitrix/components/bitrix/map.yandex.search/settings/settings.php
— /bitrix/components/bitrix/player/player_playlist_edit.php
— /bitrix/tools/autosave.php 
— /bitrix/tools/get_catalog_menu.php
— /bitrix/tools/upload.php

Именно эндпойнт player_playlist_edit.php был использован злоумышленниками для аутентификации: 


POST /bitrix/components/bitrix/player/player_playlist_edit.php?login=yes

Вероятно, для доступа к системе использовались стандартные учетные данные, так как в логах веб-сервера мы увидели всего лишь несколько POST-запросов, предшествующих началу сессии.

👀 Эта уязвимость — наряду со многими другими — описана в отчете об уязвимостях Bitrix (п. 1.4.1).

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


GET /ololo/?SEF_APPLICATION_CUR_PAGE_URL=/bitrix/admin/

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

#dfir #detect #cve #web
@ptescalator

]]>