kris_wk Posted October 19, 2022 Share Posted October 19, 2022 TL;DR If you're seeing constant logs from avahi-daemon, beware, you probably got hacked. Decided to just make a new thread for this since it came out way longer than I thought. I was originally going to leave it under this post which involved the exact same weird logs as me. I had the same exact log posts happen to me and I just discovered how deep it went after digging through my files. I had no idea what the hell was making all these avahi-daemon alerts but they happened with such frequency that I had to find out the cause. I needed to dig extremely hard to find anything whatsoever, which was hard enough for me not really knowing what I'm doing. It seems that at some point (my assumption anyway), I configured port forwarding incorrectly leaving my server wide open. Unfortunately whoever got in, they were very quiet for a long time but once my SMB shares went totally dead, I decided to scour every directory and lo and behold, tons of edited files, folders, hardlinks and symlinks. It all started with me trying to get rid of this random custom bridge that I was using and didn't even know it. There was no more docker0, only br0 and thie "br-blahandnumbers" bridge. All my dockers were running through this bridge because somehow the 172.18.0.1 ip range was added to this bridge rather than my custom network I made for my proxying. No matter how I attempted to delete this thing, it would reappear. Deleted the network.cfg, changed ip routes, tried straight up deleting the interfaces through ifconfig, then even through ip link. I was slamming my head on the desk trying to figure this out. Eventually, I found out that my br0, bond0, virb0 and even my eth0 were broadcasting at a different subnet, for example, virb0 was 192.168.23.255 or something like that. My normal ip 12.12.10.200 (not really) so eth0 really made no sense broadcasting out to 12.12.20.255. Then there was some random tunl0. I wasn't sure if this was them or me with a misconfigured cloudflared tunnel but it was on the ip route feed but went nowhere. In fact it was [email protected] I couldn't delete it either no matter how hard I tried. Whatever they did, they went super crazy hiding and faking a lot of aspects of Unraid. They faked syslogs, killed alerts, stole network bridges and locked them all down for their own use. They were definitely keeping track of what users were active at whatever time. They blacklisted a lot of the real files and scripts so that they wouldn't print unless it was to their own "rsyslog" or it was also so that Unraid, or myself wouldn't be able to use any thing they were utilizing. I'm glad I isolated half of my threads for my machines. At least it gave them a little less power. They had my share folders that pointed to a totally new user, "user0" who essentially was sudo regardless if they even figured out my password or not. This user wasn't in my Users section that's for sure, yet they had that folder on my shares with that name. That was the only way I even knew about it. I would go through some of the files and I'm hit with TONS of gibberish code and peppered in between, they ran their own code. Seemed to be like bruteforcing through some of the tools in the system. Pushing right past anything in their way, it seemed because they were able to have it all set up relativly clean. They were doing some sort of overflows to push themselves into root and then changed the real root folder to symlink to their made up folder, named simply.... " / " (I know, right?) They did similar things with just about every aspect of my system. (/usr/local/state/emhttp became /usr/local/sbin/emhttp). They really did a number on this server because damn near every single file was edited by them at some point (their permissions were different than any others so at a glance it would change how the list looked when using ls -lh to list the directories) Anything I would've tried to change would never take. Unless I went through the actual filesystem in the cmd line. They were doing something that involved compressing and uncompressing a lot of data although these were earlier findings so I wasn't sure. Looking over some stuff it seems they were constantly trying to decrypt any and all hashed keys and passwords on all my storage. Not sure what they were hoping to find aside from just more access but it seems they changed tactics and took over their own section of the filesystems, hardware and even some of the network I guess. They are 100% utilizing Samba, avahi, winbindd (most likely just trying to jump to my other systems). They downloaded dozens of extra-curricular linux tools for who knows why (chmod, chroot, Tmux, b2sum things like this. They enabled hugepages, which I assumed was to make this whole 'keeping whatever they're doing hidden by not slowing down my use too much' thing that much easier, while also possibly making whatever they're doing work better. At first I assumed cryptomining, or just using part of my system as a bot-net. I seen some virtual machine stuff sprinkled in as well. All in all, I have no clue what they were doing for sure but it wasn't good. All these ideas and observations are coming from an advanced novice. Good with PCs and software, reading logs and figuring stuff out but at the core, I really have no idea what any of it means or can mean. Whoever it was seems to be utilizing my ipv6 DNS resolver and avahi's mDNS to keep their connections alive through a hidden bridge talking back and forth to specific hostnames but I can't remember what they were. They locked me out of using ipv6 for SMB whatsoever. I assumed I was just having issues with it on my router. They've been in my system for months, judging by my older config's flash backup. They hit and hid just about everything. The only reason things started even appearing on my syslog was me deleting certain items. It started to break their scripts and files, which made errors pop up. Which then made me super curious.. I was able to really expose a lot of it by killing ip routes and attempting to erase these network bridges and bonds they were creating. I literally just found all this stuff yesterday but I got so freaked out and angry, that's why I started deleting whatever I could in the first place (stupid really cuz who does that help besides me) Unfortunately, in the process of trying to erase one of their newly created fake folders, "sbin", where /bin was linking to, I erased my own actual /bin folder and now I'm super worried I'm going to lose all my files. At least that's what I read when someone else erased the same folder. I wish I would've been able to get to the creating a backup aspect of having an Unraid system but really, I just started this whole process at the beginning of the year I almost gave up on it completely until IBRACORP's videos reignited the flame. Made it a bit easier to understand, visualize and the info is a little more modern than a lot of videos and information out there on the web. That helped tremendously so I must thank @Sycotix for that. The whole Ibra YT team I suppose. I just very much hope any other people who come across these obnoxious logs from avahi-daemon take them seriously because even though they seem normal, when they repeat the way these were, there's clearly something wrong. Quote Link to comment
Xaero Posted October 19, 2022 Share Posted October 19, 2022 There's so much misinformation/disinformation in your post that its hard to pick a place to start, and I'd almost think it was satire. For example, chmod, chroot, b2sum are all part of the stock unraid release. Nothing additional was downloaded for those. Tmux was the first and only tool you listed that wasn't part of unraid stock, and could have easily been downloading following tutorials that used it. Additionally, Hugepages are simply either supported by the kernel or not supported by the kernel, they don't really get "enabled or disabled" per se, but can be adjusted. 2048kb Hugepagesize is default, and the current release of unraid uses a kernel that supports hugepages. "/" is the root directory. "/root" is the root user's home directory. People mess this stuff up all the time because we use the term root and the username root a lot. To segregate it, root is the superuser ("su"), and the root directory is the base directory of the filesystem ("/"). /bin and /sbin are unique directories, unless one was linked on top of the other there probably wasn't much cause for concern. Certain objects in /sbin will just be symlinks to /bin/executablename and this is by design. Without detailed information on what the symptoms were, what the changes being made were, and log output it's kind of difficult to say if you actually had a compromised system, or just had something configured incorrectly. 1 Quote Link to comment
kris_wk Posted November 12, 2022 Author Share Posted November 12, 2022 i was just misinformed. These observations strictly come from combing through files, picking out things that seemed weird. Once I did though, I started seeing everything had ELF at the beginning with tons of gibberish text. So I was definitely infected with malware. Now being actively hacked, but chances are high they’ve been here for a while and I just didn’t notice. All my Windows machines had it too. They set up a domain using Active Directory, and a bunch of VMs, probably a cloud domain too. I don’t use anything like this and most of my PCs had W10 Pro. My brain is just fried trying to figure this out. Quote Link to comment
kris_wk Posted November 12, 2022 Author Share Posted November 12, 2022 Most likely originating from kids going on things they shouldn’t, and now I just don’t have a clue what to do about it. It’s like a fileless malware. I wipe everything and they still make it back on brand new installs. I clear CMOS, use new drives, OS installed from clean PCs and somehow they make it back. Quote Link to comment
Xaero Posted November 16, 2022 Share Posted November 16, 2022 ELF headers belong on Linux executables and linkable libraries, though - and it's not going to be human readable, it's binary data - if you open it in a text editor it is going to be gibberish because that's not how it is meant to be processed. 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.