iOS exploit chain deploys LightSpy feature-rich malware

[harlan4096]

A watering hole was discovered on January 10, 2020 utilizing a full remote iOS exploit chain to deploy a feature-rich implant named LightSpy. The site appears to have been designed to target users in Hong Kong based on the content of the landing page. Since the initial activity, we released two private reports exhaustively detailing spread, exploits, infrastructure and LightSpy implants.

We are temporarily calling this APT group “TwoSail Junk”. Currently, we have hints from known backdoor callbacks to infrastructure about clustering this campaign with previous activity. And we are working with colleagues to tie LightSpy with prior activity from a long running Chinese-speaking APT group, previously reported on as Spring Dragon/Lotus Blossom/Billbug(Thrip), known for their Lotus Elise and Evora backdoor malware. Considering this LightSpy activity has been disclosed publicly by our colleagues from TrendMicro, we would like to further contribute missing information to the story without duplicating content. And, in our quest to secure technologies for a better future, we reported the malware and activity to Apple and other relevant companies.

This supplemental information can be difficult to organize to make for easy reading. In light of this, this document is broken down into several sections.

1. Deployment timeline – additional information clarifying LightSpy deployment milestone events, including both exploit releases and individual LightSpy iOS implant component updates.

2. Spreading – supplemental technical details on various techniques used to deliver malicious links to targets

3. Infrastructure – supplemental description of a TwoSail Junk RDP server, the LightSpy admin panel, and some related server-side javascript

4. Android implant and a pivot into evora – additional information on an Android implant and related infrastructure. After pivoting from the infrastructure in the previous section, we find related implants and backdoor malware, helping to connect this activity to previously known SpringDragon APT with low confidence.

More information about LightSpy is available to customers of Kaspersky Intelligence Reporting. Contact: intelreports@kaspersky.com

Deployment timeline

During our investigation, we observed the actor modifying some components involved in the exploit chain on February 7, 2020 with major changes, and on March 5, 2020 with minor ones.

The first observed version of the WebKit exploit dated January 10, 2020 closely resembled a proof of concept (PoC), containing elements such as buttons, alert messages, and many log statements throughout. The second version commented out or removed many of the log statements, changed alert() to print() statements, and also introduced some language errors such as “your device is not support…” and “stab not find…”.

By analyzing the changes in the first stage WebKit exploit, we discovered the list of supported devices was also significantly extended.

As seen above, the actor was actively changing implant components, which is why we are providing a full list of historical hashes in the IoC section at the end of this report. There were many minor changes that did not directly affect the functionality of each component, but there were also some exceptions to this that will be expanded on below. Based on our observations of these changes over a relatively short time frame, we can assess that the actor implemented a fairly agile development process, with time seemingly more important than stealthiness or quality.

One interesting observation involved the “EnvironmentalRecording” plugin (MD5: ae439a31b8c5487840f9ad530c5db391), which was a dynamically linked shared library responsible for recording surrounding audio and phone calls. On February 7, 2020, we noticed a new binary (MD5: f70d6b3b44d855c2fb7c662c5334d1d5) with the same name with no similarities to the earlier one. This new file did not contain any environment paths, version stamps, or any other traces from the parent plugin pattern. Its sole purpose was to clean up the implant components by erasing all files located in “/var/iolight/”, “/bin/light/”, and “/bin/irc_loader/”. We’re currently unsure whether the actor intended to replace the original plugin with an uninstall package or if this was a result of carelessness or confusion from the rapid development process.

Another example of a possible mistake involved the “Screenaaa” plugin. The first version (MD5: 35fd8a6eac382bfc95071d56d4086945) that was deployed on January 10, 2020 did what we expected: It was a small plugin designed to capture a screenshot, create a directory, and save the capture file in JPEG format. However, the plugin (MD5: 7b69a20920d3b0e6f0bffeefdce7aa6c) with the same name that was packaged on February 7 had a completely different functionality. This binary was actually a LAN scanner based on MMLanScan, an open source project for iOS that helps scan a network to show available devices along with their MAC addresses, hostname, and manufacturer. Most likely, this plugin was mistakenly bundled up in the February 7 payload with the same name as the screenshot plugin.
...

Continue Reading