Categories
Penetration Testing

7 Questions Security Leaders Should Ask After a Penetration Test

A penetration testing engagement shouldn’t end with a report. Here’s how security leaders can use penetration testing results to strengthen defenses and reduce real-world attack risk.

For many organizations, a penetration test feels like a finish line.

The report arrives. Vulnerabilities are documented. Leadership gets an update. Security teams move on to the next project.

But that mindset misses the point.

A penetration test is not a report. It’s a stress test of your security program. The real value isn’t in the list of vulnerabilities, it’s in the questions you ask afterward and the decisions you make because of them.

Security leaders who treat penetration testing as a compliance exercise get compliance-level results. Security leaders who treat it as a strategic learning opportunity get something far more valuable: insight into how attackers could actually compromise their organization.

Here are seven questions every security leader should ask after a penetration test.

These questions help organizations understand what to do after a penetration test, how to prioritize remediation, and how to turn testing results into meaningful security improvements.

1. Are We Actually Fixing the Vulnerabilities We Just Paid to Find?

This sounds obvious. It isn’t.

One of the most common outcomes of penetration testing is that findings quietly sit in a report while other priorities take over. Months later, the same issues appear again in the next engagement.

If your organization is paying for penetration testing, remediation must be treated as a structured process, not an informal task.

Ask:

  • Who owns each finding?
  • What is the remediation timeline?
  • How is progress being tracked?
  • How will we verify that the vulnerability is truly fixed?

Strong programs track penetration testing findings through risk registers, ticketing systems, or governance workflows. Mature teams also validate remediation through retesting, ensuring the vulnerability is actually closed. If your pen test firm doesn’t support you through this process, including retesting and remediation guidance, you may be with the wrong firm.

A penetration test only reduces risk when findings lead to measurable action.

2. Which Findings Reveal Failures in Basic Security Hygiene?

Penetration tests often expose something uncomfortable: many successful attacks don’t rely on exotic techniques. They rely on missing fundamentals.

Common examples include:

  • Unpatched systems
  • Weak credential policies
  • Excessive privileges
  • Misconfigured services
  • Poor asset inventory

When these appear in penetration test results, the problem isn’t the vulnerability itself. The problem is the process failure that allowed it to exist.

Security leaders should ask:

  • Why did this issue exist in the first place?
  • What process should have caught it?
  • How do we prevent this class of vulnerability going forward?

Penetration testing often reveals whether an organization has truly mastered the basics—or is still struggling with them.

3. Did Our Security Controls Detect the Attack Activity?

Preventing attacks is only part of the equation.

Modern security programs rely heavily on detection and response capabilities. Penetration testing provides an opportunity to validate whether those capabilities actually work.

After the test, ask:

  • Did our SIEM generate alerts?
  • Did our EDR detect suspicious activity?
  • Did our SOC investigate those alerts?
  • Were attackers able to move laterally without detection?

If penetration testers were able to upload web shells, escalate privileges, or pivot through the environment unnoticed, that reveals serious gaps in monitoring and response.

Penetration testing should answer an important question:

Do our defenses actually detect attacker behavior?

Your penetration testers should know what should and should not trigger detections, alerts, or logs in your environment and they should communicate that clearly to your team. If they cannot, you may want to reconsider who you are working with.

4. Could Attackers Combine These Vulnerabilities into a Real Attack Path?

Individual vulnerabilities rarely cause breaches.

What causes breaches is attack chains.

For example:

  • An exposed service reveals credentials
  • Those credentials allow access to an internal system
  • Privilege escalation leads to domain-level access

None of those vulnerabilities alone may seem catastrophic. Combined, they can lead to a full compromise.

Security leaders should evaluate penetration test findings through the lens of attack paths:

  • How could these weaknesses be chained together?
  • What is the most damaging path an attacker could take?
  • What would stop that attack?

This is where penetration testing becomes far more valuable than vulnerability scanning:

It shows how attackers actually operate.

5. Did the Test Reflect Our Real Threat Landscape?

Not all penetration tests are equally valuable.

Some engagements are heavily driven by compliance requirements rather than realistic attacker behavior.

Security leaders should critically evaluate whether the test actually reflected the threats their organization faces.

