July 24, 2025 • 15 mins
In this episode of Upwardly Mobile, we delve deep into the sophisticated world of Konfety malware and explore how remote app attestation provides a crucial defence against its cunning tactics.
Konfety employs an "evil twin" method, creating malicious versions of legitimate apps that share the same package name and publisher IDs as benign "decoy twin" apps found on official app stores. This allows the malware to spoof legitimate traffic for ad fraud and other malicious activities.
Konfety's "evil twins" are distributed through third-party sources, malvertising, and malicious downloads, effectively bypassing official app store security checks. To evade detection, Konfety employs sophisticated obfuscation and evasion techniques. These include dynamic code loading, where malicious code is decrypted and executed at runtime from an encrypted asset bundled within the APK. It also manipulates APK structures through tactics like enabling the General Purpose Flag bit 00 (which can cause some tools to incorrectly identify the ZIP as encrypted and request a password) and declaring unsupported compression methods (such as BZIP) in the AndroidManifest.xml (which can result in partial decompression or cause analysis tools like APKTool or JADX to crash). Other stealth techniques involve suppressing app icons, mimicking legitimate app metadata, and applying geofencing to adjust its behaviour by region. The malware leverages the CaramelAds SDK to fetch ads, deliver payloads, and maintain communication with attacker-controlled servers. Users may experience redirects to malicious websites, unwanted app installs, and persistent spam-like browser notifications. The threat actors behind Konfety are highly adaptable, consistently altering their targeted ad networks and updating their methods to evade detection.
So, how does remote app attestation combat such a resilient threat? Remote app attestation is a security mechanism where a mobile app proves its identity and integrity to a trusted remote server. This process typically involves the mobile app generating a unique "fingerprint" or "evidence" of its current state, often using hardware-backed security features like Trusted Execution Environments or Secure Enclaves. This evidence includes measurements of the app's code, data, and the device's security posture (e.g., whether the bootloader is locked, if the device is rooted, or if it's running an official OS). This evidence is then sent to a trusted remote server, often an attestation service, for verification. The attestation service compares the received evidence against a known good baseline or policy, checking if the app is genuine and unmodified, if the code running is the expected untampered version, and if the device it's running on is secure and hasn't been compromised. Based on this verification, the server provides a "verdict," which determines whether the app is allowed to proceed with sensitive operations (like accessing premium content or making transactions).
Remote app attestation provides specific protections against Konfety by:
• Detecting "Evil Twins": Even if the "evil twin" spoofs a package name, its underlying code and environment measurements would likely differ from the legitimate app. The attestation service would detect this mismatch, as the "fingerprint" wouldn't match the expected genuine app.
• Preventing Tampering: Konfety's manipulation of APK structures and dynamic code loading aims to hide malicious activity. Remote attestation, particularly if it includes code integrity checks and runtime environment monitoring, would detect these unauthorized modifications or the execution of unapproved code.
• Identifying Compromised Devices: If Konfety relies on a rooted or otherwise compromised device to operate, remote app attestation can identify these device security issues, allowing the backend to deny service to that device.
• Backend Control: A key benefit is that the decision of trust is made on a secure backend, not on the potentially compromised mobile device itself. This makes it much harder for Konfety to spoof or interfere with the attestation process.
Organisations like Zimperium offer on-device Mobile Threat Defence (MTD) solutions and zDefend which are noted to protect customers against Konfety malware's new evasion techniques. HUMAN's Satori Th
Konfety employs an "evil twin" method, creating malicious versions of legitimate apps that share the same package name and publisher IDs as benign "decoy twin" apps found on official app stores. This allows the malware to spoof legitimate traffic for ad fraud and other malicious activities.
Konfety's "evil twins" are distributed through third-party sources, malvertising, and malicious downloads, effectively bypassing official app store security checks. To evade detection, Konfety employs sophisticated obfuscation and evasion techniques. These include dynamic code loading, where malicious code is decrypted and executed at runtime from an encrypted asset bundled within the APK. It also manipulates APK structures through tactics like enabling the General Purpose Flag bit 00 (which can cause some tools to incorrectly identify the ZIP as encrypted and request a password) and declaring unsupported compression methods (such as BZIP) in the AndroidManifest.xml (which can result in partial decompression or cause analysis tools like APKTool or JADX to crash). Other stealth techniques involve suppressing app icons, mimicking legitimate app metadata, and applying geofencing to adjust its behaviour by region. The malware leverages the CaramelAds SDK to fetch ads, deliver payloads, and maintain communication with attacker-controlled servers. Users may experience redirects to malicious websites, unwanted app installs, and persistent spam-like browser notifications. The threat actors behind Konfety are highly adaptable, consistently altering their targeted ad networks and updating their methods to evade detection.
So, how does remote app attestation combat such a resilient threat? Remote app attestation is a security mechanism where a mobile app proves its identity and integrity to a trusted remote server. This process typically involves the mobile app generating a unique "fingerprint" or "evidence" of its current state, often using hardware-backed security features like Trusted Execution Environments or Secure Enclaves. This evidence includes measurements of the app's code, data, and the device's security posture (e.g., whether the bootloader is locked, if the device is rooted, or if it's running an official OS). This evidence is then sent to a trusted remote server, often an attestation service, for verification. The attestation service compares the received evidence against a known good baseline or policy, checking if the app is genuine and unmodified, if the code running is the expected untampered version, and if the device it's running on is secure and hasn't been compromised. Based on this verification, the server provides a "verdict," which determines whether the app is allowed to proceed with sensitive operations (like accessing premium content or making transactions).
Remote app attestation provides specific protections against Konfety by:
• Detecting "Evil Twins": Even if the "evil twin" spoofs a package name, its underlying code and environment measurements would likely differ from the legitimate app. The attestation service would detect this mismatch, as the "fingerprint" wouldn't match the expected genuine app.
• Preventing Tampering: Konfety's manipulation of APK structures and dynamic code loading aims to hide malicious activity. Remote attestation, particularly if it includes code integrity checks and runtime environment monitoring, would detect these unauthorized modifications or the execution of unapproved code.
• Identifying Compromised Devices: If Konfety relies on a rooted or otherwise compromised device to operate, remote app attestation can identify these device security issues, allowing the backend to deny service to that device.
• Backend Control: A key benefit is that the decision of trust is made on a secure backend, not on the potentially compromised mobile device itself. This makes it much harder for Konfety to spoof or interfere with the attestation process.
Organisations like Zimperium offer on-device Mobile Threat Defence (MTD) solutions and zDefend which are noted to protect customers against Konfety malware's new evasion techniques. HUMAN's Satori Th
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome back to upwardly Mobile API and App Security. I'm
George and I'm Sky. Today we're exploring some pretty advanced
AI enabled threats targeting mobile apps and also looking at solutions.
We often hear that, you know, built in protections from
the big players like Apple, Google, Samsung, Huawei, they might
(00:20):
not always be enough.
Speaker 2 (00:21):
That's definitely true. They leave gaps, especially for sensitive data exactly.
Speaker 1 (00:26):
So today we're focusing on a specific piece of malware
called Confetti. We'll look at how it works, how it hides,
and crucially, how something like remote app attestation can help
secure your apps against this kind of threat.
Speaker 2 (00:37):
Sounds good. Confetti mainly goes after Android and it uses
this technique called the evil twin method, primarily for ad fraud.
But it's quite sneaky an.
Speaker 1 (00:46):
Evil coin Okay, can you maybe walk us through that concept?
How does it manage to you know, spoof legitimate traffic?
Speaker 2 (00:52):
So?
Speaker 1 (00:52):
Well?
Speaker 2 (00:52):
Sure, so the attackers create these malicious versions of real
legitimate apps, and the really clever part is they use
the exact same package name, the same publisher IDs as
a benign decoy twin app. You might even find that
decoy on an official store.
Speaker 1 (01:06):
Ah so it looks identical on the surface.
Speaker 2 (01:08):
Pretty much, which lets it spoof traffic convincingly. But here's
the catch, these malicious evil twins, they aren't distributed through
official stores. They come from third party sources, maybe malvertizing campaigns,
dodgy downloads completely bypassing the store's security checks.
Speaker 1 (01:26):
Okay, that makes sense. So it's sidesteps of front door security.
But how does it avoid getting caught later? How does
it hide from analysis tools and you know, security software
on the device itself.
Speaker 2 (01:35):
Yeah, this is where confetti gets really interesting. It uses
some pretty advanced evasion techniques. First up, there's something called
zip level.
Speaker 1 (01:43):
Evasion zip level How does that work?
Speaker 2 (01:46):
They basically mess with the APK file structure it's ZP format.
For example, they might flip a flag in the ZP header,
the general purpose flag, to make it look like the files.
Speaker 1 (01:56):
Encrypted, but it's not actually encrypted.
Speaker 2 (01:58):
Nope, but analysis tools see the flag, ask for a
password that doesn't exist and just give up. Or another trick,
they might declare an unsupported compression method like bzip just
for the Android manifest dot xml.
Speaker 1 (02:10):
File, even if the file isn't really compressed.
Speaker 2 (02:13):
That way exactly. Again, tools like APK tool or JDX.
They hit this, they don't know how to handle it,
and they break it. Makes reverse engineering a real nightmare.
Speaker 1 (02:23):
Wow.
Speaker 2 (02:24):
And here's the really insidious part. Something developers really need
to understand Android itself, because it's designed to be fault tolerant,
you know, for user convenience, right.
Speaker 1 (02:34):
It tries to install things even if they're a bit weird.
Speaker 2 (02:37):
Precisely, Android just quietly ignores the unsupported compression or the
fake encryption flag and installs the app perfectly fine. So
the malware works on the device, but the security tools
are completely stumped.
Speaker 1 (02:49):
So it basically turns Android's helpfulness against itself. It's quite
an exploit of design. Okay, what else have they got?
Any of the ways they hide?
Speaker 2 (02:57):
Oh yeah? Another big one is dynamic code loading. They
don't put all the malicious stuff in the main app code. Instead,
they hide key functions inside encryptid assets. Usually these are
secondary d X files. These files are only decrypted and
loaded into memory, you know, executed at run time.
Speaker 1 (03:15):
Ah, so the static scan of the initial APK wouldn't
see the really bad stuff exactly.
Speaker 2 (03:20):
It hides the core logic and often you'll see components
declared in the manifest file, the Android manifest dot xml,
but the actual code for them seems to be missing
from the main APK. That's a clue, but automated scans
might miss it initially.
Speaker 1 (03:35):
Right because the code isn't there until it's running. That's
clever for bypassing scans any other stealth tactics once it's
actually installed.
Speaker 2 (03:42):
In running, definitely, they use various stealth techniques, things like
hiding the app icon so you don't even see it
in your app list. They also mimic the metadata of
legitimate apps to try and blend in, and they use
geofencing too.
Speaker 1 (03:56):
Geofensing. How does that help them hide?
Speaker 2 (03:58):
Well, say it detects you're in the EU based on
your mobile user agent, it might redirect you to some
sketchy fishing site. But if you're elsewhere, maybe it redirects
you to Google. Just to avoid raising flags and regions
with stricter regulations or more scrutiny.
Speaker 1 (04:13):
Tailoring the attack based on location. Given all this effort
in hiding, what actually happens to the user If one
of these things gets installed, what's the impact?
Speaker 2 (04:21):
It can be pretty annoying and harmful. Users often get
redirected to malicious websites without wanting to. They get prompted
to install other unwanted apps, and they can get bombarded
with those persistent spammy browser notifications.
Speaker 1 (04:35):
Those are the worst.
Speaker 2 (04:36):
Tell me about it. And the people behind Confetti, they're
not static. They're constantly changing the ad networks they target,
tweaking these evasion methods. They adapt really quickly. It makes
them a persistent headache.
Speaker 1 (04:49):
That adaptability sounds like a major challenge. Okay, let's maybe
dig into the operation itself. You said it's multi stage.
Can you break down those stages for us?
Speaker 2 (04:57):
Sure? It typically works in three stages for these evil
twin apps. Stage one is the dropper APK. The dropper, right,
it's usually pretty small, maybe under three megabytes. It uses
the package name it's impersonating the one from the legitimate
decoy app. Often online scanners will flag this initial dropper
as malicious okay, and it often has this unique string
(05:19):
something like at njsec embedded in the ZP files comments section.
That's for tracking downloads. We'll come back to that. But
the main job of this dropper is just to use
that dynamic code loading technique we talked about to kick
off stage two.
Speaker 1 (05:31):
So the dropper is small, gets its foot in the
door and maybe tracks itself. What's stage two?
Speaker 2 (05:36):
Stage two is the obfuslated stager. This part is decrypted
from those hidden assets within the dropper APK. Its job
is to set things up. It defines necessary services, establishes
communication with the command and control server the C two server,
and sets up persistence assistanms like like hiding the app
icon from the launcher, making it harder for the average
(05:58):
user to find and uninstall it.
Speaker 1 (06:00):
Okay, so the stager sets up shop and hides then
what what's the final act?
Speaker 2 (06:04):
Stage three is the encrypted DXX payload. This is the
core malicious part. Once this gets decrypted, it contains the
modified or backdoored versions of usually advertising SDKs. This is
what carries out the actual fraud.
Speaker 1 (06:19):
And how does it do that well.
Speaker 2 (06:20):
Mainly by rendering ads improperly, like showing full screen video
ads completely out of context. You could be on your
phone's home screen or maybe using a totally different app
and suddenly, bam, a full screen ad pops up. It
often starts a specific service just to watch for when
the user is active and then blast these ads.
Speaker 1 (06:38):
That sounds incredibly disruptive and focused on AD fraud. Are
they building this whole ad system themselves or are they
piggybacking on existing stuff You mentioned ad SDKs.
Speaker 2 (06:49):
Yeah, they heavily abuse a specific SDK called the Carameld
ads SDK. Now, it's important to say Carameld itself isn't
necessarily malicious software, but Confetti exploits it. Use it to
fetch the ads they want to show, they use it
to sideload other malicious payloads, and they use it to
talk back to their own servers. One key weakness they
leverage is that this SDK apparently doesn't do a great
(07:10):
job validating if the device is real or if the
ads are being shown properly.
Speaker 1 (07:15):
So it lacks checks for device authenticity or viewability fraud.
Speaker 2 (07:19):
Exactly, which is perfect for the fraudsters because they can
make it look like legitimate ad views are happening when
they're not, or when they're being shown in these disruptive ways.
Speaker 1 (07:28):
That's a classic case of weaponizing a legitimate tool. H
You mentioned that tracking string earlier at Injoysi. How does
that tie into caramods in their campaigns?
Speaker 2 (07:37):
Right? So, that unique ID string from the dropper's comment
it gets passed along through the Caramel ads SDK and
its network communications. This lets the attackers track which of
their distribution campaigns like specific ads or download sites are
actually working, which ones are leading to successful installs. It
gives them feedback so.
Speaker 1 (07:55):
They can optimize their malwared distribution.
Speaker 2 (07:57):
Yeah.
Speaker 1 (07:57):
Okay, Beyond this ad fraud, which is already pretty bad,
does Confetti do anything else anything more invasive? Yes?
Speaker 2 (08:04):
Definitely. It also has code sideloading capabilities. It can be
instructed by the C two server to download and run
other malicious code. Often this is more modified ad SDKs
to target different AD networks, but it could potentially be anything, so.
Speaker 1 (08:19):
It's extensible, Nancy. What else?
Speaker 2 (08:21):
Another really concerning thing is intent filter intercepts and browser
search monitoring.
Speaker 1 (08:26):
Okay, what does that mean?
Speaker 2 (08:27):
It requests a lot of permissions and uses them to
intercept links. Say you click a link that should open
in the Zoom app or Telegram, Wikipedia maybe x formerly Twitter, right,
instead of opening the real app, Confetti can hijack that
action and redirect you to a scam website, phishing, malware,
whatever they want.
Speaker 1 (08:46):
Wow, hijacking intents?
Speaker 2 (08:47):
Yeah, and it also mimics search toolbars to basically spy
on your browsing history. It captures what you search for
and sends that data off to malicious domains like VP
track me dot com or you're researching dot com. That's
a huge privacy violation.
Speaker 1 (09:02):
That's incredibly invasive, not just fraud, but active spying and redirection. Okay,
so this thing is sophisticated, evasive, and multi talented in
bad ways. What can actually be done? How can developers
protect their mobile apps, especially if, as we said, the
basic OS protections aren't always catching this.
Speaker 2 (09:21):
This is really where we get into more advanced defenses.
One of the most powerful tools against threats like Confetti
is remote app attestation.
Speaker 1 (09:28):
Remote app at testation. Okay, break that down force. What's
the core idea and how does it work? How does
it establish trust when the OS itself might be fooled?
Speaker 2 (09:38):
Fundamentally, remote app attestation is about the mobile app proving
itself its identity and its integrity to a back end
server that you control or trust. It usually happens in
a few steps. First, app measurement or evidence collection measurement. Yeah,
the app ideally using hardware security features on the device
like a trusted execution environment or te It generates a
(10:00):
kind of unique cryptographic fingerprint of its current state. This
isn't just the app code itself, but also its data
and importantly, the security status of the device it's running on,
like whether.
Speaker 1 (10:11):
The phone is rooted or if the bootloader is unlocked.
Speaker 2 (10:14):
Exactly is it running an official OS version? Is the
device compromised? All that gets measured and included in the evidence.
It's a much deeper check than the OS might perform
on its own.
Speaker 1 (10:23):
Okay, So it gathers this secure evidence package, this fingerprint.
What then? Second?
Speaker 2 (10:29):
It securely sends that evidence package, sending evidence to a verifier.
This goes off the device to a trusted remote server,
your attestation service, and that server does what third verification?
This remote service takes the evidence it received and carefully
compares it against what it knows is the correct good state?
Is this the genuine app? Has the code been tampered with?
(10:51):
Is the version correct? Is the device environment secure? Is
the evidence fresh not some old recording?
Speaker 1 (10:57):
A whole battery of checks.
Speaker 2 (10:58):
A rigorous check, yes, based on known good baselines and
policies you said.
Speaker 1 (11:02):
And based on that check, what happens? What's the final.
Speaker 2 (11:04):
Step Finally, the server issues a verdict or action. If
everything checks out, the attestation passes, and the server tells
the back end API that it's okay to trust this
app instance, the app can then proceed with whatever sensitive
operation it was trying to do, like accessing user data
or making a transaction. And if it fails, if the
attestation fails maybe the code is wrong, or the device
(11:25):
is rooted, or the evidence is stale, the server issues
a fail verdict. Your back end API then knows not
to trust this request. It can deny service, flag the device,
maybe lock the account pending investigation.
Speaker 1 (11:38):
So the critical decision is made off device on a
trusted server.
Speaker 2 (11:42):
Precisely, that's the key. Attestation moves the trust decision away
from the potentially compromised device and onto a secure back
end you control. It makes it incredibly difficult for malware
on the client side to just lie about who it
is or what state the device is in. It's fundamental
for secure your API end points.
Speaker 1 (12:01):
That sounds like a really solid approach. Yeah, how does
this specifically counter Confitte's tricks like the evil twin thing
or the dynamic code loading.
Speaker 2 (12:08):
It hits them directly. Let's take detecting Evil Twins. Attestation
will immediately spot an Evil Twin trying to talk to
your back end.
Speaker 1 (12:14):
How even with the same package name.
Speaker 2 (12:16):
Yes, because even if the package name is spoofed, the
underlying code is different. The measurement that fingerprint we talked
about will include the hash of the actual running code.
The at testation server compares that hash to the known
good hash of your legitimate app. They won't match.
Speaker 1 (12:33):
Ah, so the code integrity check.
Speaker 2 (12:35):
Catches it exactly. The Evil Twins fingerprint is wrong. Attestation fails.
Back end access denied. The spoosh name doesn't help it.
Speaker 1 (12:44):
Okay, that makes sense for the evil Twin. What about
the tampering the ZP evasion. The dynamic code loading.
Speaker 2 (12:50):
At testation helps there too, primarily through preventing tampering. The
measurement includes checks on the app's code integrity. If Confetti
has modified the APK structure in a way that it
affects the installed code, or if it dynamically loads unapproved
malicious dex files at.
Speaker 1 (13:05):
Runtime, the fingerprint changes right.
Speaker 2 (13:07):
The runtime environment measurement will detect this unauthorized code execution
or modification. Again, the fingerprint sent to the attestation server
won't match the expected profile of your clean, unmodified app
running in a secure state. This verification of runtime integrity
is crucial.
Speaker 1 (13:24):
And what if confitti is running but on a device
that's already compromised.
Speaker 2 (13:29):
Like rooted attestation is great for identifying compromised devices, the
evidence collection phase explicitly checks the device's security posture, rooted status,
bootloader state, presence of known hacking tools running on an emulator,
et cetera. If the device is compromised, the attestation fails,
even if the app code itself hasn't been tampered with yet.
Speaker 1 (13:48):
So it protects the back end API even if the
compromise originates from the device environment itself.
Speaker 2 (13:54):
Correct and again the back end control is key. The
secure server makes the final trust decision based on all
this evidence. Malware like Confetti just can't easily bypass or
spoof that remote verification process.
Speaker 1 (14:06):
It really sounds like, well, maybe not a magical cure
all for every single thread out there. Remote app attestation
provides a very strong, targeted defense against the kind of
sophisticated attacks Confetti represents. It moves security beyond just the
device itself.
Speaker 2 (14:20):
It significantly raises the bar. Yes, it hardens the app
against these specific techniques tambering, impersonation, running on bad environments.
It's becoming, i'd say, an essential layer for any app
that handles sensitive data or interacts with valuable back end APIs.
Speaker 1 (14:36):
Wrapping things up. Then it's pretty clear that these thread
actors are constantly innovating. You know, the effort involved in
setting up fake mediation SDKs abusing legitimate publishers. It shows
a level of persistence and frankly ingenuity.
Speaker 2 (14:49):
Absolutely, it really highlights why developers and security teams can't
afford to be complacent. You have to stay informed about
these evolving tactics. Understanding how they attack is the first
step to build defenses that actually work protecting your users
and your infrastructure.
Speaker 1 (15:04):
Definitely, it's an ongoing challenge, so thinking ahead with mobile
malware getting smarter evasion techniques, evolving AI potentially playing a
bigger role on both sides. What do you see as
the next big security challenges? What emerging threats in API
and A security should developers really be keeping an eye
on over the next year or so.
Speaker 2 (15:22):
That's the critical question, isn't it. What's coming next? And
how do we prepare? Definitely something for all of us
to think about.
Speaker 1 (15:28):
Indeed, well, hopefully this look at canfity and the defensive
power of remote app a testation gives you some valuable
insights for securing your own mobile ecosystem. This discussion was
put together using human sources, with some assistance from AI
Welcome back to upwardly Mobile API and App Security. I'm
George and I'm Sky. Today we're exploring some pretty advanced
AI enabled threats targeting mobile apps and also looking at solutions.
We often hear that, you know, built in protections from
the big players like Apple, Google, Samsung, Huawei, they might
(00:20):
not always be enough.
Speaker 2 (00:21):
That's definitely true. They leave gaps, especially for sensitive data exactly.
Speaker 1 (00:26):
So today we're focusing on a specific piece of malware
called Confetti. We'll look at how it works, how it hides,
and crucially, how something like remote app attestation can help
secure your apps against this kind of threat.
Speaker 2 (00:37):
Sounds good. Confetti mainly goes after Android and it uses
this technique called the evil twin method, primarily for ad fraud.
But it's quite sneaky an.
Speaker 1 (00:46):
Evil coin Okay, can you maybe walk us through that concept?
How does it manage to you know, spoof legitimate traffic?
Speaker 2 (00:52):
So?
Speaker 1 (00:52):
Well?
Speaker 2 (00:52):
Sure, so the attackers create these malicious versions of real
legitimate apps, and the really clever part is they use
the exact same package name, the same publisher IDs as
a benign decoy twin app. You might even find that
decoy on an official store.
Speaker 1 (01:06):
Ah so it looks identical on the surface.
Speaker 2 (01:08):
Pretty much, which lets it spoof traffic convincingly. But here's
the catch, these malicious evil twins, they aren't distributed through
official stores. They come from third party sources, maybe malvertizing campaigns,
dodgy downloads completely bypassing the store's security checks.
Speaker 1 (01:26):
Okay, that makes sense. So it's sidesteps of front door security.
But how does it avoid getting caught later? How does
it hide from analysis tools and you know, security software
on the device itself.
Speaker 2 (01:35):
Yeah, this is where confetti gets really interesting. It uses
some pretty advanced evasion techniques. First up, there's something called
zip level.
Speaker 1 (01:43):
Evasion zip level How does that work?
Speaker 2 (01:46):
They basically mess with the APK file structure it's ZP format.
For example, they might flip a flag in the ZP header,
the general purpose flag, to make it look like the files.
Speaker 1 (01:56):
Encrypted, but it's not actually encrypted.
Speaker 2 (01:58):
Nope, but analysis tools see the flag, ask for a
password that doesn't exist and just give up. Or another trick,
they might declare an unsupported compression method like bzip just
for the Android manifest dot xml.
Speaker 1 (02:10):
File, even if the file isn't really compressed.
Speaker 2 (02:13):
That way exactly. Again, tools like APK tool or JDX.
They hit this, they don't know how to handle it,
and they break it. Makes reverse engineering a real nightmare.
Speaker 1 (02:23):
Wow.
Speaker 2 (02:24):
And here's the really insidious part. Something developers really need
to understand Android itself, because it's designed to be fault tolerant,
you know, for user convenience, right.
Speaker 1 (02:34):
It tries to install things even if they're a bit weird.
Speaker 2 (02:37):
Precisely, Android just quietly ignores the unsupported compression or the
fake encryption flag and installs the app perfectly fine. So
the malware works on the device, but the security tools
are completely stumped.
Speaker 1 (02:49):
So it basically turns Android's helpfulness against itself. It's quite
an exploit of design. Okay, what else have they got?
Any of the ways they hide?
Speaker 2 (02:57):
Oh yeah? Another big one is dynamic code loading. They
don't put all the malicious stuff in the main app code. Instead,
they hide key functions inside encryptid assets. Usually these are
secondary d X files. These files are only decrypted and
loaded into memory, you know, executed at run time.
Speaker 1 (03:15):
Ah, so the static scan of the initial APK wouldn't
see the really bad stuff exactly.
Speaker 2 (03:20):
It hides the core logic and often you'll see components
declared in the manifest file, the Android manifest dot xml,
but the actual code for them seems to be missing
from the main APK. That's a clue, but automated scans
might miss it initially.
Speaker 1 (03:35):
Right because the code isn't there until it's running. That's
clever for bypassing scans any other stealth tactics once it's
actually installed.
Speaker 2 (03:42):
In running, definitely, they use various stealth techniques, things like
hiding the app icon so you don't even see it
in your app list. They also mimic the metadata of
legitimate apps to try and blend in, and they use
geofencing too.
Speaker 1 (03:56):
Geofensing. How does that help them hide?
Speaker 2 (03:58):
Well, say it detects you're in the EU based on
your mobile user agent, it might redirect you to some
sketchy fishing site. But if you're elsewhere, maybe it redirects
you to Google. Just to avoid raising flags and regions
with stricter regulations or more scrutiny.
Speaker 1 (04:13):
Tailoring the attack based on location. Given all this effort
in hiding, what actually happens to the user If one
of these things gets installed, what's the impact?
Speaker 2 (04:21):
It can be pretty annoying and harmful. Users often get
redirected to malicious websites without wanting to. They get prompted
to install other unwanted apps, and they can get bombarded
with those persistent spammy browser notifications.
Speaker 1 (04:35):
Those are the worst.
Speaker 2 (04:36):
Tell me about it. And the people behind Confetti, they're
not static. They're constantly changing the ad networks they target,
tweaking these evasion methods. They adapt really quickly. It makes
them a persistent headache.
Speaker 1 (04:49):
That adaptability sounds like a major challenge. Okay, let's maybe
dig into the operation itself. You said it's multi stage.
Can you break down those stages for us?
Speaker 2 (04:57):
Sure? It typically works in three stages for these evil
twin apps. Stage one is the dropper APK. The dropper, right,
it's usually pretty small, maybe under three megabytes. It uses
the package name it's impersonating the one from the legitimate
decoy app. Often online scanners will flag this initial dropper
as malicious okay, and it often has this unique string
(05:19):
something like at njsec embedded in the ZP files comments section.
That's for tracking downloads. We'll come back to that. But
the main job of this dropper is just to use
that dynamic code loading technique we talked about to kick
off stage two.
Speaker 1 (05:31):
So the dropper is small, gets its foot in the
door and maybe tracks itself. What's stage two?
Speaker 2 (05:36):
Stage two is the obfuslated stager. This part is decrypted
from those hidden assets within the dropper APK. Its job
is to set things up. It defines necessary services, establishes
communication with the command and control server the C two server,
and sets up persistence assistanms like like hiding the app
icon from the launcher, making it harder for the average
(05:58):
user to find and uninstall it.
Speaker 1 (06:00):
Okay, so the stager sets up shop and hides then
what what's the final act?
Speaker 2 (06:04):
Stage three is the encrypted DXX payload. This is the
core malicious part. Once this gets decrypted, it contains the
modified or backdoored versions of usually advertising SDKs. This is
what carries out the actual fraud.
Speaker 1 (06:19):
And how does it do that well.
Speaker 2 (06:20):
Mainly by rendering ads improperly, like showing full screen video
ads completely out of context. You could be on your
phone's home screen or maybe using a totally different app
and suddenly, bam, a full screen ad pops up. It
often starts a specific service just to watch for when
the user is active and then blast these ads.
Speaker 1 (06:38):
That sounds incredibly disruptive and focused on AD fraud. Are
they building this whole ad system themselves or are they
piggybacking on existing stuff You mentioned ad SDKs.
Speaker 2 (06:49):
Yeah, they heavily abuse a specific SDK called the Carameld
ads SDK. Now, it's important to say Carameld itself isn't
necessarily malicious software, but Confetti exploits it. Use it to
fetch the ads they want to show, they use it
to sideload other malicious payloads, and they use it to
talk back to their own servers. One key weakness they
leverage is that this SDK apparently doesn't do a great
(07:10):
job validating if the device is real or if the
ads are being shown properly.
Speaker 1 (07:15):
So it lacks checks for device authenticity or viewability fraud.
Speaker 2 (07:19):
Exactly, which is perfect for the fraudsters because they can
make it look like legitimate ad views are happening when
they're not, or when they're being shown in these disruptive ways.
Speaker 1 (07:28):
That's a classic case of weaponizing a legitimate tool. H
You mentioned that tracking string earlier at Injoysi. How does
that tie into caramods in their campaigns?
Speaker 2 (07:37):
Right? So, that unique ID string from the dropper's comment
it gets passed along through the Caramel ads SDK and
its network communications. This lets the attackers track which of
their distribution campaigns like specific ads or download sites are
actually working, which ones are leading to successful installs. It
gives them feedback so.
Speaker 1 (07:55):
They can optimize their malwared distribution.
Speaker 2 (07:57):
Yeah.
Speaker 1 (07:57):
Okay, Beyond this ad fraud, which is already pretty bad,
does Confetti do anything else anything more invasive? Yes?
Speaker 2 (08:04):
Definitely. It also has code sideloading capabilities. It can be
instructed by the C two server to download and run
other malicious code. Often this is more modified ad SDKs
to target different AD networks, but it could potentially be anything, so.
Speaker 1 (08:19):
It's extensible, Nancy. What else?
Speaker 2 (08:21):
Another really concerning thing is intent filter intercepts and browser
search monitoring.
Speaker 1 (08:26):
Okay, what does that mean?
Speaker 2 (08:27):
It requests a lot of permissions and uses them to
intercept links. Say you click a link that should open
in the Zoom app or Telegram, Wikipedia maybe x formerly Twitter, right,
instead of opening the real app, Confetti can hijack that
action and redirect you to a scam website, phishing, malware,
whatever they want.
Speaker 1 (08:46):
Wow, hijacking intents?
Speaker 2 (08:47):
Yeah, and it also mimics search toolbars to basically spy
on your browsing history. It captures what you search for
and sends that data off to malicious domains like VP
track me dot com or you're researching dot com. That's
a huge privacy violation.
Speaker 1 (09:02):
That's incredibly invasive, not just fraud, but active spying and redirection. Okay,
so this thing is sophisticated, evasive, and multi talented in
bad ways. What can actually be done? How can developers
protect their mobile apps, especially if, as we said, the
basic OS protections aren't always catching this.
Speaker 2 (09:21):
This is really where we get into more advanced defenses.
One of the most powerful tools against threats like Confetti
is remote app attestation.
Speaker 1 (09:28):
Remote app at testation. Okay, break that down force. What's
the core idea and how does it work? How does
it establish trust when the OS itself might be fooled?
Speaker 2 (09:38):
Fundamentally, remote app attestation is about the mobile app proving
itself its identity and its integrity to a back end
server that you control or trust. It usually happens in
a few steps. First, app measurement or evidence collection measurement. Yeah,
the app ideally using hardware security features on the device
like a trusted execution environment or te It generates a
(10:00):
kind of unique cryptographic fingerprint of its current state. This
isn't just the app code itself, but also its data
and importantly, the security status of the device it's running on,
like whether.
Speaker 1 (10:11):
The phone is rooted or if the bootloader is unlocked.
Speaker 2 (10:14):
Exactly is it running an official OS version? Is the
device compromised? All that gets measured and included in the evidence.
It's a much deeper check than the OS might perform
on its own.
Speaker 1 (10:23):
Okay, So it gathers this secure evidence package, this fingerprint.
What then? Second?
Speaker 2 (10:29):
It securely sends that evidence package, sending evidence to a verifier.
This goes off the device to a trusted remote server,
your attestation service, and that server does what third verification?
This remote service takes the evidence it received and carefully
compares it against what it knows is the correct good state?
Is this the genuine app? Has the code been tampered with?
(10:51):
Is the version correct? Is the device environment secure? Is
the evidence fresh not some old recording?
Speaker 1 (10:57):
A whole battery of checks.
Speaker 2 (10:58):
A rigorous check, yes, based on known good baselines and
policies you said.
Speaker 1 (11:02):
And based on that check, what happens? What's the final.
Speaker 2 (11:04):
Step Finally, the server issues a verdict or action. If
everything checks out, the attestation passes, and the server tells
the back end API that it's okay to trust this
app instance, the app can then proceed with whatever sensitive
operation it was trying to do, like accessing user data
or making a transaction. And if it fails, if the
attestation fails maybe the code is wrong, or the device
(11:25):
is rooted, or the evidence is stale, the server issues
a fail verdict. Your back end API then knows not
to trust this request. It can deny service, flag the device,
maybe lock the account pending investigation.
Speaker 1 (11:38):
So the critical decision is made off device on a
trusted server.
Speaker 2 (11:42):
Precisely, that's the key. Attestation moves the trust decision away
from the potentially compromised device and onto a secure back
end you control. It makes it incredibly difficult for malware
on the client side to just lie about who it
is or what state the device is in. It's fundamental
for secure your API end points.
Speaker 1 (12:01):
That sounds like a really solid approach. Yeah, how does
this specifically counter Confitte's tricks like the evil twin thing
or the dynamic code loading.
Speaker 2 (12:08):
It hits them directly. Let's take detecting Evil Twins. Attestation
will immediately spot an Evil Twin trying to talk to
your back end.
Speaker 1 (12:14):
How even with the same package name.
Speaker 2 (12:16):
Yes, because even if the package name is spoofed, the
underlying code is different. The measurement that fingerprint we talked
about will include the hash of the actual running code.
The at testation server compares that hash to the known
good hash of your legitimate app. They won't match.
Speaker 1 (12:33):
Ah, so the code integrity check.
Speaker 2 (12:35):
Catches it exactly. The Evil Twins fingerprint is wrong. Attestation fails.
Back end access denied. The spoosh name doesn't help it.
Speaker 1 (12:44):
Okay, that makes sense for the evil Twin. What about
the tampering the ZP evasion. The dynamic code loading.
Speaker 2 (12:50):
At testation helps there too, primarily through preventing tampering. The
measurement includes checks on the app's code integrity. If Confetti
has modified the APK structure in a way that it
affects the installed code, or if it dynamically loads unapproved
malicious dex files at.
Speaker 1 (13:05):
Runtime, the fingerprint changes right.
Speaker 2 (13:07):
The runtime environment measurement will detect this unauthorized code execution
or modification. Again, the fingerprint sent to the attestation server
won't match the expected profile of your clean, unmodified app
running in a secure state. This verification of runtime integrity
is crucial.
Speaker 1 (13:24):
And what if confitti is running but on a device
that's already compromised.
Speaker 2 (13:29):
Like rooted attestation is great for identifying compromised devices, the
evidence collection phase explicitly checks the device's security posture, rooted status,
bootloader state, presence of known hacking tools running on an emulator,
et cetera. If the device is compromised, the attestation fails,
even if the app code itself hasn't been tampered with yet.
Speaker 1 (13:48):
So it protects the back end API even if the
compromise originates from the device environment itself.
Speaker 2 (13:54):
Correct and again the back end control is key. The
secure server makes the final trust decision based on all
this evidence. Malware like Confetti just can't easily bypass or
spoof that remote verification process.
Speaker 1 (14:06):
It really sounds like, well, maybe not a magical cure
all for every single thread out there. Remote app attestation
provides a very strong, targeted defense against the kind of
sophisticated attacks Confetti represents. It moves security beyond just the
device itself.
Speaker 2 (14:20):
It significantly raises the bar. Yes, it hardens the app
against these specific techniques tambering, impersonation, running on bad environments.
It's becoming, i'd say, an essential layer for any app
that handles sensitive data or interacts with valuable back end APIs.
Speaker 1 (14:36):
Wrapping things up. Then it's pretty clear that these thread
actors are constantly innovating. You know, the effort involved in
setting up fake mediation SDKs abusing legitimate publishers. It shows
a level of persistence and frankly ingenuity.
Speaker 2 (14:49):
Absolutely, it really highlights why developers and security teams can't
afford to be complacent. You have to stay informed about
these evolving tactics. Understanding how they attack is the first
step to build defenses that actually work protecting your users
and your infrastructure.
Speaker 1 (15:04):
Definitely, it's an ongoing challenge, so thinking ahead with mobile
malware getting smarter evasion techniques, evolving AI potentially playing a
bigger role on both sides. What do you see as
the next big security challenges? What emerging threats in API
and A security should developers really be keeping an eye
on over the next year or so.
Speaker 2 (15:22):
That's the critical question, isn't it. What's coming next? And
how do we prepare? Definitely something for all of us
to think about.
Speaker 1 (15:28):
Indeed, well, hopefully this look at canfity and the defensive
power of remote app a testation gives you some valuable
insights for securing your own mobile ecosystem. This discussion was
put together using human sources, with some assistance from AI
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.