BBL16 Cybersecurity Consulting

BBL16 Cybersecurity Consulting Contact information, map and directions, contact form, opening hours, services, ratings, photos, videos and announcements from BBL16 Cybersecurity Consulting, Consulting Agency, IT Park, Lahug, Cebu City.

You don’t need to invest in costly security solutions to stop advanced attackers—what your organization truly needs is proper basic hardening of the environment, along with a creative approach.

25/04/2026

When dealing with compromised service accounts as part of remediation, your first thought might be to simply reset the password — but in most cases, it’s not that straightforward. Proper preparation and coordination are essential to avoid disrupting dependent applications or services. Below outlines key pre-requisites, options, and hardening measures for handling such scenarios.

Pre-requisites Before Performing a Service Account Reset
> Document all account configurations (e.g., SPN, “password never expires,”, etc.).
> Identify and document all applications or systems linked to the service account.
> Consult the application vendor for the proper reset procedure.
> Verify if there are password length limitations
> Coordinate the reset activity with the respective application owners (impact analysis).
> Prepare a recovery checklist and testing plan to validate post-reset functionality.
> Assess whether the application supports Group Managed Service Account for replacement.

Options for Handling Compromised Service Accounts
> Disable and replace the compromised account with a newly created service account.
> Reset the password of the existing service account, following vendor and internal guidelines.
Note: After any reset or replacement, conduct post-reset application testing to confirm that all dependent systems operate correctly. Additonally, any service account that cannot be reset like in a week after the remediation, should be disabled.

14/10/2025

Securing service accounts remains a persistent challenge for many organizations. In practice, these accounts are often left solely to IT teams, with minimal governance or oversight from InfoSec. As long as applications continue to function and no issues are reported, they are quickly approved and forgotten. This creates a risky environment where both IT and InfoSec lack clear visibility and accountability over how service accounts are managed and protected.

In reality, service accounts are frequently involved in security incidents—nearly 90% of incident response cases have some connection to them. The problem is a lack of ownership, proper controls, and awareness. Until organizations treat service accounts as critical assets, this risk will persist. Unfortunately, only a small number of organizations today implement strong controls and governance around service accounts, leaving a significant gap in overall security posture.

Several things you can do:
> Use gMSA (Group Managed Service Accounts), some third party now support this feature.
> Disable service accounts that have been inactive for 30 days.
> Ensure you have documented procedures for resetting specific service accounts.
> Do not grant Domain Admin privileges. For backup service accounts, assign only Backup Operator permissions.
> Set service accounts to "Account is sensitive and cannot be delegated", unless required for delegation (e.g., double-hop scenarios).
> Deny RDP and local logon for service accounts using User Rights Assignment across all tiers.
> Implement tiering for service accounts and service instances (e.g., use a dedicated patching system for Tier 0 systems).
> Use Authentication Policy Silos for additional control, even if deny policies are in place.
> Be cautious with service accounts configured for unconstrained delegation, as this can break tiering boundaries.
> Prefer agent-based tools that use SYSTEM for authentication over agentless approaches for Tier 0.
> Use separate service accounts for vulnerability scanners in Tier 0 (prefer unauthenticated scans or dedicated scanner or agent-based solutions).
> Ensure service accounts use at least a 30-character password. If limitations prevent this, plan to decommission or upgrade the affected application.
> Restrict DMZ service accounts by denying all logon types to non-DMZ zones (e.g., internal VLANs, Domain Controllers, and other critical systems).
> Ensure that Domain Controllers are not set with unconstrained delegation
> For service accounts used by applications (e.g., web) or limited to specific systems, configure the service account properties to allow logon only to designated machines
> Prohibit the use of service accounts for VPN or remote access
> Exclude service accounts from cloud synchronization unless strictly required

13/10/2025

If you’ve experienced a major security incident (full domain/enterprise compromise), should you reset all accounts across the organisation? Yes — you should perform an Enterprise Password Reset.

What it is and when to run it?
An Enterprise Password Reset is a coordinated, organisation-wide credential reset intended to remove any credentials or secrets an attacker may have obtained. Only perform it once you have enough confidence in your investigation and containment — otherwise you risk re-exposing systems or disrupting recovery.

Pre-reset considerations (must-haves before executing)
> Investigation scope is effectively complete (near 90–100%).
> List of attacker TTPs, backdoors and all affected systems and accounts have been identified.
> Root/initial attack vector is known and remediated.
> All systems confirmed compromised are replaced or rebuilt as appropriate.
> Tactical hardening and containment controls are in place.
> Process and runbook exist for resetting application and service accounts.

