Vay3t vay3t

I faced bandwidth issues between a WG Peer and a WG server. Download bandwidth when downloading from WG Server to WG peer was reduced significantly and upload bandwidth was practically non existent.
I found a few reddit posts that said that we need to choose the right MTU. So I wrote a script to find an optimal MTU.
Ideally I would have liked to have run all possible MTU configurations for both WG Server and WG Peer but for simplicity I choose to fix the WG Server to the original 1420 MTU and tried all MTUs from 1280 to 1500 for the WG Peer.

	from impacket.dcerpc.v5 import epm, lsad, rpcrt, transport, lsat, ndr, nrpc
	from impacket.uuid import bin_to_uuidtup
	from binascii import unhexlify, hexlify
	from struct import pack, unpack
	from random import randbytes
	import sys

	# Perform a netrlogonsamlogonwithflags with a server account, it uses netlogon as SSP (see [MS-NRPC] 3.3)
	# Pure TCP RPC is used (ncacn_ip_tcp option)
	# RC4 is used here because to use AES, impacket must be patched

	# Connect
	$passwd = ConvertTo-SecureString "NewUserSSecret@Pass61" -AsPlainText -Force
	$creds = New-Object System.Management.Automation.PSCredential ("[email protected]", $passwd)
	Connect-AzAccount -Credential $creds
	#Connect-AzureAD -Credential $creds
	Connect-MgGraph -ClientSecretCredential $creds -TenantId bcdc6c96-4f80-4b10-8228-2e6477c71851

	## 1. Unauthenticated Recon:
	#Get if Azure tenant is in use, tenant name and Federation
	https://login.microsoftonline.com/getuserrealm.srf?login=[USERNAME@DOMAIN]&xml=1

	- Correr todo el proyecto y probar localmente
	- Destriparlo y dejar solo lo necesario para la parte de canary tokens http
	- Abstraer la logica de canary tokens de manera que sea golang idiomatic
	- Despues de abstraer, portar la logica de http a golang
	- Inicialmente hacer un cli y la funcionalidad http trabaje correctamente
	- Comenzar a portar los demás tipos de canary token
	- Diseñar nuevo sistema de notificaciones (slack, telegram, etc.)
	- Crear interfaz web

	Nice to have features:

	<#

	DynWin32-ShellcodeProcessHollowing.ps1 performs shellcode based process hollowing using
	dynamically looked up Win32 API calls. The script obtains the methods GetModuleHandle,
	GetProcAddress and CreateProcess by using reflection. Afterwards it utilizes GetModuleHandle
	and GetProcAddress to obtain the addresses of the other required Win32 API calls.

	When all required Win32 API calls are looked up, it starts svchost.exe in a suspended state
	and overwrites the entrypoint with the specified shellcode. Afterwards, the thread is resumed
	and the shellcode is executed enveloped within the trusted svchost.exe process.

	#!/usr/bin/env python3

	import sys
	import signal

	from types import FrameType
	from typing import Union

	def sighandler(signum: int, frame: Union[FrameType, None]) -> signal.Handlers:
	sys.stdout.write("\r")

	import json
	import os
	import time
	import webbrowser
	import sys
	import re


	def handleWindows(extra_seconds):
	print("OS : Windows")

	'''
	Based on the initial work of Digininja at https://github.com/digininja/CeWL. While CeWL is a script written
	in Ruby that requires an independent crawl of a website in order to build a custom wordlist, Whey CeWLer
	runs within Portswigger's Burp Suite and parses an already crawled sitemap to build a custom wordlist. It
	does not have the meta data parsing capabilities that CeWL does, but it more than makes up for it in
	convenience.

	The name gets its origins from the CeWLer portion of the CO2 Burp extension by Jason Gillam, which is written
	in Java and does something similar, but Whey CeWLer is a completely reimagined extension written in Python,
	making it "way cooler".