Ask:

  • Did the scope include cloud infrastructure?
  • Were identity systems tested?
  • Did the engagement cover SaaS platforms and external attack surfaces?
  • Were modern attacker techniques simulated?

If the test only evaluated a narrow portion of the environment, the results may provide false confidence.

A penetration test should reflect the actual ways attackers could target your organization today.

6. Are We Testing Often Enough?

Traditional penetration testing happens once per year.

In today’s environments, that’s increasingly difficult to justify.

Infrastructure changes constantly:

  • new systems are deployed
  • cloud environments expand
  • new applications are released
  • new vulnerabilities emerge

A penetration test provides insight into risk at a single moment in time.

Security leaders should ask:

  • How much has our environment changed since the test?
  • How quickly could new vulnerabilities appear?
  • Are we relying too heavily on point-in-time testing?

This is why many organizations are exploring continuous penetration testing and ongoing security validation approaches that provide more frequent insight into emerging risks. As environments evolve, security teams increasingly need ways to validate that their defenses still hold up against attacker techniques, not just once a year, but on an ongoing basis.

7. Can We Clearly Explain These Results to Leadership?

Technical vulnerability reports rarely resonate with executives.

Leadership wants to understand business risk.

Security leaders should translate penetration testing findings into clear outcomes:

  • Could these issues disrupt operations?
  • Could they expose sensitive data?
  • Could they lead to regulatory penalties?
  • What would the financial impact be?

The goal isn’t to alarm leadership—it’s to provide context for decision making.

Penetration testing results can help justify security investments, guide strategic initiatives, and demonstrate progress in strengthening defenses.

But only if the story is communicated clearly.

Penetration Testing Is Most Valuable When It Drives Continuous Improvement

Too many organizations treat penetration testing as a checkbox.

Run the test. File the report. Repeat next year.

That approach misses the real opportunity.

Penetration testing is most powerful when it becomes part of a continuous security improvement cycle, one where every engagement improves detection capabilities, strengthens security processes, and reduces real attack paths.

Security leaders who ask the right questions after a penetration test don’t just identify vulnerabilities.

They build stronger, more resilient security programs.

For organizations seeking deeper visibility into their exposure, penetration testing can provide critical insight into how attackers might exploit weaknesses, and where defenses need to evolve.


 

Penetration Testing FAQ

Security leaders often have additional questions about how penetration testing works and how to get the most value from it. Here are answers to a few of the most common ones.

What should you do after a penetration test?

After a penetration test, organizations should prioritize remediation of identified vulnerabilities, assign clear ownership for fixes, and track progress through a structured process. Security teams should also review whether their security controls detected the tester’s activity and evaluate how vulnerabilities could be combined into real attack paths. The goal is not just to fix individual findings, but to improve the overall security posture.

How often should penetration testing be performed?

Many organizations conduct penetration testing annually to satisfy compliance requirements. However, environments that change frequently—such as those using cloud infrastructure, SaaS platforms, or rapid software deployment—may require more frequent testing. Some organizations supplement traditional penetration testing with continuous testing or ongoing security validation to maintain visibility into new risks.

What is the difference between penetration testing and vulnerability scanning?

Vulnerability scanning uses automated tools to identify known security weaknesses across systems and applications. Penetration testing goes further by attempting to exploit those weaknesses in order to demonstrate how attackers could gain access, escalate privileges, or move through the environment. While vulnerability scans help identify potential issues, penetration testing reveals how those weaknesses could actually be used in an attack.

What should a good penetration testing report include?

A strong penetration testing report should clearly document vulnerabilities, evidence of exploitation, and the potential impact of each finding. It should also include practical remediation guidance and enough technical detail for security teams to reproduce and verify the issue. The best reports also highlight how vulnerabilities could be chained together into realistic attack paths.

Why is penetration testing important for cybersecurity?

Penetration testing helps organizations identify vulnerabilities and security gaps that attackers could exploit. By simulating real-world attack techniques, it reveals weaknesses in systems, configurations, and detection capabilities that automated tools may miss. This insight allows organizations to reduce risk and strengthen defenses before attackers discover the same weaknesses.

Categories
Cybersecurity Advisories

Phishing Campaigns Exploit Trusted MS Infrastructure

