En coulisses : détecter la fraude au télétravail dans votre organisation

Dans le premier article de cette série, « Des imposteurs à la porte : détecter la fraude au télétravail avant qu’il ne soit trop tard », nous vous avons donné des tactiques pour détecter les signes pouvant indiquer une fraude au télétravail en amont du recrutement. Nous nous sommes penchés sur les objectifs de ces acteurs malveillants, nous avons souligné l’importance cruciale d’une détection précoce et rappelé que les équipes de sécurité doivent collaborer étroitement avec les RH, l’acquisition des talents et les responsables de recrutement pour détecter les signes avant-coureurs.

Le candidat a passé toutes les étapes d’entretien, coché toutes les cases des RH (oui, même la vérification des antécédents !) et aujourd’hui, c’est un collaborateur sur votre réseau. Que se passe-t-il maintenant ? Cet article dévoile les indicateurs techniques qui trahissent la fraude au télétravail au moment de l’intégration pour éviter une faille à grande échelle. Préparez-vous à déployer des détections Splunk, à reprendre le contrôle de votre pipeline d’onboarding et à neutraliser ces menaces avant qu’elles ne puissent nuire.

Avant de passer au code, un rappel important : il faut plusieurs indicateurs et modèles de comportement pour identifier ce type de menace. Chaque exemple de comportement que nous allons citer peut également avoir un motif légitime. Il est crucial d’examiner ces exemples en conjonction avec d’autres activités et de collaborer étroitement avec les équipes RH et juridique. Nous recommandons vivement d’adopter une approche basée sur le risque et de comparer différents indicateurs issus de plateformes techniques et non techniques avant de formuler une conclusion. Les alertes basées sur les risques (RBA), une fonctionnalité de Splunk Enterprise Security, peuvent faire partie de cette approche. Si vous débutez avec les RBA, le Guide essentiel des alertes basées sur les risques vous sera d’une aide précieuse et vous apprendra à configurer ce type d’alertes dans votre environnement Splunk. Les RBA vous donneront une image plus complète de la situation, et cette évaluation exhaustive sera particulièrement appréciée de vos équipes RH et juridique. En gardant cela à l’esprit, passons maintenant à l’analyse des stratégies techniques de détection.

Incohérences dans l’expédition de l’ordinateur portable

La détection automatisée est difficile à exploiter avant le recrutement d’un collaborateur, mais la phase d’intégration offre des occasions uniques de détecter les activités suspectes. Par exemple, une démarche très simple comme l’envoi du matériel informatique peut révéler des indices essentiels.

Nombre d’acteurs du secteur des technologies ont signalé que les fraudeurs au télétravail demandent à ce que le matériel soit envoyé à une adresse qui ne correspond pas à leur localisation officielle, souvent en invoquant des raisons aussi alambiquées que difficiles à vérifier. Cette difficulté peut être purement logistique, mais elle peut aussi impliquer un risque de violation de la vie privée lorsque le collaborateur justifie sa demande par une urgence médicale ou un déménagement temporaire. L’incohérence entre l’adresse d’expédition et la localisation du collaborateur peut avoir une explication parfaitement légitime, mais combinée à d’autres comportements, elle peut trahir un tout autre scénario.

Ces incohérences ne sont pas toujours faciles à identifier. Une validation manuelle est toujours possible, mais difficilement réaliste dans une grande entreprise. Splunk peut vous aider à identifier ces incohérences en corrélant les données du système de suivi des candidatures et celles des envois d’ordinateurs portables. Vous allez donc échanger avec votre équipe de gestion des actifs pour en savoir plus sur le déploiement du matériel informatique et le processus d’expédition aux nouvelles recrues afin d’importer ces données dans votre déploiement Splunk. Vous aurez également besoin de données sur les nouveaux collaborateurs ; celles-ci peuvent se trouver dans un système de suivi des candidatures ou autre référentiel dédié aux futurs employés.

La requête suivante utilise les données d’une instance ServiceNow, jointes aux informations Workday des employés, pour détecter les collaborateurs qui demandent à ce que leur ordinateur soit envoyé à une adresse différente de leur adresse physique officielle.

Requête de détection des incohérences dans l’envoi du matériel informatique

index=servicenow sourcetype=laptop_shipment ```données d’expédition du matériel informatique```
| eval delivered_location=case(arrivalState="CA","California", arrivalState="TX","Texas", arrivalState="WA","Washington",arrivalState="VA","Virginia",arrivalState="OR","Oregon") ```indiquez les emplacements de destination les plus courants à reconnaître```
| table name Shipped_status arrivalTime employeeId Email home_state postalCode arrivalState delivered_location arrivalLocation
| join type=outer Email ```On compare les données d’expédition du matériel en faisant une jointure sur l’e-mail de l’employé avec les données enregistrées à son sujet. Si l’employé n’a pas encore d’adresse e-mail, on peut utiliser son ID pour effectuer la corrélation```
    [ search index=identity sourcetype=workday:employee earliest=-24h ```Fichier de log source pour les données de l’employé```
    | dedup name employeeId home_state]
| search delivered_location=*
| eval Suspicious=if(delivered_location==home_state,"No","Yes") ```Si le matériel a été livré dans un état qui ne correspond pas à l’adresse personnelle figurant dans les dossiers```
| search Suspicious="Yes"

La capture d’écran ci-dessus illustre le cas d’un utilisateur qui prétend habiter en Pennsylvanie, mais qui a demandé qu’on envoie son matériel dans l’Oregon. Un champ « Suspicious » (suspect) a été créé dans Splunk Enterprise pour indiquer une incohérence entre le champ « home_state » (état du domicile) et le champ « delivered_location » (adresse d’expédition). Cet exemple peut aisément être transposé à une expédition internationale et modifié en fonction des besoins de votre entreprise.

Trafic en provenance d’un fournisseur inhabituel de réseau privé virtuel (VPN)

Les fraudeurs au télétravail utilisent souvent un VPN pour dissimuler leur véritable emplacement physique. Ils masquent leur adresse IP d’origine et semblent basés dans une région où leur service de VPN a un nœud. C’est l’un des indicateurs que l’on peut détecter par un moyen technique une fois que le malfaiteur est en possession d’un appareil d’entreprise.

Si le VPN dissimule la véritable adresse IP du fraudeur, il crée également un nouveau signal : un trafic en provenance d’un fournisseur de VPN inattendu. Mais il peut arriver qu’un collaborateur en télétravail ait une raison légitime d’utiliser un VPN. C’est là que l’établissement d’un profil de référence et la gestion des exceptions peuvent être utiles (nous y reviendrons plus loin). Vous pouvez facilement observer le trafic provenant de VPN suspects en quelques étapes, grâce aux logs de votre fournisseur d’identités (IdP). Voici un exemple qui exploite les données Okta et recherche des fournisseurs courants de VPN/VPS.

Requête de détection d’utilisation de VPN inhabituel

index=okta sourcetype=OktaIM2:log ```saisissez la source des logs de votre IdP``` debugContext.debugData.tunnels IN (*Astrill*,*Azire*,*CyberGhost*,*Express*VPN,*HideMe*,*IPVanish*,*Mullvad*,*Nord*VPN*,*OVPN*,*PIA*VPN*,*Proton*VPN*,*Pure*VPN*,*Slick*VPN*,*Surf*Easy*,*SurfShark*,*Star*VPN*,*TorGuard*,*TorProxy*,*Tiger*VPN*,*TunnelBear*,*Unblock*VPN*,*Warp*VPN*,*WarpSpeed*,*VPNReactor*,*VPN*Shield*,*VPN*Super*VPN*,*ZenMate*) ```liste des fournisseurs de VPN courants. Ajoutez ou retirez des noms en fonction des caractéristiques de votre environnement```
| eval user=coalesce(’actor.alternateId’,user), user=mvindex(split(user, "@"), 0)
| rename targetUserAlternateId as user client.* as * request.* as * ipChain{}.* as * geographicalContext.* as * debugContext.* as * debugData.* as *
| eval status=case(match(_raw, "FAILURE"), "failure", !match(_raw, "FAILURE"), "success")
| stats count values(status) as status max(published) as UTC min(_time) as firsttime max(_time) as lasttime values(target_data) as target_data values(displayMessage) as displayMessage values(eventType) as eventType values(city) as city values(country) as country values(action) as action values(src_ip) as src_ip values(outcome.*) as * values(user) as user by tunnels,_time,host sourcetype index
| fillnull value="N/A"
| convert ctime(*ttime)
    ```| where isnotnull(user)``` ```décommentez cette ligne si vous voulez uniquement voir les événements pour lesquels un utilisateur réel a été enregistré dans l’IdP```

La liste de fournisseurs VPN indiquée ci-dessus n’est pas exhaustive et nous vous recommandons de mettre la vôtre à jour régulièrement. Pour obtenir la liste des VPN les plus courants, vous pouvez faire une recherche dans vos logs.

Votre fournisseur d’identité peut également vous aider ! La plupart des grands IdP vous permettent de bloquer le trafic des fournisseurs de VPN connus qui peuvent entrer en conflit avec la politique de votre entreprise. Vous trouverez ci-dessous quelques captures d’écran des consoles Okta et Duo expliquant où et comment bloquer le trafic anonymisé par VPN. Dans Okta, ce mécanisme de blocage est défini en tant que Zone réseau ; une fois configurée, celle-ci peut servir à refuser le trafic VPN. De la même manière, dans Duo, les réseaux autorisés peuvent être configurés pour produire un effet similaire.

Interface d’administration d’Okta présentant une Zone réseau et la configuration du blocage.

Capture d’écran de l’IdP Duo montrant comment refuser l’accès aux fournisseurs d’anonymisation de trafic (VPN) ou demander un deuxième facteur d’authentification.

Déplacements impossibles

Les données de géolocalisation peuvent être imprécises, mais elles sont aussi faciles à falsifier par des fraudeurs au télétravail. Il leur arrive toutefois de faire des erreurs et de révéler leur véritable localisation en créant ce qu’on appelle un scénario de « déplacement impossible », comme des connexions depuis deux régions distantes du monde à quelques minutes d’intervalle. Mais attention : cette détection demande une grande finesse d’ajustement. Il ne faudrait pas suspecter votre VP des ventes parce qu’il a fait le trajet de New York à Londres pour une réunion. Concentrez-vous sur les nouveaux collaborateurs qui n’ont normalement pas besoin de se déplacer à des fins professionnelles à ce stade de leur rôle.

Nous pouvons même aller plus loin et observer les déplacements incohérents ou impossibles qui révèlent le véritable emplacement physique d’un fraudeur. Même si ce cas est rare, il est important de le rechercher. De nombreuses sources de log peuvent vous aider à détecter une localisation improbable ou un trafic acheminé depuis des emplacements insolites. Voici les principales sources : logs des IdP (Okta, Duo, Azure, etc.), logs de pare-feux (Cisco, Palo Alto, Fortinet, Checkpoint, etc.), logs des EDR (Crowdstrike, Cisco CSE, FireEye, SentinelOne, etc.) et logs des plateformes de messagerie (Zoom, Webex, Teams, Google Meet, etc.).

