Can't speak to whether a reprimand is warranted or not and I think many here will disagree, but unless your job is investigating phishing, you shouldn't do this because you ARE ultimately putting the corporate network at risk unnecessarily - what if it was a real link and happened to exploit a zero day on your box? Management wouldn't accept your reasoning for following the link I suspect.

The risk of hitting an exploit on the command line, especially with something like wget, is enough orders of magnitude lower that I think it falls under acceptable. The standard cannot be zero risk because that's impossible. Even shutting off the internet link doesn't get you all the way to zero.

The issue isn't how much risk there is in opening it. The problem is that regardless of how much or little risk there is in opening the link, it wasn't op's job to examine it. It was unnecessary risk to open the link.

It's unnecessary to look at something on imgur, too, but that doesn't mean you should get reprimanded if that causes a hack somehow.

I mean, it's not my job to refill the office coffee pot when I take the last cup of coffee, either, but since I'm decent to my coworkers I'd probably do it. Not the OP, but since I know how to open a malicious link safely in wget I would happily do that for similar reasons, and if I got reprimanded for it "not being my job"... I'd start looking for a new job where I'm respected for what I'm able to do.

My job is not investigating phishing but security is everyone's job. Reporting what was obviously a targeted phishing attack to the people who do investigate phishing is a basic expectation. Now before you try to tell me "well you should've forwarded the email and been done with it" those guys are going to be pissed as fuck if I pass along every spam link trying to sell me boner pills, so I've got a duty to make sure it's a credible threat. As somebody who knows how to safely investigate such a link and did exactly that it was ridiculous to be penalized. Security (albeit not for email) is a part of my job. I don't think people should be trained not to use their brains when it comes to security threats. If people used their brains more often phishing would hardly be a problem to begin with.

"Now before you try to tell me "well you should've forwarded the email and been done with it" those guys are going to be pissed as fuck if I pass along every spam link trying to sell me boner pills"

I know you say the team would be pissed, but it's actually the exact opposite! Firstly, most sophisticated companies have automated the abuse inbox management process, but even when it's not automated, I'd rather 100 easily ignorable reports about boner pills than one person not send an actual spear-phishing email. Plus we can use the generic spam reports to better train our spam filters so please do keep sending them, even the Nigerian prince stuff.

Considering that from what I recall Lynx doesn't execute javascript, it would have to be one esoteric zero-day

Lynx has still had remote code execution CVEs in the past. It's probably a smaller attack surface than a regular browser, but far from nonexistent.

It's been over a decade since there was an RCE for Lynx. The difference between the attack surface of Lynx compared to a regular browser is several magnitudes. No code is safe, but giving someone grief over following a link using Lynx is security theater at its worst.

Downloading and executing code is only one way a browser session can be abused. At the very least you're giving away everything your browser (even Lynx) puts in the headers of a request. That's often a heck of a lot of useful information for an attacker. Lynx supports cookies too so it would be possible to track a user between sessions. I don't know how that might benefit an attacker but I'm not an attacker[1].

I think a reasonably paranoid approach like "Hackers might think of ways to abuse this that I haven't thought of" is best. Unless your job is to take a risk and visit a phishing site, don't take the risk. Even with Lynx.

[1] Exactly what an attacker would say!

>At the very least you're giving away everything your browser (even Lynx) puts in the headers of a request.

Which you're giving away any time you browse any external web site.

>Lynx supports cookies too so it would be possible to track a user between sessions.

You're downloading cookies for most external web sites.

If the worst you do is the same as going to espn.com, then reprimand people for going to any external web site.

The point is that you're giving data to a known phishing site by visiting the link in a phishing email. It's true that ESPN might also be a phishing site but it's less likely.

And my point is the data you're giving is not important.

By default, Lynx prompts to deny/accept cookies for every domain.

I doubt most if not all exploits would work in lynx/links.

