NewsCSO OnlineSMEFinancePublic sector

    We are fighting phishing at the wrong layer

    I timed an attacker once. From registering a domain to having it delegated, certificated and serving a live credential-harvesting page took under 24 minutes, and 12 of those were spent waiting on nameservers. I keep coming back to that number, because it quietly indicts most of what we do about phishing. We block domains. We feed them to our gateways and our DNS filters and our threat intel platforms; we measure how many we have blocked, and we report the figure to a board that finds it reassuring. Meanwhile, the thing we are blocking costs the attacker about a dollar and twenty minutes to replace. The domain is the cheapest thing the adversary owns. It is also the only thing most programs ever see. The layer where the attacker actually has costs is the server. Servers take money and setup time. They persist across campaigns because rebuilding them is tedious. And crucially, a server is shared, which means it carries the rest of the operation with it. Find the server and you do not get one indicator. You get the estate. Which is precisely why modern phishing kits are built to keep you from finding it. The wall, and the crack in it The kits that matter now are adversary-in-the-middle proxies. Rather than serve a fake login page, they relay the victim’s traffic to the real Microsoft sign-in service in real time, hand the real responses back and harvest the credentials and the session token as they pass through. The victim sees a genuine page, completes a genuine multi-factor prompt, and the attacker walks away with a live session. Microsoft documented a single campaign of this shape that reached more than 10,000 organizations , and the model has only become more commoditized since. Put one behind a content delivery network and the server disappears. That is what I ran into last month. Certificate transparency showed me the network’s certificate, not the origin’s. Passive DNS showed the domain had never resolved anywhere else. The internet-wide scanning platforms came back empty, which I initially read as absence and later understood as refusal: the origin dropped any connection that did not present the exact hostname it expected, in under half a second, without serving a byte. That distinction is worth a moment, because it is a mistake I have watched capable analysts make. A null result from a scanning platform against a hostname-gated server does not mean nothing is there. It means you knocked in the wrong language. Treating those two things as the same is how a hunt ends prematurely with everyone satisfied. The email was no help either. The lure had arrived from a genuinely compromised mailbox at a real company with every authentication check passing, so there was no attacker address anywhere in the message. There could not be. Ten approaches, ten dead ends. What finally worked was a cookie the attacker’s own server had handed to the victim. The proxy that signs its own name The mechanism is simple, which is probably why I had never thought to check for it. When the proxy relays a login, Microsoft sees a client connecting. That client is not the victim. It is the proxy, because the proxy is the thing making the connection. And Microsoft, like plenty of services, sets a cookie recording the address it observed that client arriving from. The proxy then does what a transparent reverse proxy does unless someone stops it. It relays the response back down to the victim, cookie and all, because rewriting response headers is work nobody bothered to configure. So, the victim’s browser receives a cookie stamped with the IP address of the attacker’s own relay server. The proxy writes its return address on the envelope and hands it to the person it is robbing. I found it filtering a decrypted capture for cookies the phishing site had set, and the value was neither Microsoft’s address nor my own sandbox’s. It belonged to a small hosting reseller of the kind that takes cryptocurrency. What I did next matters more than the finding itself, and it is the part I would press on any team I advise. I did not treat it as settled. One artifact is a lead, not a conclusion, and the leap from the first to the second is how research gets retracted and how intelligence programs lose the credibility that makes them worth funding. I spent the following hour trying to destroy my own finding. The obvious competing explanation was that the cookie had captured my detonation environment’s egress rather than the attacker’s, so I examined the address itself: a budget virtual server reseller, not a route any commercial sandbox uses. That weakened the alternative without closing it. What closed it was corroboration from directions my first observation could not have influenced, arriving independently and agreeing. Only then did I let myself write the word origin. Had they disagreed, it would have stayed in my notes as unverified, and I would have published it that way. Unproven results are still results. The next analyst gets more use out of a stated uncertainty than out of a confident guess. One email, then the whole estate This is what working at the server layer gets you, and it is the whole argument for doing it. The server address led to a second domain that had quietly pointed there for months without ever serving content, which led in turn to a registrar the operator used nowhere else. Resolving the remaining domains grouped them onto a handful of machines. And two of those machines were carrying domains belonging to separate cloud identity tenants the operator had gone to real trouble to keep apart. That was the break in the case. Those tenants had no visible relationship to one another. Enumerating either would never have revealed the other. But the operator had economized on hosting, and shared infrastructure exposed what compartmentalized identity had concealed. One reported phishing email became a mapped estate of dozens of lookalike domains impersonating real manufacturers, staffing agencies and waste haulers, assembled patiently over six months to support invoice fraud against their customers. None of it was visible from the domain. All of it was visible from the server. I would not have reached any of it by blocking the thing that cost a dollar. Point the same fact at your own tenant The half of this that matters most to anyone running a security program is not the research technique. It is the inversion, and it does not depend on the attacker being careless. If the proxy is what Microsoft sees, then the proxy is what your logs see. When one of your people is phished through one of these kits, the successful sign-in recorded in your tenant carries the relay’s address, not your employee’s. That is a detectable event, and it is one of the few reliable signals you get from an attack that otherwise leaves your controls reporting green. It matters because the preventive control most of us rely on is not stopping this: independent analysis has found that the large majority of accounts compromised through these kits already had multi-factor authentication enabled . Two things determine whether that detection actually works. The first is looking in hosting provider and virtual server ranges, because those are the networks your staff have no business signing in from and where these relays live. The second is remembering that the token is persistent, because the kit clicks the prompt that keeps the session alive, so the attacker’s continued activity surfaces as refresh events rather than fresh sign-ins. A hunt that queries only interactive logins will find the moment of compromise and miss everything that came after it. I have seen that happen. And when you do find one, the response order is not negotiable. The attacker holds a session, not a password. Revoke the sessions first and reset the credential second. Reversed, you have accomplished nothing and the intruder keeps working while everyone believes the incident is closed. I published the full technical breakdown of this case, along with the indicators and detection rules, in a public repository for anyone who wants to work through the evidence themselves. I would rather other people test this than take my word for it. What I would ask you to take from it is not the trick. Blocking domains will always feel like progress, because the number goes up and the reporting is easy. But we are spending our effort on the cheapest thing the adversary owns. The server is where their costs are. That is where ours should be too.

    More on fighting

    Other advisories

    Other news entries

    Source: https://www.csoonline.com/article/4231923/we-are-fighting-phishing-at-the-wrong-layer.html

    ID