Recommended scope for the Enterprise Password Reset
> KRBTGT account per domain (twice between 12 hours)
> Any read-only KRBTGT clones
> Privileged accounts (Domain Admins, Global Administrators, etc.)
> All remaining user accounts (including service accounts)
> Local administrator accounts (unless LAPS covers them)
> Trust keys and federation services (e.g., ADFS)
> Directory sync and cloud sync accounts (MSOL_*, sync accounts)
> Virtualization platform accounts
> Stand-alone security and infrastructure systems (EDR, network appliances, firewalls, etc.)
> Cloud provider accounts and cloud application accounts
> Certificates, secrets, and key material
> Session tokens and active authentication tokens
> Database and application credentials

"Note: There may be other environment-specific accounts not listed here, but this covers the majority of common accounts to target"

Considerations for Red Teaming / Pentesting:
When running Red Team exercises (especially by third parties), consider performing a tactical Enterprise Password Reset afterwards — you may not know which credentials the exercise exposed, so a targeted reset reduces risk.

11/10/2025

What is your current security boundary consideration?

--> In the past, organizations primarily relied on firewalls to establish network segregation and define security boundaries.

--> With the rise of cloud adoption, identity has become the new boundary—driven by the hybrid nature of modern environments.

--> Now, the boundary has expanded even further: anyone who holds or processes your data is effectively part of your security perimeter. This includes vendors, suppliers, and partners.

What should you do now?

1. Continue hardening both your on-premises and cloud environments (whatever security effort you are currently doing).

2. Regularly review the data access and permissions granted to vendors, suppliers and partners—and hope they maintain strong security hygiene and PRAY HARD they are not part of any Supply Chain Compromise in the future.

09/10/2025

Can you immediately use your backup data, replace compromised systems, or fail over to your disaster recovery site during a security incident? There’s no simple answer — it entirely depends on the situation and your immediate objective.

-> In a Ransomware Incident
The first instinct is to recover — and understandably so. But the real challenge lies in how to recover safely and ensure the attacker cannot regain access once systems are reconnected.

-> Disaster Recovery (DR) Considerations
A DR site is valuable during system or network outages. However, in the case of a security breach, it’s critical to confirm that the DR environment hasn’t been compromised as well. Therefore, activating DR isn’t a straightforward yes or no decision — it requires careful validation.

-> Backup System Considerations
Backups are not always guaranteed to be clean. In some cases, restoring from backup can inadvertently reintroduce malware or backdoors into your environment, giving attackers another opportunity to return. A safe and verified restoration process is essential — it saves significant time, effort, and potential re-compromise.

-> Compromised System Replacement
This step is particularly complex. Before replacing systems, you must first determine whether the attacker is still active in your environment — a challenging task on its own. Without this assurance, even newly deployed systems could be compromised again within minutes.

-> Final Thoughts
Managing a security incident is never simple. Acting too quickly can either contain the threat or unintentionally worsen the situation. What you can do now is prepare — harden your environment, secure an incident response retainer, and if you plan to handle investigations internally, ensure you have the proper tools and readiness in place.

05/10/2025

Many organizations suffer a full domain compromise from a single user clicking a malicious link or downloading a harmful file. Despite significant investments in compliance and advanced technologies, such incidents still occur—exposing a fundamental weakness in current IT security models, where just one user’s action can trigger a major breach. If your environment is built this way, where a single action can bring everything down, it’s only a matter of time before the worst happens, that will come very soon.

Effective protection doesn’t always require costly tools; some of the strongest defenses are simple and free. The goal of hardening is to reduce the attack surface and ensure immediate containment—if one system is breached, the impact should end there. Attackers should be unable to move laterally or escalate privileges to reach critical assets.

Design your environment so that any breach remains contained—this is the true goal, as 100% security doesn’t exist. When attackers can’t move beyond the initial compromise, they’ll give up and move on to easier targets. - You’re not one of those easy targets… are you?

04/10/2025

When using any cloud provider, can you truly assume that all settings are secure by default? The reality is, many default configurations are risky. This isn’t necessarily the provider’s fault—they aim to make their platforms easy to use, even for less experienced users. Unfortunately, attackers often exploit these default settings.

As a customer, you are responsible for protecting your data and workloads. This includes hardening authentication mechanisms, adopting modern authentication methods, and implementing additional security measures. Relying solely on provider defaults is not enough—those are just baseline configurations.

Most cloud providers offer free, auto-generated security recommendations and best-practice guidance. The challenge is being aware of them and acting on them. Since the cloud environment evolves daily, staying current is essential. You don’t need “100% security”—which doesn’t exist—but you do need sufficient protection to ensure your data, user registrations, authentication, and authorization are properly secured.

03/10/2025

