Infected: Don't Be Like Me, Close Your Ports

The Vulnerability of Cybersecurity

Yeah, judging by the title, it seems I’ve been pwned. I’m not a cybersecurity expert, but I’ve been pivoting to learn more about creating secure systems as I increasingly interface with the web.

Lately, I keep hearing about breaches from these major silos, and it’s gotten me thinking. What the HELL! I feel increasingly vulnerable as we grow within these ecosystems. Over time, we develop a trust in these services, paid or not, only to find they often become vectors of exploitation. An enormous amount of our data is stored within these giant silos, and it’s frustrating because it feels like we have little to no choice but to use much of the half-baked infrastructure that’s out there. We live in a world where security is seen as a liability that can be written off. Many of these companies perform a cost-risk analysis that favors continued ignorance since it’s more profitable than investing in securing their systems. It seems they’re contingent on just paying whatever fines come with their intentional ignorance. I’ll stop ranting, but the gist of this post is to ultimately say that moving forward, I intend to be responsible for my systems and not rely on the black-box infrastructure of others.

The Awakening: Recognizing the Threat

It began with a routine check of my system files and a flag was raised after looking into some of my firewall configs.

Step 1: Identifying the Culprit

Some of the tools that helped assist me on malware identifcation.

Step 2: Isolation and Backup

I disconnected my device from the network, creating a digital quarantine. Then came the backup process. Side note: I discovered a budget-friendly backup solution – an M2 NVMe SSD with an enclosure. Functional, economical, and surprisingly easy.

Firewall mishaves

My firewall configurations were a patchwork of permissions and restrictions. But a particular port, 1337, flagged by a foreign IP, seemed out of place. This kicked off another round of investigations.

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
Anywhere                   ALLOW IN            
6881:6891/tcp (Deluge)     ALLOW IN    Anywhere                  
22                         ALLOW IN    Anywhere                  
23/tcp                     ALLOW IN    Anywhere                  
51413 (Transmission)       ALLOW IN    Anywhere                  
1965                       ALLOW IN    Anywhere                  
1:65535/tcp                ALLOW IN    Anywhere                  
631/tcp                    DENY IN     Anywhere                  
1337                       ALLOW IN              
631                        ALLOW IN    Anywhere                  
1337                       DENY IN     Anywhere                  
6881:6891/tcp (Deluge (v6)) ALLOW IN    Anywhere (v6)             
22 (v6)                    LIMIT IN    Anywhere (v6)             
51413 (Transmission (v6))  ALLOW IN    Anywhere (v6)             
1965 (v6)                  ALLOW IN    Anywhere (v6)             
1:65535/tcp (v6)           ALLOW IN    Anywhere (v6)             
631/tcp (v6)               DENY IN     Anywhere (v6)             
631 (v6)                   ALLOW IN    Anywhere (v6)             
1337 (v6)                  DENY IN     Anywhere (v6)             

1337                       ALLOW OUT              
1337                       DENY OUT    Anywhere                  
1337 (v6)                  DENY OUT    Anywhere (v6)             

More Forensics

Here is a warning of a potential rootkit/.


The Hard Decision: System Wipe

In the end, I opted for a complete system reset – a clean slate approach. It was a tough call but a necessary one in the pursuit of digital cleanliness.

Reflection and Forward Steps

This ordeal was more than a cybersecurity crash course. It was a wake-up call to the realities of our digital existence. Next, I plan to document my journey in creating a robust backup system using Rsync and Rclone. Stay tuned for more adventures in the land of digital defense.

Microsoft’s In-Depth Release on Linux Trojan

Recently, Microsoft released an in-depth report following a spike in activity involving a Trojan on Linux machines. This Trojan was first discovered by the research group MalwareMustDie in 2014. For more details, you can read about the Trojan in their article, “Rise in XorDdos: A Deeper Look at the Stealthy DDoS Malware Targeting Linux Devices.”

Concerning Discovery in ‘etc/passwd’ File

The last thing that worried me, and I think might have been a false positive, concerned a user entry in my etc/passwd file. This was particularly concerning:

Kernel Overflow User

Surprisingly, I couldn’t find any detailed information on what this meant. At first glance, I thought it indicated a buffer overflow causing escalated privileges to the kernel. If anyone reading this has a better explanation of what process is responsible for this user, I’d appreciate it. From my brief research, it seems the UID 65534 is the overflow user, who is the root super-user. This ‘nobody’ user should be used exclusively with NFS (Network File Sharing), which is odd since I don’t recall installing or using that service. My hunch, giving the benefit of the doubt, is that it might be related to the Castor & Gemini server I was running. But again, I didn’t want to go down that rabbit hole. I was just looking for any indicators of suspicious activity.

Monitoring Network Activity

Lastly, since the Trojan was used for Distributed Denial of Service (DDoS) attacks, I thought it prudent to monitor network activity. I’ve been sniffing packets using Wireshark and also downloaded Snort as a precautionary measure.

farm-gallery arena