DEV Community: Cyberoptic Security Ltd

Security in CI/CD Pipelines

Cyberoptic Security Ltd — Mon, 15 Sep 2025 02:18:04 +0000

This guide covers the essential security checks every small team should use. Most of these tools are free or cheap, and they run automatically in the background without disrupting your workflow.

Building security into your CI/CD pipeline means catching obvious problems before they reach production, reducing the risk of costly incidents and emergency patches. There are a variety of security checks that should be done before deploying code, and implementing these checks in an automated pipeline is an ideal way to streamline your security testing process.

beep boop

Static Code Scanning (SAST)

Static code scanning analyses source code for security vulnerabilities without executing it. SAST tools identify common security flaws like SQL injection, cross-site scripting (XSS), buffer overflows, and hardcoded secrets.

Finding security bugs during development is much less of a headache than finding them in production. SAST provides immediate feedback during code review, helping developers learn secure coding patterns while preventing vulnerabilities from entering the codebase.

Tool options:

SonarQube Community Edition: Java, C#, JavaScript, TypeScript, Python, PHP, Go, Kotlin, Ruby, Scala, XML
Semgrep: Python, Java, JavaScript, TypeScript, Go, Ruby, C, C++, PHP, C#, Kotlin, Scala
CodeQL: JavaScript, TypeScript, Python, Java, C#, C, C++, Go, Ruby
Bandit: Python (specialised for Python security issues)
ESLint with security plugins: JavaScript, TypeScript
SpotBugs with Find Security Bugs: Java, Scala, Groovy
Clang Static Analyzer: C, C++, Objective-C
Cppcheck: C, C++
Brakeman: Ruby on Rails
gosec: Go

Implementation approach: Run SAST scans on every pull request. Start with high-severity rules only to avoid alert fatigue. Most tools integrate directly with major CI platforms through plugins or simple command-line execution.

Modern SAST tools can scan typical codebases in under 5 minutes. Configure incremental scanning to analyse only changed code for faster feedback loops.

Dynamic Application Security Testing (DAST)

DAST tools test running applications by simulating attacks against live deployments. Unlike static analysis, DAST discovers runtime vulnerabilities, configuration issues, and logic flaws that only manifest when the application is actually running.

Benefits for development teams: DAST catches authentication bypasses, server misconfigurations, missing security headers, and business logic vulnerabilities that static analysis misses. It validates that security controls work correctly in your actual deployment environment, not just in theory.

Tool landscape:

Open source: OWASP ZAP (comprehensive but slower), Nuclei (fast template-based scanning)
Commercial: Burp Suite Professional, Rapid7 AppSpider
Cloud-based: Detectify, HackerOne's pentest platform
Platform-integrated: AWS Inspector, Azure Security Center

Implementation approach: Run DAST against staging environments after deployment. Since scans take 15-60 minutes depending on application size, consider running them nightly rather than on every commit. Focus initial efforts on authentication endpoints, user input forms, and API endpoints.

Modern applications often have extensive APIs that need dedicated testing. Tools like Postman's security scanning or REST-specific DAST tools can provide better coverage than traditional web application scanners.

Software Composition Analysis (SCA) and Dependency Scanning

SCA tools analyse third-party dependencies and open-source components for known vulnerabilities, license compliance issues, and outdated packages. Modern applications typically use hundreds of dependencies, making manual tracking impossible.

Dependency vulnerabilities represent 85% of security holes in modern applications. SCA prevents the integration of components with known CVEs and helps maintain compliance with open-source licensing requirements.

Tool ecosystem:

Language-specific: npm audit (Node.js), pip-audit (Python), bundler-audit (Ruby)
Universal: Snyk (freemium), OWASP Dependency-Check (free), Trivy (free)
Platform-integrated: GitHub Dependabot, GitLab dependency scanning, Azure DevOps
Enterprise: Sonatype Nexus, JFrog Xray, WhiteSource (now Mend)

Implementation approach: Run SCA scans after dependency resolution but before deployment. Configure tools to fail builds on critical vulnerabilities while allowing lower-severity issues with appropriate business justification. Combine with automated dependency update tools like Dependabot or Renovate for streamlined patching workflows.

