context safety score
A score of 43/100 indicates multiple risk signals were detected. This entity shows patterns commonly associated with malicious intent.
malicious redirect
All application logic, assets, and bundles are loaded from a third-party domain 'q7sm4r.katawee.net' rather than the hosting domain sg77701.com. The domain 'katawee.net' with a random subdomain 'q7sm4r' is characteristic of threat-actor infrastructure used to serve dynamically swapped payloads. The site acts as a thin shell that delegates full execution to this external origin, enabling the operator to change delivered content (login forms, phishing pages, malware) at will without altering the host domain. (location: page.html: <script src="https://q7sm4r.katawee.net/system-requirement/Web.PortalNew/TC277-01/6ca1dc292f/preload.bundle.js">, vendor.bundle.js, main.bundle.js)
phishing
The page is a client-side single-page application with no visible content and an empty <title>, whose entire rendered UI is delivered via external JavaScript bundles from 'q7sm4r.katawee.net'. The path segment 'Web.PortalNew' combined with a versioned bundle identifier ('TC277-01/6ca1dc292f') is consistent with a hosted phishing kit that renders a branded login portal dynamically. The blank title and empty visible text prevent brand-name detection while allowing the JS to inject any impersonated portal UI after load. (location: page.html: <title></title>, <div id="app"><ui-view></ui-view></div>)
brand impersonation
The AngularJS 'ui-view' directive and 'Web.PortalNew' bundle path structure are common patterns in phishing kits that impersonate enterprise or banking portals (e.g., Microsoft 365, banking SSO pages). The use of 'ssodeestsebo.js' as a local script name contains 'sso' (Single Sign-On), suggesting impersonation of an SSO/identity provider login page to harvest corporate credentials. (location: page.html: <script src="/js/ssodeestsebo.js?single">, bundle path 'Web.PortalNew/TC277-01')
credential harvesting
The local script 'ssodeestsebo.js' ('sso' + obfuscated suffix) loaded at page initialization, combined with an SPA architecture that renders no static content and loads all logic from an external CDN-like host, is a strong indicator of a credential harvesting setup. The pattern allows a fake SSO login form to be rendered and credentials submitted to an attacker-controlled endpoint without any harvestable static indicators in the host HTML. (location: page.html: <script src="/js/ssodeestsebo.js?single">)
hidden content
The page delivers zero visible text content to crawlers, scanners, and non-JS agents. The entire page body is an empty SPA shell (only a JsLoadingOverlay call is present as text). All meaningful content is hidden inside JavaScript bundles served from an external host, effectively evading static content analysis and blocklist keyword matching. (location: page-text.txt: only contains JsLoadingOverlay.show() call; page.html body contains only <div id="app"><ui-view></ui-view></div>)
obfuscated code
The local script filename 'ssodeestsebo.js' appears to be an obfuscated or randomly-generated name appended to the 'sso' prefix, a technique used to avoid filename-based detection rules while retaining functional SSO-spoofing behavior. External bundle filenames use hash-like identifiers ('6ca1dc292f') preventing static analysis of script purpose. (location: page.html: /js/ssodeestsebo.js?single, https://q7sm4r.katawee.net/system-requirement/Web.PortalNew/TC277-01/6ca1dc292f/)
curl https://api.brin.sh/domain/sg77701.comCommon questions teams ask before deciding whether to use this domain in agent workflows.
sg77701.com currently scores 43/100 with a suspicious verdict and low confidence. The goal is to protect agents from high-risk context before they act on it. Treat this as a decision signal: higher scores suggest lower observed risk, while lower scores mean you should add review or block this domain.
Use the score as a policy threshold: 80–100 is safe, 50–79 is caution, 20–49 is suspicious, and 0–19 is dangerous. Teams often auto-allow safe, require human review for caution/suspicious, and block dangerous.
brin evaluates four dimensions: identity (source trust), behavior (runtime patterns), content (malicious instructions), and graph (relationship risk). Analysis runs in tiers: static signals, deterministic pattern checks, then AI semantic analysis when needed.
Identity checks source trust, behavior checks unusual runtime patterns, content checks for malicious instructions, and graph checks risky relationships to other entities. Looking at sub-scores helps you understand why an entity passed or failed.
brin performs risk assessments on external context before it reaches an AI agent. It scores that context for threats like prompt injection, hijacking, credential harvesting, and supply chain attacks, so teams can decide whether to block, review, or proceed safely.
No. A safe verdict means no significant risk signals were detected in this scan. It is not a formal guarantee; assessments are automated and point-in-time, so combine scores with your own controls and periodic re-checks.
Re-check before high-impact actions such as installs, upgrades, connecting MCP servers, executing remote code, or granting secrets. Use the API in CI or runtime gates so decisions are based on the latest scan.
Learn more in threat detection docs, how scoring works, and the API overview.
Assessments are automated and may contain errors. Findings are risk indicators, not confirmed threats. This is a point-in-time assessment; security posture can change.
integrate brin in minutes — one GET request is all it takes. query the api, browse the registry, or download the full dataset.