• HTTP based
  


• Small stub size
  


• Very crypt friendly
  


• Native
  

(Mar 4, 2022 11:01 AM)0x9F Wrote:  

I'm currently working on XenoLoader, a native HTTP loader entirely written in C, targeting Windows OS.
It comes with a small set of features, but incredible stability and best runtime results.
XenoLoader is capable of operating on freshly installed XP boxes, fully bypassing ring3 hooks & usermode filtering systems and tunnel networking-part entirely through a legitimate process. The installation routine is pretty uncommon and adaptive, based on the execution environment.
Nothing is hardcoded in the stub (except for the profile name).

I want to keep you up-to-date about what's happening.

+ = Added
# = In Progress
- = Planned

Bot features
[+] Injected Netcode (through a legitimate process)
[+] Implant Persistence (non-traditional ways, works best on real environments)
[+] Melt
[#] Failsafe syscall engine
[-] Download & Execute
[-] Update/Uninstall Bot

Characteristics:

• HTTP based
  


• Small stub size
  


• Very crypt friendly
  


• Native
  

Preview of the unfinished Control-Panel (designed in .NET WinForms Core):


Why am I creating this thread? is this yet another Development Thread of a bot which never finishes?
No. I'm actively developing this bot and have been testing alot already. I'm lazy as fuck but actually have fun developing this. Having a dev-thread
will give me some more motivation to continue the project (call me weird, it is what it is).

Why don't you have a web-panel?
XenoLoader will talk to a web-api, the CP will talk to a secured admin-web-api to gather info and control the bots.

Am I planning to sell this?
No, this is going to be released for educational & research purposes. The bot will have an Anti-Abuse mechanic implemented. I'm fighting against malicious use and will try everything in my hands to prevent it. I want people to learn from it.

Open-Source?
No.

When it will be released?
Obviously when it's finished & tested. No ETA yet. Many things are already finished and tested, currently working on core-parts of XenoLoader.


If you have questions, don't hesitate to ask.

(Mar 4, 2022 12:48 PM)ĐĮΜĘ Wrote:  Good job. Nice to see more development in this area. What else do you plan to implement and also what is your anti abuse method to stop the abuse of such tool?

• XenoLoader stub will drop a batch-script onto the Desktop upon execution, which uninstalls the bot from client-PC.
  


• Probably some bot-limitation (API shuts down itself after registering a certain amount of bots), but I'm not sure about this one.
  


• Some more surprises 🙃
  

(Mar 4, 2022 12:59 PM)m0pe Wrote:  Its Look realy nice!
hope i can buy it soon :)

(Mar 4, 2022 01:02 PM)0x9F Wrote:  I'm not planning to implement more than that. Maybe injected TOR support, but since it's planned to be educational I'm not sure if there is a reason for that. I was also thinking about a plugin-system.

The Anti-Abuse mechanic:

• XenoLoader stub will drop a batch-script onto the Desktop upon execution, which uninstalls the bot from client-PC.
  


• Probably some bot-limitation (API shuts down itself after registering a certain amount of bots), but I'm not sure about this one.
  


• Some more surprises 🙃
  

 

However, the anti-abuse mechanic is not bulletproof and can be cracked and bypassed, idk if someone will attempt to do that.

---

It's gonna be free.

(Mar 4, 2022 02:17 PM)ĐĮΜĘ Wrote:  Thanks for the in-depth response. Cant wait to see it in action.

(Mar 4, 2022 11:01 AM)0x9F Wrote:  

I'm currently working on XenoLoader, a native HTTP loader entirely written in C, targeting Windows OS.
It comes with a small set of features, but incredible stability and best runtime results.
XenoLoader is capable of operating on freshly installed XP boxes, fully bypassing ring3 hooks & usermode filtering systems and tunnel networking-part entirely through a legitimate process. The installation routine is pretty uncommon and adaptive, based on the execution environment.
Nothing is hardcoded in the stub (except for the profile name).

I want to keep you up-to-date about what's happening.

+ = Added
# = In Progress
- = Planned

