Com detectar inicis de sessió sospitosos als logs (Windows i Linux)

Detectar accessos sospitosos no és només revisar si algú va entrar des d’un país estrany. A la pràctica, es tracta d’ identificar patrons anòmals dins del soroll constant que generen els sistemes. I aquí hi ha el veritable repte: distingir el que és anòmal en el teu entorn concret. La teoria serveix de marc, però el que compta són els detalls operatius

1. Context: què fa que un login sigui sospitós

No tots els entorns són iguals. Un sysadmin que gestiona estacions de treball en una oficina corporativa no busca el mateix que qui manté nodes exposats al públic en una DMZ. Per això, el que es considera “sospitós” no és universal.

Alguns elements que cal revisar:

1. Login des d’un país o xarxa no habitual.
2. Inici de sessió amb comptes de servei.
3. Canvis en els horaris típics d’ accés.
4. Ús d’eines interactives on no s’haurien de fer servir (per exemple, ssh en un servidor que només hauria de rebre connexions d’automatització).
5. Ús de comptes inactius o deshabilitats.
6. Excés d’intents erronis seguit d’un login exitós.
7. Comportaments que imiten sessions legítimes, però amb petites diferències.

No esperis que una única mètrica o eina et resolgui això. El que funciona és combinar logs, context i petites comprovacions periòdiques ben automatitzades.

2. Linux: senyals a buscar i configuracions que ajuden

a. Configura el logging correctament

La base és tenir els logs. auditd i rsyslog han d’estar ben configurats, perquè si no no tindràs logs quan més els necessitis.

Recomanacions bàsiques:

1. auditd actiu, amb regles mínimes per a esdeveniments d’ autenticació.
2. rsyslog amb enviament remot si el node és crític.
3. Rotació diària per auth.log o secure (depenent de distro) en sistemes molt actius.
4. Logs en format JSON si s’ha de processar amb una cosa tipus Elastic o Loki.

b. Lo primer: /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/CentOS)

Busquem esdeveniments com:

• Accepted password for user from IP
• Accepted publickey for user from IP
• Failed password for invalid user
• Invalid user xyz from IP

Una expressió regular bàsica per a detectar usuaris no estàndard amb grep:

grep 'Invalid user' /var/log/auth.log

El problema aquí no és veure una IP rara, sinó veure intents reiterats amb noms que semblen locals (deploy, git, oracle) des de fora.

Quan configurem fail2ban, sempre ens hem d’assegurar de que no només bloquegi, sinó que també guardi IPs en un log a banda per a revisió diària. Moltes vegades l’atac és sorollós al principi i després canvia de tàctica. Aquest primer soroll és valuós.

c. Qui es va connectar i des d’on?

Per a iniciar sessió amb èxit:

last -i | head -n 20

Combinar això amb:

journalctl -u ssh | grep 'Accepted'

Això mostra el mètode de login (clau, contrasenya), IP i usuari.

Si l’entorn permet autenticació amb clau pública, també s’ha de revisar si hi ha canvis a ~/.ssh/authorized_keys. Si no tens auditd mirant això, pots perdre la pista de que una clau va ser afegida després d’una intrusió.

Exemple de regla d’ auditd:

-w /home/ -p wa -k ssh-key-watch

Això genera esdeveniments quan s’escriuen arxius sota home, ideal per detectar canvis a .ssh.

d. Hora i freqüència: quan alguna cosa no encaixa

Un usuari que mai entra a les 3AM no té per què començar a fer-ho. Fem servir scripts amb awk per extreure l’ hora del lastlog i buscar outliers.

Un comandament senzill per veure hores comunes:

last -F | awk '{print $1, $4}' | sort | uniq -c | sort -nr

Els resultats es comparen fàcilment amb un base que podem treure del mes anterior. Si hi ha un patró nou, el marquem per a revisió manual. No es necessita SIEM si es porta un control senzill.

3. Windows: més difícil de llegir, però igual de sorollós

A Windows, els esdeveniments estan més estructurats, però també són més verbosos. L’Event ID és el teu millor aliat.

a. Esdeveniments clau a vigilar

1. 4624 – Inici de sessió exitós.
2. 4625 – Fallit.
3. 4672 – Inici amb privilegis elevats.
4. 4648 – Inici fent servir credencials explícites (usat per Pass-the-Hash o RDP).
5. 4776 – Validació de credencials (important si hi ha DCs).
6. 4768 / 4769 / 4771 – KDC, si estàs en AD.

És recomanable filtrar 4624 per Logon Type. No tots els tipus són iguals:

1. 2 – Login interactiu (teclat local).
2. 3 – Xarxa (SMB, etc.).
3. 10 – RDP.
4. 11 – Cached interactive.

Un usuari que abans només iniciava sessió tipus 3 i ara apareix amb tipus 10 ja és motiu per revisar.

b. Exportar esdeveniments de login

Per a servidors clau, podem configurar una tasca programada que exporti esdeveniments filtrats amb wevtutil. Per exemple:

wevtutil qe Security "/q:*[System[(EventID=4624)]]" /f:text /c:100

El filtratge per temps és important. Evitem exportar milers de línies per revisar tard.

Una altra opció és fer servir PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624; StartTime=(Get-Date).AddDays(-1)} | 
  Where-Object { $_.Properties[8].Value -eq "10" } | 
  Select TimeCreated, @{N='User';E={$_.Properties[5].Value}}, @{N='IP';E={$_.Properties[18].Value}}

