Démonstration de la recherche DNS passive inversée en masse avec PowerShell pour la sécurité informatique | Reverse IP/DNS API | WhoisXML API

Démonstration de la recherche DNS passive inversée avec PowerShell pour les enquêtes de sécurité informatique : le cas du botnet Phorphiex

Les adresses IP sont des données d'entrée simples pour les enquêtes de sécurité informatique : elles sont techniquement nécessaires pour que les nœuds Internet puissent communiquer. Par conséquent, si elles ne sont pas supprimées d'une manière ou d'une autre après la commission d'un délit cybernétique, ou si elles sont trouvées dans l'un des registres avant la commission du délit, elles aident beaucoup à comprendre ce qui s'est réellement passé. 

IBM Xforce exchange est un forum qui rapporte de nombreux incidents de sécurité qui sont pertinents pour ceux qui sont en charge du maintien de la sécurité informatique. Dans cet article, nous allons choisir l'un de leurs rapports et vérifier comment nous pouvons étendre les informations données avec les APIs WhoisXML en utilisant PowerShell qui est installé sur Windows et peut être utilisé sur Linux et Mac OS X, également. Nous supposons que vous avez des compétences intermédiaires en programmation PowerShell pour suivre la description ci-dessous. 

Nous utiliserons des données DNS passives, fournies par Reverse DNS API de WhoisXML API : nous pouvons obtenir une liste d'événements de communication réseau observés par des capteurs DNS passifs dans lesquels une IP donnée se résout en un nom de domaine réel. Cela signifie que l'adresse IP donnée communiquait à un moment donné sur Internet sous le nom de domaine donné, une information qui ne peut être obtenue à partir du système de noms de domaine lui-même. En même temps, cela aide beaucoup à révéler le caractère de l'adversaire malveillant, comme le montrera la recherche démonstrative suivante. 

1. Obtention de données à partir d'une collection IBM XForce 

Notre sujet sera l'activité récemment observée du botnet Phorphiex. Je cite la description d'IBM ( https://exchange.xforce.ibmcloud.com/collection/Phorpiex-Botnet-Extortion-Activity-Monitoring-76265914d081e79d158260bf5385a9da, consulté le 19 août 2021), 

« La collection continue d'IBM X-Force a été créée pour vous fournir les derniers IoC et renseignements sur l'activité d'extorsion du botnet Phorpiex trouvée dans notre environnement. La collection sera mise à jour automatiquement dès que de nouvelles découvertes auront été faites. Veuillez noter que les IoCs de cette collection sont actionnables et peuvent donc être utilisés pour des blocages afin de protéger votre environnement. Pour cette raison, il peut arriver que des codes de référence spécifiques soient retirés de la collection dans un intervalle de temps dynamique lorsque plus aucune preuve n'est disponible pour étayer le caractère malveillant de l'indicateur ». 

« Le réseau de zombies Phorpiex était initialement connu comme un réseau de zombies utilisant le protocole IRC pour ses opérations avant de passer à une architecture modulaire. La distribution se fait par le biais de kits d'exploitation et grâce au soutien d'autres familles de logiciels malveillants. Fort de ce succès, ses opérateurs exploitent désormais les opérations en tant que Malware-as-a-Service (MaaS). Cette offre permet à d'autres cyber-gangs d'utiliser l'infrastructure du botnet à des fins malveillantes. Toutefois, les campagnes de spam dites de « sextorsion » constituent une grande partie des menaces quotidiennes. Dans les campagnes de spam, la sextorsion consiste à contraindre les victimes à payer une certaine somme d'argent dans un délai donné sous la menace de publier des photos ou des vidéos intimes de la victime. On sait qu'il s'agit d'une fausse menace puisqu'il n'existe aucun cas connu à ce jour où les auteurs de la menace ont prouvé qu'ils possédaient ce type de matériel ». 

IBM X-Force Exchange fournit une collection de rapports contenant des adresses IP à partir desquelles l'activité de ce botnet a été récemment observée. Au moment de la rédaction de cet article, la liste des adresses IP peut être déduite des informations téléchargées à partir d'IBM X-Force Exchange. Un fichier peut être téléchargé à partir du lien susmentionné en choisissant l'option « Export » dans le menu situé à côté du bouton « I'm affected ». En choisissant le format STIX 2.0, vous obtiendrez un fichier téléchargé dans un format JSON standard à partir duquel les adresses IP peuvent être déduites et traitées ultérieurement. 

2. Distiller les adresses IP à partir d'un rapport au format STIX 2.0 

Notre fichier STIX 2.0 téléchargé a été sauvegardé sous le nom xfe-collection_76265914d081e79d158260bf5385a9da.json . Pour obtenir la liste des IP avec PowerShell, dans le répertoire où se trouve le fichier téléchargé, nous effectuons la conversion suivante : 

$data=Get-Content ".\xfe-collection_76265914d081e79d158260bf5385a9da.json" |
ConvertFrom-Json
$data.objects.pattern |
foreach {$_ | Select-String -Pattern '(\d{1,3}\.){3}\d{1,3}'} |
foreach {$_.Matches.Value} > ips.csv 

La première commande convertit les entrées de la collection en un objet PowerShell. La deuxième ligne récupère le champ « pattern » du JSON qui contient également l'adresse IP dans une chaîne de caractères. Nous obtenons ensuite l'adresse IPv4 à l'aide d'une expression régulière. Le fichier ips.csv qui en résulte contient une adresse IP par ligne. Dans l'étape suivante, nous développerons un script qui complète ce fichier avec des informations DNS passives en utilisant Reverse IP API. 

3. Un script pour étendre la liste des IP avec des données DNS passives inversées 

Notre objectif d'étendre une liste d'adresses IP avec des données DNS passives inversées peut être atteint en utilisant la cmdlet PowerShell avec le code suivant (il est recommandé de l'enregistrer par exemple sous le nom ExtendIPCsvWithReversePDNS.ps1) : 

#Extends a list of IPs with Reverse IP/DNS lookup results
# The input list does not contain a header and contains valid IPs
#Usage:
# 1. set the environment variable APIKEY to your API key:
#    PS C:\Users\User\WorkingDirectory> $APIKey="YOUR_API_KEY"
# 2. Once done, you can run it like this:
#   PS C:\Users\User\WorkingDirectory> .\ExtendIPCsvWithReversePDNS.ps1
'.\inputfile.csv' '.\outputfile.csv'
# Note: if the output file exists and is not empty, the results will be appended.

[CmdletBinding()]
param(
    [string] $InputFile,
    [string] $OutputFile
)

$BaseUrl = "https://reverse-ip.whoisxmlapi.com/api/v1?apiKey=" + $ENV:APIKEY +"&ip="

Function Convert-FromUnixDate ($UnixDate) {

[timezone]::CurrentTimeZone.ToUniversalTime(([datetime]'1/1/1970').AddSeconds($UnixDate))
}

Import-Csv -Header "IP" -Path $InputFile | ForEach-Object {
Write-Host $_.IP
$URI = $BaseUrl + $_.IP
#Need this to be visible in the catch branch
$IP = $_.IP
$IPData = [PSCustomObject]@{
IP = $IP
}
try{
$APIResponse = Invoke-WebRequest -Uri $URI -UseBasicParsing
$k=0
$Result = ConvertFrom-Json $APIResponse.Content
foreach($row in $Result.result) {
$first_seen = Convert-FromUnixDate $row.first_seen
$last_visit = Convert-FromUnixDate $row.last_visit
Write-Host $k $row.name $first_seen $last_visit
$field1 = "name_" + [string]$k
$field2 = "first_seen_" + [string]$k
$field3 = "last_visit_" + [string]$k
$IPData | Add-Member -MemberType NoteProperty -Name $field1 -Value $row.name
$IPData | Add-Member -MemberType NoteProperty -Name $field2 -Value $first_seen
$IPData | Add-Member -MemberType NoteProperty -Name $field3 -Value $last_visit
$k += 1}
for($l=$k; $l -lt 300; $l++){
$field1 = "name_" + [string]$l
$field2 = "first_seen_" + [string]$l
$field3 = "last_visit_" + [string]$l
$IPData |
    Add-Member -MemberType NoteProperty -Name $field1 -Value " "
$IPData |
    Add-Member -MemberType NoteProperty -Name $field2 -Value " "
$IPData |
    Add-Member -MemberType NoteProperty -Name $field3 -Value " "
}
}
catch{
Write-Host "Ran into an issue: $($PSItem.ToString())"
for($l=0; $l -lt 300; $l++){
$field1 = "name_" + [string]$l
$field2 = "first_seen_" + [string]$l
$field3 = "last_visit_" + [string]$l
$IPData |
    Add-Member -MemberType NoteProperty -Name $field1 -Value " "
$IPData |
    Add-Member -MemberType NoteProperty -Name $field2 -Value " "
$IPData |
    Add-Member -MemberType NoteProperty -Name $field3 -Value " "
}
}
$IPData |
    Export-Csv -Append -NoTypeInformation -Encoding UTF8 $OutputFile
}

Le script contient des instructions d'utilisation dans les premières lignes de commentaire afin d'être régulier ; nous décrirons plus loin la manière de l'invoquer. En ce qui concerne son fonctionnement, nous définissons deux arguments positionnels : le fichier d'entrée qui est une liste d'adresses IP une par ligne, et le fichier de sortie auquel le résultat sera annexé. Nous stockons l'URL de base de l'API dans $BaseUrl. La fonction Convert-FromUnicDate a pour but de convertir les temps renvoyés en Epoch par l'API en dates. 

La boucle principale récupère les adresses IP par le biais d'un pipeline. Pour chaque IP, nous stockons l'enregistrement dans $IPData. L'appel à l'API et son traitement se font dans un try-catch pour gérer le cas où quelque chose se passerait mal. Nous invoquons l'API avec Invoke-WebRequest et analysons le JSON résultant avec ConvertFrom-Json. Nous voulons que chaque IP soit une ligne dans le fichier csv de sortie, nous parcourons donc en boucle le champ de résultat de l'API, qui est une liste de résultats, et nous faisons correspondre le nom, la première_visite et la dernière_visite de chaque enregistrement à un champ suivant avec un numéro ordinal. Comme Export-Csv ne peut pas gérer un nombre variable de flux par ligne pour le moment, nous remplissons les champs restants avec une valeur d'un seul espace en tant que placeholder. Nous faisons de même dans la branche catch pour avoir une ligne vide si quelque chose s'est mal passé, après avoir imprimé un message d'erreur à la console. (Notez que l'API renvoie jusqu'à 300 enregistrements en un seul appel ; si l'IP donnée en a plus, elle nous fournira 300 enregistrements arbitraires lorsqu'elle est appelée comme ci-dessus, c'est pourquoi nous générons des lignes avec 300 triplets de résultats ici. Nous nous référons à la documentation de l'API pour une description de la manière d'obtenir tous les enregistrements). Enfin, l'objet IPData résultant est ajouté au fichier csv de sortie. 

Pour utiliser le script, la variable d'environnement $APIKey doit être remplacée par votre clé d'API actuelle, c'est-à-dire 

$APIKey="YOUR_API_KEY"

(La chaîne YOUR_API_KEY ci-dessus doit être remplacée par votre clé API, qui est disponible après l'enregistrement sur https://reverse-ip.whoisxmlapi.com/api/signup, ou sur la page de votre compte après l'enregistrement). Ensuite, nous pouvons exécuter le script comme décrit dans le commentaire au début. Nous l'utilisons pour le fichier ips.csv que nous avons préparé précédemment, 

PS C:\NUsers\NUser\NWorkingDirectory> .\NExtendIPCsvWithReversePDNS.ps1 '.\Nips.csv' '.\Nips_result.csv'

Le résultat est le fichier ips_result.csv qui peut être importé dans un tableur ou visualisé en tant que texte. Il contient une ligne d'en-tête et une ligne pour chaque IP, comme suit : 

"91.232.140.99", "91.232.140.99.ip.rudna-net.pl", "1/4/2019 8:32:10 PM", "7/16/2021 8:09:19 AM"," "," ","

Nous avons omis les lignes car elles sont très longues. 

4. Résultats et conclusions 

Nous ne publions pas le fichier de données ici car il contient des adresses IP malveillantes et il est assez volumineux. Nous résumons plutôt nos conclusions. En examinant les résultats en détail, il est évident que beaucoup de ces adresses IP n'étaient pas présentes dans la base de données DNS passive. Une recherche directe dans le DNS a confirmé que la plupart d'entre elles n'ont pas d'enregistrement DNS inverse. Même les IP qui ont des enregistrements inversés se résolvent généralement à des noms générés automatiquement par les fournisseurs de réseaux câblés ou mobiles à des IP dynamiques. 

On peut donc en conclure que l'activité du bot est, selon l'analyse DNS inverse passive de la collection d'adresses IP, basée sur des machines d'abonnés individuels chez différents fournisseurs. 

Comme les données DNS passives contiennent des dates et que le fichier STIX 2.0 initial contient également des dates, il est possible de trouver, en corrélant les dates, les noms de domaine qui ont été réellement affectés. Sur la base des résultats, un avertissement pourrait être envoyé aux fournisseurs concernés, qui pourraient alors analyser leurs registres et informer leurs clients qui sont devenus partie intégrante de ce botnet, généralement à la suite de l'activité d'un kit d'exploitation dont ils ont été la cible. 

En résumé, nous avons décrit en détail comment on peut ajouter des informations supplémentaires à une liste d'adresses IP à l'aide de Reverse IP/DNS API. Notre démonstration a utilisé des données réelles et a abouti à des conséquences qui peuvent être directement utiles. Visitez le site https://www.whoisxmlapi.com/ pour obtenir une clé API qui vous permettra de reproduire les résultats ci-dessus ou d'effectuer des analyses similaires. Il est également intéressant d'examiner les autres outils puissants de cybersécurité de WhoisXML API.