#Burp suite ubuntu windows#

TriggersĬonfigure the task to begin at log on, with a delay of 10 seconds. Name your task something appropriate, and ensure that the ‘Run with highest privileges’ option is selected in order to allow Administrator level commands to execute. Open Task Scheduler and select ‘Create Task’. To achieve this, we need to create a Scheduled Task to run just after log on. I’ll run you through my process, and provide you with my PowerShell script below. Unfortunately, Edwin’s solution didn’t work out of the box for me, and as such I had to make some changes. The solution proposed by Edwin Chiwona involves portforwarding required ports so that they’re accessible by the host, and then just referencing localhost:xxxxx where needed. If you Google around for static IP addressing, you can see that it’s been raised as an issue on Microsoft’s WSL GitHub repo, with a potential workaround. I believe this approach works inconsistently at best, and is not something that can be relied upon. Insider Preview Build 18945 reportedly made things easier by allowing localhost access to Linux apps from Windows. This doesn’t sound great for our configuration of proxies between the two systems, as we’d have to reconfigure every boot with the newly aquired IP! Microsoft are supposedly working on this, but as of publishing this post, no such functionality exists. In the current version of WSL2, it is impossible to configure static IP addressing. The first hurdle on the path to my solution was WSL2’s IP addressing solution.

#Burp suite ubuntu windows#

The goal was relatively simple establish a solution whereby BurpSuite could intercept web traffic between Google Chrome running in my Windows environment, at the same time as making use of a VPN profile within WSL2. With a bit of tinkering, I was able to establish a way of getting things working with a VPN running inside WSL2, and running BurpSuite successfully on my Windows host, keeping my desktop environment clean and tidy. As most VPN profiles (such as those used with HackTheBox or TryHackMe) only permit a single connection, either the Windows host OR the WSL2 environment can be connected when using a VPN. Whilst initially an acceptable solution, I grew unhappy with the VNC solution, and wanted a true WSL 2 terminal experience. Various solutions exist to this problem, including the use of Win-Kex for Kali Linux. WSL2 on the command-line is natively great for infrastructure testing, but when assessing web applications, some form of GUI is of course required. As a result, I’ve finally ditched VMWare and fully made the transition to WSL2. The only issue I’m still aware of is some difficulty surrounding mounting additional virtual disks within WSL – but that’s hardly a day-to-day inconvenience. Almost all of the issues that plagued Microsoft’s first WSL release have been resolved. Windows Subsystem for Linux 2 (WSL2) is in a great place right now.