ESCalator
6.51K subscribers
471 photos
1 video
18 files
188 links
Tips and tricks от команды экспертного центра безопасности Positive Technologies (PT ESC)
Download Telegram
Reflection Relay. Никогда такого не было, и вот опять (CVE-2025-33073) 😐

Одной из самых популярных техник для повышения привилегий в домене Active Directory является Relay. Долгое время всем были хорошо известны атаки NTLM Relay, но не так давно было описано несколько техник, позволяющих выполнить Relay с использованием Kerberos. Многим будет понятнее, о чем речь, если сказать SMB Relay или ADCS ESC8. Но техник для Relay-атак гораздо больше, выполнять их можно на HTTP, SMB, RPC, MSSQL, WinRMS, LDAP и, вероятно, еще на какие-то протоколы, которые будут описаны в будущем.

Если Relay-атакам подвержены NTLM и Kerberos в связке с различными протоколами, то как защититься от них? На самом деле существуют встроенные механизмы защиты, которые просто нужно отладить. Подробнее о каждом из них поговорим в следующих постах. Но сегодня хочется акцентировать внимание на недавно обнаруженной уязвимости — CVE-2025-33073.

❗️ Сначала немного о самой уязвимости. Эксплуатация проходит в связке с Relay-атакой — хоть Kerberos, хоть NTLM. Корни ее уходят в далекий 2008 год. В том году Microsoft выпустила бюллетень по безопасности MS08-068, после которого перестала работать техника Relay, когда компьютер атаковал бы сам себя.

В то время еще не были широко известны техники типа Coerce, но ярлычками уже активно пользовались (например, LNK-файлами, которые хакеры разбрасывали в доступных для записи общих папках SMB) для получения сессии администратора на устройстве и выполнения Relay-атаки на него же для повышения привилегий. Такой Relay будем называть Reflective.

С тех пор появились техники принуждения к аутентификации — Coerce- и сами Relay-атаки стали более изощренными, но Reflective Relay именно через сеть не было. Но вот наступает 2021 год, и в сети появляется исследование, в котором достаточно подробно описывается механизм Kerberos-аутентификации, в том числе на SMB-сервере. Нет смысла повторятся, стоит лишь сказать, что там впервые фигурирует странное хостовое имя:

fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAA


Кроме того, автор справедливо замечает, что строка подобного вида вполне может быть DNS-записью. Несмотря на фундаментальность исследования, уязвимостей в механизме найдено не было.

🗓 Вот наступает 2025 год, и 11 июня выходит два исследования подряд: первое и второе. Они тесно связаны друг с другом и основаны на ресерче 2021 года, поэтому читать их лучше именно в таком порядке. В этих исследованиях демонстрируется возможность Reflective Relay как NTLM, так и Kerberos.

Про эксплуатацию CVE-2025-33073 в посте ниже👇

#cve #win #offensive
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍87👏2
🧤 Теперь про эксплуатацию уязвимости CVE-2025-33073:

• Учетная запись в домене с самыми рядовыми привилегиями.
• На атакуемом устройстве не настроено принудительное требование подписи SMB.
• На атакуемом устройстве не стоит патч, устраняющий уязвимость CVE-2025-33073, который был выпущен в июне 2025 года.

И дополнительно одно из двух:

• Либо возможность регистрации DNS-записи в домене (по умолчанию могут все пользователи домена).
• Либо нахождение в одной широковещательной сети с атакуемым устройством (проведение атаки NBNS, LLMNR и mDNS-спуфинга).

Рассмотрим два варианта эксплуатации с дампом локальных учетных данных из SAM и SECURITY.

1️⃣ Первый вариант с DNS-записью (скриншот 1):

1. Атакующий регистрирует DNS-запись формата localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

2. Атакующий выполняет Coerce-атаку на устройство без SMB Signing.

3. Устройство разрешает имя по DNS, в котором получает IP-адрес атакующего.

4. Устройство проходит аутентификацию на сервере атакующего.

5. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.

2️⃣ Второй вариант со спуфингом (скриншот 2):

1. Атакующий запускает спуфинг с ответом на имя хоста localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

2. Атакующий выполняет Coerce-атаку на устройство в локальной сети.

3. Устройство пытается разрешить имя по DNS, не находит его и переходит к многоадресным протоколам.

4. Атакующий сообщает устройству, что имя принадлежит ему.

