founder, phisherman & QR guy @epiapp @episecurity • defeats phishing, bad QRs and cyber threats as a public service • check a link ↙ pro acc @greenlandphish
London
Joined July 2009
- Tweets36.4K
- Following6.5K
- Followers2K
- Likes79.1K
Pinned Tweet
An Epi Special Investigation on the scam political ads plaguing X users in the UK. Over four days, we detected 425 unique malicious ads, generating over 2.3 million impressions.
From 1 to 4 July, I observed 425 distinct malicious ads that exploited the studio brand of the BBC Radio 4 Today programme and the likeness of Emily Maitlis.
1 July: 82 ads with 816,950 views
2 July: 95 ads with 433,808 views
3 July: 169 ads with 781,802 views
4 July: 79 ads with 319,412 views
Total 1–4 July: 2,351,972 views (avg: 5,534 views/ad)
Some individual ads reported over 70,000 impressions.
The vast majority of the 425 ads matched one-to-one with individual X accounts; ie. around 400 separate X accounts were used for 425 ads.
Interestingly, a large proportion of the accounts were created between 2009 and 2014, with a peak in 2011, and many of their initial tweets posted are scams and malicious links. This tells me that these Twitter accounts have not been recently created or hijacked, but are persistent scam accounts controlled and traded by organised criminals over long periods — decades, in fact.
Ads were published by X accounts originating from 89 countries, most of which X indicates are using VPNs, which obscure their true geographic location.
The ad origins include exotic and unusual countries such as: Afghanistan, Belarus, Mongolia, Palestine, Pakistan, Russia, Somalia, South Sudan, Ukraine, Uzbekistan and Venezuela.
Some important questions that need answers: Why is X allowing ads from a such an exotic variety of countries to reach British users with UK political inspired ads? Why does X let ads be published from accounts hiding behind VPNs, particularly when they acknowledge their use? What are the banks and jurisdictions of the credit cards used to pay for the ads? Why is X permitting ads from regions in active conflict zones, and most concerningly, from countries under comprehensive and targeted US and UK sanctions — including: Afghanistan, Belarus, Russia, Somalia, South Sudan and Venezuela.
Since this investigation, I have observed malicious ads exploiting the likeness of Nick Robinson on the Today programme.
Funnily enough, I will be on the Today programme on BBC Radio 4 on Wednesday morning at 06:50 to discuss my findings. I hope you join me as one of six million listening! On your radio, on BBC Sounds, or on catchup.
UK: Wed 6:50am
US Eastern: Wed 1:50am
US Pacific: Tue 10:50pm
Sydney: Wed 3:50pm
@epiapp @episecurity
Get ready for the scam ads on X, everyone!
Yes, even if you're Premium+ (£31/mo, $40/mo).
Ads are coming to X, which means scam ads are coming.
An Epi Special Investigation on the scam political ads plaguing X users in the UK. Over four days, we detected 425 unique malicious ads, generating over 2.3 million impressions.
From 1 to 4 July, I observed 425 distinct malicious ads that exploited the studio brand of the BBC Radio 4 Today programme and the likeness of Emily Maitlis.
1 July: 82 ads with 816,950 views
2 July: 95 ads with 433,808 views
3 July: 169 ads with 781,802 views
4 July: 79 ads with 319,412 views
Total 1–4 July: 2,351,972 views (avg: 5,534 views/ad)
Some individual ads reported over 70,000 impressions.
The vast majority of the 425 ads matched one-to-one with individual X accounts; ie. around 400 separate X accounts were used for 425 ads.
Interestingly, a large proportion of the accounts were created between 2009 and 2014, with a peak in 2011, and many of their initial tweets posted are scams and malicious links. This tells me that these Twitter accounts have not been recently created or hijacked, but are persistent scam accounts controlled and traded by organised criminals over long periods — decades, in fact.
Ads were published by X accounts originating from 89 countries, most of which X indicates are using VPNs, which obscure their true geographic location.
The ad origins include exotic and unusual countries such as: Afghanistan, Belarus, Mongolia, Palestine, Pakistan, Russia, Somalia, South Sudan, Ukraine, Uzbekistan and Venezuela.
Some important questions that need answers: Why is X allowing ads from a such an exotic variety of countries to reach British users with UK political inspired ads? Why does X let ads be published from accounts hiding behind VPNs, particularly when they acknowledge their use? What are the banks and jurisdictions of the credit cards used to pay for the ads? Why is X permitting ads from regions in active conflict zones, and most concerningly, from countries under comprehensive and targeted US and UK sanctions — including: Afghanistan, Belarus, Russia, Somalia, South Sudan and Venezuela.
Since this investigation, I have observed malicious ads exploiting the likeness of Nick Robinson on the Today programme.
Funnily enough, I will be on the Today programme on BBC Radio 4 on Wednesday morning at 06:50 to discuss my findings. I hope you join me as one of six million listening! On your radio, on BBC Sounds, or on catchup.
UK: Wed 6:50am
US Eastern: Wed 1:50am
US Pacific: Tue 10:50pm
Sydney: Wed 3:50pm
@epiapp @episecurity
I've reached out many times to work with X, and offered our scam checking API to block the scam ads. I haven't had meaningful engagement so far.
I'm detecting numerous scam ads on X every day on non-premium X accounts. You have probably seen my many reports on the deepfake celebrity crypto scam ads.
With ads soon appearing in tweet replies and the Explore (search) tab, no matter your X subscription, we will all start to see malicious and fraudulent ads.
X, I'm ready to help, as always.
And to the public: our scam and phishing URL checker is a public service and public good — you can check links and sites for free with Epi, before you log in, enter credentials or transfer money.
I work in service of the public, and all I want to do is stop people being phished and scammed.
PHP: PM's Home Page
皆様に、今夜に対応して頂きたい大至急のお願いです。
多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。
公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。
修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。
国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。
国家サイバー統括室(注意・警戒情報)（@cyber_forecast） / X
This is not a dunk, but please stop using PHP, when you can.
The language wasn't designed in the era of a secure internet.
RCEs are more likely when you have a language that mixes client and server in one file, with string templating hazards and inherent escaping issues.
Don't forget about your piholes! Especially if they're internet-facing (terrible idea), even if accessed via a VPN.
Pi-hole software pre-v6 uses PHP. v6, introduced in Feb 2025, uses Lua.
My wider view on the intersection of security and AI
Good piece on PHP2Shell and the role of AI. Not sure how I feel about the idea of patching systems remotely, even in extreme cases. How about for critical cases, the site is taken offline at the host, until patched and remediated?
Also, I don't think it's entirely helpful to suggest the absolute equivalence between AI model power and effective security (and threat posture). The idea that good security depends on and solely relies upon strong AI models.
This vulnerability was found by AI agents operating in the background, driven by dedicated external security analysts.
Developers and teams can run AI security agents in background, as an additional activity, but agents should not be driving all your active and realtime development work. An AI agent works for you, serves you, and does what you ask when you request a new feature or fix. You need holistic security, not merely task completion and task-focused security. You should be driving, and good security people should be the copilots too.
More agents and more tokens may mean you can potentially discover more vulnerabilities, but throwing more tokens and models at a project is not always the answer. Hallucinations, confirmation bias and model mistakes can be grave and costly for threat exposure, and provide you with a false sense of security.
If you're not looking at the code, not reviewing changes, not in control of your architecture — you may fail to spot vulnerabilities you and your team would have otherwise seen.
How do you find your unknown-unknowns without inspecting the codebase, analysing your supply chain and regular reviews with your team?
If you leave the work of security predominately down to AI agents, how do you know you have found sufficient unknown-unknowns, with high confidence?
Secure coding practices, defence-in-depth principles, security-conscious developers and expert human analysts are invaluable — timelessly so.
Token wealth does not necessarily equal real security.
Token poverty does not equal zero security.
High wealth and big spending on security does not necessarily equal high security.
AI is a tool to assist you, not someone to transfer work to. You should still be driving, doing most of the work, and making the decisions.
You can have good security without AI.
You can have good security with AI, but not from AI. AI only works for security if you and your teams are good at security to begin with. AI works if you are aware and have deep knowledge of threat vectors, attack techniques, vulnerabilities, hardening measures, sandboxes, firewalls, authentication and authorisation. You need to review every change and commit. There's real, tangible and immeasurable value in humans doing this.
With agentic development, you need to ask the right questions. This comes from a place of knowledge and experience. You not only need to be able to answer the questions yourself (sense checking and reading sources), but crucially, you need to also question the answers you get back.
Don't delegate security and its responsibility too far from yourself. It is an abdication and dereliction of duty. You — and your CISO, CEO, managers and developers — have a key responsibility to keep your applications and customer data safe.
Before and within the AI age, good CISOs and CEOs are across the details of internal operations and technical decisions, maintaining oversight and control, even when they entrust agile teams to manage operations, self-organise and make autonomous decisions.
Devolve more; delegate less.
Good piece on PHP2Shell and the role of AI. Not sure how I feel about the idea of patching systems remotely, even in extreme cases. How about for critical cases, the site is taken offline at the host, until patched and remediated?
Also, I don't think it's entirely helpful to suggest the absolute equivalence between AI model power and effective security (and threat posture). The idea that good security depends on and solely relies upon strong AI models.
This vulnerability was found by AI agents operating in the background, driven by dedicated external security analysts.
Developers and teams can run AI security agents in background, as an additional activity, but agents should not be driving all your active and realtime development work. An AI agent works for you, serves you, and does what you ask when you request a new feature or fix. You need holistic security, not merely task completion and task-focused security. You should be driving, and good security people should be the copilots too.
More agents and more tokens may mean you can potentially discover more vulnerabilities, but throwing more tokens and models at a project is not always the answer. Hallucinations, confirmation bias and model mistakes can be grave and costly for threat exposure, and provide you with a false sense of security.
If you're not looking at the code, not reviewing changes, not in control of your architecture — you may fail to spot vulnerabilities you and your team would have otherwise seen.
How do you find your unknown-unknowns without inspecting the codebase, analysing your supply chain and regular reviews with your team?
If you leave the work of security predominately down to AI agents, how do you know you have found sufficient unknown-unknowns, with high confidence?
Secure coding practices, defence-in-depth principles, security-conscious developers and expert human analysts are invaluable — timelessly so.
Token wealth does not necessarily equal real security.
Token poverty does not equal zero security.
High wealth and big spending on security does not necessarily equal high security.
AI is a tool to assist you, not someone to transfer work to. You should still be driving, doing most of the work, and making the decisions.
You can have good security without AI.
You can have good security with AI, but not from AI. AI only works for security if you and your teams are good at security to begin with. AI works if you are aware and have deep knowledge of threat vectors, attack techniques, vulnerabilities, hardening measures, sandboxes, firewalls, authentication and authorisation. You need to review every change and commit. There's real, tangible and immeasurable value in humans doing this.
With agentic development, you need to ask the right questions. This comes from a place of knowledge and experience. You not only need to be able to answer the questions yourself (sense checking and reading sources), but crucially, you need to also question the answers you get back.
Don't delegate security and its responsibility too far from yourself. It is an abdication and dereliction of duty. You — and your CISO, CEO, managers and developers — have a key responsibility to keep your applications and customer data safe.
Before and within the AI age, good CISOs and CEOs are across the details of internal operations and technical decisions, maintaining oversight and control, even when they entrust agile teams to manage operations, self-organise and make autonomous decisions.
Devolve more; delegate less.
To those implying this is an unfair or targeted attack on PHP, or that I am somehow biased or tainted because I use Node, JS and React, this is my response:
I'm advocating for a better runtime and strategies for security. There are inherently more secure runtimes and techniques out there. Isolation limits the class of attacks and blast radius.
Of course, all runtimes will have security vulnerabilities discovered. It's about designing and implementing with best practices. And about how fast you release and apply patches.
If we're talking about Node.js, the vulnerabilities patched in Node's security patches today are not related to core webserver capabilities. It's mostly patching as a response to the eMudhra intermediate CA compromise (very weak private key content). There is one upstream fix applied for an RCE attack affecting Brotli, Google's encoding algorithm, which could be used in your server pipeline. But this is not a critical security bug or core webserver logic.
This is not about PHP v Node. It's not tribal or ideological.
I've used a lot of languages, frameworks and runtimes in my years! I can see the good parts and the bad parts.
PHP is not singled out.
React SPAs and Vite SPAs are inherently more secure than RSC, React server rendering, Next.js, PHP, Laravel, ASP•NET, Spring Boot, Rails, Django, Flask, Nuxt.js, WordPress…
I have used many of these in anger while building secure web apps for decades. I'm an obsessive on security. Discovered what works and what is insufficient.
If there is an opportunity to mix client code and server code, the framework/runtime is bad.
With PHP, very often it is all the things combined: a language, framework, runtime and webserver.
I greatly value isolation and separations of concerns.
I also don't think an API server should be written in PHP or Laravel. It shouldn't be a PHP framework or PHP webserver. Too many opportunities to shoot yourself in the foot.
In the same way that I don't think an API server should be written in Next.js, ASP•NET, Rails, Django, Spring Boot, Java, Nuxt.js.
React SPAs and Vite SPAs are inherently more secure than RSC, React server rendering, Next.js, PHP, Laravel, ASP•NET, Spring Boot, Rails, Django, Flask, Nuxt.js, WordPress…
I have used many of these in anger while building secure web apps for decades. I'm an obsessive on security. Discovered what works and what is insufficient.
If there is an opportunity to mix client code and server code, the framework/runtime is bad.
With PHP, very often it is all the things combined: a language, framework, runtime and webserver.
I greatly value isolation and separations of concerns.
I also don't think an API server should be written in PHP or Laravel. It shouldn't be a PHP framework or PHP webserver. Too many opportunities to shoot yourself in the foot.
In the same way that I don't think an API server should be written in Next.js, ASP•NET, Rails, Django, Spring Boot, Java, Nuxt.js.
React SPAs and API servers are more secure as a matter of principle, compared with realtime server rendering intermingled with user content, with HTML splicing, escaping, sanitisation and templating.
There is practically zero risk of XSS and client-side injection attacks with a React SPA.
React makes it difficult to unintentionally screw up. You have to ignore warnings and actively use APIs like dangerouslySetInnerHTML.
I also think RSC and React server rendering are poor in their current form. The React wire protocol needs work.
This is not a targeted attack on PHP, nor is it fandom of React and JS.
We shouldn't be intermingling the client and server. The client cannot be trusted.
SPAs and API servers are just more secure by design.
API microservices are simpler and more secure. The request-response lifecycle is clean and the client-server demarcation is prominent. A request comes in, you validate auth, and respond with JSON or data. No HTML, no string munging. This architecture hardens the server side and client side from entire classes of cyberattacks.