Cyber Security for Protests

Published: 2020-06-05
Last Updated: 2020-06-06 14:42:48 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

Modern-day protests are as much about social media and voicing your opinions online, as they are about showing up "in person". When attending a protest, it is important to keep some basic rules in mind to stay secure. Of course, it is always best to leave expensive electronics at home, but live streaming, posting to social media, and recording events at the protest is very much a part of modern protests. The other option is to only take a relatively cheap "burner phone" with you that does not have any of your personal data associated with it. But even a cheap, but reasonably functional phone will be too expensive for most.

The rules below come mostly from various sites for protestors in Hong Kong. Hong Kong protesters during their ongoing prolonged protests have not only learned to use electronic means efficiently, but they also have faced very strong countermeasures. So let's learn "from the best" to see how to protect yourself.

Social Media and Protests

An open social media account is probably the easiest way to link a particular person to a protest. Decide who you would like to share your location/photos and other information with. This is as good of a time as any to review your social media privacy settings and double-check your friend list. Opponents will often try to disrupt protests by either claiming to be someone else or by posting bad information.

For example, opponents to a cause may post invites to protests/events that will not happen. This will not only cause lower attendance to legitimate events, but it will also frustrate supporters and make them less likely to attend future events. In another case I observed last weekend, opponents to a protest tried to scare potential attendance by stating that the protest is violent and "bombs are being thrown" while the protest was actually exceptionally quiet.

Adversaries will use social media relationships to map out networks of supporters for a specific course. They can use this to infiltrate networks by "friending" members. You may want to keep your social media identity private and use different social media accounts for different purposes.

Wireless Communication Security

Staying connected during a protest is not just important to spread the message, but also for your personal security. It can be important to quickly find out when a protest turns violent or to use tools like mapping software to find a quick way out. But wireless communication has its own risks associated with it. First of all, never ever connect to an open wireless access point while at a protest. It would be very easy for an adversary to set up an open access point, either impersonating a coffee shop access point or using an SSID that appears to be associated with the protest. Access points can also be used to monitor communication or disrupt it. For example, the malicious access point may block access to specific services like social media. Your phone will typically not fail-over to the cell phone network as long as the rest of the internet is still available via the access point. 

Try to limit the number of radios you have enabled on your phone (Bluetooth, NFC, WiFi, LTE). LTE tends to be your best option. But during large scale protests, government agencies may decide to collect LTE data. So-called "IMSI Catchers" can be used to at least identify users in the area. In some cases, they can be used to intercept and manipulate data, in particular SMS messages.

Wireless networks (Wifi or LTE) can become overloaded during large protests, or authorities may disable them. It can be helpful to set up an application that can be used to communicate short-range with friends (for example there are some Bluetooth based applications).

General Communication Security

A VPN is a reasonably good idea, but remember, VPNs are only as secure as the VPN provider. Modern systems already heavily rely on solid encrypted protocols. Even without a VPN, using HTTPS and DNS over HTTPS does obscure most of your data from prying eyes. A VPN does provide additional security in not revealing the IP addresses you are connecting to to a local observer. But the VPN provider becomes a new choke point. Select it carefully. VPN providers making inflated claims should be avoided. For example, VPNs typically do not protect you from malware.

Consider the use of independent end to end encrypted messaging systems like Telegram or Signal.

Web Browser Security

Web browsers are probably the application used most these days. Sites you visit and how you use your browser reveals a lot about who you are, what you are doing, and where you went. Even without location tracking, searchers for locations may infer for example which locations you went to. The browsers "incognito" mode can help but isn't perfect. You should also configure your browser to only keep a limited (1 week?) history. Occasionally, you may want to manually delete your browser data to erase tracking cookies and web storage that can aid in tracking your movements. 

Device Security

At a minimum, select a hard to guess passphrase, and do not use a numeric PIN alone. You may want to set a PIN for your SIM card as well. If you turn off your device, the SIM card can not be used in a different device. Without a PIN, an attacker could move the SIM card to a different device and still receive your SMS messages (e.g. to reset passwords). Biometric is convenient but can be used to unlock your device by swiping your fingerprint or holding the device up to your face. If you use biometrics: Learn how to quickly lock your device. Some devices have an "emergency lock" that can be activated by quickly pressing a button multiple times. Also, review what information is used on the lock screen.

The risk of device compromise via untrusted charging cables is often overblown. But it doesn't hurt to bring your own cable and charger, or better an extended battery pack.

Review the privacy settings on your phone and disable features like location tracking for as many applications as you can. And most importantly, update your phone before you get close to any protest. Do not update carrier settings while at a protest or close to a protest.

And don't forget those masks (at least they are now acceptable for protests not just to deceive facial recognition). Stay healthy!

Anything I missed? Anything that helped you or risks you observed? Please comment below.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute

0 comment(s)

Not so FastCGI!

Published: 2020-06-05
Last Updated: 2020-06-05 08:27:17 UTC
by Remco Verhoef (Version: 1)
2 comment(s)

This past month, we've seen some new and different scans targeting tcp ports between 8000 and 10,000. The first occurrence was on 30 April 2020 and originated from ip address and containing payload:



After this initial scan, the next similar scans used a different ip address (, but within 5 hours from the first occurrence we received a different payload:



It is clear that the payload is trying to exploit something PHP related, but it was not immediately obvious what service was being targeted. After Googling around for a while, I could identify the payload as being targeting fastcgi. Fastcgi can run using both unix sockets (named pipes on Windows) and tcp sockets. Apparently they are scanning for publicly available, incorrect configured fastcgi sockets.

Now that we know what to look at, we can dive into the source code of FastCGI to validate the protocol being used. The FastCGI code can be found at the PHP repository.

Looking at the source code and function fcgi_read_request, we can recognise the header and structure being used. Eg the first header contains the FCGI_BEGIN_REQUEST type, with FCGI_RESPONDER role. The following header consists of the type FCGI_PARAMS, with several variables being defined.

PHP_VALUE allow_url….
SCRIPT_FILENAME /usr/bin/phar.phar
SCRIPT_NAME /usr/bin/phar.phar

Next, it will send a FCGI_PARAMS to end the send of parameters, and send the header with type FCGI_STDIN.

The PHP_VALUE variable consists of php directives causing the base64 encoded script to be automatically parsed before the main file (

Using my favorite swiss army knife CyberChef, we can decode the base64 encoded script easily (recipe From Base64) and beautify the code (recipe Generic Code Beautify), resulting in the following php script:

<?php if (function_exists('error_reporting'))  {

if (function_exists('ini_set'))  {
    @ini_set('error_reporting', 0);
    @ini_set('error_log', NULL);
    @ini_set('log_errors', 0);

if ($___ ==  = "/usr/bin/phar.phar")  {
    echo"<span style='display:none'>".md5('lohpidr')."</span>";


After setting up some configuration to prevent error reporting and error logging, it will validate if the code is being executed with the script name set to /usr/bin/phar.phar. If this is the case, a non-browser visible (hidden by css) will be returned, containing the md5 hash of lohpidr, which results in the hash 58d4c1968bd824ac7ac95da61a462919.

Since the 27th of May, we now see the same payload occurring with a different originating ip address It is interesting to see is that the netblock owner of the first ( and last ( ip address is Virtual Machine Solutions LLC, the middle ( is owned by SpectraIP B.V. We don't see any other traffic from these hosts within our honeypot network.


Please share your ideas, comments and/or insights, with me via social media, @remco_verhoef or email, remco.verhoef at dutchsec dot com. Have a great day!

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec


Keywords: honeypot php
2 comment(s)
ISC Stormcast For Friday, June 5th 2020


Diary Archives