--- title: Site Hacks That Start on Your Own Computer description: "Many hacked sites were never broken into at the server. The attacker logged in with passwords taken off someone's laptop. Here is how to shut that down." date: 2026-10-19 updated: 2026-10-19 tags: [security monday, passwords, malware] url: "https://drivenhost.com/blog/hacks-that-start-on-your-computer" author: DrivenHost --- Another Monday, another note from the server room. Here is a pattern we see often enough that it is worth writing down: a site gets compromised, the owner asks which plugin let the attacker in, and the answer is none of them. Nothing was brute-forced. Nothing was exploited. Someone logged in with the real password, because that password was sitting in a browser on a machine that had malware on it. From our side that looks like an ordinary successful login. No failed attempts, no odd requests, no error in the logs. That is exactly why it can run for weeks before anyone notices. ## What malware on a laptop takes The common family here is the information stealer. It runs once, quietly, and copies everything useful it can reach: passwords saved in the browser, autofill entries, saved form data, and session cookies. Those get bundled into a file and sold in bulk. Buyers search the bundles for anything that looks like a hosting panel, a registrar, a webmail login or a WordPress admin URL. This is not a problem limited to big companies with security teams. Verizon's 2025 Data Breach Investigations Report found that of the compromised systems with corporate logins in the stolen data, 46% were non-managed devices holding both personal and work credentials. That is a personal laptop with the business login saved in it, which describes most small-business setups we support. ## Session cookies are the part people miss Two-factor authentication guards the login form. A stolen session cookie skips the login form entirely, because it is proof that someone already logged in. Paste it into a browser and you are inside the account, with no password prompt and no second factor. The practical consequence: changing a password is not the whole job. You also have to end the sessions that are already open. For WordPress, the keys and salts in `wp-config.php` are what sign the login cookies. The WordPress documentation is blunt about it: change them and all existing cookies are invalidated, and everyone has to log in again. That one edit is the fastest way to throw out every logged-in session, including the attacker's. Expect your own phone and office machines to ask for a password afterwards. On the hosting side, open a ticket and ask us to clear active sessions on the account after you reset the password. We would rather do that than have you wonder. ## Keep hosting passwords out of the browser A few habits do most of the work here. Use a dedicated password manager rather than the browser's built-in save prompt. Stealers target browser password stores first because the format is well known and easy to parse. A separate manager with its own unlock is a harder target, though not a magic one. Never reuse the cPanel password. It is the master key to the account: files, databases, email, cron, DNS records. If it appears anywhere else, that other place is now your weakest point. Watch the desktop FTP clients. Several of them keep saved passwords in a plain file on disk, which malware reads as easily as the browser store. Give each person their own FTP account instead of sharing one, so a single compromise does not mean rotating credentials for everyone. Keep two-factor on the registrar and on email, which are the two accounts that can be used to take everything else. We covered the account-level side in [hosting account security](/blog/hosting-account-security), and the same goes for every mailbox on a [business email](/email) plan. ## If you think a machine was compromised Order matters, and the first rule is that you do not use the suspect machine for any of this. Borrow a phone or another computer. Reset the cPanel password first, since it governs everything underneath. Then the email account passwords, then database users and FTP accounts, then WordPress users. Rotate the WordPress salts last, after the passwords are changed, so you are not kicking the attacker out of a session only to leave them a working login. Then go looking for what was left behind. New administrator users in WordPress, new FTP accounts, email forwarders you did not create, unexpected cron jobs, application passwords and API tokens. A lot of compromises plant a quiet second way in, and cleaning the files alone does not remove it. Our walkthrough of [what a hacked site looks like from the server](/blog/hacked-site-server-view) covers what we check first. Finally, deal with the laptop. Scanning sometimes works. Rebuilding is what we would do, because a stealer often arrives bundled with other things, and you cannot verify a clean result by feel. If you are in the middle of this right now, or you just want a second set of eyes on the login history for your account, [open a ticket with our support team](/support) and we will look through the logs with you. ## Sources - [Verizon 2025 Data Breach Investigations Report, Executive Summary](https://www.verizon.com/business/resources/reports/2025-dbir-executive-summary.pdf) - [WordPress: wp-config.php security keys and salts](https://developer.wordpress.org/apis/wp-config-php/)