5. Устройство проходит аутентификацию на сервере атакующего.

6. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.

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

Рекомендации по защите от уязвимости:

Установите обновления безопасности от 10 июня 2025 года.

Настройте принудительное требование подписи SMB для SMB-служб контроллеров и рабочих станций.

В следующих постах расскажем, как детектить уязвимость 😉

#cve #win #offensive
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👍15👏97
В продолжение предыдущих публикаций рассказываем, как обнаруживать уязвимость CVE-2025-33073 🕵️‍♂️

1️⃣ Отслеживать DNS-запросы с Marshalled-суффиксом

В атаках Reflection Relay злоумышленник вынуждает службы выполнять DNS-запросы к поддельным именам с паттерном 1UWhRCA + 37–45 символов Base64. Записи вида srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.example.com или localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.example.com — индикаторы попытки Reflection Relay (NTLM, Kerberos).

• Что мониторить

Все DNS-запросы, где имя узла заканчивается на marshalled-часть (1UWhRCA + 37-45 символов Base64).

• События

Sysmon Event ID 22 (DNS-запросы на узлах).

События DNS-серверов, содержащие такие запросы.

2️⃣ Ловить LDAP-поиск с marshalled-суффиксом

Reflection Relay вызывает LDAP-запросы от атакуемого узла к контроллеру домена, в которых параметр name= содержит поддельное DNS-имя формата [имя_узла]1UWhRCA[Base64]. Это происходит при выполнении Relay-атаки обратно на жертву.

• Что мониторить:

Запросы LDAP, в которых параметр name= содержит конструкцию:
"[имя_хоста]1UWhRCA[символы Base64]"

• События:

Windows Security Event 1644 ("A search was performed in Active Directory") на контроллерах домена.

3️⃣ Знать механику CVE-2025-33073 и Coerce-атаки

Как работает уязвимость:

• Coerce-атаки (PetitPotam, PrinterBug) вынуждают жертву подключиться к поддельному DNS-имени.
• Windows ошибочно считает запрос локальным из-за marshalled-суффикса, отключая проверки NTLM и Kerberos.
• Это позволяет атакующему выполнить Relay сессии обратно на жертву для получения RCE с правами SYSTEM.

Примеры Coerce-атак:

• PetitPotam: принуждение через уязвимость в EFS RPC, заставляющее LSASS инициировать аутентификацию;
• PrinterBug: принудительная отправка NTLM-хешей через уязвимость в службе печати Windows (MS-RPRN).

4️⃣ Опираться на примеры сработавших правил корреляции

При реализации CVE-2025-33073 совместно с PetitPotam для дампа учетных данных сработали следующие правила корреляции:

• Coerce_Auth: правило обнаруживает Coerce-атаки на узел с целью перехвата хеша машинной учетной записи атакованного узла, а также пытается определить по названию используемого пайпа, какая техника атаки используется (netdfs = DFSCoerce; spoolss = PrinterBug; fssagentrpc = ShadowCoerce; efsrpc, lsarpc, samr, lsass, netlogon = PetitPotam; msftewds = WSPCoerce) и какой инструмент применяется.

• SVCCTL_Connection: правило обнаруживает подключение к именованному каналу svcctl, который ответственен за удаленное конфигурирование служб Windows на узлах через Service Control Manager, что может привести к выполнению произвольного кода;

Remote_Password_Dump: правило обнаруживает удаленный дамп паролей через обращение к именованному каналу WINREG.

5️⃣ Использовать примеры SIGMA-правил

Если у вас нет MaxPatrol SIEM, то вот вам пример простых SIGMA-правил:

Для Sysmon Event ID 22.

Для Windows Security Event 1644.

6️⃣ Использовать наши публичные Suricata-сигнатуры для обнаружения этой атаки

#detect #cve #win #sigma #rules
@ptescalator
🔥21👍109👏1
А у нас большое событие! 😡

В PT ESC открылась Антивирусная лаборатория: мы объединили экспертизу «ВИРУСБЛОКАДА» с нашей, анализируем множество сэмплов и самостоятельно пишем сигнатуры для антивирусной базы.

🌚 Более того, на днях эксперт Позитива впервые создал детектирующую запись для антивирусного движка. А перед этим освоил теорию и практику новой для нас технологии и навык использования необходимого набора инструментов. Сможете угадать название детекта? Голосуйте в опросе ниже.

