Hack confirmed dealing with weird avahi-daemon logs...dang..


kris_wk

Recommended Posts

TL;DR  If you're seeing constant logs from avahi-daemon, beware, you possibly got hacked.   
*Recent edits in blue after learning more and being schooled*
         

      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.
EDIT This was incorrect now that I learned everything broadcasts from .255 (I AM indeed learning lol)
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.
(clearly they got root or made some groups of their own)

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 relatively 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.... " / " 
 
This too was wrong, / is root, but in other distros recently they made a folder called rootfs which they locked me out of
They did similar things with just about every aspect of my system. (/usr/local/state/emhttp became /usr/local/sbin/emhttp).

Leave me alone, I'm trying to learn still lol this one also made no sense and i see that now


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 -alh to list all directories cleanly)
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. 
I still don't understand this but I guess it's normal?

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.
And now I'm more thankful to Blackhat conferences and all the ethical hackers on Youtube along with TryHackMe for teaching me even more stuff

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.

Edited by kris_wk
Learned more and got schooled a bit
Link to comment

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. 

  • Thanks 1
Link to comment
  • 4 weeks later...

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. 

Link to comment

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.

Link to comment
  • 4 months later...

Hi @kris_wk

 

Do you have an example of the Avahi logs that you were talking about? I recently had some Avahi logs start spamming my syslog and I'm not exactly sure what it is? Google takes me to this thread and it's kinda shocking to read.

 

My errors are the following
 

Apr  5 20:18:16 AINCRAD  avahi-daemon[7137]: Joining mDNS multicast group on interface vethde33b3b.IPv6 with address fe80::3c9e:1dff:fe6b:2d30.
Apr  5 20:18:16 AINCRAD  avahi-daemon[7137]: New relevant interface vethde33b3b.IPv6 for mDNS.
Apr  5 20:18:16 AINCRAD  avahi-daemon[7137]: Registering new address record for fe80::3c9e:1dff:fe6b:2d30 on vethde33b3b.*.
Apr  5 20:18:19 AINCRAD kernel: br-870a6a64b157: port 6(vethde2abeb) entered disabled state
Apr  5 20:18:19 AINCRAD kernel: vethcf927ee: renamed from eth0
Apr  5 20:18:19 AINCRAD  avahi-daemon[7137]: Interface vethde2abeb.IPv6 no longer relevant for mDNS.
Apr  5 20:18:19 AINCRAD  avahi-daemon[7137]: Leaving mDNS multicast group on interface vethde2abeb.IPv6 with address fe80::c7:e4ff:fed0:ed63.
Apr  5 20:18:19 AINCRAD kernel: br-870a6a64b157: port 6(vethde2abeb) entered disabled state
Apr  5 20:18:19 AINCRAD kernel: device vethde2abeb left promiscuous mode
Apr  5 20:18:19 AINCRAD kernel: br-870a6a64b157: port 6(vethde2abeb) entered disabled state
Apr  5 20:18:19 AINCRAD  avahi-daemon[7137]: Withdrawing address record for fe80::c7:e4ff:fed0:ed63 on vethde2abeb.
Apr  5 20:18:21 AINCRAD kernel: veth6b779e3: renamed from eth0
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 7(vethde33b3b) entered disabled state
Apr  5 20:18:21 AINCRAD  avahi-daemon[7137]: Interface vethde33b3b.IPv6 no longer relevant for mDNS.
Apr  5 20:18:21 AINCRAD  avahi-daemon[7137]: Leaving mDNS multicast group on interface vethde33b3b.IPv6 with address fe80::3c9e:1dff:fe6b:2d30.
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 7(vethde33b3b) entered disabled state
Apr  5 20:18:21 AINCRAD kernel: device vethde33b3b left promiscuous mode
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 7(vethde33b3b) entered disabled state
Apr  5 20:18:21 AINCRAD  avahi-daemon[7137]: Withdrawing address record for fe80::3c9e:1dff:fe6b:2d30 on vethde33b3b.
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered blocking state
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered disabled state
Apr  5 20:18:21 AINCRAD kernel: device veth06c5b41 entered promiscuous mode
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered blocking state
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered forwarding state
Apr  5 20:18:22 AINCRAD kernel: eth0: renamed from veth3087c0e
Apr  5 20:18:22 AINCRAD kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth06c5b41: link becomes ready
Apr  5 20:18:23 AINCRAD  avahi-daemon[7137]: Joining mDNS multicast group on interface veth06c5b

Link to comment
  • 2 weeks later...

I've got this same issue. I currently have the machine running in safemode no plugin's with webgui on an router with zero internet connection. Docker has been set to not auto start.

 

My passwd, shadow and ntp.conf files in the /etc/ folder all have a hyphen '-' attached at the end of the name. They were created today on server boot-up. When comparing the files there are a TON of new users added that are not in my passwd and shadow files in the boot/config/ folder on my usb drive. 

 