Threat actors are orchestrating highly targeted phishing campaigns that exploit Microsoft 365’s own trusted infrastructure to bypass traditional email security tools. Leveraging legitimate Exchange Online IPs and services like SharePoint, OneDrive, and Office 365-branded login portals, these campaigns are particularly effective at evading detection and deceiving end-users.

Key Tactics Observed Across Campaigns

Abuse of Microsoft IP Space

Attackers are sending phishing emails directly from compromised or attacker-owned Microsoft 365 tenants, making the emails appear legitimate to email security gateways and email filters. Since these emails originate from Microsoft’s IP ranges and pass SPF, DKIM, and DMARC, they’re often automatically trusted.

Use of Microsoft Services in Payload Delivery

Phishing emails frequently include links to:

  • SharePoint-hosted documents with embedded phishing links
  • OneDrive URLs leading to weaponized files or credential-harvesting sites
  • Office 365 login pages that look pixel-perfect but harvest credentials

These links are hosted on Microsoft domains, which makes them especially hard to detect and block. URLs such as 1drv.ms, sharepoint.com, and *.onmicrosoft.com are widely seen in these campaigns.

Targeting and Credential Theft

The campaigns are increasingly targeting high-value users—like executives, financial officers, and IT administrators. Once credentials are harvested, attackers often:

  • Pivot within the organization
  • Launch internal phishing using trusted email threads
  • Access sensitive data or set up OAuth apps for persistent access

Campaign Variants Identified

  • “Fax” or “Voicemail” notifications leading to credential harvesting pages
  • “Encrypted document” or “shared invoice” baits, hosted on SharePoint
  • OAuth abuse where victims grant permissions to malicious apps that maintain access without re-authentication

Why This Works So Well

  • Microsoft infrastructure is trusted by default in many organizations
  • Authentication headers are valid (SPF, DKIM, DMARC all green)
  • URL scanning often skips known-good domains
  • Users are trained to trust Microsoft-branded emails

What Organizations Should Do

Harden Microsoft 365

  • Enable Safe Links and Safe Attachments
  • Use Mail Flow (Transport) Rules to flag external use of Microsoft domains
  • Configure Defender for Office 365 with aggressive anti-phishing and impersonation policies

Educate End Users

  • Provide real-world examples of SharePoint/OneDrive abuse
  • Train users to treat “legitimate-looking” Microsoft prompts with caution
  • Highlight red flags like unexpected MFA requests or login prompts after clicking shared files

Monitor for Suspicious OAuth Activity

  • Review App registrations and third-party app consent
  • Enable consent governance policies and block risky app behaviors

Leverage Threat Intelligence & Hunting

  • Monitor Microsoft logs for anomalous login patterns
  • Watch for emails with links to sharepoint.com, onmicrosoft.com, or 1drv.ms
  • Utilize advanced hunting queries in Defender or Sentinel

These attacks demonstrate that relying solely on default trust settings is no longer a viable security strategy. Organizations must fundamentally shift their mindset, treating even familiar Microsoft services with a degree of skepticism. A proactive approach, combining technical controls with user awareness, is essential to effectively defend against these sophisticated and rapidly evolving phishing tactics.

Categories
Compliance > HIPPA | Information Security Compliance > Privacy

FTC and HHS Guidance for Online Tracking Technologies by HIPAA Covered Entities and Business Associates

On January 7, 2021, the Department of Health and Human Services (HHS) Office for Civil Rights (OCR) published guidance on the use of tracking technologies by covered entities under the Health Insurance Portability and Accountability Act (HIPAA). The guidance, titled “FAQs on HIPAA and Health Websites and Social Media,” addresses various issues related to the use of tracking technologies, including cookies, beacons, and other similar technologies.

The guidance emphasizes that covered entities must ensure that their tracking technologies comply with HIPAA’s Privacy, Security, and Breach Notification Rules. Covered entities must also provide clear and conspicuous notice to individuals about their use of tracking technologies and obtain their affirmative consent before using such technologies.

The guidance also highlights the importance of properly securing any data collected through tracking technologies to protect against unauthorized access, use, or disclosure. Covered entities should implement appropriate security measures, such as encryption, access controls, and monitoring, to safeguard this data.

