For everyone interested in Fakturownia incident - the extracted data not exists anymore.Everyone make mistakes sometimes and their reaction was very professional. After my private conversation with them they declared to start public bug bounty program - great news that private companies starting to care and i hope others will go in their steps. Btw soon new interesting news.
Stay safe - fingerprint
Search
10 results for “fingerprint”
-
-
Quad-core laptop with fingerprint security and 2K display. Everything you need, nothing you don't.
KurieTim 8GB RAM Laptop Computer with 512GB PCIe SSD
🔭 https://www.amazon.com/dp/B0DWMD44QG?tag=jwebb004-20 #ad #paidlink #AmazonAffiliate #Laptop #Tech
KurieTim 8GB RAM Laptop Comput... -
@marcel I've been thinking about this too, and the fingerprint unlock is the only thing holding me back from buying it. I have an Apple Watch Ultra 2. How exactly does unlocking with it work?
Also, I'm curious - do you use the Duo with the screen folded? I'm worried some of the screen space is left unused.
-
A critical iPhone Duo security flaw allows users to bypass the lock screen on iOS 27.1. Discover the fingerprint glitch and day-one jailbreak details.
-
Somehow, the bots returned, and in greater numbers.
Think I have them under control now. Much easier with a bit of tooling to fingerprint them, seems they mostly just changed their user-agent a bit. But this is going to get *really* awkward if these dipshits ever learn how browser headers work.
-
📺 Abbiamo rimesso a nuovo l'articolo sulle alternative a YouTube!
Invidious e Piped ormai hanno senso solo sul proprio server: quelli pubblici non fanno quasi più partire un video.
Su Android arrivano Flow, PipePipe e Materialious accanto a NewPipe, più SmartTube per la TV e due dritte su contenitori e fingerprinting.
👉 https://blog.lealternative.it/2019/10/22/alternative-a-youtube/
-
Two npm worms, opposite tricks, one blind spot. ChainDrop: valid provenance, hijacked maintainer. MALFEX: new package name every two days, same nine-line loader injecting into dllhost.exe. Names and signatures are not trust. Fingerprint the machinery.
-
You review a 30-line template diff. Production sends 40,000 tokens assembled at request time from six sources, four of which changed this week and none of which appear in the pull request. The diff you approved is not the change you shipped.
This is the part of LLMOps that keeps biting teams after they have evals, tracing, and a gateway in place. The template is versioned in git. The context is assembled by code paths nobody treats as release artifacts.
The prompt is a build output
List what actually goes into a request for a typical RAG-plus-tools system:- The system template (in git, reviewed).
- Top-k retrieved chunks from an index that gets rebuilt on its own schedule.
- Tool JSON schemas, whose descriptions are prompt text written by whoever last touched the tool.
- A conversation summary produced by another model call.
- A user profile or tenant config blob.
- Few-shot examples chosen at runtime by a selector.
Each is a dependency with its own version and its own deploy cadence. The retrieved chunks change when someone reindexes. The tool schema changes when a backend engineer renames a parameter and rewrites the description. Neither triggers a review of the prompt.
So when quality drops on Tuesday and no code shipped, there is no diff to look at. That is the failure this whole post is about.
Fingerprint everything the model sees
Compute a content hash over the inputs that can change model behaviour, and log it with every trace:- model id and version
- template version
- retrieval snapshot id (the index build, not the query)
- the fully rendered prompt
- decoding parameters that matter
Store fingerprints always. Store full rendered prompts sampled or redacted, depending on your data rules — full-text retention is a compliance decision, not an observability one. The fingerprint is small, cheap, and answers "what changed" during an incident in one query.
The trade-off: a fingerprint that includes a timestamp, a request id, or a per-user greeting has near-zero collision rate and zero diagnostic value. Hash the parts that affect generation, not the metadata around it. I have watched a team spend a day on "why is our prompt hash changing every request" when the answer was a locale string.
A small assembler with provenance and eviction
You do not need a framework for this. You need three properties: every section carries a trust level, every section carries an eviction priority, and over-budget on a pinned section is a hard error rather than a silent trim.from dataclasses import dataclass, field
from hashlib import sha256
import re@dataclass
class Section:
name: str
text: str
trusted: bool # False for retrieval, tool output, user uploads
priority: int # higher survives truncation
pinned: bool = False # never evict; over budget means fail loudlyINSTRUCTION_LIKE = re.compile(
r"(ignore (all )?(previous|prior) instructions|you are now|system prompt)",
re.IGNORECASE,
)def screen(text: str) -> str:
# Cheap heuristic, not a guarantee. Log hits and route to a stricter path.
return INSTRUCTION_LIKE.sub("[filtered]", text)def count_tokens(s: str) -> int:
# Swap in tiktoken/the provider counter. One counter per model family.
return len(s) // 4@dataclass
class Assembled:
prompt: str
fingerprint: str
dropped: list[str] = field(default_factory=list)def assemble(sections, budget, model_id, template_version, snapshot_id):
ordered = sorted(sections, key=lambda s: (s.pinned, s.priority), reverse=True)
kept, dropped, used = [], [], 0
for s in ordered:
body = f"<{s.name} trust={'high' if s.trusted else 'low'}>\n"
body += (s.text if s.trusted else screen(s.text)) + f"\n</{s.name}>"
cost = count_tokens(body)
if used + cost > budget:
if s.pinned:
raise ValueError(f"pinned section {s.name} exceeds budget")
dropped.append(s.name)
continue
kept.append((s, body))
used += cost
# Render in original order so layout is stable across requests.
pos = {id(s): i for i, s in enumerate(sections)}
kept.sort(key=lambda pair: pos[id(pair[0])])
prompt = "\n\n".join(body for _, body in kept)
h = sha256()
for part in (model_id, template_version, snapshot_id, prompt):
h.update(part.encode())
return Assembled(prompt, h.hexdigest()[:16], dropped)# Usage: build once per request, log the fingerprint beside the trace id.
ctx = assemble(
sections=[
Section("question", "why was my claim denied?", trusted=True, priority=10, pinned=True),
Section("policy_chunk", retrieved_text, trusted=False, priority=5),
Section("profile", tenant_blob, trusted=True, priority=1),
],
budget=12_000,
model_id="claude-sonnet-4",
template_version="support-v14",
snapshot_id=index_build_id,
)Two details in there are load-bearing. Sections render in original insertion order rather than priority order, because reordering the same content changes model behaviour and makes your eval deltas unattributable. And
pinnedturns budget pressure into an exception instead of a degraded#ai #llm #devops #python #software #coding #development #engineering #inclusive #community
Context Assembly Is a Build Step: Versioning the Prompt You Actually Send -
----------------
🎯 Threat Intelligence: Microsoft maps a Chinese-language phishing infrastructure ecosystem (Storm-2990, Storm-3119)
===================Executive summary
Microsoft Threat Intelligence published research into a Chinese-language cybercriminal ecosystem that powers large-scale phishing. The finding matters for its structure more than for a single incident: one tracked cluster, Storm-2990, is an interconnected network of phishing kit operators, and a second cluster, Storm-3119, runs an illicit marketplace selling tools and infrastructure for bulk phishing. Together they function as a commercial supply chain: builders who maintain reusable phishing kits on one side, and a storefront that packages kits and hosting for buyers on the other.
What the tracked clusters are
• Storm-2990: an interconnected network of phishing kit operators. Kit operators maintain the reusable components behind credential phishing: fake sign-in pages, redirect logic, and the glue that makes a campaign turnkey. The 'network' framing suggests several operators connected through shared development and distribution rather than one monolithic actor.
• Storm-3119: an illicit marketplace selling tools and infrastructure for large-scale phishing. The marketplace role is operationally significant: it converts phishing from a bespoke operation into a commodity purchase, which lowers the entry cost for buyers with limited technical skill.Analysis
Two observations, with the caveat that the full report runs about fourteen minutes of reading and the material available here summarizes headline findings only.
First, a Chinese-language commerce layer points to a supplier and customer base distinct from the Russian-language phishing-as-a-service scene most defenders picture. Kit naming conventions, support channels, and pricing tend to differ between these language clusters, so detections tuned against one scene will lag against the other. That is an inference from the language observation in the source, not a claim the report makes explicitly.
Second, commercialized kits change the defensive math. Kit operators push template updates as filters catch current versions, so individual URLs and pages age out quickly, and blocklist-driven detection mainly covers the latest kit revision. This behavior is standard across phishing kit economies; a marketplace that aggregates supply simply accelerates the churn.
Detection
The available material includes no IoCs, kit names, sample domains, or hashes, so there are no signatures to relay yet. If the full Microsoft report adds named kits or tracked infrastructure, the practical detection surface is the usual one for kit-based phishing: monitoring new domain registrations with kit-like page structures, fingerprinting repeated templates instead of chasing individual URLs, and watching for credential-harvesting redirects on otherwise legitimate infrastructure.
Mitigation
The source summary does not list mitigations. Standard controls remain the baseline: phishing-resistant MFA, mail filtering with URL detonation, browser isolation for high-risk users, and rapid takedown of kit-hosted pages once identified.
References and caveats
Source: Microsoft Threat Intelligence research published October 14. The designations Storm-2990 and Storm-3119 are vendor-internal tracking names, so cross-vendor mapping of this activity is pending until other publishers report overlapping infrastructure. No independent verification of the ecosystem's scale is available at this point, and no victim or sector data was included in the available material.
🔹 ThreatIntel #Storm2990 #Storm3119 #Phishing #Microsoft
-
----------------
🛠️ Tool: claude-osint ships external recon tradecraft as Claude skills
===================What it is. claude-osint, built by Sachin Sharma (GenAI Security Research), is a library of eight SKILL.md files for the Claude skills system. Each file primes Claude with a written methodology covering one slice of external recon, aimed at authorized red-team and bug-bounty engagements. The bulk is structured markdown, about 10,000 lines total, plus two small Python scripts.
Core skills.
• osint-methodology (515 lines): strategy and discipline; asset-graph management, a severity rubric, time budgeting, identity-fabric mapping, deliverable templates.
• offensive-osint (4,555 lines): the tactical layer; probe paths, regexes, payloads, scoring rules, curl one-liners, plus 80 secret patterns, 80+ dorks, 9 read-only credential validators, and 27 attack-path templates.Org-scale skills. Six additional skills, per the README:
• org-attack-surface: maps a legal entity to its owned footprint using GLEIF org-trees, org-first RIR netblock recall, and an ASN hyperscaler-scope guard; discovery only.
• email-domain-security: composite spoofability verdict separating envelope from header-From; explicit note that SPF -all alone does not make a domain spoof-proof; SPF supply-chain analysis.
• exposure-risk-quantification: FAIR-based 0-100 and A-F score, dollar-denominated loss model, board one-pager, and honesty caps on ownership/proof claims.
• continuous-exposure-monitoring: rescan/diff loop, CTI and ransomware chatter checks, finding-lifecycle false-positive discipline, durable alert outbox.
• cloud-saas-exposure: ownership-gated bucket severity, offline AWS account-ID decoding, dependency-confusion confirmation, K8s/CI fingerprinting.
• identity-provider-recon: tenant and federation mapping, pre-auth user-enumeration oracle, name×pattern login synthesis, with a "hard enumeration boundary".Scripts. secret_scan.py is a stdlib-only 80-pattern secret scanner; h1_reference.py acts as a reference agent over disclosed HackerOne reports.
Use cases. The recon phase of authorized engagements: entity-to-footprint mapping, per-domain spoofability triage, and exposure scoring for client or board reporting. The files also read as standalone reference documents.
Limitations. The evaluation figures (56/56 pass on a 56-prompt self-evaluation, zero fabrications, ~85-90% practitioner coverage) are self-reported by the author and not independently verified. Structurally these are prompt files, not enforcement code: scope controls such as the enumeration boundary live in the instructions themselves, so scope discipline depends on the operator. The README bills the package as "god-mode" recon; the substance is closer to a well-ordered methodology library, which is the more useful framing anyway.
References. Repo: claude-osint on GitHub, author profile under Sachin Sharma; Claude skills documentation.
🔹 tool #OSINT #ClaudeSkills #RedTeam #BugBounty