The Leak Is Already Outside: Build an External Exposure Response Loop

Posted on October 20, 2026 by Brent Huston

The DLP dashboard is green.

Repository push protection is enabled. The approved file-sharing platform blocks public links. Managed laptops prevent copying sensitive files to removable media. The security team can point to policies, controls, alerts, and training.

Then someone finds a current API key in a public repository.

Or a configuration file in a support forum. A source-code fragment in a paste. An internal hostname in a public issue. A customer data sample in a forgotten cloud share. A credential in a contractor’s fork.

The organization did not see the information leave.

That does not make the exposure less real.

This is the gap between data-loss prevention and external-exposure response. Prevention controls watch selected systems, users, repositories, interfaces, and transfer paths. They are necessary. They are not proof that sensitive information never crossed a path the organization could not see.

The practical lesson is simple:

A data-protection program is incomplete until it can find, neutralize, and learn from sensitive information that is already outside the managed boundary.

Prevention Sees the Paths It Controls

Organizations should prevent sensitive data from leaving in the first place.

That includes classifying information, limiting access, using secrets managers, scanning source code, blocking known secret patterns, controlling file sharing, monitoring managed endpoints, and reducing the lifetime and authority of credentials.

The joint CISA and FBI guidance on Product Security Bad Practices identifies hardcoded credentials and secrets in source code as a dangerous practice for products used in critical infrastructure and recommends secrets managers and scanning within the development process.

GitHub provides another useful example. Its secret-security guidance distinguishes push protection, which attempts to stop supported secrets before they enter a repository, from secret scanning and public monitoring, which identify exposures that already exist. GitHub describes public monitoring as visibility into credentials exposed beyond repositories owned by the enterprise.

That distinction matters.

Preventive and detective controls are not interchangeable. One attempts to stop the event. The other assumes prevention can fail and looks for evidence afterward.

Even strong platform controls have scope. GitHub’s own secret-scanning documentation describes supported patterns, pair-matching conditions, legacy-token limitations, large-push conditions, and other cases in which push protection may not detect or block a secret.

That is not an argument against push protection.

It is an argument against treating any point control as proof of absence.

Public repositories are only one possible destination. Sensitive material can also appear in support portals, issue trackers, package artifacts, code forks, shared folders, archived pages, discussion sites, and third-party systems. Some of those channels belong to the organization. Others do not. Some produce useful logs. Others may provide only a timestamp, a URL, and a copy of what was exposed.

The control model must account for both conditions:

Prevent what can be prevented inside managed workflows.
Monitor and respond where prevention cannot provide complete visibility.

Treat External Exposure as Incident Evidence

Finding sensitive material outside the organization is not merely a content-cleanup task.

It may be evidence of an incident.

An exposed credential may still authorize access. A configuration may reveal trust relationships, administrative interfaces, naming conventions, or control gaps. Source code may disclose intellectual property, security assumptions, embedded secrets, or exploitable implementation details. A customer record may trigger privacy, contractual, legal, or regulatory obligations. A seemingly harmless internal identifier may help an attacker improve targeting.

The correct response depends on what the artifact can do, what it reveals, how current it is, and who may have obtained it.

This is why deletion alone is not containment.

Removing a repository, post, attachment, or cached page can reduce continuing exposure. It does not invalidate a credential, erase copies, reverse indexing, identify prior access, or prove that the information was never used.

For secrets, the priority is authority.

The OWASP Secrets Management Cheat Sheet recommends that secrets be revocable, rotated, limited in lifetime and privilege, and supported by lifecycle records that help responders understand who had access and when the secret was used or changed. Stopping the application or deleting the exposed file does not necessarily revoke the credential behind it.

For other data classes, the priority may be different. The organization may need to preserve evidence, restrict further access, notify an owner, assess contractual scope, request removal, investigate misuse, or determine whether the material exists in additional locations.

The external artifact is the beginning of the response question, not the end.

Build the External Exposure Response Loop

A practical external-exposure capability has five stages: discover, classify, neutralize, trace, and learn.

1. Discover: What is visible outside the boundary?

Define the sensitive artifacts the organization cares enough to recognize.

The list may include:

Credentials, tokens, private keys, and connection strings.
Source code and proprietary algorithms.
Device, cloud, application, and network configurations.
Internal domains, hostnames, project names, and administrative paths.
Customer, employee, regulated, or contractually protected data.
Documents carrying distinctive identifiers, watermarks, or structured patterns.

Then define the monitoring scope, frequency, owners, escalation path, and evidence-handling requirements for each class.

No discovery method sees the entire internet. A useful program therefore states its coverage and blind spots explicitly. It distinguishes continuous monitoring from periodic searches, platform-native scanning from broader exposure monitoring, and confirmed findings from possible matches that still require analyst validation.

The goal is not to claim universal visibility.

The goal is to reduce the period during which a consequential exposure remains unknown.

2. Classify: What can the artifact enable?

Do not prioritize solely by how embarrassing the artifact looks.

