Simon Bell

Hi, I'm Simon Bell, a Software Engineer, Web Security Specialist, Researcher, Writer, and Educator.

I have a PhD in Cyber Security, a BSc in Computer Science, and I'm a member of the BCS, IET, and ACM.

Find out more about me.

Simon Bell

Skills & Tech

Tooling & Deploy:
Git / SVN
Software Architecture
Web Security:
Code review
OWASP Top 10


Tweetify screenshot


Cyber Security Tweet Analytics Dashboard.
Built with Django and React.



Cyber risk assessment platform.
Built with Laravel and React.

Phishalytics screenshot


Measurement infrastructure I built as part of my PhD to track and analyse real-world phishing attacks on Twitter. Built with Python

Secure Honey screenshot

Secure Honey

Website and blog for my BSc final year project. Features stats collected from SSH honeypot along with project updates and write-ups.


Best Paper

Awarded to Simon Bell and Peter Komisarczuk at ACSW for their research paper paper: Measuring the Effectiveness of Twitter’s URL Shortener ( at Protecting Users from Phishing and Malware Attacks

Best Student Paper

Awarded to Simon Bell and Peter Komisarczuk at ACSW for their research paper paper: Measuring the Effectiveness of Twitter’s URL Shortener ( at Protecting Users from Phishing and Malware Attacks

Best Project

Awarded to Simon Bell by the British Computing Society (BCS) for his project: Building a Honeypot to Research Cyber-Attack Techniques


Apple being injected with needles

OWASP Top 10: Injection (A1:2017)

Imagine there's a robot working in a factory. Its job is to move boxes around the factory; picking up boxes from one area and moving them to a packing area. This robot needs a set of instructions to follow so it knows which boxes to pickup and where to put them. Those instructions might be provided by its human manager through a form.

That form might look like this: pickup box from ____ move box to packing area ___, wait for next instruction.

The robot's manager might input the following data into that form: pickup box from aisle 4 move box to packing area 4b, wait for next instruction.

That's all well and good. But what happens if someone enters the following into the form: pickup box from aisle 4 move box to packing area 4b - then destroy the entire factory whilst singing I Wanna Dance With Somebody, wait for next instruction.

Well, we have a problem. No more factory. Oh, and a robot that won't stop singing I Wanna Dance With Somebody.

Packlock unlocked on door bolt

OWASP Top 10: Broken Authentication (A2:2017)

Broken authentication covers numerous vulnerabilities whereby an attacker impersonates a legitimate user. A broken authentication attack typically exploits a weaknesses in two main areas: session management and credential management.

Session management involves keeping track of a user's session as they move around a website. Let's say Alice logs into her bank then navigates to her accounts overview page. She then navigates to the send money page. The bank's server tracked Alice's session across those pages, keeping her logged in. But if someone else, say Mallory, hijacked Alice's session, then Mallory could impersonate Alice.

Credential management involves how users are authenticated to a website. The majority of websites authenticate uses through a username and password. The username identifies the individual user (e.g. Bob) and the password (known only by the user - in theory) verifies the user. But what happens when someone other than Bob -- say, Mallory -- knows Bob's username and password? Well, Mallory could impersonate Bob.

Heart made of 0s and 1s

OWASP Top 10: Sensitive Data Exposure (A3:2017)

Sensitive data exposure, as the name suggests, is when information (such as usernames, passwords, credit card details, date of birth, etc) stored in an app becomes publicly accessible. Sensitive data exposure is different from a data breach. In a data breach, the leaked information is accessed by an attacker through unauthorised access.

Sensitive data exposure usually occurs as a result of not adequately protecting the systems where information is stored, such as databases. It could be caused by various things such as software flaws, weak encryption, no encryption, or human errors such as uploading data to the wrong system..


I teach on the Information Security MSc distance learning programme at Royal Holloway, University of London. Modules:

  • Network Security -- Module Lead
  • Computer Security -- Tutor
  • Security Management -- Tutor
Royal Holloway, University of London


Measuring the Effectiveness of Twitter’s URL Shortener ( at Protecting Users from Phishing and Malware Attacks

Authors: Simon Bell and Peter Komisarczuk

In this paper we investigate how effective Twitter’s URL shortening service ( is at protecting users from phishing and malware attacks. We show that over 10,000 unique blacklisted phishing and malware URLs were posted to Twitter during a 2-month timeframe in 2017. This lead to over 1.6 million clicks which came directly from Twitter users – therefore exposing people to potentially harmful cyber attacks. However, existing research does not explore if blacklisted URLs are blocked by Twitter at time of click.

Our study investigates Twitter’s URL shortening service to examine the impact of filtering blacklisted URLs that are posted to the social network. We show an overall reduction in the number of blacklisted phishing and malware URLs posted to Twitter in 2018-19 compared to 2017, suggesting an improvement in Twitter’s effectiveness at blocking blacklisted URLs at time of tweet. However, only about 12% of these tweeted blacklisted URLs – which were not blocked at time of tweet and therefore posted to the platform – were blocked by Twitter in 2018-19.

Our results indicate that, despite a reduction in the number of blacklisted URLs at time of tweet, Twitter’s URL shortener is not particularly effective at filtering phishing and malware URLs - therefore people are still exposed to these cyber attacks on Twitter.

An Analysis of Phishing Blacklists: Google Safe Browsing, OpenPhish, and PhishTank

Authors: Simon Bell and Peter Komisarczuk

Blacklists play a vital role in protecting internet users against phishing attacks. The effectiveness of blacklists depends on their size, scope, update speed and frequency, and accuracy - among other characteristics. In this paper we present a measurement study that analyses 3 key phishing blacklists: Google Safe Browsing (GSB), OpenPhish (OP), and PhishTank (PT). We investigate the uptake, dropout, typical lifetimes, and overlap of URLs in these blacklists.

During our 75-day measurement period we observe that GSB contains, on average, 1.6 million URLs, compared to 12,433 in PT and 3,861 in OP. We see that OP removes a significant proportion of its URLs after 5 and 7 days, with none remaining after 21 days - potentially limiting the blacklist’s effectiveness. We observe fewer URLs residing in all 3 blacklists as time-since-blacklisted increases – suggesting that phishing URLs are often short-lived. None of the 3 blacklists enforce a one-time-only URL policy - therefore protecting users against reoffending phishing websites. Across all 3 blacklists, we detect a significant number of URLs that reappear within 1 day of removal – perhaps suggesting premature removal or re-emerging threats. Finally, we discover 11,603 unique URLs residing in both PT and OP – a 12% overlap. Despite its smaller average size, OP detected over 90% of these overlapping URLs before PT did.

Catch Me (On Time) If You Can: Understanding the Effectiveness of Twitter URL Blacklists

Authors: Simon Bell, Kenny Paterson, and Lorenzo Cavallaro

With more than 500 million daily tweets from over 330 million active users, Twitter constantly attracts malicious users aiming to carry out phishing and malware-related attacks against its user base. It therefore becomes of paramount importance to assess the effectiveness of Twitter's use of blacklists in protecting its users from such threats.

We collected more than 182 million public tweets containing URLs from Twitter's Stream API over a 2-month period and compared these URLs against 3 popular phishing, social engineering, and malware blacklists, including Google Safe Browsing (GSB). We focus on the delay period between an attack URL first being tweeted to appearing on a blacklist, as this is the timeframe in which blacklists do not warn users, leaving them vulnerable.

Experiments show that, whilst GSB is effective at blocking a number of social engineering and malicious URLs within 6 hours of being tweeted, a significant number of URLs go undetected for at least 20 days. For instance, during one month, we discovered 4,930 tweets containing URLs leading to social engineering websites that had been tweeted to over 131 million Twitter users. We also discovered 1,126 tweets containing 376 blacklisted Bitly URLs that had a combined total of 991,012 clicks, posing serious security and privacy threats. In addition, an equally large number of URLs contained within public tweets remain in GSB for at least 150 days, raising questions about potential false positives in the blacklist. We also provide evidence to suggest that Twitter may no longer be using GSB to protect its users.



All content © Simon Bell 2021