251–260 of 335 posts
Earlier quoted context omitted.
You innocent young being. There are some gaping holes in your Internet lore knowledge, but it's been eons since that's been seen in the wild.
This recently came up in a conversation with family, and my nephew of 17 years old knew about it, and said it still exists. Personally I haven't seen it in a long time. I didn't have the guts to tell my family about goatse.
Earlier quoted context omitted.
My It department does mandatory phishing training every year, and then for the "test" e-mails, they spoof a domain and whitelist the DMARC on their side so it goes through. So we get e-mails from @microsoft.com and it's only if you dig in the metadata that you see it failed authentication. The only tell in the e-mail is checking the URL, which doesn't tell you much because tons of regular e-mails use tracker redirect…
Hey, simulating the hack is a lot better than using some canned tool with blatant knowbe4 urls.
Earlier quoted context omitted.
It’s a trade-off. Most people are never going to check the links no matter how much you ask them to, and even if they did they wouldn’t know what to check for. But the tool Microsoft give you to check a link before opening it is that awful URL rewriter, which prevents the small minority who would check from being able to. Similarly those flashing cmd windows are usually automatic update processes that Windows has no…
There is an easy answer. Give employees two computers. One is the 'business' one. Mostly locked down, with checks in place. The other is on a different network, isolated from all business functions, and they can do what they want but must never use it for work data, just like their phones (that everyone knows they use for social media etc. in the day). Sure, you still have to deal with copying from one to the other (…
Developers are the exception here, where usually they'd prefer to develop on a machine with minimal BS running, even if it means carrying around an ultraportable in addition to their development workstation laptop.
Earlier quoted context omitted.
I don't think you can put cookies on a TLD. So if Google used mail.google and calendar.google , the login system would be more complex, because they can't share cookies.
Modern auth systems do not work by exposing multiple services on a single domain with shared cookies. Instead, they authenticate using a common auth service (say, auth.google), which by virtue of being a single domain can persist shared cookies for all its consumers. This would yield a valid token (possibly a JWT) that the authenticating application can then use however it would like, including as a cookie on the app…
Earlier quoted context omitted.
All that anti-phishing training that taught us to look closely at the URL and now it's all just safelinks.protection.outlook.com
My It department does mandatory phishing training every year, and then for the "test" e-mails, they spoof a domain and whitelist the DMARC on their side so it goes through. So we get e-mails from @microsoft.com and it's only if you dig in the metadata that you see it failed authentication. The only tell in the e-mail is checking the URL, which doesn't tell you much because tons of regular e-mails use tracker redirect…
Ah no need, corporate IT already make all URLs malicious looking through some microsoft "secure link" service, and constantly shows everyone shady looking prompts that constantly change and have cmd.exe windows flash in at random. A phone call from Microsoft about my Norton anti-virus subscription putting me into debt that can only be settled with Nintendo gift cards bought in cash across 16 specific gas stations see…
It’s a trade-off. Most people are never going to check the links no matter how much you ask them to, and even if they did they wouldn’t know what to check for. But the tool Microsoft give you to check a link before opening it is that awful URL rewriter, which prevents the small minority who would check from being able to. Similarly those flashing cmd windows are usually automatic update processes that Windows has no…
The flashing cmd.exe windows are not drivers from Windows Update - this could have been the case as drivers shipped with Windows Update is a total security nightmare running arbitrary code with administrative privileges upon hotplug - but in this context of managed devices, commonly from HP or Lenovo's corporate portfolio, it's usually additional products and changes pushed by group policy or random management software.
The often changing user prompts, looking like they were from some early 2000's hello world example, come from obscure and overlapping management software they remotely deploy which they change at will. You don't need a proprietary solution to remotely upgrade Google Chrome, just specify an enterprise policy with auto-update. You don't need a proprietary solution to prompt users and manage Windows Update, because you have... Windows Update.
The URL checker has no valid benefit, and makes it so people can never learn how to do it themselves. The browser performs the exact same checks with the exact same capabilities through its safe browsing stuff, and corporate IT often has network-level solutions too.
Corporate IT uses emails services that spoof domains and look suspicious, reversing all the phishing training they paid for.
Not to mention that Corporate IT might deploy network-wide solutions like Cisco Umbrella, which is a TLS Man-in-the-Middle attack where you install their root CA on all machines and let them control DNS to randomly redirect all traffic to their servers, effectively undermining the basis of all modern web security for the entire organization.
In general there's a fetish for buying products that has significant negative impact to security, user experience and possibility of training users, usually for the purpose of feigning progress and meeting some targets. Say, they had a ransomware incident, and now they're buying every ransomware product for a few years. Stuff with such buggy kernel code that it deadlocks and makes it impossible to create new processes until you hard reboot. I'm sure that's not a security problem!
Earlier quoted context omitted.
I don't think you can put cookies on a TLD. So if Google used mail.google and calendar.google , the login system would be more complex, because they can't share cookies.
Modern auth systems do not work by exposing multiple services on a single domain with shared cookies. Instead, they authenticate using a common auth service (say, auth.google), which by virtue of being a single domain can persist shared cookies for all its consumers. This would yield a valid token (possibly a JWT) that the authenticating application can then use however it would like, including as a cookie on the app…
I created a separate Chrome profile, and logged in to gmail. Then I disabled javascript, then deleted all my google.com cookies (but left my mail.google.com cookies). Then I reenabled javascript and visited mail.google.com again. I was logged out. So Google is using the google.com cookies.
Earlier quoted context omitted.
You innocent young being. There are some gaping holes in your Internet lore knowledge, but it's been eons since that's been seen in the wild.
Its been just long enough. I hope it makes a comeback.
Earlier quoted context omitted.
You innocent young being. There are some gaping holes in your Internet lore knowledge, but it's been eons since that's been seen in the wild.
This recently came up in a conversation with family, and my nephew of 17 years old knew about it, and said it still exists. Personally I haven't seen it in a long time. I didn't have the guts to tell my family about goatse.