Modern SCA tools provide vulnerability prioritisation based on actual usage (reachability analysis), automated remediation suggestions, and integration with development workflows through pull request comments.

Secrets Detection and Management

Secrets scanning tools detect accidentally committed credentials, API keys, certificates, and other sensitive data in source code, configuration files, and build artifacts. These tools use pattern matching, entropy analysis, and machine learning to identify potential secrets.

Hardcoded secrets in repositories create permanent security liabilities. Even private repositories can be compromised, and secrets in git history are difficult to fully remove. Automated detection prevents these credentials from entering version control.

Detection tools and platforms:

Open source: GitLeaks, TruffleHog, detect-secrets
Platform-integrated: GitHub secret scanning, GitLab secret detection, Azure DevOps credential scanner
Enterprise: GitGuardian, Cycode, SpectralOps
Pre-commit hooks: git-secrets, pre-commit framework with secrets plugins

Implementation approach: Deploy secrets detection at multiple points: pre-commit hooks for immediate developer feedback, CI pipeline scans for every code change, and periodic repository history scans for comprehensive coverage. Configure different sensitivity levels for different secret types.

Modern secrets management platforms can automatically rotate compromised credentials when detected. Tools like HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault provide APIs for programmatic secret rotation and can integrate with CI/CD pipelines.

Container Image Security Scanning

Container scanning analyses Docker images and other container formats for OS-level vulnerabilities, malicious packages, configuration issues, and compliance violations. This includes both base image components and application-specific additions.

Container images often contain hundreds of system packages, any of which may have known CVEs. Scanning identifies vulnerable packages, misconfigurations like running as root, exposed sensitive files, and compliance violations against security benchmarks like CIS Docker Benchmark.

Scanning tools and integration:

Open source: Trivy (comprehensive and fast), Grype, Clair
Cloud provider: AWS ECR image scanning, Azure Container Registry scanning, Google Container Analysis
Commercial: Snyk Container, Aqua Security, Twistlock (now Prisma Cloud)
Registry-integrated: Docker Hub vulnerability scanning, Red Hat Quay

Implementation approach: Implement multi-stage scanning: scan base images during selection, scan intermediate build images, and scan final runtime images before registry push. Consider both OS-level and application-level vulnerability detection.

Modern container scanners provide specific remediation guidance, including base image upgrade recommendations, package updates, and configuration fixes. Integration with image build pipelines enables automatic rebuilds when new vulnerabilities are discovered in base images.

Infrastructure as Code (IaC) Security Scanning

IaC security tools analyse infrastructure configuration files (Terraform, CloudFormation, Kubernetes manifests) for security misconfigurations, compliance violations, and policy breaches before deployment.

Configuration risk management: Infrastructure misconfigurations cause 65% of cloud security incidents. IaC scanning prevents deployment of overly permissive security groups, unencrypted storage, public cloud resources, and non-compliant configurations.

Tool landscape by platform:

Terraform: tfsec, Checkov, Terrascan, Snyk Infrastructure as Code
CloudFormation: cfn-nag, Stelligent cfn_nag, Checkov
Kubernetes: kube-score, Polaris, Falco, OPA Gatekeeper
Multi-platform: Checkov, Prisma Cloud, Bridgecrew (now Prisma)

Integration approach: Run IaC scans on infrastructure pull requests before merge, during CI/CD pipeline execution before deployment, and periodically against live infrastructure for drift detection. Configure different rule sets for development, staging, and production environments based on risk tolerance.

Many IaC scanners support industry frameworks like CIS Benchmarks, NIST, SOC 2, and GDPR compliance requirements. Custom policy creation enables organisation-specific security requirements and governance rules.

CI/CD Pipeline Security Platforms

Different CI/CD platforms offer varying levels of built-in security capabilities and third-party integrations. Understanding platform-specific features helps optimise your security implementation approach.

GitHub Actions and GitHub Advanced Security

Built-in Security Features:

