Med-Mastodon

Europe Says<a href="https://www.europesays.com/2207401/" rel="nofollow noopener" translate="no" target="_blank">https://www.europesays.com/2207401/</a> Scammers have a new tactic: impersonating DOGE <a href="https://pubeurope.com/tags/DepartmentOfGovernmentEfficiency" class="mention hashtag" rel="nofollow noopener" target="_blank">#DepartmentOfGovernmentEfficiency</a> <a href="https://pubeurope.com/tags/DepartmentOfGovernmentEfficiency" class="mention hashtag" rel="nofollow noopener" target="_blank">#DepartmentOfGovernmentEfficiency</a>(DOGE) <a href="https://pubeurope.com/tags/doge" class="mention hashtag" rel="nofollow noopener" target="_blank">#doge</a> <a href="https://pubeurope.com/tags/ElonMusk" class="mention hashtag" rel="nofollow noopener" target="_blank">#ElonMusk</a> <a href="https://pubeurope.com/tags/Musk" class="mention hashtag" rel="nofollow noopener" target="_blank">#Musk</a> <a href="https://pubeurope.com/tags/proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#proofpoint</a> <a href="https://pubeurope.com/tags/scam" class="mention hashtag" rel="nofollow noopener" target="_blank">#scam</a>

Emory<a href="https://soc.kvet.ch/tags/Microsoft" class="mention hashtag" rel="nofollow noopener" target="_blank">#Microsoft</a> <a href="https://soc.kvet.ch/tags/Entra" class="mention hashtag" rel="nofollow noopener" target="_blank">#Entra</a> getting more unwanted attention. Didn't we hear about this a couple of months ago?> Researchers at <a href="https://soc.kvet.ch/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a> are describing a hacking campaign that is using the team filtration pen testing framework to target more than 80,000 Microsoft Entra ID accounts at hundreds of organizations worldwide. Blame is being placed on a threat actor called <a href="https://soc.kvet.ch/tags/UNK_sneakystrike" class="mention hashtag" rel="nofollow noopener" target="_blank">#UNK_sneakystrike</a>. The attacks occurred from December of last year through to March.<a href="https://soc.kvet.ch/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#infosec</a> <a href="https://podcasts.apple.com/us/podcast/cyber-security-headlines/id1527478719?i=1000712717747" rel="nofollow noopener" translate="no" target="_blank">https://podcasts.apple.com/us/podcast/cyber-security-headlines/id1527478719?i=1000712717747</a>

