Kane Cutler: youngest PFI in the world

Newcastle-based Kane Cutler becomes youngest cybercrime expert drafted into exclusive Payment Card Industry investigation team

Newcastle-based Kane Cutler has been accepted by the Payment Card Industry Security Standards Council (PCI SSC) as a Payment Card Industry Forensic Investigator (PFI). At 26 years old this exclusive accreditation makes Kane one of, if not the youngest, PFI in the world. Only three companies in the UK operate in this field and Security Risk Management (SRM) which Cutler joined in early 2015 is one of these. He joins fellow SRM consultants Chris McGee and Andrew Linn in this select field.

Kane’s new role puts him at the frontline in investigating cybercrime. At the request of the PCI, his forensic investigation work will often deal with theft, either of significant sums from online transactions or in terms of personal data theft, putting individuals at risk of a host of other fraud issues. He is also likely to be called upon to deal with major incidents of data theft such as those recently suffered by TalkTalk and Wetherspoons.

To become a PFI, you must be a PCI Data Security Standard Qualified Security Assessor (QSA) which requires 5 years’ industry experience. In addition to this, Cutler is an experienced Information Security Officer and Penetration Tester and has significant experience working with the ISO 27001 standard as both an implementer and as an auditor, including identifying risks and implementing remediation recommendations within an Information Security Management System (ISMS).

As an Information Security Consultant with SRM, Kane Cutler is also responsible for diagnosing and remediating any issues that arise in relation to firewalls, protection software, web filters, mail filters, DNS infrastructure, application testing, and intrusion detection systems.

SRM Director Brian Fenwick, who was responsible for recruiting Kane, commented: “As a North East based company with consultants based nationwide we were delighted to recruit Kane in the North East and to assist him to broaden his cyber security expertise. Kane has joined a cutting edge Cyber Security company that has the intention to be at the head of PCI Forensic Investigation in Europe.”


As with any black hat related activity, innovations are always emerging to circumvent security and exploit vulnerabilities. Older forms of ransomware was mostly kept by specific groups of hackers that would utilise it solely for their personal gain.

As of recent times, a new form of ransomware has been identified that affects Windows, Linux and Mac with Javascript code. This nasty program acts as a Ransomware as a Service (RaaS) which allows anyone to download and distribute their own copy as long as they have a bitcoin address.

In return for this service, the developers of this ransomware take 25% of all ransom payments. Victims of ransomware are presented with a ‘lock screen’ which informs them that all their files have been encrypted together with a message demanding a certain amount of Bitcoin payment in order to decrypt their data.

New variations of this malware will continue to rise as they are an easy way of making money and so far there is no way of decrypting the majority of ransomware as they use strong encryption that is used within the Internet.

The worrying factor for this new ransomware is the implications of it being offered as a service as opposed to keeping it within the confines of a few groups; when coupled with ease of use and quick money, it is fairly easy to see how this can spread like wildfire among unsuspecting users.

Time and time again, the basic best practices of security are repeated to warn people of the risks of this compromise. In this case, crucial safeguards would be to avoid visiting malicious websites and being extra cautious with email attachments by verifying the email source.


Magento Exploits – a technical review

By Mustafa El-Jarrah Information Security Consultant, Security Risk Management Ltd

Exploits appear in trends with the magnitude and duration of these trends exacerbated by the community edition download zip not being updated with the latest patches, often requiring the end user to run patches immediately after installation. This combined with sluggish patching practices in live deployments (often out of fear of breaking something) lead to exploits still being prevalent in the wild several months after their public disclosure date.

The most common type of evidence left is usually Access Log data from the server software, less commonly, there can also be execution and error log data for the PHP preparser software.

Unfortunately, these PHP logs are uncommon and often disabled by default but when present, can be instrumental in definitively distinguishing legitimate code and access from malicious ones.

MAGMI Plugin

In the first 2 quarters of the year, the prevalent exploit within the Magento ecosystem was a vulnerability within the Magento Mass Import (MAGMI) plugin that allowed file uploads to bypass the Magento authentication steps.

Artefacts associated with this type of exploit were often located within the /plugins/ or /magmi/ directories of the compromised site.

Magento version 1.8 and older is affected.

Magmi version 0.7.17a and older is affected.

Key Identifiers

Proof of concept:

http://www. magentosite.com/magmi/web/magmi.php
Under upload new plugins:
Click on “choose file”

Magento plugins are zipped php files; create or obtain a php shell and zip the file.

File: evil_plugin.zip. Once the file has been uploaded, it will say: Plugin packaged installed.

Your malicious example.php file is extracted. You can access it by navigating to your file from: http://www.examplesite.com/magmi/plugins/example.php
Artefacts associated with this type of exploit were often located within the /plugins/ or /magmi/ directories of the compromised site.


Towards the second quarter of the year, an exploit that leveraged a vulnerability in the visual (what you see is what you get, or “wysiwyg”) page editor build into the Magento administrator tools.

This allowed an attack to run code or commands, retrieve security tokens and inject data into the database.

This attack was most visible in the server access logs where abnormally large numbers of ‘POST’ requests were being directed towards the WYSIWYG system, often with requests to either uploaded shells or pages requiring a security token in the URL.

Magento version and prior is vulnerable.

Key Identifiers

