impr

src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

@@ -53,6 +53,10 @@ Explained in [**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) you n
 
 <figure><img src="../../images/image (56).png" alt="" width="314"><figcaption></figcaption></figure>
 
+### Learn how to create a Magisc module
+
+Check [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437)
+
 ## Post Android 14
 
 In the latest Android 14 release, a significant shift has been observed in the handling of system-trusted Certificate Authority (CA) certificates. Previously, these certificates were housed in **`/system/etc/security/cacerts/`**, accessible and modifiable by users with root privileges, which allowed immediate application across the system. However, with Android 14, the storage location has been moved to **`/apex/com.android.conscrypt/cacerts`**, a directory within the **`/apex`** path, which is immutable by nature.

src/pentesting-web/websocket-attacks.md

@@ -101,6 +101,16 @@ In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Bur
 
 Attackers can exploit this by hosting a **malicious web page** that initiates a cross-site WebSocket connection to a vulnerable application. Consequently, this connection is treated as part of the victim's session with the application, exploiting the lack of CSRF protection in the session handling mechanism.
 
+In order for this attack to work, these are the requirements:
+
+- The websocket **authentication must be cookie based**
+- The cookie must be accessible from the attackers server (this usually means **`SameSite=None`**) and no **Firefox Total Cookie Protection** enabled in Firefox and no **blocked third-party cookies** in Chrome.
+- The websocket server must not check the origin of the connection (or this must be bypasseable)
+
+Also:
+
+- If the authentication is based on a local connection (to localhost or to a local network) the attack **will be possible** as no current protection forbids it (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
+
 ### Simple Attack
 
 Note that when **establishing** a **websocket** connection the **cookie** is **sent** to the server. The **server** might be using it to **relate** each **specific** **user** with his **websocket** **session based on the sent cookie**.
@@ -157,6 +167,18 @@ Exposing the web application and making a user connect to it you will be able to
 sudo python3 -m http.server 80
 ```
 
+### CSWSH Protections
+
+The CSWSH attack is based on the fact that an **user will connect to a malicious page** that will **open a websocket connection** to a web page where the user is already connected and will authenticate as him as the request will send the user's cookies.
+
+Nowadays, it's very easy to prevent this issue:
+
+- **Websocket server checking the origin**: The websocket server should always check from where a suer is connecting to prevent unexpected pages from connecting to it.
+- **Authentication token**: Instead of basing the authentication on a cookie, the websocket connection could be based on a token that is generated by the server for the user unknown to the attacker (like an anti-CSRF token)
+- **SameSite Cookie attribute**: Cookies with `SameSite` value as `Lax` or `Strict` won't be sent from an external attackers page to the victim server, therefore, cookie based authentication won't be successful. Note that Chrome now puts the value **`Lax`** to the cookies withuot this flag specfied maing this more secure by default. Although, the first 2 minutes a cookie is created it will have the value **`None`** making it vulnerable during that imited period of time (also it's expected that this meassure will be removed at some point).
+- **Firefox Total Cookie Protection**: Total Cookie Protection works by isolating cookies to the site in which they are created. Essentially each site has its own cookie storage partition to prevent third parties linking a user’s browsing history together. This makes **CSWSH unusable** as the attackers site won't have access to the cookies.
+- **Chrome third-party cookies block**: This could also prevent sending the cookie of the authenticated user to the websocket server even with `SameSite=None`.
+
 ## Race Conditions
 
 Race Conditions in WebSockets are also a thing, [check this information to learn more](race-condition.md#rc-in-websockets).
@@ -176,6 +198,7 @@ h2c-smuggling.md
 ## References
 
 - [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages)
+- [https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)
 
 {{#include ../banners/hacktricks-training.md}}
 

src/windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md

@@ -146,6 +146,8 @@ To identify misconfigured GPOs, PowerSploit's cmdlets can be chained together. T
 
 **OUs with a Given Policy Applied**: Identifying organizational units (OUs) affected by a given policy can be done using `Get-DomainOU`.
 
+You can also use the tool [**GPOHound**](https://github.com/cogiceo/GPOHound) to enumerate GPOs and find issues in them.
+
 ### Abuse GPO - New-GPOImmediateTask
 
 Misconfigured GPOs can be exploited to execute code, for example, by creating an immediate scheduled task. This can be done to add a user to the local administrators group on affected machines, significantly elevating privileges: