Cybersecurity in a Hybrid Health-Fintech - A case of M-TIBA (White Paper Series - Part 1)

Disclaimer. The views, assessments, and observations presented in this article are provided strictly for educational and analytical purposes, based on publicly available information and professional expertise. Defthon is not affiliated with, funded by, or acting on behalf of M-TIBA, any of its partners, competitors, government agencies, or any other stakeholder mentioned or implied.

This analysis is vendor-neutral and non-partisan. It does not seek to assign blame, validate unverified claims, or reach definitive conclusions while official investigations are ongoing. All references to entities, systems, or potential impacts are intended solely to support high-level risk awareness, resilience building, and the advancement of cybersecurity best practices.

Background

Few weeks ago the news on M-TIBA PHI data leaked was all over where hackers claimed  to have stolen approx. 2.15 TB of data (17 million-plus files). M-Tiba is a mobile health wallet (Digital health financing platform) developed in Kenya. The application allows  save, send, receive, and use funds specifically for healthcare services (consultations, treatment, medication) at partner clinics/health-providers.

Infrastructure Overview

M-TIBA operates through multiple front-end and back-end components designed to support digital health payments and services. On the front end, users access the platform via Android and iOS mobile applications as well as the USSD code *253#. The back end includes a Provider Portal for healthcare facilities, a Payer/Insurer Dashboard for insurers, and the CarePay platform, which integrates mobile money services such as M-PESA with healthcare provider systems and payer platforms. The mobile applications are distributed through the Google Play Store and Apple App Store, while the USSD service is likely hosted in a public cloud environment. The web-based portals and the CarePay infrastructure appear to be hosted in the cloud, with indications pointing to AWS, based on the presence of managed DNS services linked to that environment.

Key Actors

The key Actors in the M-TIBA ecosystem are the patients (end user), the healthcare provider, and the payer (insurer). Patients use the platform to access and fund healthcare services.

Providers deliver care, while insurers or payers finance and manage the associated costs.

Analysis  & Best Practice

Kenya enjoys very fast internet access and leads the world in mobile money penetration, reaching over 91% by mid-2025. This means that the vast majority of Kenyan adults use mobile financial services, primarily driven by the ubiquitous M-Pesa platform. This makes it easier for many service providers to integrate with Mobile Money service providers such as M-pesa, Airtel Money, and seamlessly able to transact across other platforms. 

A hybrid health-fintech environment like M-TIBA’s (mobile apps + USSD + web portals + cloud + third-party integrations) brings powerful capabilities, but it also introduces a wide and complex risk surface. Example: 

1. Expanded attack surface 

A hybrid model means there are many entry points, namely; 

a. Mobile apps (Android & iOS).

b. USSD channels.

c. Web portals (provider and insurer dashboards).

d. APIs connecting M-PESA, healthcare systems, and cloud services.

Each new interface increases the likelihood of misconfigurations, weak controls, or outdated

components. In most cases, Webportals and APIs are the ones mostly  targeted by malicious

actors. Web portals attacks are mainly  XSS, SQL Injection, DDoS while APIs weaknesses

targeted are mainly authentication, authorization, and data handling , often due to

misconfigurations or design flaws.

Refer to OWASP 2025 Top 10(https://owasp.org/Top10/2025/0x00_2025-Introduction/). 

Comprehensive Threat Modeling

Threat Modeling proactively focuses on identifying and understanding potential threats, their impact and mitigation. Threat Modelling Manifesto recommends four steps that should be put into consideration throughout the product lifecycle in order to proactively identify and mitigate potential risks. 

“At the highest levels, when we threat model, we ask four key questions:” 

i). What are we working on? - Understand the environment, components, and boundaries. In the Case of M-TIBA, the organization ought to understand what data they are handling, where it is located, who has access to it, it is encrypted and so on. 

ii). What can go wrong? - Identify potential threats to the scoped components. Use STRIDE methodology to uncover risks across the infrastructure.

iii). What are we going to do about it? -Determine the mitigation approaches to employ if the worst happens. 

iv). Did we do a good enough job? - Review and assess the effectiveness of the threat model. Continuously test the effectiveness of controls implemented. 

Threat modeling will help the organization identify potential problems with a system. Additionally, it will enable you to identify design and implementation problems that need to be mitigated at any point during the system's lifecycle. The output of the threat model, which is known as threats, will inform decisions that you might make in the following design, development, testing, and post-deployment phases.

Joke of the Day:

What did the moderator say to kick off the IT speed dating session?

“Singles, sign on!”    

See you on the Next Defence Marathon Episode.