La requête suivante utilise le modèle de données Authentification et Splunk Enterprise Security pour détecter un déplacement impossible en calculant une approximation de la distance à parcourir et de la « vitesse » de déplacement pour qu’un utilisateur puisse se connecter ou travailler depuis deux emplacements différents dans un intervalle donné. Elle compare ensuite la vitesse et la distance au seuil que vous aurez défini. La requête ci-dessous est une section SPL complète. Vous devrez l’adapter à votre environnement, mais la logique et les calculs sous-jacents peuvent être utilisés avec vos propres données.  Nous vous encourageons à affiner vos requêtes pour votre environnement, notamment en limitant les seuils de vitesse et de distance.

Requête de détection des emplacements géographiques improbables

| tstats summariesonly=true values(Authentication.app) as app from datamodel=Authentication.Authentication where ((index="okta" AND sourcetype="OktaIM2:log") OR (index="firewall" AND sourcetype="pan:globalprotect")) ```Indiquez vos sources de log d’authentification en veillant à utiliser le modèle de données Authentification sous sa forme accélérée``` AND Authentication.action="success" AND Authentication.app IN ("Workday", "Slack", "*GlobalProtect", "Jira*", "Atlassian Cloud", "Zoom") AND NOT Authentication.user="unknown" by _time index sourcetype host Authentication.user Authentication.src span=1s ```Choisissez les applications à superviser en priorité pour détecter les accès géographiquement impossibles. Voici quelques exemples```
| `drop_dm_object_name("Authentication")`
| fields user,src,app,_time,count,host
| eval user=lower(replace(user, "((^.*\\\)|(@.*$))", "")) ```On normalise la façon dont l’utilisateur apparaît```
| join type=outer user
    [| inputlookup identity_lookup_expanded where user_status=active ```Lookup d’actifs et d’identités provenant de Splunk Enterprise Security, détenant toutes les identités ainsi que leurs informations respectives```
| rex field=email "^(?<user>[a-zA-Z0-9_\-\.]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$"
| rename email as user_email bunit as user_bunit priority as user_priority work_country as user_work_country work_city as user_work_city
| fields user user_email user_bunit user_priority user_work_country user_work_city]
| eventstats dc(src) as src_count by user
| eventstats dc(user) as user_count by src
| sort 0 + _time
| iplocation src
| lookup local=true asn_lookup_by_cidr ip as src OUTPUT ip asn description ```Lookup fournie avec Splunk pour le suivi des informations ASN```
| eval session_lat=if(isnull(src_lat), lat, src_lat), session_lon=if(isnull(src_long), lon, src_long), session_city=if(isnull(src_city), City, src_city), session_country=if(isnull(src_country), Country, src_country), session_region=if(isnull(src_region), Region, src_region)
| eval session_city=if(isnull(session_city) OR match(session_city,"^\s+|^$"), null(), session_city), session_country=if(isnull(session_country) OR match(session_country,"^\s+|^$"), null(), session_country), session_region=if(isnull(session_region) OR match(session_region,"^\s+|^$"), null(), session_region)
| where isnotnull(session_lat) and isnotnull(session_lon)
| eval session_city=if(isnull(session_city),"-",session_city), session_country=if(isnull(session_country),"-",session_country), session_region=if(isnull(session_region),"-",session_region)
| streamstats current=t window=2 earliest(session_region) as prev_region,earliest(session_lat) as prev_lat, earliest(session_lon) as prev_lon, earliest(session_city) as prev_city, earliest(session_country) as prev_country, earliest(_time) as prev_time, earliest(src) as prev_src, latest(user_bunit) as user_bunit, earliest(app) as prev_app values(user_work_country) as user_work_country by user
| where (src!=prev_src) AND !(prev_city=session_city AND prev_country=session_country) AND ((isnotnull(prev_city) AND isnotnull(session_city)) OR prev_country!=session_country) ```On recherche les disparités entre l’IP précédente et l’IP actuelle, entre la ville précédente et la ville actuelle, ou entre le pays précédent et le pays actuel```
| `globedistance(session_lat,session_lon,prev_lat,prev_lon,"m")` ```commande intégrée permettant de calculer la distance```
| eval time_diff=if((_time-prev_time)==0, 1, _time - prev_time)
| eval speed = round(distance*3600/time_diff,2)
| eval distance= round(distance,2)
| eval user_work_country=case(user_work_country="usa","United States", user_work_country="cze","Czechia",user_work_country="pol","Poland", user_work_country="ind","India", user_work_country="fra","France", user_work_country="can","Canada", user_work_country="mys","Malaysia", user_work_country="kor","South Korea", user_work_country="aus","Australia", user_work_country="bel","Belgium", user_work_country="dnk","Denmark", user_work_country="bra","Brazil", user_work_country="deu","Germany", user_work_country="jpn","Japan", user_work_country="che","Switzerland", user_work_country="swe","Sweden", user_work_country="zaf","South Africa", user_work_country="irl","Ireland", user_work_country="ita","Italy", user_work_country="nor","Norway", user_work_country="gbr","United Kingdom", user_work_country="hkg","Hong Kong", user_work_country="chn","China", user_work_country="esp","Spain", user_work_country="nld", "Netherlands", user_work_country="twn","Taiwan", user_work_country="est","Estonia", user_work_country="sgp","Singapore", user_work_country="are","United Arab Emirates", 1=1,"N/A") ```Pays apparaissant couramment dans les logs des IdP, normalisés pour apparaître sous leur nom complet```
| lookup local=true asn_lookup_by_cidr ip as prev_src OUTPUT ip as prev_ip asn as prev_asn description as prev_description
| eval suspect=if(!user_work_country==session_country,"Sketchy","Normal") ```On détermine si le pays où travaille un utilisateur correspond à son pays actuel```
| search (speed>500 AND distance>750) ```Ce déplacement devrait être impossible dans l’intervalle donné```
| table _time,prev_time,user,host,src,prev_src,app,prev_app,distance,speed,suspect,session_city,session_region,session_country,prev_city,prev_region,prev_country,user_priority,user_work_*,prev_ip,ip,asn,prev_asn,prev_description,description
| rename _time as event_time
| convert ctime(event_time) timeformat="%Y-%m-%d %H:%M:%S"
| convert ctime(prev_time) timeformat="%Y-%m-%d %H:%M:%S"
| eval problem=if(!session_country==prev_country AND (!session_country==user_work_country),"Yes","Nope")
| search NOT (prev_city="-" OR session_city="-") AND NOT
    [inputlookup known_devices_public_ip_filter.csv
    | fields ip
    | rename ip as src]  ```On ajoute une lookup des IP connues pour éliminer les faux positifs``
| dedup user host prev_src src
| fillnull value="N/A"
| search problem="Yes"

Appareils audio/vidéo virtuels  

D’après les observations, certains fraudeurs au télétravail utilisent des appareils audio/vidéo virtuels dans leurs efforts pour masquer leur emplacement réel lors des appels sur Cisco Webex, Zoom ou Microsoft Teams. Grâce à cette technique, l’appel audio/vidéo semble provenir d’un emplacement conforme à la localisation de l’employé ou du candidat. En réalité, le fraudeur transmet son trafic audio/vidéo via un emplacement intermédiaire, généralement une ferme d’ordinateurs.

La détection de cette activité demande une analyse attentive, des examens réguliers et une excellente compréhension des appareils audio et vidéo utilisés dans votre environnement. La clé de la détection consiste à commencer par établir le profil de référence de votre environnement pour identifier les valeurs anormales. Cela vous permettra, par exemple, de repérer qu’un nouveau collaborateur utilise une caméra virtuelle que personne d’autre n’utilise dans l’entreprise. Les logs d’audit des outils de téléconférence et de collaboration comme Zoom, Cisco Webex et Microsoft Teams peuvent également permettre d’identifier les appareils utilisés par les fraudeurs au télétravail. La recherche ci-dessous identifiera les appareils audio/vidéo inhabituels ou atypiques utilisés sur ces plateformes.

Requête de détection des appareils audio/vidéo et de streaming inhabituels

index=zoom      sourcetype=zoom:metrics:meetings:participant ```Indiquez la source de log audio/vidéo appropriée``` camera=* microphone=* speaker=*  ```On recherche les logs qui contiennent des informations sur les caméras, les micros et les haut-parleurs utilisés``` NOT (camera=*iPhone* OR camera="*FaceTime*" OR speaker="*AirPods*" OR camera="*MacBook*" OR microphone="*MacBook Pro Microphone*") ```Généralement, les fraudeurs au télétravail utilisent une combinaison de caméra/micro/haut-parleur unique dans l’environnement. Que ce soit sur Mac ou sur PC, il y aura au moins un indicateur anormal signalant l’utilisation d’un outil rarement observé dans la base d’utilisateurs globale.``` ```Utilisez la commande rare pour examiner successivement les caméras, les micros et les haut-parleurs. Décommentez chaque ligne ci-dessous une par une, en veillant à ce qu’une seule commande rare soit décommentée à la fois```
| rare camera limit=50 ```Recherche mettant en évidence les 50 caméras les plus rares```
```| rare speaker limit=50```
```| rare microphone limit=50```
```Une fois que vous savez quels sont les caméras, les micros et les haut-parleurs les plus rares, vous pouvez les spécifier directement dans la recherche```

Le fraudeur qui gère l’identité du faux collaborateur peut, dans certains cas, utiliser des points de saut pour dissimuler son emplacement ou celui de son appareil d’entreprise. Ce phénomène peut être détecté en examinant et en corrélant attentivement les logs concernés. La corrélation des logs de différentes plateformes comme Zoom et Workday HR est une bonne pratique standard pour l’identification des incohérences. Dans l’exemple de code ci-dessous, les logs de Zoom ont été corrélés avec les logs RH (Workday) de l’utilisateur.

Requête de détection des appareils audio/vidéo rares avec des incohérences dans l’emplacement physique apparent

index=zoom sourcetype=zoom:metrics:meetings:participant ```Indiquez la source de log de streaming audio/vidéo appropriée``` camera="*Stream*"  (speaker="*Headphones*" OR speaker="*DarkStar*" OR microphone="*Tiny*")   ```Déclarez toutes les combinaisons rares de caméras, microphones et hauts-parleurs qui seraient inhabituelles dans votre environnement. Ce sont des exemples```
| table join_time leave_time leave_reason speaker camera location microphone user_name role pc_name email ip_address
| where isnotnull(role) ```On affiche uniquement les résultats lorsque l’utilisateur a participé à une réunion Zoom ou l’a organisée```
| stats count min(join_time) as join_time max(leave_time) as leave_time values(pc_name) as pc_name values(leave_reason) as leave_reason by ip_address speaker camera location microphone user_name role email ```La localisation figure dans les logs, mais elle est générique, donc on utilise également iplocation avec ip_address```
| iplocation ip_address
| rename email as work_email
| join type=outer work_email
    [ search index=identity sourcetype=workday:employee earliest=-24h ```On joint les données RH, dans notre cas il s’agit de Workday```
    | spath All_Work_Addresses output=Workday_location
    | spath primaryWorkEmail output=work_email
    | spath Employee_ID output=employeeNumber
    | spath Preferred_Name output=name
    | spath "Location_Address_-_State__United_States_" output=state  
| table Workday_location name state work_email employeeNumber
| dedup name employeeNumber state]
| eval problem=if(Region==state,"No","Yes") ```La région a été fournie par iplocation sur l’adresse IP dans Zoom, l’état provient des logs de Workday```
| search problem="Yes" Workday_location=* ```On cherche les résultats qui présentent une incohérence```
| fields - lat lon
| table ip_address speaker camera microphone location City Country Region state Workday_location problem ```work_email masqué dans les résultats pour des raisons de confidentialité```

Comme on le voit dans l’exemple de résultats de recherche ci-dessous, les logs de Zoom indiquent que les télétravailleurs sont basés en Californie et en Virginie. Pourtant, dans Workday, ces employés sont censés habiter au Texas, dans le Maryland ou dans l’Idaho. La localisation RH dans l’Idaho ne correspond jamais aux logs Zoom. Ce télétravailleur semble au contraire se trouver en Californie, et pas dans l’Idaho. Le champ « problem » a été créé pour signaler une incohérence géographique entre la localisation de l’appareil Zoom d’un collaborateur et son emplacement enregistré dans les systèmes RH.

Exemples d’événements trahissant une incohérence dans la localisation d’un employé

Observation d’une grande latence vidéo

Un examen plus approfondi du trafic réseau, en particulier en provenance des applications de visioconférence, peut être utile pour corroborer d’autres preuves. Dans certains cas, les fraudeurs se trahissent par une latence bien supérieure à celle de la majorité des employés. La latence peut, bien sûr, être le résultat d’une mauvaise connexion ; mais lorsqu’elle s’ajoute à d’autres indicateurs, elle peut confirmer une suspicion. Les fraudeurs au télétravail utilisent généralement différents logiciels de streaming pour se connecter via des fermes d’ordinateurs, ce qui peut provoquer des phénomènes de latence, de chute de frame rate ou de basse résolution. Bien souvent, les fermes d’ordinateurs auxquelles ces fraudeurs ont recours emploient différents intermédiaires ou changent de tactique, ce qui facilite la détection. Dans le code SPL ci-dessous, l’analyse de l’environnement a déterminé qu’une latence vidéo de 150 ms était élevée et inhabituelle. Un seuil à 300 ms fait encore plus ressortir les valeurs aberrantes. 

Requête de détection des latences vidéo élevées

index=zoom  ```Utilisez la source de données audio/vidéo appropriée```
| spath "payload.object.participant.qos{}.type"
| search "payload.object.participant.qos{}.type"=video_input ```On s’intéresse à l’entrée vidéo, car c’est là que le lag sera le plus évident```
| rename payload.object.participant.qos{}.details.avg_latency as avg_latency "payload.object.participant.qos{}.details.latency" as latency payload.object.participant.email as email
| rex field=avg_latency "(?<average_latency>\d+) ms"
| rex field=latency "(?<overall_latency>\d+) ms"
| search email="*@splunk.com" ```Remplacez par le domaine de messagerie de votre entreprise```
| table email overall_latency latency avg_latency average_latency _raw
| stats latest(overall_latency) as overall_latency by email _raw
| where overall_latency>300 ```Une latence de 150 ms devrait être très visible par l’utilisateur final```

Utilisations diverses des outils d’accès à distance

Les outils d’accès à distance offrent de nombreuses possibilités aux acteurs malveillants. Ils ont des fonctionnalités communes : transfert de fichiers, contrôle de système à distance et redirection d’appareil, notamment. Un fraudeur au télétravail peut utiliser ces capacités pour accomplir différentes tâches sur le réseau ; il peut, par exemple, exfiltrer des fichiers, installer des logiciels malveillants et travailler à distance sur le système en masquant sa localisation. Mais l’utilisation de ce type de logiciel peut être détectée. Certaines entreprises ont des licences d’outils d’accès à distance comme Splashtop ou TeamViewer. Dans ce cas, l’entreprise assume le coût des versions payantes de ces logiciels. Dans les opérations de fraude au télétravail, les outils payants sont plus rares. Il est important de commencer par examiner l’environnement pour savoir quels outils et programmes d’accès à distance sont autorisés ou interdits. Le meilleur moyen de proscrire ce comportement consiste à bloquer l’exécution de ces applications sur un poste de travail à l’aide d’un outil de gestion comme Jamf, JumpCloud, Intune ou AppLocker, voire d’un EDR comme Crowdstrike, SentinelOne, Cisco CSE ou autre.

Vous pouvez rechercher les usages non autorisés dans les logs des endpoints en vous appuyant sur une liste standard d’outils d’accès à distance. Déterminez quels outils sont interdits ou autorisés dans votre environnement, puis interrogez vos données EDR pour savoir si quelqu’un les utilise. Ci-dessous, quelques exemples de dépôts GitHub contenant les noms d’applications de ce type.

• https://github.com/jischell-msft/RemoteManagementMonitoringTools
• https://github.com/0x706972686f/RMM-Catalogue/blob/main/rmm.csv
• https://github.com/LivingInSyn/RMML/tree/main/RMMs
• https://github.com/magicsword-io/LOLRMM/tree/main/yaml

À savoir : ces dépôts sont une excellente ressource pour obtenir une liste des outils d’accès à distance, mais ils peuvent devenir obsolètes. Vérifiez systématiquement la source et ne lui faites pas une confiance aveugle.

Requête de détection des outils d’accès à distance

index=edr* sourcetype=crowdstrike:falcon:fdr:* CommandLine ```Indiquez la source des logs EDR qui contient des informations CommandLine et Process Application``` IN (
    *Splashtop*,
    *LogMeIn*) ```Ce ne sont que des exemples. Nous recommandons d’obtenir une liste complète d’outils d’accès à distance auprès de différents dépôts Git et d’en saisir les noms dans la déclaration IN``` OR AppName IN (*Splashtop*,
    *LogMeIn*) ```Indiquer les mêmes exemples ici``` ```On exclut les processus et les applications connus```
| eval App=coalesce(AppName,ParentBaseFileName) ```On combine le nom de l’application et le nom du fichier parent s’il est connu```
| fillnull value="null"
| stats values(App) as App by AppName event_simpleName ParentBaseFileName ImageFileName CommandLine ```On agrège par eventtype, Commandline, processus, processus parent et nom d’application```
| convert ctime(*time)
| sort 0 + f_time
| stats count values(ParentBaseFileName) as ParentBaseFileName values(CommandLine) as CommandLine by event_simpleName App
| table App event_simpleName ParentBaseFileName CommandLine

Envisagez les choses dans leur ensemble

Il est impératif de garder en tête que, prise isolément, aucune des stratégies ci-dessous ne peut confirmer la présence d’un fraudeur au télétravail dans votre organisation. Au contraire, il faut évaluer conjointement plusieurs indicateurs pour produire une évaluation de confiance.

La RBA se prête parfaitement à ce scénario d’utilisation. Elle permet à votre entreprise d’agréger des indicateurs et d’observer des motifs de comportement potentiellement incompatibles avec le profil d’un télétravailleur classique. Ces cas isolés peuvent faire l’objet d’un examen plus approfondi, en mobilisant également des indicateurs non techniques et en procédant à une évaluation holistique avec la participation des équipes RH et juridique de l’organisation.

Vous détenez désormais de puissantes détections Splunk pour identifier les possibles fraudeurs au télétravail au moment de l’intégration et après. Si les techniques des adversaires évoluent sans cesse (c’est la règle du jeu), la mise en place de détections reste une première étape cruciale ; en sachant quoi chercher, vous aurez fait la moitié du chemin vers la victoire.

Le défi suivant, celui de la réponse, présente un tout autre niveau de complexité, car il implique de tenir compte des subtilités du paysage des RH et du juridique. Contrairement aux menaces techniques traditionnelles, la réponse à la fraude au télétravail nécessite un partenariat bien plus étroit que d’habitude entre les équipes techniques et RH. Dans notre dernier article, nous vous expliquerons comment différentes équipes de Splunk ont collaboré pour identifier, examiner, évaluer et signaler les cas de fraude au télétravail. Vous aurez ainsi un guide détaillé pour établir un plan de réponse interfonctionnel performant en environnement réel. Ne le manquez pas.