I have noticed that the data activity that people have been posting about the avahi-daemon is not there because this machine has zero web access. I am currently backing up the data I care the most about and will completely rebuild the array as I can't figure out what is causing these very STRANGE issues, including the webgui freezing and the system log filling with these very strange connections on ipv6.

Link to comment

Those exact same things are happening to me... I bid you good luck on finding someone who can help. IDK who to even ask. I dont think AV companies do this, I dont know who to talk to. I've tried to ask people smarter and better at this than me and they all think I'm fuckin crazy so I''ve decided to start a cybersec career by learning as much as I can. I have a million books, and a TryHackMe sub. f*ck it....I hope I learn fast cuz I deadass wanna dedicate my life to helping anyone getting exploited by these lazy ass thractors lol

and this was not directed at the gentleman who tried to help me with what was normal in Linux. I appreciate that schooling cuz I needed something to be normal. I gotta screenshot the crazzy stufff though because it''s undeniable now.

Edited by kris_wk
Didnt want Xaero to think I meant them
Link to comment
On 4/5/2023 at 11:36 PM, 97WaterPolo said:

Hi @kris_wk

 

Do you have an example of the Avahi logs that you were talking about? I recently had some Avahi logs start spamming my syslog and I'm not exactly sure what it is? Google takes me to this thread and it's kinda shocking to read.

 

My errors are the following
 

Apr  5 20:18:16 AINCRAD  avahi-daemon[7137]: Joining mDNS multicast group on interface vethde33b3b.IPv6 with address fe80::3c9e:1dff:fe6b:2d30.
Apr  5 20:18:16 AINCRAD  avahi-daemon[7137]: New relevant interface vethde33b3b.IPv6 for mDNS.
Apr  5 20:18:16 AINCRAD  avahi-daemon[7137]: Registering new address record for fe80::3c9e:1dff:fe6b:2d30 on vethde33b3b.*.
Apr  5 20:18:19 AINCRAD kernel: br-870a6a64b157: port 6(vethde2abeb) entered disabled state
Apr  5 20:18:19 AINCRAD kernel: vethcf927ee: renamed from eth0
Apr  5 20:18:19 AINCRAD  avahi-daemon[7137]: Interface vethde2abeb.IPv6 no longer relevant for mDNS.
Apr  5 20:18:19 AINCRAD  avahi-daemon[7137]: Leaving mDNS multicast group on interface vethde2abeb.IPv6 with address fe80::c7:e4ff:fed0:ed63.
Apr  5 20:18:19 AINCRAD kernel: br-870a6a64b157: port 6(vethde2abeb) entered disabled state
Apr  5 20:18:19 AINCRAD kernel: device vethde2abeb left promiscuous mode
Apr  5 20:18:19 AINCRAD kernel: br-870a6a64b157: port 6(vethde2abeb) entered disabled state
Apr  5 20:18:19 AINCRAD  avahi-daemon[7137]: Withdrawing address record for fe80::c7:e4ff:fed0:ed63 on vethde2abeb.
Apr  5 20:18:21 AINCRAD kernel: veth6b779e3: renamed from eth0
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 7(vethde33b3b) entered disabled state
Apr  5 20:18:21 AINCRAD  avahi-daemon[7137]: Interface vethde33b3b.IPv6 no longer relevant for mDNS.
Apr  5 20:18:21 AINCRAD  avahi-daemon[7137]: Leaving mDNS multicast group on interface vethde33b3b.IPv6 with address fe80::3c9e:1dff:fe6b:2d30.
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 7(vethde33b3b) entered disabled state
Apr  5 20:18:21 AINCRAD kernel: device vethde33b3b left promiscuous mode
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 7(vethde33b3b) entered disabled state
Apr  5 20:18:21 AINCRAD  avahi-daemon[7137]: Withdrawing address record for fe80::3c9e:1dff:fe6b:2d30 on vethde33b3b.
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered blocking state
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered disabled state
Apr  5 20:18:21 AINCRAD kernel: device veth06c5b41 entered promiscuous mode
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered blocking state
Apr  5 20:18:21 AINCRAD kernel: br-870a6a64b157: port 6(veth06c5b41) entered forwarding state
Apr  5 20:18:22 AINCRAD kernel: eth0: renamed from veth3087c0e
Apr  5 20:18:22 AINCRAD kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth06c5b41: link becomes ready
Apr  5 20:18:23 AINCRAD  avahi-daemon[7137]: Joining mDNS multicast group on interface veth06c5b

 Yeah those were the same...I'll try to pull mine up but my unraid has been turned off for months while I learn how to get my family vids and pics off with unraid writing over everything... long story which i think i described above..

Link to comment

Did some more research this afternoon. 

 

It seems to attach to dockers' network bridging to allow it to run hidden (using containers not visible in the webgui) disabling docker makes the script go crazy. It also utilizes miniupnpd in Linux based routers (such as Asus) which has been proven to have a known exploit for versions under 2.0. 

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.