Если у вас есть интересный вредонос, который надо проанализировать и для которого необходимо создать правила обнаружения в наших продуктах, то не стесняйтесь: [email protected]

#avlab
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🤯13🔥114👎2😁2
Вредоносы в SYSVOL: ищем источник 😐

Допустим, мы расследуем инцидент с шифровальщиком. Для запуска шифровальщика хакеры использовали групповую политику (например, прописали задачу планировщика). Сам вредонос они положили в папку SYSVOL на контроллере домена (DC).

🥷 Как понять, откуда действовал хакер? В этом посте сфокусируемся на файловом следе.

Логика простая: чтобы положить файл в SYSVOL, хакер должен был так или иначе «зайти» на DC. Поэтому смотрим, когда был создан файл (кстати, поэтому важно сначала собрать данные для расследования, а потом уже зачищать системы), и соотносим эту информацию с входами в систему.

Кажется, все просто, но есть нюанс: содержимое каталога SYSVOL реплицируется между DC с помощью DFSR (Distributed File System Replication). То есть хакеру достаточно положить вредоносный файл на один DC, а дальше система автоматически распространит его по всем остальным. Как понять, какой DC был исходным, особенно если DC много?

Посмотрим отладочные логи DFSR на произвольном DC из тех, на которых вредонос попал в папку SYSVOL. Обычно эти логи находятся в папке %systemroot%\debug, имена файлов имеют вид Dfsrxxxxx.log и Dfsrxxxxx.log.gz (.gz в Windows? Да!). Логи текстовые, вполне поддаются грепу, но при этом некоторые события имеют многострочный формат, — учитывайте это, если не хотите потерять контекст.

Поищем в логах имя нашего вредоноса (пусть это будет badfile.exe). Если мы нашли исходный DC с первого раза, мы должны найти в логах подобное сообщение:

20250526 02:44:24.906 5628 USNC  2871 UsnConsumer::CreateNewRecord LDB Inserting ID Record:
+ <...>
+ name badfile.exe


Если коротко, то оно свидетельствует о появлении нового файла в реплицируемой папке, то есть искомый файл был изначально размещен на этом DC. В этом случае можно переходить к последнему абзацу в посте ниже 🙂

Можно на всякий случай перепроверить это в журнале $UsnJrnl:$J:

badfile.exe,.exe,132035,6849,257939,4,.\Windows\SYSVOL\domain\scripts,52168700184,2025-05-25 23:44:23.6245532,FileCreate,Archive,436154648

Видно, что файл создается на файловой системе (FileCreate).

Если бы файл был реплицирован, это выглядело бы так:

2025-03-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,FILE_CREATE,archive,7|109885

2025-05-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,RENAME_OLD_NAME,archive,7|109885

2025-05-25 23:44:25 +0000 UTC,badfile.exe,Windows\SYSVOL\domain\scripts\badfile.exe,RENAME_NEW_NAME,archive,5|269425


Видно, что файл сначала создается в папке DFSR, а потом уже переносится в SYSVOL.


Если же вредонос был реплицирован на исследуемый DC, мы увидим в логах DFSR подобное сообщение:

20250526 02:44:24.949 4452 INCO  3065 InConnection::ReceiveUpdates Received: uid:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 gvsn:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 fileName:badfile.exe session:86382 connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} csId:{F0285778-7EF8-4808-85D7-68223AA11FB5} csName:SYSVOL Share


Очень интересно, но ничего не понятно.

Продолжение в следующем посте 🔽

#ir #dfir #DFSR
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17127🔥4
Продолжаем искать файловый след из поста выше 🐾

Чтобы понять, с какого DC реплицировался файл, нужно узнать, какому хосту соответствует указанный connId (это значение статично и соответствует однонаправленной связи между двумя машинами).

Как это сделать

1️⃣ Можно посмотреть таблицу соответствия в файле \System Volume Information\DFSR\Config\Replica_<GUID группы репликации>.XML. Поищем в нем наш connId и увидим примерно следующее:

<DfsrConnection>
<ConnectionGuid>C62DFB26-63FA-4E9F-B533-0F487BF8E043</ConnectionGuid>
<...>
<PartnerName>DC02</PartnerName>
<...>
<PartnerDns>dc02.corp.local</PartnerDns>
<...>
</DfsrConnection>


