Bichitos¶
Once the delivery of the implant (phishing, lv 2 mitm on the network, physical access…) is completed, Hive will start to receive Online Bichitos.
List Bichitos,Information¶
The active footholds will appear under the Implant itself They will be first organized by *Hostname* Within each Hostname, Offline footholds (they were online and become offline) Under Offline active Footholds will be ready to interact with.
Note
A Offline
bichito or foothold, will be determined if a job is sent, and no response back from any redirector is obtained in respTime
*[more details on the developers’ guide]*
- Params.
- ID → Target IMplant process ID
- PID → Target foothold PID for bichito
- Architecture → target hardware process arch
- Mac Addr
- OS Version
- Hostname
- UserName → the user context that the bichito is executed with
- AdminRoot → will show how privileged the process is in the target OS
- Redirector attached → Last redirector where the foothold connected to
- Status → Offline if no response within responseTime
Jobs¶
Similarly to Hive Jobs, this log will show jobs that are being sent to be processed by target foothold
Logs¶
Error log generated by the foothold, for example, when it is unable to connect to one redirector
Interact - Job Console¶
This is the main Job-based console of Siesta Time
Jobs are sent to the Hive, then the Hive detects which redirector the foothold is attached to, and finally the foothold grabs the Job and response back in respTime
Results will be shown in the Bichito’s Job Log
clear¶
Clear JS console
respTime <seconds>¶
Change target Bichito respTime to target integer in seconds
ttl <seconds>¶
Change the time to live of the target Bichito to target integer seconds
exec <commandString>¶
Pass target string to default command interpreter (sh/bash/cmd) and retrieve output
EG.: exec ipconfig
accesschk <pathFile>¶
Provide target operating system’s file access control rules as an output
EG.: accesschk C:\\windows\system32\calc.exe
read <pathfile>¶
Read bytes of target file and retrieve the output
write <string> <pathfile>¶
Write string on target File. If a file exists, it will append at the end.
wipe <pathfile>¶
Wipe target file. Will transform its bytes to 0 and then remove the disk header.
upload <operator-PathFile> <Foothold-Pathfile>¶
Upload Operators source file to target foothold location
EG.: upload /home/rebujacker/upload1 C:\\Users\test\Desktop\
download <Foothold-pathfile> <operator-pathfile>¶
Download target foothold file to a operator folder
EG.: download C:\\Users\test\Desktop\download1 /home/rebujacker/download1
Note
Every Output is set to hold a maximum of 20 Megabytes. For moving bigger blobs of data you need to use POST./Staging Servers
kill¶
Kill actual bichito process
removeInfection¶
If the implant was configured to hold a persistence on target foothold, this command will:
- Steps
- Remove/Wipe Persistence configurations/files
- Remove/Wipe executable on disk, if applicable.
- Kill the actual bichito process
Note
This command output will be always “Processing” since the target foothold will never answer back after removal
Attach Bichitos/Footholds to Post. Servers¶
Once the foothold is running one of your implant processes (Bichitos) the natural way to interact for non basic operations will be the Post./Staging Servers that can be created/deleted at any moment. For the moment, these attacks/injections come in the following way:
SSH Rev Shell¶
Create a new thread from the actual Bichito process. This thread will create an outbound SSH client request against a target previously created “Rev SSH Handler”
Empire¶
Generate a launcher that will be executed by a bichito thread using “Exec” and “python”. Python needs to be installed on target foothold previously.
Metasploit¶
TBD
Note
These attack/Injections normally have a Offline option, that will let Operators to build their own Post. Servers without hive
Warning
For the moment these actions are not creating new processes, or injecting in other’s processes, that is TBD