You may be thinking: “As the head of IT, we’ve achieved all required certifications and compliance standards—do we really need a security assessment after that?” The answer depends on your risk appetite. Foundational security assessments are critical for organizations in situations such as:

1. Experiencing an active security incident
2. Undergoing a post-incident recovery review
3. Identifying multiple findings in a PenTest or Red Team exercise
4. Receiving an unusually high volume of security alerts
5. Expanding identity management from on-premises to the cloud (hybrid environments)
6. Preparing for ransomware readiness and resilience controls
7. Facing imminent or high-risk cyber threats
8. Modernizing IT infrastructure or operations
9. Engaging in mergers or acquisitions (due diligence requirement)
10. Seeking or renewing cyber insurance coverage

This list isn’t exhaustive—it represents a baseline. If your organization fits into any of these scenarios, a security assessment should be part of your strategic planning.

We don’t limit this to specific industries; instead, we focus on situations where the need is most urgent and impactful.

29/09/2025

When responding to security incidents, many organizations adopt the TIER model as part of the hardening. However, attackers can still exploit privileged accounts from lower TIERs to reach TIER 0 assets. Several factors contribute to this challenge (not limited to the following):

1. Incomplete TIER model implementation – Most organizations only focus on TIER 0. While this is a good starting point, full implementation across all TIERs is necessary. Until then, hardening and monitoring should serve as compensating controls.

2. Unclear asset classification – Many organizations struggle to determine which assets belong to which TIER. As a reminder: systems that create or manage identity are TIER 0, business workload systems are TIER 1, and workstations typically fall under TIER 2.

3. Limited technical understanding – Teams often lack a solid grasp of the TIER model and its importance. Moreover, the technical implementation is complex and not easy to complete.

4. Operational readiness gaps – Administrators of critical systems sometimes resist TIER practices, viewing them as burdensome, which can lead to mistakes or broken processes.

5. Insufficient security monitoring – Standard monitoring isn’t enough. Effective TIER monitoring requires proper baselining, testing, and violation analysis.

6. Lack of TIER model gap analysis – Without identifying gaps in the implementation, organizations remain vulnerable to attackers bypassing controls and accessing critical systems.

7. Neglected support systems – Supporting systems (e.g., patching servers, antivirus platforms) that serve TIER 0 assets like Active Directory must also be segregated by TIER. Each should have dedicated instances and service accounts.

8. Overlooking advanced TIER controls – Even after implementing TIER 0 through TIER 2, organizations often ignore critical elements such as Privileged Access Workstations, Authentication Silos, and cloud considerations.

The TIER model is a powerful security concept—effective only if implemented correctly. Half measures can create a false sense of security and leave critical systems exposed.

25/09/2025

Threat actors often target exposed web applications as their preferred entry point because these systems are publicly accessible over the internet and typically deployed in the DMZ for on-premises environments. Once an attacker compromises such an application, they can establish a foothold and move laterally into the internal network, potentially reaching Domain Controllers—at which point it’s “game over.”

Protecting exposed web applications is particularly challenging since they are open to anyone online. Therefore, hardening efforts should focus on containment: if the web server is breached, the compromise should be limited to that system alone, with strict controls preventing the attacker from moving into the internal LAN where Domain Controllers and critical servers reside. At a minimum, organizations should enforce strong inbound and outbound restrictions in the DMZ. Key considerations include (in addition to what you already have such as EDR, security monitoring, WAF, etc.):

1. DMZ → Internet (outbound)
- Block internet access for DMZ servers
- Limit destinations and keep exposure minimal
- Avoid risky ports like RDP and SSH

2. DMZ → LAN / Active Directory / Critical Servers (outbound)
- No direct communication with internal resources.
- If required, avoid high-risk ports such as RDP and SSH
- DMZ servers should remain in a workgroup (not domain)

3. DMZ → Cloud (outbound)
- Allow only if necessary for business functions
- Again, restrict sensitive ports like RDP and SSH

4. DMZ → Backend Databases/Applications (outbound)
- Limit communication only to what the web application requires
- Use a dedicated backend DMZ to isolate these systems
- Apply the same traffic restrictions on backend servers
- Restrict inbound from Backend Databases/Applications

5. Inbound → DMZ
- Minimize all inbound traffic from both the internet and LAN
- Use a management network to access DMZ servers securely

6. Finally, avoid outdated or overly permissive firewall rules—especially “ANY-ANY” configurations—which create dangerous exposure and provide attackers with unrestricted pathways.

Address

IT Park, Lahug
Cebu City
6000

Website

Alerts

Be the first to know and let us send you an email when BBL16 Cybersecurity Consulting posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share

Category