KrebsOnSecurity RSSOops: DanaBot Malware Devs Infected Their Own PCs<a href="https://krebsonsecurity.com/2025/05/oops-danabot-malware-devs-infected-their-own-pcs/" rel="nofollow noopener" translate="no" target="_blank">https://krebsonsecurity.com/2025/05/oops-danabot-malware-devs-infected-their-own-pcs/</a> <a href="https://burn.capital/tags/DefenseCriminalInvestigativeService" class="mention hashtag" rel="nofollow noopener" target="_blank">#DefenseCriminalInvestigativeService</a> <a href="https://burn.capital/tags/ArtemAleksandrovichKalinkin" class="mention hashtag" rel="nofollow noopener" target="_blank">#ArtemAleksandrovichKalinkin</a> <a href="https://burn.capital/tags/U" class="mention hashtag" rel="nofollow noopener" target="_blank">#U</a>.S.DepartmentofJustice <a href="https://burn.capital/tags/Russia" class="mention hashtag" rel="nofollow noopener" target="_blank">#Russia</a>'sWaronUkraine <a href="https://burn.capital/tags/Ne" class="mention hashtag" rel="nofollow noopener" target="_blank">#Ne</a>'er-Do-WellNews <a href="https://burn.capital/tags/AleksandrStepanov" class="mention hashtag" rel="nofollow noopener" target="_blank">#AleksandrStepanov</a> <a href="https://burn.capital/tags/ALittleSunshine" class="mention hashtag" rel="nofollow noopener" target="_blank">#ALittleSunshine</a> <a href="https://burn.capital/tags/LummaStealer" class="mention hashtag" rel="nofollow noopener" target="_blank">#LummaStealer</a> <a href="https://burn.capital/tags/Flashpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Flashpoint</a> <a href="https://burn.capital/tags/proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#proofpoint</a> <a href="https://burn.capital/tags/microsoft" class="mention hashtag" rel="nofollow noopener" target="_blank">#microsoft</a> <a href="https://burn.capital/tags/teamcyrmu" class="mention hashtag" rel="nofollow noopener" target="_blank">#teamcyrmu</a> <a href="https://burn.capital/tags/Intel471" class="mention hashtag" rel="nofollow noopener" target="_blank">#Intel471</a> <a href="https://burn.capital/tags/Maffiozi" class="mention hashtag" rel="nofollow noopener" target="_blank">#Maffiozi</a> <a href="https://burn.capital/tags/DanaBot" class="mention hashtag" rel="nofollow noopener" target="_blank">#DanaBot</a> <a href="https://burn.capital/tags/JimmBee" class="mention hashtag" rel="nofollow noopener" target="_blank">#JimmBee</a> <a href="https://burn.capital/tags/Zscaler" class="mention hashtag" rel="nofollow noopener" target="_blank">#Zscaler</a> <a href="https://burn.capital/tags/google" class="mention hashtag" rel="nofollow noopener" target="_blank">#google</a> <a href="https://burn.capital/tags/Paypal" class="mention hashtag" rel="nofollow noopener" target="_blank">#Paypal</a> <a href="https://burn.capital/tags/Lumen" class="mention hashtag" rel="nofollow noopener" target="_blank">#Lumen</a> <a href="https://burn.capital/tags/DCIS" class="mention hashtag" rel="nofollow noopener" target="_blank">#DCIS</a> <a href="https://burn.capital/tags/ESET" class="mention hashtag" rel="nofollow noopener" target="_blank">#ESET</a> <a href="https://burn.capital/tags/Onix" class="mention hashtag" rel="nofollow noopener" target="_blank">#Onix</a> <a href="https://burn.capital/tags/fbi" class="mention hashtag" rel="nofollow noopener" target="_blank">#fbi</a>

🆘Bill Cole 🇺🇦Just had to spend an hour dissecting and explaining a "Secure Email" message from Delta Dental to their business partner (our customer) via <a href="https://toad.social/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a> because it was so flagrantly wrong: no DKIM, "From" *and envelope sender* forged to be the target, and the actual message isn't in the email, which is just a fancy link to a Proofpoint website. Like it's 1996 all over again... <a href="https://toad.social/tags/Email" class="mention hashtag" rel="nofollow noopener" target="_blank">#Email</a> <a href="https://toad.social/tags/InfoSec" class="mention hashtag" rel="nofollow noopener" target="_blank">#InfoSec</a>

Jonathan Kamens 86 47It turns out this isn't so simple. I can't say whether Gmail's servers accept insecure TLS ciphers, because it turns out the TLS connection failures weren't the only reason <a href="https://federate.social/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a> was failing to deliver email to my server. There was another reason, which was my fault. I started looking deeper into this when I discovered that <a href="https://federate.social/tags/IronPort" class="mention hashtag" rel="nofollow noopener" target="_blank">#IronPort</a> appliances were having the same problem as Proofpoint delivering email to me. I wrote up the whole debugging story here: <a href="https://blog.kamens.us/2024/11/21/yet-another-night-debugging-email-delivery-problems/" rel="nofollow noopener" translate="no" target="_blank">https://blog.kamens.us/2024/11/21/yet-another-night-debugging-email-delivery-problems/</a>

