Coalition Indicator Sharing and Source Protection
A coalition partner shares a report at TLP:AMBER with moderate confidence: a malware hash, a C2 IP, and a phishing lure theme targeting defense contractors. Your national CERT finds the hash on a defense contractor's file server, and the contractor is cooperating. The partner's handling caveat says the indicators came from a sensitive collection platform and must not be released to commercial services. A 48-hour warning window exists before an expected phishing wave. Your team wants to submit the hash to a public malware service for enrichment and to push the C2 IP to a shared sensor network. The partner has not authorized either action. Internally, one analyst argues that the contractor's safety justifies immediate sharing; another argues that exposing the source will burn a long-running collection. You must decide handling, enrichment, and what to tell the contractor.
1. How should the report be handled and shared internally?
Read the worked answer
TLP:AMBER means limited disclosure to the recipient organization and its contractors on a need-to-know basis; the source caveat is stricter. Store the report in the controlled intelligence system, not in wide email. Internally, share only with the CERT malware team and the contractor liaison. Do not upload the hash to a public service: a hash lookup is often enough to link the sample to your collection, and a public submission can expose the partner's platform. Share a sanitized advisory with the contractor: a credential-phishing theme targeting defense contractors, reported by a coalition partner, moderate confidence. Give the hash only under a confidential handling agreement if the contractor needs it for scanning. Log every disclosure. The partner's authorization is required for any onward sharing beyond the original purpose.
2. What enrichment can you do without exposing the source?
Read the worked answer
Run the sample in an internal sandbox, compute imphash and fuzzy hashes, extract the C2 configuration, and compare it against internal telemetry. Use passive DNS and certificate transparency for the C2 IP and related domains; those are public sources and do not reveal the partner. Ask the partner for permission to use a closed trusted community or a commercial intelligence feed under non-disclosure. Ask whether the hash can be shared with the national CERT under the coalition agreement. If a public service is unavoidable, submit a derived indicator such as a YARA rule rather than the exact hash, and only after legal review. Do not push the C2 IP to a shared sensor network without authorization; that is an operational disclosure, not just enrichment.
3. The 48-hour warning window and moderate confidence-what action do you recommend?
Read the worked answer
Moderate confidence and a 48-hour warning justify a defensive warning, not a public block. Recommend: (1) notify the contractor's security team with the lure theme and sanitized indicators; (2) enable enhanced logging on the contractor's mail gateway and endpoints; (3) pre-position a block for the C2 IP at the contractor's proxy, to be enabled on confirmation; (4) ask the partner for a downgraded indicator set that can be shared; (5) monitor for the phishing wave. The risk of not warning is a successful compromise; the risk of warning is source exposure and false alarm. A sanitized warning that omits the exact hash and collection method balances them. If the partner refuses any sharing, escalate through the coalition liaison; do not unilaterally release. The contractor's safety is a strong argument, but the handling caveat is an agreement, not a suggestion.