Classify it by authority, sensitivity, current validity, exploitability, reach, and affected business process.

Ask:

Is this an active secret, an expired secret, or a string that only resembles one?
What systems, data, funds, or actions could it authorize?
Is the artifact complete enough to use, or does it become dangerous when combined with other information?
Is the exposed copy current, historical, partial, or modified?
Does it contain regulated data, customer information, trade secrets, or security architecture details?
Is it publicly accessible, indexed, cached, mirrored, or limited to a narrower audience?
Who owns the asset and who has authority to contain it?

The fastest path to a good decision is a prepared owner map. Security should not discover during the incident that nobody knows who can rotate the key, suspend the integration, contact the platform, interpret the contract, or decide whether operations can tolerate emergency change.

3. Neutralize: Remove authority before chasing every copy

If an exposed artifact grants access, invalidate that authority first.

Revoke the token. Rotate the key. Terminate sessions. Disable the account. Restrict the affected interface. Replace the certificate. Narrow the permission. Add temporary monitoring or access controls while the permanent change is implemented.

Then address continuing availability of the artifact through the appropriate channel: delete an owned copy, request removal, use an established takedown process, restrict a share, or work with the platform or third party that hosts it.

Containment order matters.

If responders spend hours removing a public page while the exposed credential remains valid, they are reducing visibility without reducing authority. A downloaded copy can still work.

The neutralization plan must also account for dependencies. Rotating one secret may break applications, vendors, automated jobs, recovery processes, or downstream services. That is a reason to engineer revocation and replacement paths before an incident, not a reason to keep exposed authority alive.

4. Trace: How did it get there, and what happened next?

Once the immediate risk is controlled, reconstruct the path.

Determine:

Where the artifact originated.
Which person, system, process, or third party handled it.
When it became exposed and when the organization discovered it.
Whether logs show access, authentication, downloading, reuse, or related activity.
Whether the same material exists in forks, mirrors, archives, tickets, backups, chat systems, or build artifacts.
Whether similar artifacts were created by the same workflow.
Whether an attacker could combine the finding with other public information.

NIST SP 800-61 Rev. 3 frames incident response as part of cybersecurity risk management rather than a stand-alone activity and connects preparation, detection, response, and recovery. External-exposure work should follow the same logic. The team needs enough evidence to reduce immediate impact and improve the system that allowed the exposure.

Tracing must remain proportionate. Not every public identifier justifies a full forensic investigation. Not every old credential remains usable. The classification stage should drive the depth of response.

5. Learn: Which control or assumption failed?

The last stage converts a one-time cleanup into program improvement.

An exposure may reveal:

A secret embedded in code because the approved retrieval method was too difficult.
A repository that did not inherit the organization’s security configuration.
A contractor or vendor using an unmanaged development workflow.
Sensitive troubleshooting data copied into a support channel.
A DLP policy that covered endpoints but not build logs or cloud collaboration.
A credential with excessive privilege or no practical rotation process.
A data classification rule that employees could not apply to real work.
An alert that reached a mailbox nobody owned.

Fix the common cause, not only the visible artifact.

The question is not simply, “Did we remove it?”

The better question is, “What changed so that the same process is less likely to expose the next artifact?”

Prioritize Authority, Exposure, and Business Consequence

External findings need a decision model.

A useful triage approach considers three dimensions.

Authority

What can the artifact authorize or enable?

An active administrative credential, signing key, production token, or remote-access configuration may require immediate containment. A disabled test credential may require documentation and process correction without the same urgency.

Exposure

Who could obtain it, and for how long?

Public, indexed, and mirrored content has a different exposure profile from a restricted ticket available to a small support team. However, restricted does not mean safe. Third-party access, retention, forwarding, and account compromise still matter.

Business consequence

What could happen if the information is used or disclosed?

Consider system control, customer harm, financial movement, service disruption, regulatory scope, intellectual property, safety, contractual commitments, and reputational impact.

These dimensions prevent two common mistakes.

The first is treating every match as a crisis.

The second is treating a small-looking artifact as harmless when it carries substantial authority.

Measure the Response, Not Just the Number of Hits

Raw alert volume is a weak success measure.

More useful measures include:

Time from external publication to discovery.
Time from discovery to owner acknowledgement.
Time to invalidate active authority.
Time to determine the affected systems and data.
Percentage of high-impact secrets with a tested emergency rotation path.
Percentage of material findings with preserved evidence and documented disposition.
Recurrence rate by workflow, business unit, vendor, repository, or artifact type.
Percentage of monitoring patterns with a named owner and review date.
Number of findings that produced a control, process, or architecture improvement.
Percentage of high-risk exposures for which misuse could be assessed from available logs.

One metric deserves special attention:

How long does it take to make a discovered artifact harmless?

Discovery creates the opportunity to respond.

Neutralization changes the risk.

Where ClawBack Fits

MicroSolved currently positions ClawBack™ as a data-leak detection capability supporting exposure monitoring, advisory retainers, and vCISO relationships, with evidence that can support response conversations.

