[nerdjon]

I DESPISE these links from Outlook and Teams (not sure if it is specifically the teams implementation or something else).

I don't know about your company but mine has us do these phishing tests and training videos all the time and then we get rid of one of the safety features that they keep hammering us about.

I can't just look at the URL before clicking it. I once "fell victim" to one of our phishing tests because I clicked the link in the email. And its like... well we have been trained by our own email system that the only way to actually see the validity of the link is to click it.

[open-paren]

Those corporate phishing tests are often administered by KnowBe4, and KnowBe4 identifies their phishing emails with custom email headers (can't remember what it is off the top of my head). So if you view the source code of an email and look for the obvious KnowBe4 header, you can tell ahead of time.

[0xR1CK]

viewsource > ctrl+f > 'threatsim'

[isoprophlex]

lol yeah. I curled the url in a suspicious email once, to investigate what it was. YOU FAILED THE TEST. ugh...

[nerdjon]

It just frustrates me that I have brought this up multiple times, wondering why we are paying to do this training and then we can't actually do the training.

Like it would be one thing if the URL then just had the full URL in it and we could still see where it was going. But no, it is a completely obfuscated URL.

The worst part is, it isn't like it takes you to a page to verify you actually want to go to this link. It just takes you right there assuming you are on a browser that has approved that it can open links from your email.

I really really want to do know what good this does AT ALL besides likely checking some checkbox for something.

[mnw21cam]

In their defence, curl isn't completely benign in this case. You just confirmed to the person who sent you the link that your email address is valid and reaches a person.

[saalweachter]

Also, there's no reason to believe that you're curling the same redirect as you get from clicking the link.

There's this thing compromised webservers do where, if you type in www.example.com into your browser, and go straight there, you get the normal web page. If you click a link from Google, and have a google.com referrer in your request, you get a little bit of JavaScript included that that redirects you to another site to buy herbal remedies or fake watches or whatever.

If you are the business owner and go directly to your home page to see what's what, you think everything is fine; if you are a tech trying to debug it and you curl the webpage, everything looks fine [unless you curl with a referrer set]. You probably think Google has the wrong URL or something.

Likewise -- I don't know what a click-through from an email client looks like, but it wouldn't surprise me if there's an identifiable header or referrer or something. If that's the case, you could write your malicious URL shortener to redirect you to www.example.com/ if you curl it bare, or www.exam.ple.co/m/ if you have the redirect header. Curling the URL in question doesn't necessarily prove it's safe to click on.

[isoprophlex]

Christ, that's depressing. I'm not much of a web guy, didn't know you could do this. Thanks for sharing...

[salawat]

Not that depressing. Audit your current web server configurations. You can dump the in-memory representation generally. Diff it with the on disk representation, and bam. Instant canary. If you're worried about a tainted on disk version, do the integrity check against a version invisible to the outside net.

Also, redeploy configs and reload on the regular, and you essentially force an actor to get an active foothold on your system to re-exploit and persist the compromise.

It's not impossible to defend yourself against these types of things if you're vigilant. You can also script your deployment to the point where you can nuke your site from orbit with minimal impact, and reestablish it. It's all about your threat model.

But yes. Things like nginx, apache & co are remarkably comprehensive in the things you can configure them to do. I find that my most dreaded part of standing up a new service is inevitably writing the load balancer/host web server configs.

No computing is 100% fire and forget safe though.

[isoprophlex]

You're completely right of course, and I hadn't considered that.

However, there's apparently people scraping and reselling (or bribing employees, dunno) corporate directories. In my case everyone has [e-mail], so judging by the high volumes of creepy ass, targeted corporate spam I get on my work mail... this is hardly a public secret.

[Ferret7446]

Not necessarily? What's stopping an email server from probing links in all incoming emails regardless of valid recipient for malware analysis purposes?

In fact, I would be surprised if, e.g., Gmail, does not do this.

[hotnfresh]

Our tests (outlook email) motherfucking bypass user filters too. I wrote some so I’d never have to worry about these damn things, but they go right through.

Guess I’m going to have to configure an actual user-agent email client that won’t screw me when someone else asks it to.