Does your cybersecurity awareness training contain any hacklore?

I’m collecting examples of hacklore in the wild. Whether it’s training slides, quiz questions, or instructions that focus on rare threats instead of the ones causing the most real-world harm, I want to see it all.

Post some screenshots or notes here, or email them to "info" at hacklore.org. Let’s help organizations replace stale guidance with advice that truly keeps people safe.

@boblord The Federal Communications Commission recently issued guidelines in Public Notice DA 25-996 for the security of broadcasters' STL (studio-to-transmitter) links that included the following:

"Change their devices’ default passwords and replace them with robust alternatives, and regularly change passwords to promote continued security. "

I think the objectionable part is the last part of the preceding sentence. (Most of the rest of the public notice seems OK, actually...but the password lore is especially hard to root out.)

I guess they don't know about NIST.

This came in response to attacks enabled through not changing default passwords. Of course, advice to change default passwords is valid, but regular password changes....

The official notice: https://www.fcc.gov/document/fcc-urges-broadcasters-follow-cybersecurity-best-practices

Description with additional context:
https://radioinsight.com/headlines/322882/fcc-report-11-30-fcc-advises-stations-to-ensure-stl-eas-security/

@boblord I am so sick of the old tropes... Juicejacking, dangerous public Wi-Fi, etc. Will you be posting any submissions/findings?

@chetwisniewski Yes!

@boblord Great initiative, saved and shared!

One suggestion re: "QR codes are simply a way to open a URL" -> users have no clue what URLs are or how to interpret them. Even if you assume they can parse out the true domain (major if!), they don't know which domains are trustworthy. On top of this mobile browsers make it esp. hard to inspect URLs. We need to come up with better advice for site verification!

@buherator I made the edits to the references to "URLs". Thank you for that insight that got past all the proofreaders!!!!!
As for the other part about being able to determine the risk level for a site, well, that might be more of a challenge than copy editing. ;-) But fully agree.

@boblord Wow that was quick, glad I could help!

I've been doing infosec for ~20 years but I only realized recently we communicate wrong after some relatives fell for QR-based scams and had to walk them through what happened.

I agree that determining risk is incredibly hard in this case and TBH I think "don't trust QRs" may be more effective than trying to teach everyone URLs, DNS and PKI...

@buherator I posted some thoughts here:

https://medium.com/@boblord/methods-of-delivery-vs-intrusion-the-hacklore-edition-b042f51954a6

Feedback welcome!

@boblord I agree with your post and also that scanning QRs is not the problem (as stated on Hacklore).

Now that I look more into it, I think I found what's been bugging me about this point. It seems that QR is the only part where Hacklore expects extra work from the user:

"which is mitigated by existing browser and OS protections, and by **being cautious** about the information you give"

... but the recommendations don't say anything about how to "be cautious", while scams initiated via untrustworthy channels are a very real problem.

I think this should deserve a recommendation bulletpoint with at least some rules of thumb. I'm thinking along the lines of:

"If you are contacted via $untrused_comms to give out $sensitive_data, reject the request and initiate the contact yourself via $known_good" (may be simple enough to work if phrased carefully?)

@buherator What are the best anti-scam resources I can link to? It's not the focus on Hacklore but I can make sure there is a smoother on ramp to good guidance.

@boblord That'd make sense, but unfortunately I don't know of any resources I could recommend (in part because of the reasons Hacklore exists...). I keep this in mind though and let you know if I find anything!