But your point is spot on, don't take it upon yourself to do things that aren't in your job description. Otherwise you become that person who takes it upon themselves to "fix" things and makes the problem worse for the people responsible for fixing things.

When I got outed for doing that, I got a thank you card.

I made my own signs for wayfinding (Main Building ——>, and “Floor 7” when the stairwell was missing it).

Some are still up a few years later.

> don't take it upon yourself to do things that aren't in your job description

That's a great way to never go anywhere in your career.

Did you alter the URL at all? Every phishing test campaign I've seen has a URL in the form of like http://totallylegit.your-company.com/somePath/login?id=12345.... I'd change the id= to some other value before testing to mess with their tracking.

Unless you're certain how that ID is generated and/or linked to your identity, you've probably just put someone else at your company on the naughty list.

Be a good guy greg and write a quick curl script to hit all 25k other links. If everyone is in trouble then no one is in trouble!

"We just got a new alert that an employee fell for the phishing attempt!"

"But... this employee has been dead for 20 years..."

Seems like you should just hit all the IDs to be safe. Or put your own personalized message in the ID parameter.

id=SSBsaWtlIFN3ZWRpc2ggUGhpc2g

Just change it something incredibly unlikely. Like "id=1".

Counting opening a mail as failing is ridiculous. A a phising test should only count captured logins.

Following a link can readily enough expose someone to risks. Phishing isn't always just about entering logins.

That's true for any email, not just phising. Unless you can verify and trust all senders.

Yup. This is why people are taught not to click links in emails for things like banking. It's a dangerous world out there, even for seemingly innocuous things.

When I see one of these, I actually do go onto my Corp iPhone to delete the email instead of Outlook/Windows.

It may not be a perfect approach since we do use it for MFA...

Presumably you were able to explain your case and have the reprimand expunged from your record. As long as they are reasonable in that way I don't think occasionally testing the people handling sensitive data is a bad idea.

Should it be expunged though? They've indicated they were aware it was quite clearly a phishing attempt, but they still accessed the link. If the test was to see if a user would try accessing the link, then this user failed the test. Why should that be expunged?

Curiosity shouldn't preclude security, and intent shouldn't preclude policy if the operator operated knowingly.

This isn't to attack maxk42, but to engage the question head on.

The goal is "don't be phished", right? Measuring http requests is a proxy for that, and not a completely accurate one.

> intent shouldn't preclude policy

Oh boy, I hope I never work in this kind of organization.

I was hoping implicit in this statement, along with other contexts offered that this would have been read with "information security" in mind, on me to communicate that better next time.

I think a better idea for the person involved is to work at a company that isn't run by self-serious bureaucrats.

If I’m curious I’ll open the link off the company network. Easiest way I can think of is just opening with a browser on my private iPhone while on a 4G connection.

It would still trigger the fail. Typically the link contains an identifier and the landing page is hosted on a public facing web server.

Yeah - I’d be wary of doing it without changing the parameters for that reason. But obviously you can’t check a link without checking a link.

It would also be interesting to hear whether someone actually considers me to have failed anything when visiting a (faux) attacker’s link on my own device off the company network and entering no credentials.

They’re probably not that advanced with it. If anything, you’ll upset IT with extra paperwork to grant you the exemption from the hit.

I wonder what happens when a bot crawls one of the phishing sites and triggers all the unique links...

Next time I’ll try that. Hit all the Id’s but my own and take the day off when everyone else is sent to reeducation camp.

The fact you visited the link would let them know that company x has an current employee named y.

Whilst that information might not be sensitive it could be used at a later date to extract sensitive company information.

They could also look you up on LinkedIn.

There should be a line drawn between real security-conscious workplaces, and the kind of self-important chickenshit places that seem to delight in playing games and harassing their employees with this kind of thing.

Yes, it does. You should have been let go.

Really, you'd fire every engineer that shows an ounce of curiosity? I'm glad I don't work where you work.