Déplacer le curseur de la souris en PowerShell

Posté le de — Aucun commentaire ↓
Déplacer le curseur de la souris en PowerShell

Bonjour à tous, aujourd’hui je voulais vous partager un bout de script qui permet de déplacer le curseur de la souris en PowerShell. Ça parait bête, mais c’est bien pratique pour faire des blagues potaches à vos collègues, combiner avec des ruber ducky, ou faire des pièces jointes piégées à base de Macro Office. Voir simplement placer la souris à un endroit particulier dans un script avec une IHM…

Add-Type -AssemblyName System.Windows.Forms
while ($true){
  $Pos = [System.Windows.Forms.Cursor]::Position
  $x = ($pos.X % 500) + 10
  $y = ($pos.Y % 500) + 10
  [System.Windows.Forms.Cursor]::Position = New-Object System.Drawing.Point($x, $y)
  Start-Sleep -Seconds 10
}
Déplacer le curseur de la souris en PowerShell

D’ailleurs et dans la même veine, vous pouvez utiliser les objets COM pour simuler la saisie de touches au clavier hein. C’est bien pratique quand vous voulez faire des démonstrations de charges malveillantes dans des macros piégés.

Par exemple, vous créez une Macro « moisie » comme je le fait dans mon livre mais au lieu d’ouvrir un canal de contrôle-commande vers un PowerShell Empire, vous ouvrez un notepad.exe, changez le focus pour mettre le bloc note devant, et faite écrire un texte de sensibilisation dedans. Effet garantie.

$wshell = New-Object -ComObject wscript.shell
$wshell.AppActivate('Bloc-note')
Sleep 1
$wshell.SendKeys('Geek!!!')
Simuler des frappes clavier en PowerShell

Voilà, maintenant vous … Lire la suite

Interception/déchiffrement du TLS 1.3

Posté le de — 4 commentaires ↓

Bonjour à tous, Il n’y a pas longtemps, on m’a demandé pourquoi faire de l’interception/déchiffrement du TLS 1.3, ça pouvait être « compliqué » comme je le disais. J’avais en tête le truc dans les grandes lignes avec en particulier le fait que le SNI passait désormais dans le handdshake chiffré par TLS, rendant plus compliqué l’interception des clés des certificats associés à la communication.

C’était un peu léger comme explication, je me basais surtout sur mes expériences avec TLS la lecture de ce papier de Symantec/Broacom sur le sujet. Néanmoins c’était une vue très bas niveau du sujet. Puis en commençant mes recherches pour vous écrire un article sur le sujet, je suis tombé sur cet article de Vladimir Kolla :

TLS 1.3, ESNI, DoH, interception… ce n’est pas si compliqué 😉

https://greenlock.ghost.io/tls-1-3/

Et puis je me suis dis qu’il y avait pas grand chose à dire de plus en fait là…

Son article est juste nickel, s’il était en Creative Commons, je vous l’aurais bien remis « as-it » sur mon blog mais bon tant pis, je me contenterai de la ref. Du coup son post fait aussi référence au No Limit Secu sur TLS 1.3, qui … Lire la suite

The percentage of small buckets… – Splunk

Posté le de — 2 commentaires ↓

Bonjour à tous, aujourd’hui je vous partage un bug que j’ai rencontré avec un instance Splunk il y a quelques temps de ça. L’erreur en question était celle-ci : « The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index« . J’ai mis un moment à la détricoter.

The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index

Après quelques recherches (ici, là), j’ai fini par identifier la root-cause : des logs sui arriveraient avec « trop de retard » par rapport à leur date réelle d’émission. Ce délai forcait Splunk, qui range les données dans les Bucket de manière temporellement ordonnée, à recréer des bucket pour ces évènements car ceux correspondant à cette plage temporelle avaient été fermés.

A la recherche des logs pétés

A partir de mon erreur, je me lance donc dans le SPL ci-dessous et effectivement j’ai bien une des sources de logs qui arrivent avec des latences pas normales.

index=<monindex>
| eval latency=_indextime-_time
| stats min(latency),
max(latency),
avg(latency),
median(latency)
by index sourcetype host
| sort - "avg(latency)"
The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index

Du coup j’ai gratté un peu sur l’hôte en question et il s’avère qu’on a régulièrement des grosses latence à l’indexation, à … Lire la suite

Application Compatibility – Forensgeek

Posté le de — Aucun commentaire ↓
Forensics

Bonjour à tous, pour changer on continue la série sur la forensics. Aujourd’hui je vais vous parler du ShimCache (dit aussi AppCompatCache, c’est la même chose), mais aussi du RecentFileCache et l’AMcache. Que l’on regroupe sous l’appelation Application Compatibility.

C’est quoi l’Application Compatibility de Windows ?

Alors l’Application Compatibility Cache, comme son nom l’indique, s’occupe d’assurer la rétrocompatibilité des applications prévus pour d’anciennes versions de Windows avec le système courant. Finalement, on y regroupe plusieurs éléments quand on parle forensics.

Le ShimCache (ou AppCompatCache)

D’abord de ShimCache, c’est un vieux truc qui date de Windows 95 ! Et dont le but initiale est surtout d’aider au débug pour les dev. Dedans, vous allez trouver plein d’informations relatives aux exécutions des programmes et qui peuvent varier un peu selon les versions de Windows. Vous trouverez notamment dans ce cache :

  • Le chemin complet de l’exécutable ;
  • La taille du fichier ;
  • Les date de dernière modification et d’exécution.
  • Si le programme a effectivement a lancé (mais pas trop loin hein).

RecentFileCache et AMcache

Le RecentFileCache est apparu avec Windows 2003 SP1 et le service « Windows Application Expérience Service Lookup ». Ce dernier a pour but de … Lire la suite