CodeQL for semantic code analysis (free for public repos, paid for private)
Secret scanning with automatic token revocation for popular services
Dependency vulnerability alerts with Dependabot integration
Security advisories and vulnerability database

Third-party Integrations:

Extensive action marketplace includes security tools like Snyk, Semgrep, OWASP ZAP, and container scanners
Actions can be configured with specific security policies and failure conditions

Enterprise and Compliance Features:

GitHub Advanced Security provides code scanning, secret scanning, and dependency review for private repositories
Detailed security dashboards and compliance reporting

Platform-specific Considerations:

Free security features for public repositories make it attractive for open source projects
Tight integration with GitHub's development workflow and pull request process

GitLab CI/CD

Built-in Security Features:

Integrated SAST, DAST, dependency scanning, container scanning, and license compliance
Results integrate directly into merge request workflows
Built-in container registry with automated vulnerability scanning

Third-party Integrations:

Comprehensive security scanner integrations available through GitLab's CI/CD configuration
API-based integrations with external security tools and platforms

Enterprise and Compliance Features:

Centralised security dashboard with vulnerability management across projects
Security metrics and compliance tracking with policy management
Organisation-wide security requirements enforcement

Platform-specific Considerations:

All-in-one DevOps platform reduces tool sprawl
Policy enforcement for image promotion between environments
Strong focus on DevSecOps workflow integration

Azure DevOps

Built-in Security Features:

Native integration with Microsoft Defender for DevOps
Security findings across the development lifecycle with threat intelligence prioritisation
Built-in compliance tracking and audit logging

Third-party Integrations:

Azure DevOps marketplace includes security extensions for various scanning tools
Pipeline templates for common security workflows
Integration with Azure ecosystem security services

Enterprise and Compliance Features:

Policy enforcement with integration to Azure Policy for infrastructure governance
Comprehensive audit logging and compliance tracking capabilities
Enterprise-grade access control and security management

Platform-specific Considerations:

Strong integration with Microsoft ecosystem and Azure cloud services
Enterprise-focused with robust governance and compliance features
Seamless integration with existing Microsoft toolchains

Jenkins

Built-in Security Features:

Basic pipeline security through Jenkinsfile configuration
Built-in user authentication and authorisation mechanisms
Pipeline approval workflows for sensitive operations

Third-party Integrations:

Extensive plugin library includes OWASP Dependency-Check, SonarQube Scanner, and container scanning tools
Wide variety of security scanner integrations available through plugins
Integration platforms and reporting tools through plugin ecosystem

Enterprise and Compliance Features:

Pipeline-as-code security enforcement through pipeline libraries
Shared security scripts and templates for consistency
Audit logging capabilities through plugins

Platform-specific Considerations:

Self-hosted platform requires additional attention to server hardening
Plugin security updates and management responsibility
Greater flexibility but increased security management overhead compared to cloud-hosted platforms

Cloud-Native CI/CD (AWS CodePipeline, Google Cloud Build)

Built-in Security Features:

Serverless security scanning options that scale automatically
Integration with cloud-native secrets management services
Automated security scanning without infrastructure management overhead

Third-party Integrations:

Seamless integration with cloud security services like AWS Inspector and Google Binary Authorization
API-based integrations with cloud marketplace security tools
Native integration with cloud provider security ecosystems

Enterprise and Compliance Features:

Integration with cloud compliance frameworks and governance tools
Comprehensive audit logging for regulatory requirements
Cloud-native policy enforcement and security governance

Platform-specific Considerations:

Serverless architecture reduces infrastructure security management overhead
Deep integration with cloud provider security and compliance services
Scaling and cost considerations tied to cloud provider pricing models
Platform lock-in considerations for multi-cloud strategies

Pipeline Access Control and Supply Chain Security

CI/CD pipelines require privileged access to source code, build environments, and production systems, making them high-value targets for attackers. Pipeline security focuses on protecting the build and deployment process itself.

Access control implementation:

Service accounts with least-privilege permissions for automated processes
Multi-factor authentication requirements for all human pipeline access
Role-based access control for pipeline configuration changes
Short-lived, rotatable tokens instead of static credentials
Network segmentation between build and production environments

