A Healthcare Penetration Testing Case Study with Boston Children's Hospital

In July 2025, Boston Children's Hospital's GRUID team engaged Hackerest to perform an independent security assessment of the Global Research Unique Identifier (GRUID), a healthcare research application designed to support privacy-preserving patient identification across institutions and datasets.

GRUID involved a standalone desktop component, backend APIs, AWS-hosted resources, encryption and hashing workflows, custom license controls, and security requirements tied to the protection of PHI.

You can learn more about the project on the official FORCE Registry GRUID page.

The goal was not simply to run a vulnerability scan. The GRUID team needed to validate whether PHI remained protected throughout the full workflow, identify practical remediation steps before broader adoption, and obtain stakeholder-ready evidence that an independent security assessment had been performed.

Hackerest delivered a focused healthcare application penetration test covering the desktop application, backend API, AWS data workflow, authentication model, encryption logic, business logic, and HIPAA-aligned security expectations.

Outcome: a prioritized remediation roadmap, real-time finding visibility through the Hackerest platform, retest support for addressed issues, and stakeholder-ready attestation that the client team could use as evidence of independent security due diligence.

Note: This case study intentionally avoids disclosing sensitive implementation details, vulnerabilities, internal architecture information, or technical findings.

Assessment at a glance

Client review

"The Hackerest team was extremely helpful and detail-oriented throughout the process. We appreciated the consistent updates and attention to every aspect of our project scope. We will be sure to circle back to Hackerest for our next relevant project!"

Following the initial assessment and remediation work, the client continued evolving the application and returned to Hackerest to discuss additional security review of future updates.

For healthcare research software, this is the right security pattern: review the system before broader adoption, remediate the highest-priority issues, and reassess when the product changes.

Why this case matters

Many healthcare, research, and life sciences teams face the same challenge as GRUID: they need to prove that their application protects patient-related information, but their systems are too custom for a generic automated scan to provide meaningful assurance.

Applications that combine PHI, AWS-backed APIs, encryption workflows, custom identifiers, authentication logic, and desktop components require a deeper review.

For these systems, the real question is not only whether common vulnerabilities exist. It is whether the full workflow can withstand realistic abuse, protect patient data, and produce evidence that stakeholders can trust.

If you want broader context on how Hackerest approaches ongoing testing and remediation, you can also explore our PTaaS overview.

The challenge

The Global Research Unique Identifier was built to support a difficult healthcare research problem: helping identify the same patients across institutions or datasets without transmitting or storing raw patient identifiers.

That type of workflow creates a higher security bar than a standard web application. The system needs to protect PHI, preserve privacy, enforce access controls, and maintain trust in the logic used to generate and manage protected identifiers.

For Boston Children's Hospital's GRUID team, the key question was direct:

Could the application protect PHI throughout the full workflow, from the standalone desktop application to the AWS-hosted backend, while meeting the security expectations of a healthcare research environment?

Answering that question required more than automated scanning. Hackerest needed to review how the application behaved across the complete desktop-to-cloud workflow, including authentication, license enforcement, encryption, hashing, AWS-hosted resources, and business logic around protected identifiers.

Why Boston Children's Hospital's GRUID team chose Hackerest

The client needed more than a generic penetration test.

The application combined healthcare data protection requirements, AWS-backed infrastructure, custom authentication and license workflows, encryption logic, and a standalone desktop component. The assessment required a partner who could review the system as a complete workflow, not as isolated technical components.

Hackerest was chosen because the engagement required a team able to:

• Think like attackers while understanding healthcare data protection constraints
• Review AWS-backed application behavior and cloud security assumptions
• Test business logic that automated scanners would not understand
• Validate authentication, token, and license workflows
• Assess whether PHI could be exposed, inferred, or mishandled
• Give developers practical remediation guidance
• Produce stakeholder-friendly reporting and attestation

Through the Hackerest platform, the client could monitor findings in real time, review impact and remediation guidance as issues were identified, and track the assessment from discovery through validation.

This helped turn the engagement from a one-time security review into a practical remediation and assurance workflow.

What Hackerest validated

Hackerest structured the assessment around the main risk areas for a healthcare research application handling PHI.

PHI protection across the workflow

Hackerest reviewed whether patient-related information could be transmitted insecurely, stored inappropriately, inferred from generated identifiers, or exposed through implementation choices.

This included checks around data transmission and storage workflows, encryption at rest and in transit, public and private key encryption, hashing implementation, identifier generation logic, and potential unencrypted or un-anonymized data exposure.

Authentication, API, and access control security

The assessment reviewed whether users, tokens, sessions, and API interactions were properly protected.

This included backend API testing, authentication and token validation, session management, horizontal and vertical privilege escalation testing, rate limiting and abuse prevention, and security misconfiguration checks such as CORS, TLS, HTTP security headers, CSRF/SSRF, and vulnerable components where applicable.

AWS-hosted backend security

Hackerest reviewed the available AWS-related materials and cloud-facing implementation details to assess whether backend resources were configured and used securely.

This included AWS configuration review based on available materials, DynamoDB data protection review, Lambda function behavior, API exposure, backend authorization logic, IAM considerations, and other security-sensitive configuration patterns.

Desktop application hardening

Because GRUID included a standalone desktop component, Hackerest reviewed risks that are often missed in web-only assessments.

This included production build hardening, local configuration handling, local storage and memory leakage, interaction between the desktop client and backend APIs, and client-side assumptions that could affect backend security.

Business logic and license controls

Hackerest also tested the workflows specific to GRUID's operating model.

This included license key generation and enforcement, time-limited and usage-limited license behavior, attempts to bypass usage restrictions, MFA workflow validation, and abuse scenarios around protected identifier generation and access control.

What made this assessment different

