Account takeover: what actually happens when someone hijacks an advertiser's login

A password worth more than the account it opens

Most accounts on the internet hold nothing a thief can use directly. A stolen login to a forum or a newsletter is worth pennies on a criminal marketplace because there is nothing behind it. An advertiser's account on a classifieds directory is a different animal. Behind that one login sits a paid subscription tied to a card on file, months or years of ranking history that a brand-new listing could never buy back, a badge that took actual verification work to earn, and a phone number or inbox that existing clients already trust. Whoever holds the password inherits all of it instantly, with no waiting period and no new checks.

That is what makes these accounts worth stealing even when there is no cash balance sitting inside them. A criminal who takes over a listing does not need to drain a wallet. They need the badge, the position in search results, and the trust that both represent, and they get all three the moment the password works. The listing itself can be swapped out entirely, different photos, different contact number, different city, while the credibility signals the platform spent months building stay exactly where they were.

Operators tend to under-defend these accounts precisely because the value is not a number in a balance field. A bank builds fraud controls around a dollar figure it can point to. A directory has to defend reputation and search position instead, assets that do not show up on a balance sheet but that a client relies on just as literally when they decide whether to trust a stranger's listing. Treating advertiser logins like low-stakes accounts because no cash sits behind them misreads what is actually at risk.

The gap shows up first in support tickets, not in fraud dashboards: an advertiser writes in insisting they never posted what is now live under their name, or a client complains about a listing that stopped answering the way it used to. By the time either message arrives, the account has usually been in someone else's hands for days.

How the login actually gets stolen

Very few of these takeovers involve a criminal specifically targeting one advertiser. The far more common pattern is credential stuffing: an attacker takes email and password pairs leaked from a completely unrelated breach, on a shopping site or a forum that has nothing to do with the directory, and runs them automatically against the login form here, betting that a meaningful share of people reuse the same password everywhere. Security researchers classify this as a distinct category of automated attack from ordinary password guessing, precisely because nothing is being guessed. Every credential tried has already been proven to work somewhere else.

Phishing is the other major source, and the two feed each other. A fake email about a reported listing or an expiring subscription, styled to look like it came from the platform, sends the advertiser to a login page that captures whatever they type. Those stolen pairs often end up in the same lists later used for stuffing attacks against other sites, so the two vectors are not really competitors, they are stages of the same supply chain.

What makes credential stuffing hard to stop with the obvious fix is scale and distribution. A handful of failed logins from one IP address gets caught by almost any basic lockout. Thousands of attempts spread across a rotating pool of residential proxies, a few per address, look like ordinary traffic to a defense built around blocking one address after a few failures. This is why attempts against any login form with real value behind it tend to be constant, low-level background noise rather than a rare, dramatic event, and why treating account security as something to think about only after an incident is reported is already too late.

The practical consequence for an operator is that the login form itself is the front line, not the support queue that deals with the aftermath. Whatever gets built to slow this down has to work against continuous, distributed attempts, not against one obviously suspicious person trying the same account fifty times in a row.

What it actually costs once someone is inside

The first thing an attacker with a working login usually does is check what the account can reach: billing details, payout information, the listing content itself, and whatever contact details route incoming client interest. Changing the contact number or the linked messaging handle is often the very first move, because it silently redirects every future client inquiry to the attacker rather than the real advertiser, who has no idea anything has changed until a client mentions it or the money stops arriving.

The badge is the second casualty, and it is the one that matters most to the platform's own reputation. Calling a listing verified is a claim about a process that was true at one specific moment, not a permanent fact about whoever is currently running the page, and a hijacked account defeats that claim completely while leaving the badge itself untouched. The person a client is now dealing with was never checked. The platform's own trust signal is now vouching for someone it has never seen.

Money moves too, and it usually moves through the card already on file rather than a new one. An attacker who wants to launder a stolen card's validity, or simply wants to fund heavier promotion on the account they just took, buys ad credits or featured placement using the payment method the real advertiser left saved. When the actual cardholder eventually notices the charge, they dispute it with their bank, and that dispute counts against exactly the same fraud and dispute-rate thresholds that already put a high-risk merchant account on notice, except this time the operator cannot even point to a customer relationship gone wrong. The card on file belonged to someone who never authorized the specific purchase a stranger made with their own stolen login.

