Translated ['src/mobile-pentesting/ios-pentesting/ios-protocol-handlers.

src/SUMMARY.md

@@ -283,6 +283,7 @@
   - [SID-History Injection](windows-hardening/active-directory-methodology/sid-history-injection.md)
   - [Silver Ticket](windows-hardening/active-directory-methodology/silver-ticket.md)
   - [Skeleton Key](windows-hardening/active-directory-methodology/skeleton-key.md)
+  - [Timeroasting](windows-hardening/active-directory-methodology/TimeRoasting.md)
   - [Unconstrained Delegation](windows-hardening/active-directory-methodology/unconstrained-delegation.md)
 - [Windows Security Controls](windows-hardening/authentication-credentials-uac-and-efs/README.md)
   - [UAC - User Account Control](windows-hardening/authentication-credentials-uac-and-efs/uac-user-account-control.md)

src/mobile-pentesting/ios-pentesting/ios-protocol-handlers.md

@@ -1,5 +1,3 @@
-{{#include ../../banners/hacktricks-training.md}}
+# WebView Protocol Handlers
-
-# Обробники протоколів WebView
 
 {{#include ../../banners/hacktricks-training.md}}

src/windows-hardening/active-directory-methodology/TimeRoasting.md

@@ -1,4 +1,6 @@
-## TimeRoasting
+# TimeRoasting
+
+{{#include /banners/hacktricks-training.md}}
 
 timeRoasting, основна причина - застарілий механізм аутентифікації, залишений Microsoft у його розширенні до NTP серверів, відомому як MS-SNTP. У цьому механізмі клієнти можуть безпосередньо використовувати будь-який відносний ідентифікатор (RID) облікового запису комп'ютера, а контролер домену використовуватиме NTLM хеш облікового запису комп'ютера (згенерований MD4) як ключ для генерації **Message Authentication Code (MAC)** пакета відповіді.
 
@@ -11,12 +13,12 @@ timeRoasting, основна причина - застарілий механі
 Можна побачити, що коли елемент ADM ExtendedAuthenticatorSupported встановлений на `false`, оригінальний формат Markdown зберігається.
 
 >Цитата з оригінальної статті：
->>Якщо елемент ADM ExtendedAuthenticatorSupported є false, клієнт ПОВИНЕН створити повідомлення запиту клієнта NTP. Довжина повідомлення запиту клієнта NTP становить 68 байт. Клієнт встановлює поле Authenticator повідомлення запиту клієнта NTP, як описано в розділі 2.2.1, записуючи найменш значущі 31 біти значення RID у найменш значущі 31 біти підполя ідентифікатора ключа аутентифікатора, а потім записуючи значення селектора ключа у найзначніший біт підполя ідентифікатора ключа.
+>>Якщо елемент ADM ExtendedAuthenticatorSupported є false, клієнт МАЄ побудувати повідомлення запиту клієнта NTP. Довжина повідомлення запиту клієнта NTP становить 68 байтів. Клієнт встановлює поле Authenticator повідомлення запиту клієнта NTP, як описано в розділі 2.2.1, записуючи найменш значущі 31 біт значення RID у найменш значущі 31 біт підполя ідентифікатора ключа аутентифікатора, а потім записуючи значення селектора ключа у найзначніший біт підполя ідентифікатора ключа.
 
 У розділі 4 Документу Приклади протоколу пункт 3
 
 >Цитата з оригінальної статті：
->>3. Після отримання запиту сервер перевіряє, що розмір отриманого повідомлення становить 68 байт. Якщо це не так, сервер або відхиляє запит (якщо розмір повідомлення не дорівнює 48 байтам), або розглядає його як неаутентифікований запит (якщо розмір повідомлення становить 48 байт). Припускаючи, що розмір отриманого повідомлення становить 68 байт, сервер витягує RID з отриманого повідомлення. Сервер використовує його для виклику методу NetrLogonComputeServerDigest (як зазначено в [MS-NRPC] розділ 3.5.4.8.2) для обчислення крипто-перевірок і вибору крипто-перевірки на основі найзначнішого біта підполя ідентифікатора ключа з отриманого повідомлення, як зазначено в розділі 3.2.5. Сервер потім надсилає відповідь клієнту, встановлюючи поле ідентифікатора ключа на 0, а поле крипто-перевірки на обчислену крипто-перевірку.
+>>3. Після отримання запиту сервер перевіряє, що розмір отриманого повідомлення становить 68 байтів. Якщо це не так, сервер або відхиляє запит (якщо розмір повідомлення не дорівнює 48 байтам), або розглядає його як неаутентифікований запит (якщо розмір повідомлення становить 48 байтів). Припускаючи, що розмір отриманого повідомлення становить 68 байтів, сервер витягує RID з отриманого повідомлення. Сервер використовує його для виклику методу NetrLogonComputeServerDigest (як зазначено в [MS-NRPC] розділ 3.5.4.8.2) для обчислення крипто-перевірок і вибору крипто-перевірки на основі найзначнішого біта підполя ідентифікатора ключа з отриманого повідомлення, як зазначено в розділі 3.2.5. Сервер потім надсилає відповідь клієнту, встановлюючи поле ідентифікатора ключа на 0 і поле крипто-перевірки на обчислену крипто-перевірку.
 
 Згідно з описом у вищезгаданому офіційному документі Microsoft, користувачам не потрібна жодна аутентифікація; їм потрібно лише заповнити RID, щоб ініціювати запит, а потім вони можуть отримати криптографічну перевірку. Криптографічна перевірка пояснюється в розділі 3.2.5.1.1 документа.
 
@@ -26,7 +28,7 @@ timeRoasting, основна причина - застарілий механі
 
 Криптографічна перевірка обчислюється за допомогою MD5, а конкретний процес можна знайти в змісті документа. Це дає нам можливість виконати атаку на roasting.
 
-## how to attack
+## як атакувати
 
 Цитата на https://swisskyrepo.github.io/InternalAllTheThings/active-directory/ad-roasting-timeroasting/
 
@@ -35,4 +37,4 @@ timeRoasting, основна причина - застарілий механі
 sudo ./timeroast.py 10.0.0.42 | tee ntp-hashes.txt
 hashcat -m 31300 ntp-hashes.txt
 ```
-
+{{#include /banners/hacktricks-training.md}}