Bot features
[+] Injected Netcode (through a legitimate process)
[+] Implant Persistence (non-traditional ways, works best on real environments)
[+] Melt
[#] Failsafe syscall engine (x86 -> x64)
[-] Download & Execute
[-] Update/Uninstall Bot

Characteristics:

• HTTP based
  


• Small stub size
  


• Very crypt friendly
  


• Native
  

Preview of the unfinished Control-Panel (designed in .NET WinForms Core):


Why am I creating this thread? is this yet another Development Thread of a bot which never finishes?
No. I'm actively developing this bot and have been testing alot already. I'm lazy as fuck but actually have fun developing this. Having a dev-thread
will give me some more motivation to continue the project (call me weird, it is what it is).

Why don't you have a web-panel?
XenoLoader will talk to a web-api, the CP will talk to a secured admin-web-api to gather info and control the bots.

Am I planning to sell this?
No, this is going to be released for educational & research purposes. The bot will have an Anti-Abuse mechanic implemented. I'm fighting against malicious use and will try everything in my hands to prevent it. I want people to learn from it.

Open-Source?
No.

When it will be released?
Obviously when it's finished & tested. No ETA yet. Many things are already finished and tested, currently working on core-parts of XenoLoader.


If you have questions, don't hesitate to ask.

(Mar 4, 2022 06:56 PM)Invasi0nZ Wrote:  This sounds like an incredibly interesting project, may I ask what you mean exactly by non-traditional persistence? Also, how well does using a different process as pipe for network traffic work? Wouldn't that be pretty noisy in terms of accessing a different process? Looking forward to the finished product!

(Mar 5, 2022 09:03 AM)SIM549839 Wrote:  Do you adapt your own syscalls stubs for each possible win system? Since win7 and win10 syscalls stubs can be different. (extra add esp,4 or w/e.)

"CreateRemoteThread" on a process is a very sus behavior that is detected by quite a few AV's, especially if the remote memory has PAGE_EXECUTE_READWRITE flag and was allocated on the fly.

Direct syscalls can help with EDR's though which is fine for most people I guess.

A much better approach would be to side load yourself via some unknown dll hijhack, this way you don't write to any memory & the file is signed and preserved, all the .txt .data sections hashes remain the same.
All your funny shit will happen in the DLL, communication as well...  Since the file is signed --> traffic is usually trusted.. also no memory scan is triggered by most av's.

I don't see the point of releasing a "Loader" to a community like HF with kill switches that prevent malicious use...
Also making "A" bot "crypter" friendly is not the most "whitehat" thing to do.

Generally if this bot is good enough I would sell it, but this community isn't really the audience you want to target for $$.

(Mar 5, 2022 09:32 AM)0x9F Wrote:  Do you adapt your own syscalls stubs for each possible win system? Since win7 and win10 syscalls stubs can be different. (extra add esp,4 or w/e.)
Yes, every syscall stub will be handled differently depending on what Win OS version is currently installed. I've successfully managed to open the gate (and test) on Win7, Win8/8.1 and Win10. Haven't looked at XP x64 variants and Win11 tho.

A much better approach would be to side load yourself via some unknown dll hijhack, this way you don't write to any memory & the file is signed and preserved, all the .txt .data sections hashes remain the same.
All your funny shit will happen in the DLL, communication as well...  Since the file is signed --> traffic is usually trusted.. also no memory scan is triggered by most av's.

I'm not injecting a dll at all, instead I'm writing pure shellcode and setup a completion based pipe-server/client to route the communication with endpoint. I was also thinking about using shared memory.

I don't see the point of releasing a "Loader" to a community like HF with kill switches that prevent malicious use...
Also making "A" bot "crypter" friendly is not the most "whitehat" thing to do.
I take it as a challenge for myself, but yeah you're right. no reason to crypt a bot which has an inbuilt anti-abuse-mechanic.

(Mar 5, 2022 09:35 AM)SIM549839 Wrote:  Good luck my man ;)

• Crafted the key to the gate of heaven, syscall engine works fine on Win 7, 8/8.1 and 10 for now. Haven't checked how context switches are done in other versions of Windows yet. 
  


• Improved implant installer 
  


• Added few helpers/wrappers for the sake of (future) maintenance
  


• Cleaned code here and there
  


• Currently working on edge-features of implant installer.