SentinelOne Was Watching, So Sable Took the Quiet Path

In our last defended-network article, we showed Sable operating against a SIEM-instrumented lab. The takeaway was simple: frontier models can reason about detection, but consistency is still the hard part. Sable evaded Wazuh well on Linux and struggled more as the engagement moved deeper into Windows, which made the result more credible.

This engagement showed the next step. Sable was given six internal subnets inside a multi-thousand-person company with no starting credentials and one warning: SentinelOne was active. It treated SentinelOne as a constraint, avoided noisy endpoint activity, and started with quieter surfaces: Active Directory, domain services, printers, fax infrastructure, SMB shares, service accounts, and file workflows. It first mapped the [REDACTED].corp domain, identified three Domain Controllers, and found that although LDAP anonymous reads were blocked, null-session SAMR enumeration still exposed the domain SID, password policy, users, groups, and group memberships.

LDAP anonymous reads were blocked, but null-session RPC still exposed the domain SID and account data.

That early enumeration recovered more than 500 users and business-specific groups, including Payroll, Revenue, Audit, VPNconsultant, and others. Sable still did not have a password, shell, or foothold. What it had was a map of the organization: users, groups, naming patterns, business functions, and infrastructure clues.

Null-session SAMR enumeration exposed business-specific domain groups, giving Sable an organizational map without credentials.

In a defended network, that map mattered because it let Sable reason about where risk was likely to accumulate without touching endpoints. The trace explicitly noted that SentinelOne was in play, so Sable prioritized low-noise paths over endpoint interaction.

Sable treated SentinelOne as a constraint and prioritized low-noise paths over lateral movement.

That led to the fax infrastructure. Fax servers are easy to ignore. They often sit in the background handling document routing, LDAP lookups, SMB writes, email delivery, or printer integrations. Those workflows frequently require domain credentials. Sable followed that trail to a MultiTech FaxFinder appliance and tested a low-rate default credential path. The test confirmed the issue: invalid credentials redirected back to /login, while admin/admin returned an authenticated session.

Sable confirmed default admin/admin access to FaxFinder and established an authenticated session.

Sable pulled the FaxFinder LDAP configuration page and found a domain LDAPS bind account stored in cleartext. The page exposed the domain controller, LDAPS port, domain name, username, and password value for the faxfinder account.

Authenticated FaxFinder access exposed a cleartext domain LDAPS bind credential.

Sable did not assume the credential was valid just because it appeared in a configuration page. It validated the account against SMB and LDAP on the Domain Controller and confirmed that faxfinder was a live, low-privileged domain account.

Sable validated the leaked FaxFinder credential as a live domain account.

Sable had a real domain account with limited privileges, while still avoiding payloads, credential dumping, and lateral movement. The next question was what a normal domain account could see that anonymous access could not.

Sable used faxfinder to enumerate SMB shares across the Domain Controllers. Most exposure looked normal: administrative shares, SYSVOL, NETLOGON, and expected domain infrastructure. Then [REDACTED]DC2 stood out. It exposed non-standard shares, including Reports2, Users, and R$. That was the first sign of role drift: a Domain Controller was also supporting a business file workflow. Sable checked Reports2 and found read/write access with the low-privileged account.

The low-privileged FaxFinder account had read/write access to Reports2 on a Domain Controller.

The issue extended beyond one service account. Sable checked the ACL and found broad access: Everyone had Full Control. It then safely validated impact by uploading, listing, and deleting a benign marker file.

The Reports2 ACL granted broad Full Control access.

Sable safely validated write access by uploading, listing, and deleting a benign marker file.

Reports2 was more than just writable. It contained over 1,100 accounting-style Excel files, including hundreds of trial-balance spreadsheets. Sable treated this as a finance/reporting archive exposed on a Domain Controller, with both confidentiality and integrity risk because the same low-privileged account could read and write to the share.

The writable share contained accounting-style reports, suggesting a live business workflow on a Domain Controller.

The Reports2 finding was not isolated. After validating the FaxFinder credential, Sable found multiple places where low-privileged domain access crossed into sensitive business infrastructure. On [REDACTED]DC2, that meant a writable reporting share on a Domain Controller. On [REDACTED]D3, it meant READ,WRITE access to multiple business/application shares, including BOFA-IOC, FileSaves, and RevTracWeb. Those shares were not endpoint compromise, but they created direct integrity and exposure risk across business workflows.

The low-privileged FaxFinder account had read/write access to multiple business/application shares on [REDACTED]D3.

Sable also found AAD Connect/MSOL synchronization artifacts tied into the same environment, along with a legacy PeopleSoft configuration file exposing a database Connect ID and password. The PeopleSoft credential appeared in pstools75.cfg as ConnectID and ConnectPSWD, creating another credential exposure in the same application-share path. Sable treated it as exposure rather than confirmed compromise, but it reinforced the broader pattern: low-privileged domain access was enough to uncover sensitive identity, application, and business workflow risk without touching endpoints.

Sable found AAD Connect tied to the Domain Controller tier, another sign of tier-zero role drift.

Sable also found evidence that the accessible business shares contained sensitive financial material, including a bank-statement folder and PeopleSoft-related directories. This changed the finding from generic share exposure to business-data exposure: the low-privileged account was not only able to enumerate shares, but could see paths tied to finance and enterprise application workflows.

Sable found accessible business-share paths containing financial and PeopleSoft-related material.

SentinelOne did what EDR is supposed to do: it changed the path. Sable treated it as a constraint, avoided noisy endpoint behavior, and moved through quieter weaknesses in the environment: exposed identity data, default appliance access, leaked service credentials, writable business shares, exposed application credentials, and financial workflow access.

This is what we predicted back in March. As AI hacking agents get more competent, the hard problem becomes whether defenders can stop an agent that reasons around controls instead of running directly into them. In this engagement, Sable started with zero credentials and still found domain-impacting risk across identity, applications, and business data. EDR helped shape the route, but it did not remove the exposure.