That is the right place for external-exposure monitoring in the operating model.

Its job is not to replace DLP, repository controls, secrets management, identity governance, incident response, or legal and privacy review. It helps close the visibility gap between what internal controls observed and what may be visible outside the organization.

The value of a finding depends on the process around it:

What classes of information are in scope?
Which sources and channels are monitored?
How are possible matches validated?
Who owns each artifact class?
What evidence is preserved?
What requires immediate escalation?
How will credentials be revoked, files removed, and downstream impact assessed?
How will lessons feed back into prevention?

ClawBack should therefore be treated as part of an exposure-response capability, not as an isolated alert feed.

What Security Leaders Should Do This Week

Choose one artifact class with meaningful business consequence: production API keys, administrative credentials, network configurations, source code, customer records, or another clearly owned data set.

Then run this exercise:

Define what a recognizable exposure looks like. Identify patterns, identifiers, owners, and likely external channels.
Document current coverage. Record which preventive and detective controls can see the artifact, and which paths remain outside their scope.
Prepare the owner map. Name the people who can classify the finding, revoke authority, approve operational impact, preserve evidence, request removal, and assess notification obligations.
Test neutralization. Measure how long it takes to revoke or replace the artifact without creating uncontrolled business disruption.
Simulate one discovery. Walk the finding through discover, classify, neutralize, trace, and learn.
Verify the logs. Confirm that responders can determine whether the artifact was used and which systems were affected.
Close one recurring path. Improve the workflow most likely to produce the same exposure again.

Data-loss prevention is important.

Secret scanning is important.

Repository protection is important.

None of them can prove that sensitive information is absent from every external place the organization does not control.

Build the response loop for the moment the leak is already outside.

Put External Exposure Monitoring Into the Security Program

MicroSolved, Inc. can help organizations:

Define external-exposure monitoring requirements for credentials, source code, configurations, and other sensitive artifacts.
Integrate ClawBack findings into vCISO, advisory, and incident-response workflows.
Build artifact classification, ownership, escalation, and evidence-handling processes.
Test credential revocation, session termination, takedown, and downstream-impact procedures.
Review DLP, repository, secrets-management, vendor, and cloud-collaboration control gaps.
Turn recurring exposures into practical control and process improvements.

To discuss ClawBack or an external-exposure response review, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

Methodology: MailItemsAccessed-Based Investigation for BEC in Microsoft 365

Posted on November 3, 2025 by Brent Huston

When your organization faces a business-email compromise (BEC) incident, one of the hardest questions is: “What did the attacker actually read or export?” Conventional logs often show only sign-ins or outbound sends, but not the depth of mailbox item access. The MailItemsAccessed audit event in Microsoft 365 Unified Audit Log (UAL) brings far more visibility — if configured correctly. This article outlines a repeatable, defensible process for investigation using that event, from readiness verification to scoping and reporting.

Objective

Provide a repeatable, defensible process to identify, scope, and validate email exposure in BEC investigations using the MailItemsAccessed audit event.

Phase 1 — Readiness Verification (Pre-Incident)

Before an incident hits, you must validate your logging and audit posture. These steps ensure you’ll have usable data.

1. Confirm Licensing

Verify your tenant’s audit plan under Microsoft Purview Audit (Standard or Premium).
- Audit (Standard): default retention 180 days (previously 90).
- Audit (Premium): longer retention (e.g., 365 days or more), enriched logs.
Confirm that your license level supports the MailItemsAccessed event. Many sources state this requires Audit Premium or an E5-level compliance add-on.

2. Validate Coverage

Confirm mailbox auditing is on by default for user mailboxes. Microsoft states this for Exchange Online.
Confirm that MailItemsAccessed is part of the default audit set (or if custom audit sets exist, that it’s included). According to Microsoft documentation: the MailItemsAccessed action “covers all mail protocols … and is enabled by default for users assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 licence.”
For tenants with customised audit sets, ensure the Microsoft defaults are re-applied so that MailItemsAccessedisn’t inadvertently removed.

3. Retention & Baseline

Record what your current audit-log retention policy is (e.g., 180 days vs 365 days) so you know how far back you can search.
Establish a baseline volume of MailItemsAccessed events—how many are generated from normal activity. That helps define thresholds for abnormal behaviour during investigation.

Phase 2 — Investigation Workflow (During Incident)

Once an incident is underway and you have suspected mailboxes, follow structured investigation steps.

1. Identify Affected Accounts

From your alarm sources (e.g., anomalous sign-in alerts, inbound or outbound rule creation, unusual inbox rules, compromised credentials) compile a list of mailboxes that might have been accessed.

2. Extract Evidence

In the Purview portal → Audit → filter for Activity = MailItemsAccessed, specifying the time range that covers suspected attacker dwell time.
Export the results to CSV via the Unified Audit Log.

3. Correlate Access Sessions

Group the MailItemsAccessed results by key session indicators:

ClientIP
SessionId
UserAgent / ClientInfoString

Flag sessions that show:

Unknown or non-corporate IP addresses (e.g., external ASN)
Legacy protocols (IMAP, POP, ActiveSync) or bulk-sync behaviour
User agents indicating automated tooling or scripting

4. Quantify Exposure

Count distinct ItemIds and FolderPaths to determine how many items and which folders were accessed.
Look for throttling indicators (for example more than ~1,000 MailItemsAccessed events in 24 h for a single user may indicate scripted or bulk access).
Use the example KQL queries below (see Section “KQL Example Snippets”).

5. Cross-Correlate with Other Events

Overlay these results with Send audit events and InboxRule/New-InboxRule events to detect lateral-phish, rule-based fraud or data-staging behaviour.
For example, access events followed by mass sends indicate attacker may have read and then exfiltrated or used the account for fraud.

6. Validate Exfil Path

Check the client protocol used by the session. If the client is REST API, bulk sync or legacy protocol, that may indicate the attacker is exfiltrating rather than simply reading.
If MailItemsAccessed shows items accessed using a legacy IMAP/POP or ActiveSync session — that is a red flag for mass download.

Phase 3 — Analysis & Scoping

Once raw data is collected, move into analysis to scope the incident.

1. Establish Attack Session Timeline

Combine sign-in logs (from Microsoft Entra ID Sign‑in Logs) with MailItemsAccessed events to reconstruct dwell time and sequence.
Determine when attacker first gained access, how long they stayed, and when they left.

2. Define Affected Items

Deliver an itemised summary (folder path, count of items, timestamps) of mailbox items accessed.
Limit exposure claims to the items you have logged evidence for — do not assume access of the entire mailbox unless logs show it (or you have other forensic evidence).

3. Corroborate with Throttling and Send Events

If you see unusual high-volume access plus spike in Send events or inbox rule changes, you can conclude automated or bulk access occurred.
Document IOCs (client IPs, session IDs, user-agent strings) tied to the malicious session.

Phase 4 — Reporting & Validation

After investigation you report findings and validate control-gaps.

1. Evidence Summary

Your report should document:

Tenant license type and retention (Audit Standard vs Premium)
Audit coverage verification (mailbox auditing enabled, MailItemsAccessed present)
Affected item count, folder paths, session data (IPs, protocol, timeframe)
Indicators of compromise (IOCs) and signs of mass or scripted access

2. Limitations

Be transparent about limitations:

Upgrading to Audit Premium mid-incident will not backfill missing MailItemsAccessed data for the earlier period. Sources note this gap.
If mailbox auditing or default audit-sets were customised (and MailItemsAccessed omitted), you may lack full visibility. Example commentary notes this risk.

3. Recommendations

Maintain Audit Premium licensing for at-risk tenants (e.g., high-value executive mailboxes or those handling sensitive data).
Pre-stage KQL dashboards to detect anomalies (e.g., bursts of MailItemsAccessed, high counts per hour or per day) so you don’t rely solely on ad-hoc searches.
Include audit-configuration verification (licensing, mail-audit audit-set, retention) in your regular vCISO or governance audit cadence.

KQL Example Snippets

MITRE ATT&CK Mapping

Tactic	Technique	ID
Collection	Email Collection	T1114.002
Exfiltration	Exfiltration Over Web Services	T1567.002
Discovery	Cloud Service Discovery	T1087.004
Defense Evasion	Valid Accounts (Cloud)	T1078.004

These mappings illustrate how MailItemsAccessed visibility ties directly into attacker-behaviour frameworks in cloud email contexts.

Minimal Control Checklist

Verify Purview Audit plan and retention
Validate MailItemsAccessed events present/searchable for a sample of users
Ensure mailbox auditing defaults (default audit-set) restored and active
Pre-stage anomaly detection queries / dashboards for mailbox-access bursts

Conclusion

When investigating a BEC incident, possession of high-fidelity audit data like MailItemsAccessed transforms your investigation from guesswork into evidence-driven clarity. The key is readiness: licence appropriately, validate your coverage, establish baselines, and when a breach occurs follow a structured workflow from extraction to scoping to reporting. Without that groundwork your post-incident forensics may hit blind spots. But with it you increase your odds of confidently quantifying exposure, attributing access and closing the loop.

Prepare, detect, dissect—repeatably.

References

Microsoft Learn: Manage mailbox auditing – “Mailbox audit logging is turned on by default in all organizations.”
Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts – “The MailItemsAccessed action … is enabled by default for users that are assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 license.”
Microsoft Learn: Auditing solutions in Microsoft Purview – licensing and search prerequisites.
Office365ITPros: Enable MailItemsAccessed event for Exchange Online – “Purview Audit Premium is included in Office 365 E5 and … Audit (Standard) is available to E3 customers.”
TrustedSec blog: MailItemsAccessed woes – “According to Microsoft, this event is only accessible if you have the Microsoft Purview Audit (Premium) functionality.”
Practical365: Microsoft’s slow delivery of MailItemsAccessed audit event – retention commentary.
O365Info: Manage audit log retention policies – up to 10 years for Premium.
Office365ITPros: Mailbox audit event ingestion issues for E3 users.
RedCanary blog: Entra ID service principals and BEC – “MailItemsAccessed is a very high volume record …”

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Ensuring Cybersecurity: Blocking Discord Access with Firewall Rules

