HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

A Christmas project - decoding a sophisticated trojan attack

A Christmas project - decoding a sophisticated trojan attack One of our users reported their site was not working properly, so I looked into this as a bug report. What I found was really quite fascinating so I thought I'd share the story.

A trojan had infected their server and was causing the problems. It affected PHP code, but was not a specific attack against ocPortal – all PHP code on the server was infected, not just ocPortal's. So we have no reason to believe there is a security hole in ocPortal, it was likely a problem at server-level, or in one of the other scripts on the server.

As a little project during my Christmas vacation I decided to reverse engineer it inside a sandboxed virtual machine, because it was hard to see what it was doing. It was running through several layers of obfuscated code, and the only realistic way to decode it was to make a modified version of PHP that spits out what was being run through:
i.e. make PHP spit out what it is doing after it decoded all the trojan code.

The trojan was downloading HTML code from a series of domains registered from a country which has been in the news this year (the "home server"), and then injecting them into the footer of the normal code the infected website producced. It sent various details about the user visiting the site, and either got a payload from the home server, or didn't. It was 'turned off' for the IP I was testing with, but I assume it turned itself on for particular interesting target IPs (perhaps cyberwarfare targets?), or perhaps was turned off prior to a mass activation.

It had clearly been coded to operate under-the-radar:
  • Highly obfuscated code that needed C-programming skills to get past
  • Coded to only run for user-agents claiming to be IE
  • Coded to not run for search engines claiming to be IE, to ensure there was no easy way to index what servers were infected
  • Targeted to specific website visitors, not everyone
i.e. the trojan author did not want people to find out about it, or to isolate the full infected attack platform, or for anyone to know what it was doing.

In the case of this particular infected site it didn't work, because the trojan code assumed a PHP extension was installed that was not installed. So they slipped up, and it was very much over the radar, and I was able to analyse it. I have not mentioned the particular country involved, or any exact details, because it could easily have been faked, and I don't particular want to get in the middle of someone's international cyberwarfare exercise ;).

Our lessons:
  • Be a bit paranoid. Make sure your servers are secure. Cleaning everything out is a real pain. In this case there was no evidence of direct victimisation of the infected server (stealing user details etc), but that could have easily been different if the hacker had different motivations.
  • In our modern world of "cyberwarfare", innocent servers may be collateral damage, used as pawns for broad-but-targeted attacks.

View all


There have been no trackbacks yet