A standard application scan can identify common technical vulnerabilities. It cannot tell a healthcare research team whether a custom PHI-handling workflow behaves safely under realistic misuse.

This engagement was not limited to common vulnerability classes such as injection, cross-site scripting, or broken authentication. The most important risks were tied to how the GRUID workflow was designed.

Privacy-preserving workflows need adversarial review

For GRUID, the security of the system depended on whether patient-related information could remain protected across the full workflow.

Hackerest reviewed whether data protection assumptions matched the actual behavior of the application, API, and backend. This included checking whether PHI could be transmitted insecurely, stored inappropriately, inferred from generated identifiers, or exposed through implementation choices.

Business logic was part of the attack surface

The application included custom license controls, protected identifier generation, authentication workflows, and security-sensitive logic that could not be meaningfully validated through automated scanning alone.

Hackerest tested whether those controls could be bypassed, abused, or manipulated in ways that would undermine the intended privacy and access control model.

Desktop applications introduce different risks

Because GRUID included a standalone desktop component, the assessment also considered local storage, configuration handling, build hardening, and the interaction between client-side logic and backend APIs.

This was important because desktop applications often introduce risks that are not present in web-only systems. Attackers may inspect local files, reverse engineer application behavior, or manipulate client-side workflows.

Cloud security depends on implementation details

AWS provides strong native security capabilities, but the final security posture depends on how APIs, IAM permissions, storage, encryption, and application logic are configured together.

Hackerest reviewed the available AWS-related materials and adapted the methodology where direct account access was not available, combining source material review, API behavior analysis, deployment logic review, and guided cloud configuration walkthroughs with the client.

This allowed the client to gain meaningful assurance without requiring invasive access to the production cloud environment.

How Hackerest's PTaaS model helped

For healthcare teams, a penetration test report delivered only at the end of the engagement can slow remediation. Developers often need context, prioritization, and clear next steps while the assessment is still active.

Through the Hackerest platform, Boston Children's Hospital's GRUID team could:

• Monitor findings in real time
• Review severity, impact, and remediation guidance
• Communicate directly during the test
• Track remediation status
• Access the final technical penetration test report
• Receive retest support for addressed issues
• Obtain a remediation attestation document for stakeholders

This shortened the feedback loop between discovery and remediation.

Instead of treating the pentest as a static report, the client could use it as an active remediation workflow.

The results

Boston Children's Hospital's GRUID team finished the engagement with more than a list of findings. They had a clear remediation roadmap, validation support, and stakeholder-ready evidence that an independent security assessment had been performed.

At the end of the engagement, Hackerest delivered:

• A detailed penetration test report with severity-rated findings
• Practical remediation guidance for each identified issue
• Technical proof-of-concept details where appropriate
• Real-time finding visibility through the Hackerest platform
• Retest support for addressed issues
• A stakeholder-friendly attestation document confirming the assessment scope and remediation status

This gave the client both technical guidance for remediation and a concise evidence package that could be shared with stakeholders without exposing sensitive implementation details.

For a healthcare research application, this distinction matters. The final deliverable was not only a technical report. It was a way to demonstrate security due diligence while protecting confidential information about the system.

Following the initial assessment and remediation work, the GRUID team continued evolving the application and returned to Hackerest to discuss additional security review of future updates. This continued collaboration helped keep security validation aligned with product changes rather than treating the penetration test as a one-time milestone.

Lessons for healthcare research teams

This engagement reinforced several important principles for healthcare application security.

Healthcare data protection is a full-workflow problem

Protecting PHI is not only about encrypting a database or enabling TLS.

Security depends on how data is collected, transformed, transmitted, stored, accessed, logged, and deleted. In healthcare research applications, even indirect exposure or weak identifier design can create privacy risk.

Business logic needs dedicated testing

License keys, protected identifiers, hashing workflows, and privacy-preserving logic cannot be fully assessed by automated scanners.

They require manual review and a clear understanding of how the application is supposed to work, how users interact with it, and how attackers might try to abuse assumptions in the workflow.

Security validation should evolve with the product

Healthcare applications change over time. New features, authentication changes, cloud updates, and workflow modifications can introduce new risks, especially when PHI or privacy-preserving logic is involved.

A one-time penetration test can provide valuable assurance at a specific point in time, but ongoing or follow-up reviews help teams keep security aligned with the product as it evolves.

Real-time reporting improves remediation speed

Giving teams access to findings as they are identified helps them start remediation earlier and reduces the delay between discovery and action.

For fast-moving healthcare technology teams, this can make the difference between a static report and an actionable remediation workflow.

How Hackerest helps healthcare technology teams

Hackerest helps healthcare, SaaS, and research teams validate the security of applications that handle sensitive workflows, patient-related information, cloud infrastructure, and compliance-driven requirements.

Our assessments can cover:

• Web applications
• APIs
• Cloud environments
• AWS architectures
• Desktop applications
• Authentication and authorization workflows
• Encryption and data protection controls
• Business logic and abuse scenarios
• Compliance-driven security requirements
• Remediation validation and attestation
• Follow-up reviews for new versions and product changes

For teams handling PHI or healthcare research data, Hackerest provides both technical depth and audit-ready deliverables that can be shared with internal stakeholders, customers, partners, and compliance teams.

How can you benefit from this?

If your team is building a healthcare, research, or life sciences application that handles PHI, encrypted data workflows, AWS-hosted APIs, or custom patient identification logic, a generic vulnerability scan is not enough.

Do not wait until a customer, partner, funder, or compliance review asks for proof that your system has been independently assessed.

Hackerest helps healthcare technology teams validate real security risks through manual penetration testing, cloud security review, business logic testing, remediation support, stakeholder-friendly reporting, and follow-up reviews as the product evolves.