Posted on June 18, 2024 by Brent Huston

I. Introduction

Purpose of Blocking Discord Access

Social media and communication platforms like Discord are everywhere in today’s digital landscape. However, their widespread use also introduces significant cybersecurity risks. Discord, known for its extensive user base and real-time communication features, can be a vector for malicious actors’ malware distribution and command and control (C2) operations. Blocking access to Discord within a corporate environment is a proactive measure to mitigate these risks.

Importance of Controlled Access to Prevent Malware Command and Control

Controlling access to external platforms is crucial in preventing unauthorized use of corporate resources for malicious purposes. By restricting access to platforms like Discord, organizations can reduce the risk of malware infections, data breaches, and unauthorized communications. This measure helps keep network integrity and security intact, safeguarding sensitive business information from cyber threats.

II. Assessing Business Needs

Identifying Users with Legitimate Business Needs

Before implementing a blanket ban on Discord, it’s essential to identify any legitimate business needs for accessing the platform. This could include marketing teams monitoring brand presence, developers collaborating with external partners, or customer support teams engaging with clients through Discord channels.

Documenting and Justifying Business Needs

Once legitimate needs are identified, they should be documented comprehensively. This documentation should include the specific reasons for access, the potential benefits to the business, and any risks associated with allowing such access. This step ensures that decisions are transparent and justifiable.

Approval Process for Access

Establish a formal approval process for users requesting access to Discord. This process should involve a thorough IT and security team review, considering the documented business needs and potential security risks. Approved users should be granted access through secure, monitored channels to ensure compliance with corporate policies.

III. Technical Controls

A. Network Segmentation

Isolating Critical Systems

One of the fundamental strategies in cybersecurity is network segmentation. Organizations can limit the potential impact of a security breach by isolating critical systems from the rest of the network. Critical systems should be placed in separate VLANs (Virtual Local Area Networks) with strict access controls.

Implementing VLANs

Creating VLANs for different departments or user groups can help manage and monitor network traffic more effectively. For instance, placing high-risk users (those needing access to external platforms like Discord) in a separate VLAN allows for focused monitoring and control without impacting the broader network.

B. Firewall Rules

Blocking Discord-Related IPs and Domains

To block Discord access, configure firewall rules to block known Discord IP addresses and domain names. For example:

! Block Discord IP addresses
access-list 101 deny ip any host 162.159.129.233
access-list 101 deny ip any host 162.159.128.233

! Block Discord domain names
ip domain list discord.com
ip domain list discord.gg
access-list 101 deny ip any host discord.com
access-list 101 deny ip any host discord.gg

! Apply the access list to the appropriate interface
interface GigabitEthernet0/1
 ip access-group 101 in

For comprehensive lists of Discord servers and IPs to block, refer to resources such as:

Creating Whitelists for Approved Users

For users with approved access, create specific firewall rules to allow traffic. This can be done by setting up a whitelist:

! Allow approved users to access Discord
access-list 102 permit ip host approved_user_ip any

! Apply the whitelist access list to the appropriate interface
interface GigabitEthernet0/1
 ip access-group 102 in

C. Proxy Servers

Filtering Traffic

Utilize proxy servers to filter and control web traffic. Proxy servers can block access to Discord by filtering requests to known Discord domains. This ensures that only approved traffic passes through the network.

Monitoring and Logging Access

Proxy servers should also be configured to monitor and log all access attempts. These logs should be reviewed regularly to detect unauthorized access attempts and potential security threats.

D. Application Control

Blocking Discord Application

Application control can prevent the installation and execution of the Discord application on corporate devices. Use endpoint security solutions to enforce policies that block unauthorized software.

Allowing Access Only to Approved Instances

For users who need Discord for legitimate reasons, ensure they use only approved instances. This can be managed by allowing access only through specific devices or within certain network segments, with continuous monitoring for compliance.

Conclusion

Blocking Discord access in a corporate environment involves a multi-layered approach combining policy enforcement, network segmentation, firewall rules, proxy filtering, and application control. Organizations can mitigate the risks associated with Discord by thoroughly assessing business needs, documenting justifications, and implementing robust technical controls while allowing necessary business functions to continue securely.

For assistance or additional insights on implementing these controls, contact MicroSolved. Our team of experts is here to help you navigate the complexities of cybersecurity and ensure your organization remains protected against emerging threats.

* AI tools were used as a research assistant for this content.

ClawBack from MicroSolved: A Solution for Detecting Data Exposures on IT Help Forums and Support Sites

Posted on March 27, 2023 by Brent Huston

Introduction