In addition, the guidance addresses several specific issues related to tracking technologies, such as:

  • The use of cookies for targeted advertising: Covered entities must obtain affirmative consent before using cookies for targeted advertising. They must also allow individuals to opt out of such advertising.
  • The use of beacons to track individuals’ locations: Covered entities must obtain affirmative consent before using beacons to track individuals’ locations. They must also provide clear notice to individuals about the purpose of such tracking and the types of data that will be collected.
  • The use of third-party tracking technologies: Covered entities must ensure that any third-party tracking technologies they use are compliant with HIPAA. They must also enter into a business associate agreement with any third party that has access to protected health information (PHI).

While this is not new information, the details of a $7.8 million fine being leveraged against BetterHelp yesterday, March 2, 2023 signal a shift in enforcement.

“The Federal Trade Commission has issued a proposed order banning online counseling service BetterHelp, Inc. from sharing consumers’ health data, including sensitive information about mental health challenges, for advertising. The proposed order also requires the company to pay $7.8 million to consumers to settle charges that it revealed consumers’ sensitive data with third parties such as Facebook and Snapchat for advertising after promising to keep such data private.” 1

There had, up until now, been some ambiguity regarding what constituted PHI and PII (Protected Health Information and Personal Identifiable Information). The most notable example of this is the following example:

If a person visits an informational site about pregnancy, and the covered entity gathers information such as IP Address, Email, Location Data, etc. – that information is considered PHI/PII. It will be covered under HIPAA’s privacy guidance. This is true even if the site visitor does not have a relationship with the covered entity.

This is a significant change in previously understood and enforced HHS guidance. As such, organizations in the healthcare vertical should review all applications, web, and mobile, for tracking technology and evaluate what it is gathering and it if violates the HHS guidance.

SecurIT360 has put together a package that assists covered entities in evaluating the compliance, reputational, and technical risk associated with tracking technology across their application portfolio.

This approach can be summarized as follows:

  • Perform an in-depth technical analysis of the HHS guidance for HIPAA-covered entities.
    • Tracking on user-authenticated webpages
    • Tracking on unauthenticated webpages
    • Tracking within mobile apps
    • HIPAA compliance obligations for regulated entities when using tracking technologies
  • Establish a testing protocol that evaluates those requirements in addition to standard web security standards (OWASP WTG v4.2).
  • Create a project plan for the execution of this testing protocol as it is applied to all domains in scope.
  • Perform testing.
  • Present a comprehensive technical report that outlines detailed risk and remediation for issues found.
  • Assist with establishing a remediation plan.
  • Perform validation of remediation.
  • Issue a final report reflecting the residual risk after remediation.

For reference, we have included some additional scenarios that are both discovered and solved by this approach.

  • Unauthorized access to PHI: If tracking technology is used to monitor the location or movements of individuals in a healthcare setting, it could potentially provide access to PHI that should be kept confidential. For example, if a hospital uses a tracking system that shows the location of patients or staff members, but the system is not properly secured, unauthorized individuals could potentially gain access to PHI.
  • Unintentional disclosure of PHI: If tracking technology is used to monitor the location or movements of individuals in a healthcare setting, there is a risk that PHI could be unintentionally disclosed. For example, if a tracking system is used to monitor the location of patients, and the system is not configured properly, it could potentially display PHI in a public area or to unauthorized individuals.
  • Improper disposal of PHI: If tracking technology is used to collect PHI, there is a risk that the data could be improperly disposed of. For example, if a tracking system is used to monitor the location of patients or staff members, and the system is not properly secured or disposed of, PHI could potentially be accessed by unauthorized individuals.
  • Use of PHI for marketing purposes: If tracking technology is used to collect PHI, there is a risk that the data could be used for marketing purposes without proper consent. For example, if a tracking system is used to monitor the location of patients, and the data collected is used for marketing purposes without proper consent, this would be a violation of HIPAA.

Failure to obtain proper consent: If tracking technology is used to collect PHI, proper consent must be obtained from individuals before their data can be used. For example, if a tracking system is used to monitor the location of patients, but the patients are not properly informed of the data collection or their rights, this would be a violation of HIPAA.

References:

1: https://www.ftc.gov/news-events/news/press-releases/2023/03/ftc-ban-betterhelp-revealing-consumers-data-including-sensitive-mental-health-information-facebook