jikYet another night debugging email delivery problems I’ve run my own mail server for 30+ years. It’s a pain sometimes, but I’m a stubborn old cuss and I think it’s worth it both because I value my privacy and don’t want my emails being stored on somebody else’s servers, and because I’m a sysadmin at heart and I love a good sysadmin challenge, which running a mail server definitely is.Every once in a while the corporate email service providers come up with a new way to screw things up for small mail server operators like me. Most recently, both Proofpoint and Cisco IronPort SMTP servers started having trouble delivering emails to my server. Maybe you’ll find the explanation of why amusing, or at least maybe you’ll find the bits below about how to get sendmail to accept more TLS ciphers useful.The behavior I was seeing was that whenever someone using Proofpoint or IronPort for their outbound email delivery attempted to send me email, it would be delayed for many hours before finally being delivered. I started digging into my sendmail logs and saw messages like this every hour:<pre>Nov 17 00:33:33 jik4 sendmail[372431]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=esa12.hc6077-55.iphmx.com [139.138.46.199] Nov 17 00:33:33 jik4 sendmail[372431]: 4AH5XXPf372431: esa12.hc6077-55.iphmx.com [139.138.46.199] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA</pre>My mail server runs on CentOS Stream 9, which is pretty strict about which TLS ciphers its servers accept by default. Therefore, my first theory about what was causing the delivery issues was that Proofpoint’s and IronPort’s servers are running old SSL libraries that don’t support modern, secure ciphers.However, this raises an obvious question: if that’s true, then why were these messages eventually being delivered at all. Shouldn’t the servers just keep trying and failing to connect with their old TLS ciphers and then eventually give up? I.e., shouldn’t delivery just fail completely, rather than being delayed?I hand-waved away this question by observing that either of the following might be true:<ul><li>Some of their servers run more modern code, so eventually one of those servers attempts to deliver the message and it works.</li><li>They have a fallback built into their delivery pipeline, such that if a certain number of delivery attempts with TLS fail, they fall back on delivering without TLS.</li></ul>Neither of these is true, and I shouldn’t have hand-waved away this question, but I’ll get to that later since I’m telling the debugging story in chronological order.Since at this point my theory was that the problem was that Proofpoint and IronPort servers didn’t support modern SSL ciphers, I decided to try figuring out how to get my sendmail to accept a larger list of SSL ciphers. I have attempted to do this in the past and failed, but this time I decided to be more persistent.The first problem I had to solve was how to identify which TLS ciphers were supported by the running sendmail process, so I could easily test whether my attempts to make it accept more were working. I dig around a bit online and found the tool “sslscan” which works great for this purpose: “sslscan –starttls-smtp hostname:25″. Sslscan is conveniently available for installation from Debian’s repositories.First attempt at expanding the list of accepted ciphers: I captured the list of supported ciphers with sslscan, ran “<code>update-crypto-policies --set LEGACY</code>“, restarted sendmail, and tested again with sslscan. No change, unfortunately.Next, I said to myself, “Hmm, is there some way to explicitly tell sendmail in its configuration file to accept more ciphers.” After consulting /usr/share/sendmail-cf/README and the openssl-ciphers man page, I concluded that adding “<code>define(`confCIPHER_LIST', `ALL')dnl</code>” to the M4 source file for my sendmail.cf, then rebuilding and reinstalling it and restarting sendmail, might yield a bigger list of supported ciphers. And indeed, sslscan confirmed that this added 5 additional supported ciphers to the original list of 12.However, those ciphers looked mostly like the old ones, so I was pretty sure I had to go further. Next I tried using “<code>@SECLIST=1:ALL</code>” as the cipher list instead of just “<code>ALL</code>“. I suspected that this might make a difference because /etc/crypto-policies/back-ends/openssl.config starts with “<code>@SECLIST=2:</code>“. Alas, it didn’t help.I tried again with “<code>@SECLIST=0</code>” instead of “<code>@SECLIST=1</code>“, and the added an additional 14 ciphers. Some of these looked quite different, so maybe this would be enough to get Proofpoint and/or IronPort to be able to deliver email? I went back to one of the websites where I knew how to trigger an email message sent to me through Proofpoint, and tried it out. No luck, still “no shared cipher” in the log.At this point I needed another solution, so I asked myself whether I might have been wrong to hand-wave away the question of why the email messages were eventually being delivered successfully. Just allowing my brain that small amount of space to question my priors caused me to have a revelation. It suddenly occurred to me that there were other log messages related to Proofpoint and IronPort delivery fails that I had been dismissing as irrelevant which in fact where not irrelevant at all. They looked like this:<pre>Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: timeout waiting for input from esa12.hc6077-55.iphmx.com during server cmd read Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: lost input channel from esa12.hc6077-55.iphmx.com [139.138.46.199] to MTA after rcpt Nov 17 14:33:44 jik4 sendmail[614551]: 4AHJH3eD614551: collect: premature EOM: Connection timed out with mx0a-001e6701.pphosted.com Nov 17 19:15:28 jik4 sendmail[701129]: 4AI0ESSZ701129: timeout waiting for input from mx0a-001e6701.pphosted.com during server cmd read Nov 18 06:58:18 jik4 sendmail[908302]: 4AIBvHH3908302: lost input channel from mx0a-001e6701.pphosted.com [148.163.149.215] to MTA after mail</pre>When I first saw these messages, I just assumed they indicated that Proofpoint’s and IronPort’s servers were being stupid about something. That was a mistake. In fact, it was my server that was being stupid.I use fail2ban configured on my server, and I have it configured to aggressively block suspicious SMTP connections. It blocks a server for an hour after a single suspicious log message from that server, and the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages shown above, that are generated after Proofpoint or IronPort attempts and fails to initiate TLS and then disconnects, count as suspicious.So while the fact that Proofpoint and IronPort don’t support modern TLS ciphers was the root cause of the issue, my server was exacerbating the problem by banning their IP address immediately after they tried to do TLS, so that they were then unable to reconnect and deliver the message without TLS.The reason why the messages from these servers were eventually being delivered is that there’s sometimes a 1–2 second delay between when a suspicious log message appears and when fail2ban bans the associated server IP, and after trying over and over eventually the Proofpoint or IronPort managed to sneak in a successful message delivery during that short delay.The solution, therefore, is to make fail2ban less aggressive about banning suspicious SMTP servers. However, if I do that, then my server is much more vulnerable to brute-force SMTP authentication attacks? What to do, what to do?Maybe there’s another suspicious log message I can match against in the logs instead of the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages which are caused innocuously when a TLS connection fails? With just a little bit of digging I found these:<pre>Nov 21 23:07:50 jik4 sendmail[58510]: 4AM47hXh058510: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=postmaster, relay=[109.172.142.229]</pre>Wait a minute, why the heck isn’t fail2ban banning based on this message which is obviously, unambiguously a brute-force login attempt?Well, you see, it turns out that I originally configured fail2ban to ban based on the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages way back in 2007 (like I said, I’ve been running my own mail server for a long time), and back in 2007, the “AUTH failure” log messages did note have the “relay=” at the end of them. That wasn’t added until release sendmail 8.14.4, which was released in December 2009 (I figured out which release this was added in by doing a binary search through all of the old sendmail source archives on ftp.sendmail.org).Putting this all together:<ul><li>One root cause of the incoming email delivery issues is Proofpoint and IronPort being stupid about which TLS ciphers they support.</li><li>A second root cause is my fail2ban configuration being too aggressive about banning suspicious SMTP servers, resulting in servers being banned for engaging in innocuous activities.</li><li> Configuring sendmail to accept more TLS ciphers is the wrong solution.</li><li>The right solution, which I’ve implemented, is to make fail2ban more selective about which log messages it considers suspicious, so it won’t ban the Proofpoint and IronPort servers for failing to initiate a TLS connection.</li></ul>See, now, this is actually one of the reasons I love running my own mail server: there is immense satisfaction in getting to the bottom of one of these problems and successfully solving it. <a class="" href="https://www.addtoany.com/add_to/mastodon?linkurl=https%3A%2F%2Fblog.kamens.us%2F2024%2F11%2F21%2Fyet-another-night-debugging-email-delivery-problems%2F&linkname=Yet%20another%20night%20debugging%20email%20delivery%20problems" rel="nofollow noopener" target="_blank"></a><a class="" href="https://www.addtoany.com/share" rel="nofollow noopener" target="_blank"></a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/fail2ban/" target="_blank">#fail2ban</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/ironport/" target="_blank">#IronPort</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/openssl/" target="_blank">#OpenSSL</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/proofpoint/" target="_blank">#Proofpoint</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/sendmail/" target="_blank">#sendmail</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/smtp/" target="_blank">#SMTP</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/sslscan/" target="_blank">#sslscan</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://blog.kamens.us/tag/tls/" target="_blank">#TLS</a>

Jonathan Kamens 86 47<a href="https://federate.social/tags/ProofPoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#ProofPoint</a> has no trouble sending emails to <a href="https://federate.social/tags/gmail" class="mention hashtag" rel="nofollow noopener" target="_blank">#gmail</a>, implying that gmail's servers support <a href="https://federate.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a> versions or ciphers that are no longer considered sufficiently secure. <a href="https://federate.social/tags/smdh" class="mention hashtag" rel="nofollow noopener" target="_blank">#smdh</a>

Jonathan Kamens 86 47It looks like PNC Paid is using <a href="https://federate.social/tags/ProofPoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#ProofPoint</a> servers for its outbound email delivery. I know from personal experience that ProofPoint absolutely sucks at email delivery, so perhaps that's part of the problem.Note that ProofPoint, A SECURE EMAIL COMPANY, runs mail servers that are incapable of negotiating non-deprecated TLS ciphers:STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=mx0a-000ade01.pphosted.com [205.220.165.107]<a href="https://federate.social/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#infosec</a>

J. Trent AdamsI can't help but feel that Proofpoint missed out when enumerating only 5 products in it's Nexus line of cybersecurity defenses... though... perhaps they're still working on Nexus VI. <a href="https://www.proofpoint.com/us/blog/email-and-cloud-threats/introducing-proofpoint-nexus-human-centric-security" rel="nofollow noopener" translate="no" target="_blank">https://www.proofpoint.com/us/blog/email-and-cloud-threats/introducing-proofpoint-nexus-human-centric-security</a><a href="https://infosec.exchange/tags/proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#proofpoint</a> <a href="https://infosec.exchange/tags/nexus" class="mention hashtag" rel="nofollow noopener" target="_blank">#nexus</a> <a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#cybersecurity</a> <a href="https://infosec.exchange/tags/bladerunner" class="mention hashtag" rel="nofollow noopener" target="_blank">#bladerunner</a>

Marcel SIneM(S)US<a href="https://social.tchncs.de/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a>: Betrüger verschicken Millionen <a href="https://social.tchncs.de/tags/Spam" class="mention hashtag" rel="nofollow noopener" target="_blank">#Spam</a>-Mails im Namen von Disney & Co. | Security <a href="https://www.heise.de/news/Proofpoint-Betrueger-verschicken-Millionen-Spam-Mails-im-Namen-von-Disney-Co-9818191.html" rel="nofollow noopener" translate="no" target="_blank">https://www.heise.de/news/Proofpoint-Betrueger-verschicken-Millionen-Spam-Mails-im-Namen-von-Disney-Co-9818191.html</a> <a href="https://social.tchncs.de/tags/Phishing" class="mention hashtag" rel="nofollow noopener" target="_blank">#Phishing</a> <a href="https://social.tchncs.de/tags/Spoofing" class="mention hashtag" rel="nofollow noopener" target="_blank">#Spoofing</a> <a href="https://social.tchncs.de/tags/DKIM" class="mention hashtag" rel="nofollow noopener" target="_blank">#DKIM</a> <a href="https://social.tchncs.de/tags/SPF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SPF</a> <a href="https://social.tchncs.de/tags/SenderPolicyFramework" class="mention hashtag" rel="nofollow noopener" target="_blank">#SenderPolicyFramework</a> <a href="https://social.tchncs.de/tags/DomainKeysIdentifiedMail" class="mention hashtag" rel="nofollow noopener" target="_blank">#DomainKeysIdentifiedMail</a>

postmodernProofPoint, a company that claims to prevent phishing, had their service exploited for months to send phishing emails! <a href="https://www.bleepingcomputer.com/news/security/proofpoint-settings-exploited-to-send-millions-of-phishing-emails-daily/" rel="nofollow noopener" translate="no" target="_blank">https://www.bleepingcomputer.com/news/security/proofpoint-settings-exploited-to-send-millions-of-phishing-emails-daily/</a><a href="https://infosec.exchange/tags/infosecisgoingjustgreat" class="mention hashtag" rel="nofollow noopener" target="_blank">#infosecisgoingjustgreat</a> <a href="https://infosec.exchange/tags/phishing" class="mention hashtag" rel="nofollow noopener" target="_blank">#phishing</a> <a href="https://infosec.exchange/tags/echophishing" class="mention hashtag" rel="nofollow noopener" target="_blank">#echophishing</a> <a href="https://infosec.exchange/tags/proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#proofpoint</a>

Jonathan Kamens 86 47For the record, I did finally receive the two missing email notifications. The one stamped 12:20pm was actually delivered to my mail server at 12:24am, 12 hour late. The one stamped 12:29pm was delivered at 10:51pm, 10 hours late and out of order. <a href="https://federate.social/tags/ProofPoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#ProofPoint</a> <a href="https://federate.social/tags/fail" class="mention hashtag" rel="nofollow noopener" target="_blank">#fail</a>

Jonathan Kamens 86 47Incidentally, it appears that the bank, or more accurately, <a href="https://federate.social/tags/ProofPoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#ProofPoint</a>, _tried_ to send the notifications but failed. I got two logs like this 16 minutes after the successful notifications:Jun 10 12:36:29 jik4 sendmail[2332181]: 45AGKC922332181: SYSERR(root): collect: I/O error on connection from mx0b-00100303.pphosted.com, from=<ng.prd.bounces@eas.easternbank.com>So the company that <a href="https://federate.social/tags/EasternBank" class="mention hashtag" rel="nofollow noopener" target="_blank">#EasternBank</a> is using specifically to provide reliable email delivery is fucking it up. <a href="https://federate.social/tags/email" class="mention hashtag" rel="nofollow noopener" target="_blank">#email</a> <a href="https://federate.social/tags/fail" class="mention hashtag" rel="nofollow noopener" target="_blank">#fail</a>

AAKL"Spammers will probably bid to buy it, so community is trying to find a better home for decades-old service." <a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#cybersecurity</a> <a href="https://infosec.exchange/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#infosec</a> <a href="https://infosec.exchange/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a> Shuts Down Spam and Open Relay Blocking System SORBS <a href="https://www.theregister.com/2024/06/07/sorbs_closed/" rel="nofollow noopener" translate="no" target="_blank">https://www.theregister.com/2024/06/07/sorbs_closed/</a> <a href="https://geeknews.chat/@theregister" class="u-url mention" rel="nofollow noopener" target="_blank">@theregister</a> <a href="https://theblower.au/@ssharwood" class="u-url mention" rel="nofollow noopener" target="_blank">@ssharwood</a>

FKA ZOGAnyone know have hints on how to get an email server de-listed from the Cloudmark so called "blacklist"?The system is NOT sending spam.Repeated requests using the web form they provide for this has not worked.It is a legit SMTP server with reverse DNS and SPF records, etc.<a href="https://jauntygoat.net/tags/cloudmark" class="mention hashtag" rel="nofollow noopener" target="_blank">#cloudmark</a> <a href="https://jauntygoat.net/tags/proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#proofpoint</a>

Pyrzout :vm:Human error still perceived as the Achilles’ heel of cybersecurity <a href="https://www.helpnetsecurity.com/2024/05/27/cisos-cyber-attacks-defense-confidence/" rel="nofollow noopener" translate="no" target="_blank">https://www.helpnetsecurity.com/2024/05/27/cisos-cyber-attacks-defense-confidence/</a> <a href="https://social.skynetcloud.site/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#cybersecurity</a> <a href="https://social.skynetcloud.site/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a> <a href="https://social.skynetcloud.site/tags/report" class="mention hashtag" rel="nofollow noopener" target="_blank">#report</a> <a href="https://social.skynetcloud.site/tags/survey" class="mention hashtag" rel="nofollow noopener" target="_blank">#survey</a> <a href="https://social.skynetcloud.site/tags/News" class="mention hashtag" rel="nofollow noopener" target="_blank">#News</a> <a href="https://social.skynetcloud.site/tags/CISO" class="mention hashtag" rel="nofollow noopener" target="_blank">#CISO</a>

Pyrzout :vm:Human Error and AI Emerge as Key Challenges in Survey of CISOs – Source: securityboulevard.com <a href="https://ciso2ciso.com/human-error-and-ai-emerge-as-key-challenges-in-survey-of-cisos-source-securityboulevard-com/" rel="nofollow noopener" translate="no" target="_blank">https://ciso2ciso.com/human-error-and-ai-emerge-as-key-challenges-in-survey-of-cisos-source-securityboulevard-com/</a> <a href="https://social.skynetcloud.site/tags/rssfeedpostgeneratorecho" class="mention hashtag" rel="nofollow noopener" target="_blank">#rssfeedpostgeneratorecho</a> <a href="https://social.skynetcloud.site/tags/SecurityBloggersNetwork" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityBloggersNetwork</a> <a href="https://social.skynetcloud.site/tags/CyberSecurityNews" class="mention hashtag" rel="nofollow noopener" target="_blank">#CyberSecurityNews</a> <a href="https://social.skynetcloud.site/tags/SecurityAwareness" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityAwareness</a> <a href="https://social.skynetcloud.site/tags/SecurityBoulevard" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityBoulevard</a> <a href="https://social.skynetcloud.site/tags/Dataprotection" class="mention hashtag" rel="nofollow noopener" target="_blank">#Dataprotection</a> <a href="https://social.skynetcloud.site/tags/datasecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#datasecurity</a> <a href="https://social.skynetcloud.site/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a> <a href="https://social.skynetcloud.site/tags/ransomware" class="mention hashtag" rel="nofollow noopener" target="_blank">#ransomware</a> <a href="https://social.skynetcloud.site/tags/Phishing" class="mention hashtag" rel="nofollow noopener" target="_blank">#Phishing</a> <a href="https://social.skynetcloud.site/tags/Careers" class="mention hashtag" rel="nofollow noopener" target="_blank">#Careers</a> <a href="https://social.skynetcloud.site/tags/Blog" class="mention hashtag" rel="nofollow noopener" target="_blank">#Blog</a> <a href="https://social.skynetcloud.site/tags/spam" class="mention hashtag" rel="nofollow noopener" target="_blank">#spam</a> <a href="https://social.skynetcloud.site/tags/BEC" class="mention hashtag" rel="nofollow noopener" target="_blank">#BEC</a>

Erik van Straten2FA (MFA) beschermt *niet* tegen steeds meer phishingaanvallen:<<<Tycoon 2FA operates as an adversary-in-the-middle (AitM) phishing kit. Its primary function is to harvest Microsoft 365 and Gmail session cookies. >>> <a href="https://www.proofpoint.com/us/blog/email-and-cloud-threats/tycoon-2fa-phishing-kit-mfa-bypass" rel="nofollow noopener" translate="no" target="_blank">https://www.proofpoint.com/us/blog/email-and-cloud-threats/tycoon-2fa-phishing-kit-mfa-bypass</a>U kunt zichzelf hier prima tegen beschermen, zonder passkeys of software van bijvoorbeeld Proofpoint te gebruiken: zie <a href="https://security.nl/posting/841126" rel="nofollow noopener" translate="no" target="_blank">https://security.nl/posting/841126</a><a href="https://infosec.exchange/tags/2FA" class="mention hashtag" rel="nofollow noopener" target="_blank">#2FA</a> <a href="https://infosec.exchange/tags/MFA" class="mention hashtag" rel="nofollow noopener" target="_blank">#MFA</a> <a href="https://infosec.exchange/tags/AitM" class="mention hashtag" rel="nofollow noopener" target="_blank">#AitM</a> <a href="https://infosec.exchange/tags/AitM" class="mention hashtag" rel="nofollow noopener" target="_blank">#AitM</a> <a href="https://infosec.exchange/tags/Passkeys" class="mention hashtag" rel="nofollow noopener" target="_blank">#Passkeys</a> <a href="https://infosec.exchange/tags/PasswordManager" class="mention hashtag" rel="nofollow noopener" target="_blank">#PasswordManager</a> <a href="https://infosec.exchange/tags/Passwords" class="mention hashtag" rel="nofollow noopener" target="_blank">#Passwords</a> <a href="https://infosec.exchange/tags/Phishing" class="mention hashtag" rel="nofollow noopener" target="_blank">#Phishing</a> <a href="https://infosec.exchange/tags/PhaaS" class="mention hashtag" rel="nofollow noopener" target="_blank">#PhaaS</a> <a href="https://infosec.exchange/tags/EvilProxy" class="mention hashtag" rel="nofollow noopener" target="_blank">#EvilProxy</a> <a href="https://infosec.exchange/tags/EvilGinx" class="mention hashtag" rel="nofollow noopener" target="_blank">#EvilGinx</a> <a href="https://infosec.exchange/tags/EvilGinx2" class="mention hashtag" rel="nofollow noopener" target="_blank">#EvilGinx2</a> <a href="https://infosec.exchange/tags/Tycoon" class="mention hashtag" rel="nofollow noopener" target="_blank">#Tycoon</a> <a href="https://infosec.exchange/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a>

Botconf<a href="https://infosec.exchange/tags/Botconf2024" class="mention hashtag" rel="nofollow noopener" target="_blank">#Botconf2024</a> has started this morning and we are already deep into the first talks. The full schedule is available at <a href="https://www.botconf.eu/schedule/" rel="nofollow noopener" translate="no" target="_blank">https://www.botconf.eu/schedule/</a>We will announce the talks we broadcast on our social networks and they will be available from <a href="https://www.youtube.com/BotconfTV" rel="nofollow noopener" translate="no" target="_blank">https://www.youtube.com/BotconfTV</a>This conference would not be possible without the speakers of course, but also thanks to our great sponsors ! This year <a href="https://infosec.exchange/tags/Proofpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proofpoint</a> and <a href="https://infosec.exchange/tags/Qintel" class="mention hashtag" rel="nofollow noopener" target="_blank">#Qintel</a> are supporting <a href="https://infosec.exchange/tags/Botconf2024" class="mention hashtag" rel="nofollow noopener" target="_blank">#Botconf2024</a> as Diamond sponsors. Thank you so much !

Ted Pavlic (he/him)Figured out why ASU's <a href="https://mas.to/tags/GMail" class="mention hashtag" rel="nofollow noopener" target="_blank">#GMail</a> half has been sending so many messages to spam, particularly messages from ASU's Outlook half, after Google stepped up DKIM enforcement earlier this month. <a href="https://mas.to/tags/ProofPoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#ProofPoint</a> is messing everything up. I'm guessing a lot of <a href="https://mas.to/tags/Enterprise" class="mention hashtag" rel="nofollow noopener" target="_blank">#Enterprise</a> folks are going through similar headaches because of ProofPoint!

Recent searches

Search options

Administered by:

Server stats:

#proofpoint