In today’s interconnected world, the sharing of information has become a necessary aspect of both personal and professional life. However, this also increases the risk of exposing sensitive data to malicious actors. IT help forums, and support sites are particularly vulnerable to such data exposures, as users inadvertently share information that can compromise their networks and systems. ClawBack from MicroSolved is a powerful tool designed to identify and mitigate these data exposures, helping organizations safeguard their sensitive information.

ClawBack: A Solution for Detecting Data Exposures

ClawBack is a data leakage detection tool developed by MicroSolved, an industry leader in information security services. It is specifically designed to scan the internet for sensitive data exposure, including IT help forums and support sites, where individuals and organizations may unwittingly disclose critical information. By utilizing cutting-edge search techniques, ClawBack can efficiently and effectively identify exposed data, enabling organizations to take appropriate action.

Key Features of ClawBack

Advanced Search Algorithms: ClawBack employs sophisticated search algorithms to identify specific data types, such as personally identifiable information (PII), intellectual property, and system configuration details. This ensures that organizations can focus on addressing the most critical exposures.
Comprehensive Coverage: ClawBack’s search capabilities extend beyond IT help forums and support sites. It also covers social media platforms, code repositories, and other online sources where sensitive data may be exposed.
Customizable Searches: Organizations can tailor ClawBack’s search parameters to their unique needs, targeting specific keywords, internal project names, and even key/certificate shards. This customization ensures organizations can focus on the most relevant and potentially damaging exposures.
Real-time Alerts: ClawBack provides real-time notifications to organizations when sensitive data is detected, allowing for prompt response and mitigation.

The Importance of Addressing Data Exposures

Organizations must recognize the importance of addressing data exposures proactively. The sensitive information disclosed on IT help forums and support sites can provide cybercriminals with the tools to infiltrate an organization’s network, steal valuable assets, and cause significant reputational damage.

ClawBack offers a proactive solution to this growing problem. Identifying and alerting organizations to potential data exposures allows them to take swift action to secure their sensitive information. This can include contacting the source of the exposure, requesting the removal of the exposed data, or initiating internal remediation processes to mitigate any potential risks.

Conclusion

In conclusion, ClawBack from MicroSolved is an invaluable tool for organizations seeking to protect their sensitive data from exposure on IT help forums and support sites. Its advanced search algorithms, comprehensive coverage, and real-time alerts enable organizations to proactively address data exposures and strengthen their security posture.

As cyber threats continue to evolve, it is essential for organizations to remain vigilant and invest in solutions like ClawBack to safeguard their valuable information. By doing so, organizations can build a robust security foundation that will help them thrive in the digital age.

What Is The Danger of Leaked Source Code?

Posted on January 12, 2022 by Brent Huston

Source code leaks are one of the biggest risks facing software developers today. It exposes sensitive business secrets, intellectual property, and trade secrets. It also puts the source code itself at risk of being used maliciously.

When source code leaks, it can lead to a number of issues. For instance, it could allow hackers to steal valuable IP. It could expose sensitive customer information. It could put employees at risk of having their identities stolen. And it could cause legal problems for companies.

In fact, according to a recent study conducted by KPMG, nearly half of respondents said that they had experienced a leak of confidential or proprietary information. Of those, almost two-thirds said that the leak was due to a developer leaving the company.

To learn more about our solution to helping customers detect and respond to source code leaks (along with other forms of critical data), check out our ClawBack™ product. The page contains several videos, pricing, and use cases. Give us a call at 1-614-351-1237 or drop us a line at info@microsolved.com to learn more or discuss how ClawBack can go to work for you!

How To Handle Leaked Credentials

Posted on January 3, 2022 by Brent Huston

OK, so you used ClawBack™ or some other tool and found leaked credentials linked to one of your employees on the web. Now, what do you do?

First, don’t panic. Leaked credentials happen all of the time. On average, it was discovered that employee email credentials from 10% of all Fortune 500 companies have been leaked in some form of data breach. (blog.finjan.com) Another report published recently suggests that the web currently hosts leaked credentials of employees for 97% of the top 1,000 global companies – many stemming from third-party data breaches. (blog.finjan.com)

Once you come to terms with your find, it’s time to get down to business researching the issue. The first step is to determine what kind of data you have identified. Usually, leaked credentials come with a user ID like an email, system login name, or the like. Presumably, this is how you found the credentials in the first place. Next, determine if you have a password and/or hash for that user that was contained in the leak. If you found only a list of emails or names, there is not much actionable intelligence there, beyond maybe letting those users know that they are at increased risk for phishing and reminding them to be vigilant.

If, however, you have a password or hash tied to one of your user names in the leak, a few more steps are involved. If you have a password, the first step is to determine if that password meets whatever password policies you have defined across the organization. This is a key leverage point for identifying potential leaks – many, if not most, leaked passwords come from third-party systems and websites that are compromised by attackers but are only used by the firm’s employees. It’s pervasive for industry sites, or shopping sites to be linked to your employee’s identity – it could be as simple as your employee signed up for the site with their work email, and that site got breached. If that is the case, then as long as your employee doesn’t use that password at work (or similar passwords: eg: Summer12 and Summer13, etc.) there is little risk to the firm. If the password would not meet your password policy for your domain, webmail, and other applications, then this is likely the case. If that happens, simply contact the employee, advise them of the leaked credential, and make sure that they understand to change their passwords anywhere they used that password in their online life.

