[0x9F]

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.


Planned bot features
[+] Injected Netcode (through a legitimate process)
[+] Implant Persistence (non-traditional ways, works best on real environments)
[+] Melt
[+] Failsafe call-engine (wow64/x86)
[+] 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):


I will update the progress with new posts, since HF has some limitation for OP editing.

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.

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.

[ĐĮΜĘ]

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.

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?

[m0pe]

Its Look realy nice!
hope i can buy it soon :)

[0x9F]

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?

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.

---

Its Look realy nice!
hope i can buy it soon :)

It's gonna be free.

[ĐĮΜĘ]

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.

Thanks for the in-depth response. Cant wait to see it in action.

[0x9F]

Thanks for the in-depth response. Cant wait to see it in action.

You're welcome. Here to answer your questions.

[lo0sr]

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!

[ecccccccccc]

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.

looks nice, good job op

[Beyonder]

Nice to see someone making something for others to learn from, not everything in life is about money!

Looking forward to the future of this dev-thread ! :*

[0x9F]

⁹

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!

Implant installation/persistence
I'd say try finding it out yourself when it's released. Have fun playing around 🙃

Also, how well does using a different process as pipe for network traffic work?

I've improved it a bit and it's stable and fully functional.

Wouldn't that be pretty noisy in terms of accessing a different process?

Let's say im currently working on a noise-cancellation-system. 🙃

[SIM549839]

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 $$.

[0x9F]

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 $$.

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.

[SIM549839]

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.

Good luck my man ;)

[0x9F]

Good luck my man ;)

Thanks bud. This bot will take time tho, I'm currently busy with few RL things and trying to work on it whenever I can.

---

Update from 5th March, 2022

• 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.
  

[Gentl3man]

Looks pretty neat! Good luck! Looking for more updates!