I received a critical security alert on my google account about suspicious activity in/from my account. I reset my password and logged out of all sessions.
The security alert comes from a Linux system, which would not be a big deal since this is my OS of choice on my PC. However, I received the alert more than 48h after my PC was last powered on, and 1 hour after I had gone to sleep. In the session manager in google account panel tells me there might be malicious apps/malware/info stealer that caused the alert.
The security check tells me that there was no changes to my account. And it does not inform me about what the suspicious activity was, and from which IP.
I have run clamscan -r -i --bell /home, without detection of malware.
I had some issues with sudo apt update not working (connection timing out (deb . volian . org, always same IP)), however I think that is a DNS issue? There was a period of panic as I thought this might be the virus preventing me from accessing the package manager, I have since installed packages, so no problems there, other than apt update. Edit: Was unrelated, and is now working.
I will list out some things I think might be relevant:
Recently upgraded my pfSense firmware to 2.7.2 (Shuttle DS437)
Recently moved and got a new ISP
Use thunderbird (when I googled my problem I read this might be relevant about the suspicious activity?)
Other activity from my network not logged in on my google account that has been flagged and shown under my account (same IP? this seems unlikely)
Possibility that the Linux system is not my PC and is someone else (trying to log in?)
From what I heave read, the security alert is pretty much real-time, and therefore seems odd to blame it on malware since my computer had not been on for quite some time. Would a session-stealer circumvent this?
My router is Shuttle DS437 with pfSense 2.7.2, there is no BIOS update for this device since its release in 2013 (ver. DS437000.101). I could not find any exploits for it. Perhaps it would be wise to switch to a device with newer BIOS, since it is my firewall after all.
Not sure if I still have my LiveUSB, but can make one with my other computer. I should mention that I have LUKS encryption on my main partition. I would assume the encryption prevents any scanning utility.
I’m not familiar with the google alerts, but can you tell if it came from your IP and involved a log in event? Sometimes they will show log in attempts that are unsuccessful. it still qualifies as suspicious, but it’s a non-event unless you have a weak/leaked password, etc.
Also, the default clamscan virus databases are a little dated. There are a list of unofficial sigs that are more up to date. There are also paid services with more bleeding edge virus signatures.
Also, there are rootkit hunter packages (rkhunter) that will also scan for root kits. I don’t know how effective they are.
Anyhow, the first thing to verify is that if you computer/system was involved and if there was a successful log in.
I’m not really a security guy so just spit balling here.
Beware it seems like ML is increasingly used, and has some false positive rate, and because ML no one can tell why it triggered.
Consider turning the host and watching for what network traffic happens. Better to watch from another host (acting as switch/router), but probably fine on the host itself. You could drop all it’s network / Internet destined traffic as to not make things worse.
seems odd to blame it on malware since my computer had not been on for quite some time. Would a session-stealer circumvent this?
Totally. Session tokens may be stolen days/weeks/months before use. It would depend on the service, how long they’re valid for, if they’re pinned some client property like an IP.
An out of date bios on a router feels an unlikely path in. What would the steps be? Exploit old bios → take over FreeBSD router → take over Linux desktop. Possible, but would be worthy of a trending HN post!
(I presume you haven’t made swiss cheese of your firewall rules.)
There was no info about the suspicious activity other than it came from a Linux system. And that they suggested a malware scan and password reset. There is/was no notification of login or any attempt of changing the password. No IP is noted either.
I am quite confident it was not a password leak, I use KeePassXC with god knows how many bits of entropy. And it is unique of course.
Thanks, will check them out. How do one go about decrypting it manually? Do I have to use a decrypter tool and input the passphrase?
I’m increasingly convinced that it is a false positive, but err on the side of caution. The lack of concrete evidence would point to (in my unqualified opinion) automated pattern recognition or ML, especially since ML or “AI” is a black box.
I did watch the network traffic with btop and the graph in pfSense dashboard, but no deep packet inspection. Will try out opensnoop.
Yeah, don’t think it is that viable, I’m not that important. After all, I don’t have any flight logs to a certain island :P.
Just got adguard and snooper, not really any firewall rules.
You could use whatever method you use to decrypt the drive. How does it get decrypted when you boot normally? Do you input a password? If it’s luks encrypted, then you probably just use cryptsetup luksOpen to decrypt the drive. The decrypted volume should be at /dev/mapper/ Maybe it’s different on pfsense systems. I haven’t played around with it too much or BDSM for that matter.
Encryption protects against powered off in person attacks, but a running system stores the decryption keys in working memory.
Honestly, having your data encrypted just makes ransomware that much more efficient since I only have to encrypt the keyfile to render the drive inaccessible.
So backup the offset and keyfile if you are running encryption.
So far as your OS possibly being compromised: format reload
NEVER trust an OS. Reformat and reload using a hash verified image.
To ease the transition keep your data on a separate drive from the OS
Then be sure all your data files are chmod’d 755 at the highest.
If there is an exploit on the data drive, this renders it non-executable for users
Thankfully it’s not that easy. A malware with this capability will need to coerce the user to run it as root, or else have a good 0-day exploit to escalate its privileges. Since I have never heard of such a malware, I’d assume that companies (the main targets for ransomware) don’t use a lot of drive encryption outside of hardware-supported encryption directly on the drive’s controller.