But, what if the password could be one of your domain or webmail accounts? If the password would meet your policies, then immediately force a password change on all systems for that user. If possible, you should also terminate any open sessions and force the user to change their credentials. While a determined attacker may exploit this process to reset the password themselves if they have the ability, it prevents any non-resourced attackers from exploiting the credentials. The worst case is that an employee loses a current session and has to reset their passwords to continue working.

However, don’t stop there – contact the user and advise them of the leaked credential. Ask them if it was used on any work-related systems or applications, and if so, immediately begin an investigation on those systems looking for signs of illicit access. This should be performed using intensive log reviews and should go back to the date of the user’s previous password change whenever possible. Do not depend on the leak date, if shown, as the boundary for the incident. Attackers may have had knowledge and access prior to making the leak public. Often, attackers use compromised accounts for some time, getting what they want from the victim, and then release the stolen credentials to other attackers via a sale, or to the public, in the hopes that the additional attacker traffic will hide the original compromise.

Lastly, if you only have a hash of a potential password, I would still follow the process above. Most hashes can be broken given enough resources. Thus, it is erring on the side of caution to follow the above process, and accept the hash as a credential that could be in use in your environment.

Got other workarounds for leaked credentials? I’d love to hear them. Drop me a line on Twitter, and let me know (@lbhuston). I’ll share any insights in future posts.

If you’d like to learn more about ClawBack – check out our solution for hunting down leaked credentials, source code, and configuration data. Get in touch with us for a discussion, or check out the videos on our website for a walkthrough.

Getting ROI with ClawBack, our Data Leak Detection Platform

Posted on November 11, 2020 by Brent Huston

So, by now, you have likely heard about MicroSolved’s ClawBack™ data leakage detection engine. We launched it back in October of 2019, and it has been very successful among many of our clients that have in-house development teams. They are using it heavily to identify leaks of source code that could expose their intellectual property or cause a data breach at the application level.

While source code leaks remain a signficant concern, it is really only the beginning of how to take advantage of ClawBack. I’m going to discuss a few additional ways to get extreme return on investment with ClawBack’s capabilities, even if you don’t have in-house developers.

One of the most valuable solutions that you can create with ClawBack is to identify leaked credentials (user names and passwords). Hackers and cyber-criminals love to use stolen passwords for credential-stuffing attacks. ClawBack can give you a heads up when stolen credentials show up on the common pastebin sites or get leaked inadvertantly through a variety of common ways. Knowing about stolen credentials makes sense and gives you a chance to change them before they can be used against you.

We’ve also talked a lot about sensitive data contained in device configurations. Many potentially sensitive details are often in configuration files that end up getting posted in support forums, as parts of resumes or even in GITHub repositories. A variety of identifiable information is often found in these files and evidence suggests that attackers, hackers and cybercriminals have developed several techniques for exploiting them. Our data leak detection platform specializes in hunting down these leaks, which are often missed by most traditional data loss prevention/data leakage prevention (DLP)/data protection tools. With ClawBack watching for configurations exposures, you’ve got a great return on investment.

But, what about other types of data theft? Many clients have gotten clever with adding watermarks, unique identity theft controls, specific security measures and honing in on techniques to watch for leaked API keys (especially by customers and business partners). These techniques have had high payoffs in finding compromised data and other exposures, often in near real time. Clients use this information to declare security incidents, issue take down orders for data leaks and prevent social engineering attackers from making use of leaked data. It often becomes a key part of their intrusion detection and threat intelligence processes, and can be a key differentiator in being able to track down and avoid suspicious activity.

ClawBack is a powerful SaaS Platform to help organizations reduce data leaks, minimize reputational risk, discover unusual and often unintentional insider threats and help prevent unauthorized access stemming from exposed data. To learn more about it, check out https://microsolved.com/clawback today.

ClawBack For Credit Unions

Posted on September 10, 2020 by Brent Huston

I got a question recently from one of our Credit Union clients about ClawBack™. They explained that they don’t really do any internal development, so leaking source code was not a concern for them. Based on that, they wondered, would ClawBack still be a useful tool for them?

I pointed out that most larger Credit Unions do some form of development, or at the very least, that their systems admin folks often write (and potentially expose) scripts and other management tools that would be of use to an attacker. However, even if they didn’t do any development at all, leveraging something like the Professional level of ClawBack as a DIY tool ($149.00 per month) is still a good idea.

Further, I explained that source code leaks are only one third of the focus of the ClawBack tool. It also searches for leaked device/application configurations and leaked credentials. Every Credit Union with a network needs to think about leaked device and application configurations. These are the most commonly found items in ClawBack’s history. Whether by accident, or misunderstanding or malicious intent, thousands of leaked configuration files wind up on the Internet in repositories, support forums, answer sites, social media and paste bins. When found, they can provide significant amounts of damaging information to attackers, ranging from logins and passwords to sensitive cryptography and API keys. In some cases, they can be a nearly complete map of the internal network.

