Search the Community
Showing results for tags 'node'.
So, it has been a bit since I did any work on the BBTPS so posting some work I began doing on it. First, I have gotten some messages about the BBTPS needing to use npm to get Express before adding to Bunny. If you pull the No_Express branch, you will only need to copy it to the Bunny. No Node dependencies needed. That one had the web server rewritten to use core modules instead of addons. First, current bug: If your script is huge and you specify it to be a process, it may not run. This is due to the cmdline 8191 character limit. The process launcher in the BBTPS launches a new powershell process with your script as a compress/encoded command. If it is too big, it gets truncated. I am working on a different method so any size script could be fired as a process. Running it in a thread works fine since it runs as a job script within the agent. Work around would be to store the script in the /loot/bbtps folder and have a script in your joblist as a process that pulls the main script through SMB server that is running and execute it. What led to this discovery was another user pointing out issues with Powercat I included, which is a huge script and broke because of the limit. Stuff I am working on: Welp, for one I am refactoring the node server. This is to make it easier to future changes that require changes to the server which leads into the next change. The quack scripts control are being moved over to the node server. The launcher for the agent will not launch directly from the payload.txt but by the node server when it comes online. This will reduce the stager size since I will not need the looping wait counter to wait for the server to come up anymore. A new field is being added to the joblist.json schema called admin that will be boolean. This field specifies if the script requires admin rights. This leads to the new feature I am working on Autoadmin. No need to guess if the user is admin or not. The BBTPS will fire off a non-privilege command prompt. It will then fire a non-hidden stager that will pull down stage1 which will check for certain requirements. After checking, a signal is sent back the the node server running on the Bashbunny. The signal depends on if the user is a local admin or not. If they are then the signal will cause the Bashbunny node server to quack out the commands in the still open cmd prompt to launch a hidden stager elevated and even quack out the keystrokes to select yes. If the user is not admin then a normal hidden stager is launched with no extra keystrokes needed. On the server the joblist it has will filter out admin jobs if the user is not admin or keep them and run them with the non-admin jobs if user is admin. Non-admin jobs always run. Reduction of config files...well by 1. I am removing the payselect.txt file for config selection. It can be done from within the payload.txt file. The joblist.json file that lists the scripts is still there (how else are you going to be able to have different lists of scripts to run ready to go?) and the config file for the joblist is still needed to be configured (this is how you select the folder that has your scripts and the joblist file to use along with the quack delays and other fine tunings or do all your joblists work the same way?). The other files are still needed to preconfigure all your different job packs so if you want to switch, you just need to change the config file name in the payload.txt. HoppEye8x by H8.to. This will come in a later version as I am still working out a good way to implement this though would extend the possibility of being able to on the fly select out of 8 preloaded jobpacks you preconfigure to launch. This would extend the number of scripts you can run by 8x the number of scripts you have configured in each jobpack per. More work on instructions. I figured out I had issues with my instructions because I was trying to instruct on proper powershell module writing at the same time (which is not required for the BBTPS to work with but makes them way more easier to be ported around in into different jobpacks). New instructions will only include how to install, where all the configuration is done and their mean and use the current sample I have as an example of how it works so the samples will include the new methods. Just to reiterate, the BBTPS is a tool, not a payload. Payloads included with the BBTPS and jobpacks created from them in the repo are from other projects and there as example of usage not as included functions of the tool.