Staging Beacons to Isolated Targets with BOF.NET
Using BOF.NET to deliver staged, web-hosted shellcode to internal systems.
Background
Delivering staged implants has been back on the cards for a while. Major EDR vendors are now scrutinising executables more if they appear to house embedded shellcode, as this produces an artefact with much higher entropy. This is why staging has had a bit of a comeback, because if your implant stage is delivered remotely and in-memory, then you can reduce the entropy of the file and avoid this cat-and-mouse game. I’ve personally found this to be quite effective, especially for lateral movement.
Of course, staging relies on the target reaching your remote stager. This can be a bit more difficult for more isolated targets, such as those found deep within ICS networks. I’ve found that one of the most effective solutions is to host the shellcode via beacon on a neighbouring host (assuming you can get one) using BOF.NET.
Hosting Files in-memory via BOF.NET
Ceri Coburn’s BOF.NET project includes several built-in BOFs to demonstrate the project’s functionality, including a virtual file system (VFS) and a WebServer BOF. This provides all the functionality we need to temporarily store and host a file in-memory, without uploading or dropping our shellcode anywhere. After initialising BOF.NET in beacon, adding files to the VFS is straightforward:
beacon> bofnet_vfs_add [local-path] [filename] [mimetype]
With your payload available in beacon’s memory, you can host the file on any interface that your target can access. In this example, I’m using the GOAD SCCM lab on Ludus, where the IP of my foothold beacon (with hostname “client”) is 10.3.10.43. This makes the VFS accessible via HTTP through client, client.sccm.lab, etc.
beacon> bofnet_job WebServer http://[internal-ip]:[port]/
The WebServer BOF allows you to serve content on any port permitted by your privileges. In this example, a high-integrity beacon is used to serve on port 80, which is allowed through the firewall. Whatever port you use must be accessible through the local firewall. I recommend using TrustedSec’s list_firewall_rules BOF to help with this.
Pivot Listeners
In situations where the target is unreachable from your beacon, or has no open ports, it’s worth using the reverse TCP beacon rather than the traditional “bind” peer-to-peer variants. In other words, if the target can reach you but you can’t reach the target, pivot listeners are probably your best bet. Note that you must have the privileges to create a listener on whichever port you decide to listen on.
Currently, you can only start a pivot listener through the GUI, where you specify the listen IP. This should ideally match your BOFNET WebServer IP and listen port:
Next, generate the pivot listener shellcode and upload it to the VFS. Host it using the WebServer BOF, ensuring the target can access both the server and the shellcode. You can view any hits to your server using the following command:
bofnet_jobstatus [job-id]By configuring an arbitrary payload stager to point to the internal BOF.NET WebServer address, execution should allow it to fetch the stage from the neighbouring host. In turn, this should allow a beacon to establish a connection back to the pivot listener.
Kudos to Rasta Mouse for proofreading.