2️⃣ Можно поискать в логах DFSR события, содержащие одновременно интересующий нас connId и слова "partnerDns", "partnerName" или "partnerAddress". Можем обнаружить что-то типа:

20250314 01:22:31.307 6304 DOWN  3959 [ERROR] DownstreamTransport::EstablishConnection EstablishConnection failed. Check that the connection partner is valid. If not then recreate the connection with valid partner. connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} rgName:Domain System Volume partnerName:DC02 partnerDns:dc02.corp.local


3️⃣ Если DC «живы», то информацию о GUID’ах можно извлечь с помощью утилиты Dfsradmin. Этот способ разбирать не будем — более подробно про логи DFSR можно почитать по ссылке.

Итак, в ходе расследования мы выяснили, что изначально вредоносный файл был размещен на DC02.

Дело за малым — узнать, кто и откуда заходил на этот DC и положил туда этот файл. Журналы ОС и SUM в помощь — никто не обещал, что будет легко! 🙂

#ir #dfir #DFSR
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25👏87🔥43
Нефритовый металл: уже не новая группа Telemanmilconfav атакует военные организации? 🪖

В марте исследователи из F6 опубликовали материал о группировке Telemancon, атаковавшей промышленные организации. Группа была названа в честь использования сервиса telegra.ph, man — от слова manufactory, con — из-за сохранения нагрузки в %userprofile%\Contacts\.

Нами были обнаружены несколько файлов, связанных с этой группой. Один из них — Письмо_в_АО_УАПО_запрос_РКМ_и_закл_ВП.scr 📬

При запуске, как и в случае с семплами, описанными F6, SCR-скрипт открывал decoy-документ PDF и вредоносный PowerShell-скрипт в той же %userprofile%\Contacts\, в честь которой назвали эту группу: тематика decoy-документа была связана с войсками национальной гвардии и оборонными заказами

Но больший интерес представляет обнаруженный архив Гуманитарная_помощь_накладные_июнь_2025_1.zip. Он содержит пять SCR-скриптов: четыре из них маскируются под XLSX-файлы, один — под картинку (скриншот 1).

После запуска каждый из них дропает два файла: PowerShell-скрипт (в папку %userprofile%\Favorites\) и легитимный XLSX-файл (в одном из пяти случаев это картинка). Excel-документы и картинка отсылали к информации о гуманитарной помощи для военных (скриншот 2).

🫤 Сами инструменты претерпели изменения: их стало сложнее анализировать и они повысили устойчивость к защитным механизмам. Основные изменения коснулись TMCDropper. Раньше код имел структуру с отдельными зашифрованными модулями, а в новой версии используется VM-based obfuscation.

Сам же TMCShell не претерпел больших изменений: в него добавили дополнительную проверку на наличие файлов с расширением .ps1, чтобы избежать автозапуска на виртуальных машинах.

Ключевым изменением является использование глобальной переменной, например $qvwml (для каждого скрипта они разные), которая управляет процессом расшифровки полезной нагрузки. Изначально $qvwml = 0, но после успешных проверок (включая .ps1 и отключение AMSI) ее значение увеличивается:

$qvwml += 2


Эта переменная влияет на regex-маску в цикле расшифровки:

foreach($ucbxt in $cjzuc){
"$ucbxt -replace ('.(.'+'.'*$qvwml+')'),('$'+$(h)+55/55)"|iex|iex
}


После изменения $qvwml повторно запустить скрипт невозможно, так как regex-маска больше не соответствует исходному шаблону.

TMCShell получает содержимое страницы c telegra.ph и из первой строки декодирует адрес С2, а из второй — цифровую подпись (скриншот 3; ответ, который парсит TMCShell). Сам C2-сервер на момент анализа имел IP-адрес 212.80.206.125, который принадлежит израильской AS 44709 (O.m.c. Computers & Communications Ltd), как почти во всех зафиксированных случаях, связанных с этой группировкой.

🏮 Самый интересный момент заключается в том, что Excel-документы содержали метаданные, которые указывают, что документ редактировался последний раз (вероятно, и создан) в системе с китайской локалью в WPS Office, аналоге Microsoft Office, созданной китайской компанией Kingsoft. Сам WPS Office поддерживает несколько языков, включая русский и английский, но в русской или английской версии в поле Heading Pairs должно быть указано Лист1 или Sheet1, в то время как во всех четырех документах-приманках поле Heading Pairs содержало 工作表, 1, где 工作表 означает «рабочий лист» (скриншот 4).

