Analysis of cifrat: could this be an evolution of a mobile RAT?

CERT Polska has analyzed an android malware sample distributed through infrastructure impersonatingBooking.com. We refer to it ascifrat(a name derived from the theio.cifnzm.utility67pupackage name and its RAT functionality) for this analysis purpose because, we could not confidently map it to a known family name (as of the analysis date).

The analyzed sample was delivered through a phishing chain that ended with a fake Booking Pulse application update page and a malicious APK download. The visible app was only the beginning of the infection path. Static and dynamic reverse engineering showed that the downloaded APK was a multi stage dropper that unpacked a second APK, then a hidden final payload, and ultimately deployed an accessibility controlled RAT communicating over WebSockets.

The infection chain starts with a phishing email. The victim is encouraged to click a link, which first leads them to:

https://share.google/Yc9fcYQCgnKxNfRmH

and then redirects them to:

https://booking.interaction.lat/starting/

That final page presents itself as aBooking.combranded security/update prompt and offers a malicious APK download:

The downloaded app is the outer dropper. After installation, it loads a native library, decrypts another embedded APK disguised asGoogle Play Services, and that second APK decrypts one more hidden stage. The final recovered payload is a full Android RAT that abuses accessibility features and has support for overlay injection, SMS access, screen streaming, camera capture, remote gestures, and SOCKS5 tunneling.

The infection flow observed from the victim side is as follows.

The victim first receives a phishing email. The message uses social engineering to persuade the recipient to click a link embedded in the body.

Clicking the phishing link redirects the victim throughshare.google/Yc9fcYQCgnKxNfRmHand then tobooking.interaction.lat/starting/. On that page, the user sees a fakeBooking.combranded update message claiming that a security update is required. PressingAktualizuj terazbutton leads to the download ofcom.pulsebookmanager.helper.apk. Downloaded application is impersonatingBooking.compulse app:

Once installed, the app does not immediately expose its final malicious behavior. Instead, it acts as a delivery shell. It loads a native decoder, decrypts an embedded second stage APK, and installs that second stage under the packageio.cifnzm.utility67pu, labeledGoogle Play Services.

That second stage APK is still not the final payload. ItsApplicationclass extracts another hidden asset namedFH.svg, decrypts it, treats the result as a ZIP archive, loads hidden dex files from it, and then transfers execution into the actual malware module.

At that point the malware becomes a fully functional RAT. The recovered final stage contains screen streaming support, keylogging, HTML injection, SMS collection, camera support, remote gestures, device manipulation, and a dual WebSocket control plane connected tootptrade.worldC2 server.

Every Android application starts with anAndroidManifest.xmlfile. In this sample, the manifest already shows that the downloadedBooking.comthemed APK is not a normal standalone application. Before any code is decompiled, the manifest reveals a staged installer design: the app requests sideload permissions, explicitly expects another package to exist, uses a customApplicationclass for early bootstrap, and monitors package installation events.

The first useful indicator is the manifest of the outer APK. Even without decompiling Java code, it already shows a sideloading oriented application that expects a second package to appear and monitors installation events.

This tells us several things immediately:

Further down the manifest, the outer APK also requestsRECEIVE_BOOT_COMPLETED,QUERY_ALL_PACKAGES,MANAGE_EXTERNAL_STORAGE,REQUEST_DELETE_PACKAGES, andPACKAGE_USAGE_STATS. That combination is excessive for aBooking.comrelated helper app but consistent with a dropper that wants broad package visibility, installation control, and post install persistence options.

The bundled strings reinforce that the visible app is an installation funnel rather than a normalBooking.comapplication:

So even at the manifest/resources level, the outer APK already looks like an installer shell.

The outer launcher activity isBaseActionHandler6ut. Its visible job is to present the victim with a fake update workflow, but the implementation shows that this is not just a static HTML page. The activity builds a WebView, exposes a JavaScript bridge, and loads a decoded local asset:

After recovering the JNI backed decoder, these values become:

This does not mean the victim only ever sees a local page. The local asset acts as a bootstrap page used by the outer dropper. Separately, the same outer stage decodesxc.btohttps://booking.interaction.lat/update/, passes that value intoKokokotProcessorrdy, and that activity loads the supplied URL in its ownWebView. The same remoteBooking.comthemed page is later reused by the final stage throughBuildConfig.BASE_URL. In practice, Stage 0 starts from a local bootstrap asset, but the visible Booking fake site is the remotehttps://booking.interaction.lat/update/page.

The bridge is active and not cosmetic. It fingerprints the victim device and can trigger the installation flow:

So the fake Booking page can both collect device information and advance the victim deeper into the install chain.

The real bootstrap begins even earlier, insidev0a0cac5c.l0a0cac5c.attachBaseContext(). That class copies an architecture specific native library from APK assets into a private directory and loads it withSystem.load():

The APK bundles four architecture variants:

In the observed dynamic run, the x64 variant was dropped to:

and loaded from there. The runtime dump matched the bundled asset exactly.

At this point the outer APK has already done three things:

Analysis ofl0a0cac5c_x64.soshows that the library is not just a passive helper.JNI_OnLoadlocates the obfuscated decoder class, registers native methods for it, retrieves runtime paths, and performs anti-analysis checks before continuing.

The decompiledJNI_OnLoadpath includes:

This is important because it confirms that the outer Java layer’s frequent calls tom0a0cac5c.F0a0cac5c_11(...)are backed by a real JNI decoder registered at process startup.