Thirdly, ClawBack also focuses on leaked credentials. It can help identify stolen and compromised passwords belonging to members of your organization. Many times, these credentials contain the same or similar passwords as Internet exposed applications, webmail or email access and potentially even weakly secured VPN instances. Stolen and leaked credentials are among the most significant root causes of breaches, business email compromise and a variety of other fraud.

Your CU Security team can add ClawBack to their toolkit for less than $150 per month. It’s simple to use, flexible and an incredibly powerful capability to minimize the damage from data leaks. Check out this less than 8 minute video for more information. If you’d like to discuss ClawBack or our ClawBack Managed and Professional Services, please drop us a line, or give us a call at (614) 351-1237 today.

3 Things Attackers Can Leverage From a Device Configuration Leak

Posted on September 3, 2020 by Brent Huston

One of the questions I often get around our ClawBack data leak detection SaaS product is “What can a hacker get from a leaked config?”. I put together this quick post about three of the most common and powerful elements that we often find in leaked configurations we discover.

1) Credentials – Let’s face it, credentials are often the easiest way to leverage leaked configs. Sure, it might be for an edge router or some network gear, or maybe it’s for the VPN. Configs often contain sets of credentials, either in plain text or in hashed form. Hashes need to be cracked, sure, but that is often quite possible. Even when the credentials aren’t able to be used remotely, they often help us tune our password guesses and learn more about the policies and password requirements of other systems. You wouldn’t believe the number of times, though, that the credentials from a leaked config simply work across the network or enterprise and often at a significantly powerful level.

2) Encryption Keys – Leaked router, firewall or VPN device configurations often contain encryption keys. While these still require an attacker to be in a position to gather traffic, they are very useful to well resourced attackers with that capability. If you’re at the level of risk where you need to worry about nation-state or politically motivated attackers, you really don’t want to leak your encryption keys. In addition to simply being a significant issue going forward, leaking encryption keys is a “long tail” vulnerability, because it provides cryptanalysis capabilities to adversaries who might have historic traffic archived, that the leak makes possible for them to leverage. Thus, the life of the key becomes the window of vulnerability. This is especially true when static cryptographic protocols are in use.

3) Network Recon Data – From IP addresses to firewall rules and from SNMP strings to dynamic routing data, device configurations can provide a veritable treasure trove of recon data about your environment. Partner connections, vendors with remote access, interconnects with other environments and the general day to day operations of the computing systems can often be found in leaked configurations. Depending on the type and criticality of the device, the config can often give up a complete view of the guts of the organization.

That’s just the top 3. We’ve seen thousands of leaked configurations in our work on ClawBack and penetration testing. It’s no doubt that leaked configs are useful to the attacker. The big question is, if you had leaked configurations out in the world, would you know about it? Would you know how to hunt them down, claw them back and mitigate the damage? If not, or if the idea makes you nervous, give us a call. We’re happy to help you solve these problems. You can get in touch by calling 614-351-1237 or drop us an email at info@microsolved.com.

ClawBack Professional and Managed Services Launched

Posted on August 31, 2020 by Brent Huston

Clawback small

ClawBack™, our data leak detection engine which we released last fall, is a cloud-based SaaS tool focused on helping organizations detect leaked source code, device/application configurations and credentials. You can learn more about the product and why we made it in this quick 8 minute video by clicking here.

While ClawBack has been a very successful product in its own right, the SaaS platform is primarily “Do It Yourself” in terms of operations. It’s easy to use and manage, but the customer does the work of reviewing the alerts and managing the responses. Over the last several months, some clients have asked for a managed service option, where MSI will manage the ClawBack product, review the alerts and work with the customer to issue take downs or provide mitigation advice. Today, we are proud to announce the immediate availability of the ClawBack Managed Service. Now you can get the power and vigilance of ClawBack without the overhead of managing and monitoring the product directly, reviewing the alerts and issuing appropriate take down requests.

Several clients have also asked us about other professional services associated with ClawBack and with Data Leak Prevent/Protection (DLP) capabilities in general. MSI is also proud to announce the immediate availability of the following associated professional services:

Monitoring term identification, optimization and improvement
Watermark implementation in source code and device configurations
Data leak awareness training, especially focused on source code, configurations and credentials
Data leak impact modeling and table top simulations
30/60/90 day data leak assessments
Exfiltration testing and Data Loss Prevention (DLP) assessments and optimization
Data classification and data leak policy and process development and reviews

Additionally, we are launching multiple year packages that combine these services in 3 and 5 year plans, allowing our clients to create long term solutions to the problems of data leakage, intellectual property risk management and compromises stemming from leaked source code, configs and credentials. To learn more about these services or create a package that fits your firm’s needs, give us a call at 614-351-1237 or drop us a line (info@microsolved.com).