kMDItemWhereFroms face à l’attribut de quarantaine
D’où vient ce fichier sur Mac ? Lire kMDItemWhereFroms, le comparer aux données de quarantaine et interpréter un attribut de quarantaine absent.
TL;DR. kMDItemWhereFroms est un attribut étendu contenant une liste de propriétés binaire de chaînes, en général l’URL de téléchargement et la page de référence (pour Mail, des chaînes de type expéditeur et objet). Il répond à la question « d’où vient ce fichier ? », mais, contrairement à l’attribut de quarantaine et à la base QuarantineEventsV2, il ne porte ni flags, ni agent, ni UUID. Un fichier qui a encore un WhereFroms mais a perdu son attribut de quarantaine est une piste utile, pas une preuve de manipulation.
Ce que contient kMDItemWhereFroms
Le nom complet de l’attribut est com.apple.metadata:kMDItemWhereFroms. Les navigateurs et Mail le posent lorsqu’ils enregistrent un fichier. Sa valeur est une liste de propriétés binaire contenant un tableau de chaînes :
- pour un téléchargement dans un navigateur, en général l’URL de téléchargement suivie du référent ou de la page d’où il a été lancé ;
- pour une pièce jointe Mail, des chaînes de type expéditeur et objet.
Il se trouve sur le fichier lui-même, à côté de com.apple.quarantine. L’entrée du glossaire kMDItemWhereFroms en donne la définition courte.
Comment le lire
Avec mdls
Sur un système allumé, Spotlight expose directement la valeur :
mdls -name kMDItemWhereFroms ~/Downloads/report.pdf
mdls interroge Spotlight : il fonctionne sur le Mac en marche, pour les fichiers que Spotlight a indexés. Pour des éléments collectés, lisez l’attribut lui-même.
Avec xattr
xattr -p com.apple.metadata:kMDItemWhereFroms ~/Downloads/report.pdf
xattr -l -x ~/Downloads/report.pdf
La première commande affiche la valeur sous forme de texte. Comme il s’agit d’une liste de propriétés binaire, la sortie paraît illisible : les URL se lisent, mais elles sont entrecoupées d’octets de longueur et de type qui ne s’affichent pas. xattr -l sans -x pose le même problème. La seconde commande affiche chaque attribut en vidage hexadécimal, ce qui préserve les octets exacts.
Pour une arborescence, utilisez le listing du guide de collecte :
xattr -r -l -x ~/Downloads ~/Desktop ~/Documents ~/Library/LaunchAgents > ~/qcase/xattr_$(id -un).txt 2>/dev/null
Quarantine Parser décode exactement le WhereFroms à partir des listings hexadécimaux. À partir d’un simple rendu texte, il ne peut le décoder qu’approximativement, car des octets ont pu se perdre en chemin vers le terminal. Si vous avez le choix, collectez avec -x.
Trois enregistrements, trois questions différentes
WhereFroms, l’attribut de quarantaine et la base se recoupent, mais chacun prouve autre chose.
| kMDItemWhereFroms | com.apple.quarantine | QuarantineEventsV2 | |
|---|---|---|---|
| Emplacement | Attribut étendu du fichier | Attribut étendu du fichier | Base SQLite par utilisateur |
| Contenu | URL et référent ; pour Mail, expéditeur et chaînes de type objet | Flags, heure Unix en hexadécimal, nom de l’agent, UUID | Heure, agent, identifiant de bundle, URL de données et d’origine, expéditeur, numéro de type |
| Ce qu’il indique | L’URL ou le message d’où le fichier a été enregistré | Que le fichier a été marqué pour Gatekeeper, quand, par quelle app, et s’il a été approuvé | Qu’un téléchargement en quarantaine a eu lieu ; ni chemin ni nom de fichier local |
| Survit à la suppression du fichier | Non | Non | Les lignes persistent en général |
| Supprimable | Oui, comme tout attribut étendu | Oui : xattr -d com.apple.quarantine ou xattr -c | Lignes avec sqlite3, ou le fichier entier |
C’est l’UUID de la valeur de quarantaine qui relie le fichier à sa ligne de base ; voir le guide des flags. WhereFroms n’a pas de telle clé : tout lien entre une valeur WhereFroms et une ligne de base repose sur la concordance des URL et des heures. Rappelez-vous aussi que beaucoup de lignes réelles ont des colonnes d’URL vides, et que des outils comme curl, wget, scp, rsync ou git n’adhèrent pas du tout à la quarantaine.
Le cas « WhereFroms sans quarantaine »
Quarantine Parser lève une piste lorsqu’un fichier porte un WhereFroms mais pas d’attribut de quarantaine, formulée « xattr -d possible ». Le raisonnement : un navigateur qui écrit un WhereFroms laisse normalement aussi un attribut de quarantaine, et xattr -d com.apple.quarantine retire ce dernier sans toucher au premier, ni à la base.
Cette explication est plausible, surtout pour des exécutables, pour lesquels retirer la quarantaine évite Gatekeeper. Avant de conclure à de l’anti-forensique, envisagez d’autres explications :
- Copies partielles des attributs. Une copie, une synchronisation ou un transfert a pu conserver certains attributs étendus et pas d’autres. Le comportement dépend de l’outil et des systèmes de fichiers concernés.
- Extraction par d’autres outils. L’Utilitaire d’archive propage la valeur de quarantaine de l’archive aux fichiers extraits ; les désarchiveurs tiers ne le font pas forcément. Ce qu’ils font des autres attributs dépend de l’outil.
- L’effacement de tous les attributs est un autre cas.
xattr -cretire tous les attributs, WhereFroms compris ; il ne produit donc pas ce cas de figure.
Testez l’outil et la version de macOS concernés quand c’est possible, et cherchez des éléments concordants : une ligne de base dont l’URL correspond au WhereFroms, ou une ligne récupérée dans l’espace libre.
AppleDouble : des attributs qui voyagent
Les attributs étendus peuvent survivre au fichier d’origine lorsqu’ils voyagent avec une copie.
Fichiers ._ sur exFAT, FAT et SMB
Sur les systèmes de fichiers sans attributs étendus, macOS écrit un fichier compagnon AppleDouble nommé ._<nom> qui contient les attributs. Quand un utilisateur copie un fichier téléchargé sur une clé USB en exFAT ou sur un partage SMB, le fichier ._ peut emporter la valeur de quarantaine et le WhereFroms jusqu’à la destination, même après la suppression de l’original sur le Mac.
__MACOSX dans les ZIP du Finder
Les archives créées avec la commande « Compresser » du Finder contiennent des entrées __MACOSX/._<nom> porteuses des mêmes données. Velociraptor fournit MacOS.Forensics.AppleDoubleZip pour les lire à grande échelle. Quarantine Parser lit directement les attributs de quarantaine et WhereFroms des fichiers AppleDouble : déposez le fichier ._ ou le dossier __MACOSX avec le reste des éléments.
com.apple.provenance : présent mais opaque
Sur les macOS récents, de nombreux fichiers portent aussi com.apple.provenance, une valeur de 11 octets. C’est une clé opaque vers la table provenance_tracking d’ExecPolicy, ni une URL ni un horodatage. Quarantine Parser ne la décode pas. Notez sa présence, mais ne tirez pas de conclusion de ses seuls octets.
Pour une référence condensée de ces artefacts, consultez la fiche sur les événements de quarantaine de notre site partenaire, et le cas d’enquête pas à pas pour voir ces deux situations en contexte.
Questions fréquentes
Pourquoi xattr -l affiche-t-il du texte illisible pour kMDItemWhereFroms ?
La valeur est une liste de propriétés binaire, pas du texte. xattr -l l’affiche comme s’il s’agissait de texte : les URL apparaissent mêlées à des octets non imprimables. Utilisez xattr -l -x pour un vidage hexadécimal exact, ou mdls -name kMDItemWhereFroms sur un système allumé.
Un fichier avec kMDItemWhereFroms mais sans attribut de quarantaine prouve-t-il une manipulation ?
Non. C’est compatible avec l’exécution de xattr -d com.apple.quarantine, mais une copie ou un transfert qui a conservé certains attributs étendus et pas d’autres pourrait produire le même résultat. Traitez-le comme une piste et testez les outils et la version de macOS en cause.
Lequel des trois enregistrements survit à la suppression du fichier ?
En général, seule la ligne de la base QuarantineEventsV2, car les lignes persistent habituellement après la suppression du fichier téléchargé. kMDItemWhereFroms et com.apple.quarantine sont des attributs étendus et disparaissent avec le fichier, sauf si une copie AppleDouble existe ailleurs.