Supply chain attack prevention: Modern software supply chain attacks target the build process to inject malicious code. Protection strategies include:

Dependency pinning with hash verification
Private registries for internal dependencies and build tools
Build environment isolation and reproducible builds
Software Bill of Materials (SBOM) generation for transparency
Signature verification for downloaded tools and dependencies

Pipeline monitoring requirements:

Audit logging for all pipeline configuration changes
Alerting on failed security scans or unusual build patterns
Monitoring for unauthorised access to build environments
Tracking deployment success rates and rollback frequency
Integration with security incident response procedures

Implementation Strategy

Implement security scanning incrementally to avoid overwhelming development workflows. Start with the highest-impact, lowest-effort security checks and expand coverage based on your team's capacity and risk profile.

Foundation security measures: Secrets scanning and dependency vulnerability detection provide immediate security value with minimal configuration overhead. Most CI/CD platforms include these capabilities natively or through simple marketplace integrations.

Static analysis integration: SAST tools for your primary programming languages offer significant vulnerability reduction with moderate setup effort. Configure rule sets conservatively initially to minimise false positives and developer friction.

Container and infrastructure scanning: If your team uses containerisation or infrastructure-as-code, these scans prevent configuration-based security issues. Implementation complexity varies by platform but typically requires only pipeline configuration changes.

Dynamic testing and advanced monitoring: DAST scanning and comprehensive security monitoring require more setup effort but provide coverage for runtime vulnerabilities and production security events that other tools miss.

Gradual expansion approach: Add one security check type at a time, allowing your team to adapt to new tools and processes. Focus on tool tuning and workflow integration before introducing additional scanning capabilities. This approach ensures security measures enhance rather than impede development productivity.

Balancing Automation with Manual Security Review

Automated scanning handles consistent, repeatable security checks, while manual review addresses complex business logic, architectural decisions, and contextual security considerations that tools cannot evaluate.

Code review security integration: Incorporate security considerations into existing code review processes. Review authentication mechanisms, input validation, error handling, and privilege escalation paths during normal peer review workflows.

Periodic security assessments: Schedule quarterly security reviews or external penetration testing to identify blind spots in automated coverage. These assessments validate that security controls work effectively in practice, not just in theory.

Security incident response: Establish clear procedures for handling security findings from both automated tools and manual review. Define severity levels, response timelines, and escalation paths for different types of security issues.

Continuous security improvement: Use security findings as learning opportunities. Conduct post-incident reviews to identify process improvements, tool configuration changes, or additional security measures needed to prevent similar issues.

Staying Current with Security Threats

Security threats evolve constantly. Maintain awareness without getting overwhelmed by focusing on actionable intelligence relevant to your technology stack and threat model.

Information sources:

Platform-specific security advisories (GitHub Security Lab, GitLab Security)
Language and framework security announcements
Cloud provider security bulletins
OWASP project updates and vulnerability databases

Tool maintenance: Keep security scanning tools updated with latest vulnerability signatures and detection rules. Many tools provide automatic updates or notifications when new security rules become available.

Learning from incidents: When security issues are discovered, conduct brief post-mortems to identify process improvements, tool configuration changes, or additional security measures needed to prevent recurrence.

Industry best practices: Follow security researchers and practitioners in your technology areas. Security conferences, blogs, and communities provide insights into emerging threats and defensive techniques.

Conclusion

Integrating security into CI/CD pipelines provides teams with security capabilities without requiring dedicated security staff. Automated security scanning catches common vulnerabilities early in the development cycle, reducing remediation costs and deployment risks.

Implementation principles:

Start with platform-native security features before adding external tools
Prioritise high-impact security checks with low false positive rates
Implement scanning incrementally to avoid disrupting development workflows
Configure tools for fast feedback and minimal developer friction
Balance automation with manual security review for comprehensive coverage