The attack in this example is written in Python and is implemented through a ‘POST’ method. Typical exploit attempts would look like the following within logs. – – [23/Apr/2015:00:45:44 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1″ 403 1880 “-” – – [22/Apr/2015:00:42:38 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1″ 200 2211 “-”


Lines 1-3 create an account and sets the target for exploit. The target consists of the target’s domain and a static vulnerable URL which is exploited for this attack.
Lines 5-14 is a SQL statement that is executed by the target servers. It inserts a new admin user inside the database.
Lines 19-22 is the ‘POST’ process with the encoded form of the ‘getCsvFile’ function which was identified to be exploitable and acts as the entry point for the SQL injection.
Lines 24-27 contain a condition statement to verify whether the exploit was successful – if it was, it prints out “SUCCESSFUL” along with the username and password. If it wasn’t successful, it prints out “UNSUCCESSFUL”.


Although the method of entry was not identified on this attack, once the attacker gains access to the site. They inject app/mage.php with code that captures ‘POST’ data being sent to the server. The code encrypts the captured data which includes credit card and billing details and places inside a fake image file entitled ‘mage.jpg’; hence the name of the attack. The image name can be different however this is the most common one that we have come across and the same name reported by other people that have seen the compromise.

The encrypted image can only be opened by the attacker as he would have the private key corresponding to the public key incorporated within the exploit code.

Key Identifiers

Open the file app/Mage.php.
The first part of the file should contain ‘Notice of License’ as follows


* Magento




* This source file is subject to the Open Software License (OSL 3.0)

* that is bundled with this package in the file LICENSE.txt.
If there is other code present prior to the code above then this most likely indicates an issue. There could be a legitimate reason as to why there is other code present however, in the majority of cases this would likely be of a malicious nature.

Web Shells

Common Web Shell capabilities that we’ve encountered:

File Browser/Editor
File Uploader
Permissions Editor
Database UI and SQL interface
Basic Bruteforcing tools
Basic Hash Cracking for passwords (3 providers)
Live PHP execution
Encypted POST variable back door (this is unusual, it’s often either/or with the GUI or POST vars execution)
Encrypting functionality (also unusual, looks like it was used for hiding what data was extracted)
Reverse Shell functionality (when supplied with an IP and port, the shell can be made to run a Perl script to Dial Home)
Functionality to hide from search engines (checks requests for known search engine UserAgent IDs and returns a HTTP 404 response)
Ajax enabled Web console
Cookie handling
Hex Dumping file data
Scraping of ExploitDB for known vulnerabilities matching the installed system
Important to note that web shells have generically been base64 encoded in the past and it was relatively easy decoding them to analyse their functionality/capability. However, as of recent times, we are seeing a new approach to web shells where they are obfuscated with base64 encoding and also encrypted with a password.

This means traditional means of decoding are failing and after doing some research, there doesn’t seem to be a viable way of decrypting them which leaves us with very little when it comes to describing their capabilities in the PFI reports.

How to protect your data in free public WiFi hotspots

In an ‘ethical experiment’ conducted earlier this year, a primary school child hacked into a free public WiFi hub in just over ten minutes.

The young hacker, a seven-year-old called Betsy, followed instructions she had acquired through a Google search, under the supervision of professional hacker Marcus Dempsey. It took her just 10 minutes and 54 seconds to set up a rogue access point at a free public WiFi hotspot and start eavesdropping on Internet traffic. It takes little imagination to conclude how much damage a maliciously motivated adult hacker could achieve in similar circumstances.

Yet, a recent survey (Kaspersky) reveals that 70% of tablet owners and 53% of smartphone owners use public Wi-Fi hotspots. The security risk posed by hackers using the vulnerabilities of these connections is immense, affecting all types of personal data including bank details and passwords.

What precautions can be taken to minimise this risk? To begin with, and obvious though it may sound, avoid using free public Wi-Fi. One way of doing this is to use your smartphone’s network. It may cost a bit more – particularly if you are abroad – but it could save you in the long run.

If you can’t do that, then treat all WiFi with suspicion. Possibly the greatest risk is not, as is often feared, the encryption or data but lack of verification that a hotspot is genuine. If possible, try to verify that any wireless connections are legitimate. Sometimes malicious users set up a connection name that is similar to that of the café or hotel that provides free WiFi but it is advisable to speak to someone who works there to check the correct connection name and IP address.

Using a virtual private network (VPN) will effectively provide you with a means of encrypting your data as it passes through the network. It will usually cost a bit more and performance will be slower but is still less expensive than using mobile data roaming in most cases. Accessing websites using encrypted HTTPS SSL, which is now offered on many services that exchange e-commerce data or login, is also a wise precaution as is anti-malware and security software for your device.

Two-factor authentication is a good idea for any computer user but has added benefits for those using an open WiFi hotspot. For example, Google offers two-step verification on all user accounts which means that in the unlikely event that a password or username is intercepted, hackers will still need to go through an added step to break into the account.

At the risk of repetition, however, it is important to emphasise that the greatest risk in using free public WiFi is that a malicious or ‘evil twin’ hotspot can be set up to carry out spoofing attacks that manipulate DNS to feed the user authentic-looking login screens. Troels Oertig, head of Europol’s cybercrime centre, has said (in a BBC interview) that people should only send personal data across networks they trust. Authentication and trust are therefore key.

And if the ‘ethical experiment’ proves anything it is that you can’t even trust a seven-year-old.

SRM Blog