IoCs:

f8f096d2e94bbdbfd20aae45432af58a7bdf3406fa4dde568154b930cac855ca
20b0faa0f058cd71be39075ed1a0294e2a9e7c2f670b7ba5e3e35e6581907122
37bff1efb37a61f1e4d9f9fda43f33db852da01b22b623faedcef20173ee78fa
7c29891b5eacc464620db0a23b2e05b47373b98524aebba05cf3bd8c2b5f42fe
63b7073a8b74dd7810493700881b9afea3627126cbcb1d942e7a01d573207129
4102a0bec73711e754a5ad067d1779cb8c71628b0c38384e41b2041e64ffddba
5df092a5f3d088043cd5724197b63ba239b12edc8cd6dbcf7e3f9d7ce8594426

212.80.206.125


#TI #APT #malware #ioc
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥119👏2
Собеседование → ПО на iPhone от «работодателя» → у вас больше нет смартфона 👋

Новая старая схема блокировки iPhone через «режим пропажи» снова в ходу. Только теперь она стала изощреннее: в начале поста — реальный пример многоходовочки, который мы подробно описали в статье на Хабре.

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

😎 Бонус: мы подготовили наглядную схему восстановления доступа к iPhone. Она доступна в формате PDF с кликабельными ссылками — скачивайте и сохраняйте на разные устройства (на всякий случай).

#ios #dfir #mobile
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍8👏7🏆31😈1
HTML-вложения как инструмент фишинга 🤑

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

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

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

В начале JavaScript-кода (скриншот 1) определяются константы P и W, являющиеся ключом шифрования и зашифрованным текстом, а также функция дешифрования k. Полученные дешифрованные инструкции помещаются в константу Y и имеют вид, представленный на скриншоте 2.

Как можно понять по этим инструкциям, они создают элемент iframe, содержимое которого получено из фишингового URL-адреса (его значение закодировано в base64); также установлены CSS-стили, позволяющие полученному контенту занять всю доступную область экрана. Кроме того, в этих инструкциях видим вызов метода document.write для размещения полученного контента на вкладке браузера.

Пока что это просто набор текста. Отдельно остановимся на способе запуска инструкций из константы Y. Для этого из вложения вызывается следующая часть скрипта (скриншот 3).

При определении константы H создается ссылка на глобальный объект o, которым в JavaScript-коде является window. Вызов o[X]X просто закодировано слово Function) эквивалентен вызову у глобального объекта свойства Function, при передаче параметров в которое они будут исполнены как новые функции. Как мы видим далее по коду, в объект передаются декодированные инструкции из константы Y.

Чтобы дополнительно усложнить детектирование исполнения вредоносного кода скрипта, злоумышленники создают пустую функцию y, переопределяют для нее метод toString, дополняя его вызовом вышеупомянутого глобального объекта window. Далее выполняется строчка U = ${y}: y преобразуется в строку, вызывая переопеределенный toString, внутри которого уже запускается загрузка контента.

Подозрительные маркеры при анализе подобных образцов — переопределение стандартных методов (вроде toString); маппинг слов из числового массива через вызов функции fromCharCode (в константе X), а также определение длинных числовых и текстовых констант с дальнейшим определением функций по их декодированию.

2️⃣ Еще один заинтересовавший нас образец содержит интересные методы «антидебага», но о них чуть попозже. Он представляет собой форму ввода учетных данных для открытия заблюренного pdf-документа.

HTML-образец содержит два скрипта. Первый после простой валидации наличия email-адреса в поле ввода содержит POST-метод, отправляющий учетные данные на сторонний сервер (скриншот 4).

Как можем видеть, в качестве query-параметра у URL-ссылки есть количество попыток. Естественно, никакой аутентификации по введенным в форму данным не производится, они просто утекают по указанному адресу. При этом параметр attempt инкрементируется, и при третьей попытке ввести в форму какие-то данные производится перенаправление на легитимный веб-ресурс. Спасибо авторам за комментарии к коду, позволившие понять, что вообще происходит.

Второй скрипт, о котором мы упомянули ранее, имеет следующий вид, представленный на скриншоте 5.

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

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

#phishing #detect #tip
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
23🔥17👍12