Measurable security improvements: Teams implementing comprehensive pipeline security typically see large reduction in security vulnerabilities reaching production, faster incident response times, and improved compliance with security frameworks. The initial investment in tool setup and configuration pays dividends through reduced security incidents and emergency patches.

Long-term benefits: Beyond immediate vulnerability detection, pipeline security creates a culture of security awareness within development teams. Developers learn secure coding practices through tool feedback, understand common vulnerability patterns, and build security considerations into architectural decisions.

Modern CI/CD platforms make security integration straightforward with built-in scanning capabilities, extensive tool marketplaces, and detailed documentation. Small teams can achieve robust security posture by leveraging these platforms effectively and implementing security checks systematically.

https://www.cyberoptic.co.nz/

SharePoint “ToolShell” Vulnerability (CVE-2025-53770)

Cyberoptic Security Ltd — Sun, 14 Sep 2025 21:26:49 +0000

TL;DR

This is a critical SharePoint server bugthat lets attackers break in without authenticating and gain admin access to the system. This currently only affects SharePoint on-premise, and SharePoint online in M365 is not impacted.

In practice, an unauthenticated POST to the SharePoint ToolPane.aspx page (with a spoofed Referer header) bypasses login checks, allowing a malicious payload to run on the server.

Attackers can upload a web shell, extract the site's secret machine keys (ASP.NET ValidationKey/DecryptionKey), and use those keys to forge trusted ViewState or authentication tokens.

In short, they gain full access to SharePoint content (files, configs, internal APIs) and persistent control that survives normal fixes. The bug has been actively exploited in the wild, so urgent patching and follow-up are needed.

SharePoint is having a bad day

Exploit Chain

The "ToolShell" attack is an exploit chain combining two SharePoint flaws CVE-2025-53771/53770 into unauthenticated RCE. These were previously identified as CVE-2025-49706/49704 and patched however, bypasses for these have since been discovered. In simplified terms, attackers do the following:

Authentication bypass via ToolPane.aspx: The attacker sends a specially crafted POST request to

/_layouts/15/ToolPane.aspx?DisplayMode=Edit

with the HTTP Referer header set to /_layouts/SignOut.aspx. This tricks SharePoint into trusting the request without a real login. In effect, the attacker gains anonymous admin access to the ToolPane editor. (This bypass was patched as CVE-2025-53771.)