Underneath all of this sits a support cost that is easy to underestimate: two people, the real advertiser and whoever the attacker is now impersonating them to, both believe they are dealing with a legitimate account, and someone on the platform's side has to work out which version is genuine, restore the correct one, and explain to a client why the person they had been messaging for a week was not who they thought.

Whether this becomes a legal notice, not just a support ticket

Whether an account takeover creates a legal notification duty depends on exactly what the attacker could see, not just that they logged in. California was the first state to add compromised login credentials, specifically a username or email address combined with a password or a security question answer, to what counts as personal information under its breach notification law, back in 2014, and well over a dozen other states have since added similar language of their own. Where that category applies, a takeover limited to the login itself, with no Social Security number, government ID, or financial account number exposed, can trigger a notification duty on its own.

What that duty actually requires is usually lighter than people assume, and it is worth knowing the difference before deciding whether to worry. Several of the states that cover compromised credentials this way let the operator satisfy the requirement with a narrower notice, one that simply directs the affected person to reset the password and any security question tied to it, rather than the fuller notice package that a stolen Social Security number requires, complete with regulator notice and, in some states, an offer of credit monitoring. A number of states also only require any notice at all once there is a real risk of identity theft or financial harm, so a login-only takeover with nothing else exposed can fall outside the duty entirely in those places.

This is exactly why the details of what an attacker actually accessed matter more than whether they logged in at all. A session that only reached the listing editor is a different event, legally, from one that opened the page holding a payout bank account number or a scanned ID uploaded during verification. Logging what was viewed, not only when the login happened, is what lets someone decide quickly which rule actually applies instead of guessing under pressure with a client already asking questions.

None of this requires a legal team on retainer to get right. It requires knowing, before the first incident, which category an account takeover on this platform would fall into, and having that answer ready instead of researching it for the first time while an advertiser is already threatening to call a lawyer.

What actually stops it, in order

Multi-factor authentication on the advertiser login is the single highest-leverage fix, because it defeats credential stuffing directly: the attacker has a password that works, but not the second factor, and the attempt fails regardless of how many valid password pairs they are trying. NIST's current digital identity guidelines, finalized in 2025 and written for federal systems but widely used elsewhere as the reference point for this exact problem, describe the same conclusion from the defender's side: rather than forcing users to change passwords on a schedule, which mostly trains people to pick weaker passwords they can remember changing, the guidance calls for forcing a change only when there is actual evidence of compromise, for checking any new password against lists of commonly used or already-known-compromised values, and for capping the number of consecutive failed login attempts a single account will tolerate before it locks. None of that is exotic engineering. It is a login form that pushes back.

Killing every active session the moment a password changes closes the most common follow-on move, where an attacker who gets locked out by a password reset simply keeps using the session they already opened before the reset happened. Without that step, a password reset protects against the next login, not the one already in progress.

Treating a sudden, major change to a previously verified listing as a signal worth a second look, not just an approval to wave through, catches a specific pattern that a hijacked account produces almost every time: new photos, a new phone number, and a badge that carries over from before, all changing within the same session. A brief manual check before that combination goes live costs a moment of staff time and stops the exact scenario where a badge earned months ago ends up vouching for someone who was never verified.

Payout and bank details deserve a stronger lock than everything else in the account, since that is the one field an attacker changes specifically to redirect real money, not just reputation. A cooldown period before a changed payout account becomes active, paired with a notice sent to the old contact details rather than the new ones, gives the real advertiser a window to catch the change and object before a single payment goes to the wrong place.

None of this needs to happen all at once. Turning on multi-factor authentication for accounts that carry a stored payment method, putting a delay on payout changes, and writing down, in a paragraph, what counts as an incident and who decides whether it triggers a notification duty are three afternoons of work, not a security program. The alternative is finding out how each of those questions gets answered while an advertiser is already on the phone asking why someone else is using their photos.