The sameJNI_OnLoadpath also resolves runtime locations:

and checks/proc/self/mapsforlibjdwp.so, which is a strong anti debugging signal:

That native behavior matches what we observed elsewhere in the sample:

The outer Java layer is filled with encoded calls like:

After reversing the JNI decoder, the recovered behavior is:

That decoder resolves the core outer stage pivots:

This is the point where the outer APK stops looking like a generic fake app and starts looking like a true staged loader.

To make this step reproducible, we wrote a small helper that implements the recovered JNI string routine directly:

With that helper, the encoded strings used by the outer loader can be resolved deterministically:

That is how we produced the decoded constant set used throughout the rest of the analysis.

The next stage is stored as:

This point is important because the 32 byte XOR key is not stored in Java as a plaintext constant. Instead, Java asks the JNI-backed native decoder to decode an obfuscated string, receives a 64 character hexadecimal value, converts that value into 32 raw bytes, and only then uses those bytes to decryptinit_bundle_uzge.bin. In other words, the key material is recovered through the native decoding path, while the actual XOR over the stage 2 bundle is performed in Java:

Recovered key hex:

To validate the stage 2 unpacking path independently of the app, we also wrote a minimal helper that applies the recovered 32-byte XOR key toinit_bundle_uzge.bin:

Running that helper produces the second stage APK, which can then be unpacked and decompiled separately:

The decrypted result is written into aPackageInstallersession:

Analysis confirmed that the outer APK decrypts and installs a second APK:

The outer stage also reports the installation flow to a decoded reporting URL. In this sample, that URL is not stored in plaintext. It is initialized inad.athrough the JNI backed native decoder and then passed byJuwekinManager89k.report()asreportUrl, which is finally used innew URL(this.reportUrl).openConnection(). The decoded value ishttps://aplication.digital/receiving/stats/:

Recovered event names include:

Once unpacked, the installedio.cifnzm.utility67pupackage already exposes accessibility, SMS, device admin, screen capture, and camera components. Even before the hiddenFH.svgstage is unpacked, the second stage manifest is already strongly malicious:

This means stage 2 already contains the structural components of the malware module rather than a benign update module.

The most important deeper finding is that the installedio.cifnzm.utility67puAPK is still not the final stage. ItsApplicationclassCgridtheyextracts another hidden asset,FH.svg, and decrypts that before running the real payload.

The hardcoded stage 3 values are visible directly:

The decryption routine inCgridtheyis RC4 like:

After decryption, the output is treated as an archive and patched into the live class loader:

Whend(absolutePath2, context)succeeds, the asset is added to anArrayListand injected into the live class loader with:

Finally, execution is handed to the real final application:

DecryptingFH.svgrecovers the real final hidden dex files. That is the stage that contains the RAT logic.

For reproducibility, we mirrored that logic in a standalone helper and applied it directly to the hidden asset:

That producesFH.svg.rc4.dec, which is a ZIP archive containing the final hidden dex pair:

Even at this stage, the application still presents the victim with the same fakeBooking.comthemed site (via webview):

but itsMainApplicationclearly behaves like a persistent malware module:

Two details matter here:

This is not the behavior of a simple downloader. It is the initialization logic of the actual RAT.

The final stage hardcodes a single backend host and then builds two separate WebSocket channels from it:

The URLs are constructed as:

The client code also adds identifying headers:

and weakens TLS verification deliberately:

Recovered final endpoints:

The control/data split is important because it explains why the recovered feature set is so broad: the malware module separates command delivery from high-volume data transport such as keylogs, HTML-injection telemetry, and screen frames.

The recovered stage 3 source shows that this is a feature rich accessibility controlled Android RAT.

Keylogging and lock screen capture

The keylogger is initialized with a list of high value package categories:

It also captures key events directly:

Combined with the presence ofPatternLockActivity,PINLockActivity, andPasswordLockActivity, this means the malware is built to capture credentials, not just UI metadata.

HTML injection/overlay phishing

The final stage contains a dedicated HTML injection manager:

It reports both the list of available templates and the corresponding injection events to the C2 server:

This is source backed evidence for web inject and overlay capability rather than a single hardcoded phishing screen.

Screen streaming

The malware module requests MediaProjection permission and starts screen sharing after approval:

The protocol also defines:

which matches both raw screen streaming and layout/tree extraction.

SOCKS5 tunneling

The malware module also exposes a SOCKS5 tunnel controlled through the C2 infrastructure:

and identifies itself to the relay with a handshake containing device metadata:

This strongly indicates that the malware is intended not only for data theft, but also for remote access and network traffic relaying.

Analyzed sample is not merely a fake Booking Pulse application or a simple downloader. Our analysis recovered the full infection chain, from the phishing email to the final stage of the malware.

The complete technical path is:

phishing email -> share.google/Yc9fcYQCgnKxNfRmH redirect -> booking.interaction.lat/starting/ -> com.pulsebookmanager.helper -> WebView lure -> native loader l0a0cac5c.so -> JNI string decoder and anti-analysis -> XOR-decrypted stage 2 APK io.cifnzm.utility67pu -> RC4-like decrypted FH.svg -> final accessibility controlled RAT -> WebSocket C2 at otptrade.world

The final payload supports credential capture, HTML injection, SMS theft, screen streaming, camera use, remote device control, and SOCKS5 relaying. In other words, theBooking.comthemed APK is only the visible entry point into a much deeper Android malware pipeline.