RCE via insecure deserialization:With access to ToolPane.aspx, the attacker submits a malicious payload in the POST body. This payload uses an ASP.NET <asp:UpdateProgress> and a nested *Scorecard:ExcelDataSet*element whose *CompressedDataTable *attribute contains attacker-controlled data. SharePoint's Data Web Part (DWP) parser deserializes that *CompressedDataTable *on the server, triggering code execution. In practice this means the attacker can execute arbitrary PowerShell or other commands as the SharePoint process (w3wp.exe). For example, researchers observed the attacker's payload run *whoami *and write it to a web-accessible file to confirm code execution.
Web shell and machine-key theft:The RCE allows the attacker to upload a web shell (commonly named spinstall0.aspx*or similar) into the SharePoint layouts folder. Using this shell or the existing context, the attacker reads the server's ASP.NET configuration (web.config), specifically the **section. The *ValidationKey *and *DecryptionKey *are used by ASP.NET to sign ViewState and encrypt auth tokens. The web shell code typically uses *System.Web's MachineKeySection to dump these keys to the attacker. With those keys known, the attacker has the server's cryptographic secrets.
Persistence via forged ViewState/cookies:Armed with the stolen keys, the attacker can now forge valid ASP.NET payloads. They can craft a malicious __VIEWSTATE(or authentication cookie) and sign it so the server will accept it as legitimate. For example, tools like ysoserial.net can generate a new deserialization payload encoded into ViewState using the stolen ValidationKey. This grants the attacker essentially backdoor access, even if the original exploit is closed, the attacker can re-enter by sending new signed payloads that the patched server will trust. In effect, they maintain authenticated RCE without triggering logins or alerts.
Post-exploitation and privilege escalation:Once code execution is achieved, attackers typically spawn a command shell on the host. In observed cases the SharePoint worker process (w3wp.exe) launches cmd.exe and then powershell.exe with encoded arguments to run their scripts. From this position, attackers can use Windows tools to gain higher privilege. For instance, they might use PsExec(with the -s option) or WMI tools (Impacket's wmiexec.py) to run processes as the LOCAL SYSTEM account. With SYSTEM-level code execution on the SharePoint server, attackers have full control: they can disable antivirus, dump AD credentials, or move laterally across the network. (Microsoft reports that after exploiting SharePoint, actors often use PsExec and Impacket/WMI to execute further commands as SYSTEM -- effectively a total takeover.)

How It Works "Under the Hood"

This exploit chain abuses normal ASP.NET mechanisms in unexpected ways:

ASP.NET ViewState:SharePoint pages use the __VIEWSTATE*hidden field to preserve state. By default, ASP.NET signs (and optionally encrypts) *ViewState with a MAC using the server's ValidationKey (from ). In normal use, this prevents tampering of page data. In ToolShell, the attacker injects a ViewState-like payload indirectly via the DWP (MSOTlPn_DWP) as described above. After stealing the keys, they can create entirely new ViewState blobs that the server will accept as valid.
ASP.NET machineKey:The *element in *web.config*defines two critical values: the *ValidationKey(for HMAC signing) and the DecryptionKey (for any encryption). ASP.NET uses these keys to

(a) sign VIEWSTATE,

(b) encrypt/decrypt FormsAuth or FedAuth cookies, and

(c) protect any other secure state.

When the attacker steals the keys, they can forge new authentication cookies (bypassing login) and viewstate, and even decrypt any data previously protected. For example, Cloudflare notes that with the machine keys an attacker "can independently forge authentication tokens and VIEWSTATE payloads" that survive normal mitigations. Simply rebooting the server or patching won't invalidate requests signed with the old key.
Data Web Part deserialization:SharePoint's ToolPane.aspx is meant for site admins to add/edit web parts. It processes a "Data Web Part" (DWP) specification from form data. The attacker abuses a legitimate PerformancePoint web control (Scorecard:ExcelDataSet) that has a property (CompressedDataTable) which ASP.NET deserializes directly. Hazcod's PoC explains that by setting *to base64-compressed XML, the SharePoint DWP parser will invoke .NET deserialization on it. In that payload, the attacker can embed a *System.DelegateSerializationHolder*or similar gadget that runs code. This is the core insecure deserialization: SharePoint never expected untrusted data here, and thus executes the serialized object unchecked. (The key form parameters are *MSOTlPn_Uri-- a fake control path -- and MSOTlPn_DWP -- the injected ASP.NET snippet.)
Referer check bypass: The authentication bypass itself was a patch bypass. SharePoint originally intended to block direct ToolPane access by checking the Referer header against legitimate pages. The exploit sends a Referer of /layouts/SignOut.aspx which, due to a logic bug, caused the check to succeed. In other words, SharePoint thought the user was signing out and then immediately editing ToolPane, and did not enforce login. Microsoft patched this logic, but attackers reversed it into the new CVE-53771 bypass.

Why It Remains Dangerous After Patching

If an attacker has already exploited the vulnerability before patching, the danger does not go away with a software update. This is because the attacker steals long-term secrets (the machine keys) during the attack. With those keys in hand, the attacker can forge new exploits or tokens at any time in the future, even after the CVE is patched. In short, the patch closes the vulnerability, but it does not change the stolen keys. Analysts warn that attackers "take the server's cryptographic machine keys" so they can persist beyond normal fixes. With the old keys, they can continue to generate authenticated ViewState payloads or cookies that the server will trust.

Put simply: a patched system that was already breached will still trust requests signed with the old ValidationKey/DecryptionKey. Rebooting or removing the web shell is not enough. Only rotating those keys, or completely rebuilding the server, can invalidate the attacker's hold. Until then, the attacker effectively has a master key to the server.

Mitigation and Hardening

Once patched, administrators must assume any exposed SharePoint system may have already been compromised. Below are the key steps needed to properly remediate and secure affected systems:

### Apply Microsoft's security updates

Install the July 2025 cumulative updates for SharePoint:

SharePoint Subscription Edition: KB5002768

SharePoint Server 2019: KB5002754

SharePoint Server 2016: KB5002760

These updates patch both CVE-2025-53770(RCE) and CVE-2025-53771(auth bypass), closing the main vulnerability chain exploited in the wild Microsoft Security Blog.

2. Enable AMSI and Defender

Microsoft recommends enabling AMSI (Antimalware Scan Interface) in SharePoint to inspect potentially malicious content. Ensure Microsoft Defender Antivirusis installed and active on the SharePoint server. This increases the chance of detecting web shells or suspicious ViewState payloads Microsoft Blog.

3. Rotate ASP.NET Machine Keys

The exploit allows attackers to steal the *section from *web.config, granting them the ability to forge authentication cookies or ViewState payloads. Simply patching will not revoke that access.

You must rotate these keys to invalidate any existing tokens. Microsoft recommends doing this via Central Admin:

Central Admin > Monitoring > Review job definitions > Run "Machine Key Rotation"

Then restart IIS (iisreset) to flush cached values Cloudflare, Microsoft Blog, and TrustedSec.

US-CERT and CISAexplicitly advise rotating the keys before and after applying updates.

4. Check for Signs of Compromise

Because attackers may already be inside the system, look for known indicators of compromise (IOCs):

Presence of suspicious files like:
- /layouts/15/spinstall0.aspx(or variants: spinstall1.aspx, debug_dev.js)
- Unusual scripts or executables in the SharePoint *LAYOUTS *folder
POST requests to /layouts/15/ToolPane.aspx?DisplayMode=Edit with odd Referer values
PowerShell execution or encoded command lines launched by w3wp.exe
Unexpected outbound connections or file writes from SharePoint directories

These indicators have been confirmed by Horizon3.ai, Cloudflare, and Hazcod's analysis. Also review Windows Event Logs and Defender logs for signs of tampering.

5. Invalidate All Authentication Tokens

Once the machine keys are rotated, all existing ViewState, FedAuth cookies, and FormsAuth tokens are invalidated. This ensures any attacker-forged tokens no longer work.

You should also:

Invalidate current user sessions
Require re-authentication for all users
Change credentials for any privileged SharePoint service accounts
Reboot the server after rotation to enforce the new keys Microsoft

6. Limit Exposure and Tighten Permissions

Remove internet exposure for outdated SharePoint versions (e.g. 2013 or earlier) as these are no longer supported NCSC NZ, CISA.
Apply the principle of least privilege to farm and service accounts.
Remove unnecessary admin users and test accounts from the SharePoint site.
Use firewall rules or a WAF to limit access to SharePoint's */layouts/15/ToolPane.aspx *endpoint where practical.

By combining the patch, detection, key rotation, IOC checking, and token invalidation, you significantly reduce the chance that attackers can maintain access using the stolen secrets. A reboot alone is not sufficient. These steps are consistent with best practice guidance from Microsoft, CISA, Cloudflare, VulnCheck, and NCSC NZ.

Official Security Advisories

Microsoft Security Update Guide
- CVE-2025-53770 (Remote Code Execution): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770
- CVE-2025-53771 (Auth Bypass): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53771
Microsoft Blog -- Immediate mitigation and response guidance

https://www.microsoft.com/en-us/security/blog/2025/07/09/investigating-exploitation-of-sharepoint-cve-2025-53770
Microsoft KB Articles for Patching
- Subscription Edition: KB5002768
- SharePoint 2019: KB5002754
- SharePoint 2016: KB5002760
Cyberoptic Security

https://www.cyberoptic.co.nz/

Pen Testing Your Mobile Application (and Its API)

Cyberoptic Security Ltd — Fri, 29 Aug 2025 00:16:12 +0000

Mobile apps are everywhere. Whether it's a banking app, a fitness tracker, or a marketplace for local goods, almost every business building digital products today has a mobile application at its core. But while app development has accelerated, security often struggles to keep up.

Mobile application testing is a critical part of a secure software development lifecycle. Unfortunately, many development teams still underestimate the risks, or assume that app stores, operating systems, or third-party libraries will take care of it all. They don't.

There are two sides to mobile application security testing: the application itself, and the API it talks to. Both need proper penetration testing.

Testing the App Itself

Most mobile apps run on iOS or Android, and a lot of teams rely heavily on the security of those platforms to protect the app itself. While Apple and Google do a good job, relying on device-level security alone is risky. Once someone has physical access to the phone, or has jailbroken or rooted it, your app's internal security is the only thing standing between them and your users' data.

Good mobile app penetration testing looks at:

Poor data hygiene -- is sensitive data cached, logged, or stored insecurely?
Insecure local storage -- are hardcoded secrets or credentials accessible from the app binary?
Weak protections -- does the app allow users to bypass authentication or escalate privileges?
Reverse engineering -- can someone decompile the app and understand how it works?
Insecure code -- are you using vulnerable libraries or outdated SDKs?

The OWASP Mobile Top 10 is a solid reference point here. It covers key mobile app security risks like insecure authentication, improper platform usage, and insufficient cryptography. If your app hasn't been tested against these, it's vulnerable -- plain and simple.

Testing the API Behind the App

The second half of the equation is your app's backend, the API it talks to.

Too many mobile apps act like the API is some black box, assuming that only the app can talk to it. But the truth is, anyone can send requests to your API with the right tools, Postman, Burp Suite, or even curl. If your API doesn't validate requests properly, or if it exposes too much data, it becomes a target.

API penetration testing helps identify:

Broken object-level authorisation - can one user access another's data?
Excessive data exposure - are you unintentionally releasing sensitive data?
Lack of rate limiting - can this be abused to adversely affect your service?
Poor authentication - can it be easily bypassed?
Injection flaws - does the API prevent injection attacks such as SQLi?

All of these are covered in the OWASP API Security Top 10, which should be considered essential reading for any team developing a mobile or web application.

Real-World Risk: What Happens if You Don't Test?

Let's say someone gets hold of a user's device. Maybe it's lost, stolen, or handed in for repairs. If your app stores sensitive data locally, like session tokens or personal info, that's an issue. Or worse, if you've hardcoded credentials to your API inside the app (and yes, this still happens), then you've just given an attacker everything they need to target your backend systems.

We've seen real-world examples where apps left sensitive endpoints unprotected or trusted the app too much and didn't verify requests on the server side. In one case, an app allowed anyone to pull down full user profiles just by changing a user ID in the request. That's the kind of thing that proper penetration testing picks up before it becomes a news headline.

What Mobile Application Penetration Testing Involves

At Cyberoptic Security, we break mobile application testing into two focused phases:

Mobile app testing -- reviewing how the app handles data, how it's built, and how resilient it is to reverse engineering and tampering. We simulate what an attacker could do with a compromised device or a modified app binary.
API testing -- analysing the API endpoints your app communicates with. We test access controls, input validation, authentication mechanisms, and other key areas where APIs often fail.

This combined approach provides a clear picture of how your app would stand up to real-world attacks.

Why Dev Teams Should Care

Mobile app development is fast-paced. MVPs get released quickly. Security can get pushed aside for speed. But in 2025, security is no longer a nice-to-have, it's an expectation. Users trust your app with their data, and regulators increasingly expect responsible handling of personal information.

Pentesting your mobile application (and its API) helps protect your users, your reputation, and your business. It's far more cost-effective to find these issues early than to clean up after a breach or privacy complaint.

Useful Resources for Mobile and API Security

These are excellent resources for developers and security teams. In addition to good development practices, mobile app penetration testing is also highly recommended.

Need Help?

At Cyberoptic Security, we work with companies to deliver practical, hands-on mobile app and API security testing. We take the time to understand your tech stack, your threat model, and your release cycle. Whether you're launching your first app or scaling to thousands of users, we'll help you do it securely.

If your development team is building or maintaining a mobile app, now is the time to invest in security testing. Don't wait for something to go wrong.