Aquí, l’índex de l’arrelament Properties depèn de la versió de Windows i del tipus de logon. Es necessita provar en cada entorn.

c. Detecció de persistència

Una pràctica que pot ser útil és comparar els hashes de C:\Users\<usuari>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\*.lnk setmanalment. Una LNK sospitosa amb una shell pot no aixecar alertes immediates però sí que apareix com un login legítim a l’Event Viewer.

El canvi sovint ve just després d’un login tipus 10 des d’una IP fora del rang intern.

4. Automatització i revisió humana

No tot es pot automatitzar, però moltes tasques es poden deixar com a scripts simples que corren cada hora i generen un diff.

1. Scripts que comparen el last diari amb una llista blanca d’IPs per usuari.
2. Alertes si un login es fa amb su cap a root sense venir de sudo.
3. Comparatives de login horari amb valors històrics.
4. Scripts a PowerShell que generen CSVs diaris amb logins remots, que després es grafiquen en un petit dashboard a Grafana.

La revisió humana continua sent clau. Amb una alerta per si sola no n’hi ha prou. Per això el context històric és tan valuós: qui es connecta, des d’on, a quina hora, i amb quin mètode.

5. Errors comuns

1. Donar per fet que els logs estan activats. Servidors amb auditd instal·lat però sense regles, o sistemes Windows on la mida del log era tan petita que els esdeveniments de fa 2 dies ja estaven esborrats.
2. No enviar logs a un servidor extern. Un atacant que obté accés root pot netejar les seves empremtes. Si no tens logs remots, perds el fil.
3. Ignorar els logins fallits si no n’hi ha un d’exitós després. Molts atacs moderns proven accessos i abandonen si no obtenen èxit immediat. Però aquestes IPs solen tornar.
4. Dependre completament d’eines SIEM mal ajustades. Una alerta cada 5 minuts per coses trivials acaba portant a ignorar-ho tot.

6. Què fer quan veus alguna cosa rara

Una cosa és detectar. Una altra és saber respondre.

a. Verifica l’ origen de la IP

Abans d’ aixecar l’ alarma, verifica la IP. Pot ser una VPN legítima, un nou node o un canvi d’infraestructura que no es va comunicar.

Podem creuar IPs amb:

1. DHCP lease logs (si aplica).
2. Llistat d’ IPs assignades de VPN.
3. Cloudtrail, si és AWS (el login via SSM de vegades apareix com a estrany).

b. Busca canvis de comportament

Una entrada sospitosa aïllada no sempre implica compromís. Però si va seguida de:

1. Canvis en grups (per exemple, net localgroup administrators).
2. Addició de claus públiques.
3. Nous cron jobs o tasques programades.
4. Accessos a recursos interns que l’usuari normalment no toca (bases de dades, shares, etc).

… llavors convé prendre acció immediata.

c. No esborris el sistema abans de revisar

Un error comú és un formatar un servidor compromès sense fer un bolcat dels logs, connexions i processos actius. Podem seguir aquestes passes:

1. Muntar el disc com a read-only en un altre sistema.
2. Fer un volcat de logs (/var/log, journalctl, Registres d’esdeveniments).
3. Fer servir eines com volatility, Sysmon, KAPE, log2timeline, segons el cas.
4. Només llavors, aïllar el node i remaquetar-lo.

7. Controls preventius que eviten mals de cap

Algunes configuracions que podem aplicar:

Linux

1. SSH només amb clau pública, sense excepcions.
2. Des-habilitar root login per SSH (PermitRootLogin no).
3. Fer servir sudo amb logs a /var/log/sudo i auditd per a comandaments crítics.
4. Fail2ban amb llistes blanques estrictes.
5. Script que compari el hash de .bash_history setmanalment. Si canvia, revisar-ho.

Windows

1. Límit de sessions RDP simultànies.
2. Sysmon actiu i configurat amb una plantilla estricta (recomano les de SwiftOnSecurity).
3. Audit habilitat per a canvis de privilegis i nous usuaris.
4. GPO que desactiva credencials en caché si no són necessàries.
5. Tasques programades que exporten esdeveniments de logon i canvis en grups.

8. Un hàbit saludable

Una petita rutina de revisió. En 15 minuts diaris:

1. Revisar logs d’ accessos en sistemes clau.
2. Comparar sessions actives (w, who, quser) contra les esperades.
3. Verificar si hi ha scripts modificats en carpetes sensibles (/etc/cron*, C:\Windows\Tasks).
4. Mirar els últims canvis d’usuaris i grups.
5. I si no tenim temps, deixar programat un diff automàtic entre snapshots.

No sembla gaire, però es poden detectar accessos maliciosos en aquest interval, abans que es converteixin en un incident més gran.

Conclusió

Detectar inicis de sessió sospitosos no és una qüestió de tenir les eines més cares ni d’aplicar la checklist perfecta. És qüestió de saber com es comporta el teu entorn, tenir configuracions sensates i revisar patrons que canvien. Si els logs estan ben estructurats, tens context i els teus scripts són simples però efectius, pots detectar molt.

No et fiïs dels SIEMs si no entenen els logs subjacents. I no subestimis el que pots treure amb un grep, awk o PowerShell ben orientat. El diable està en els detalls.