<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Persistence on Ethical Hacking | Pentest e Sicurezza Informatica | Hackita</title><link>https://hackita.it/tags/persistence/</link><description>Recent content in Persistence on Ethical Hacking | Pentest e Sicurezza Informatica | Hackita</description><generator>Hugo</generator><language>it</language><lastBuildDate>Thu, 16 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://hackita.it/tags/persistence/index.xml" rel="self" type="application/rss+xml"/><item><title>Post-Exploitation Windows e Active Directory: Guida Completa</title><link>https://hackita.it/articoli/post-exploitation/</link><pubDate>Thu, 16 Jul 2026 00:00:00 +0000</pubDate><guid>https://hackita.it/articoli/post-exploitation/</guid><description>&lt;h1
 id="post-exploitation-windows-e-active-directory-dal-foothold-allobiettivo" class="group/anchor-heading"&gt;
 Post-Exploitation Windows e Active Directory: dal Foothold all&amp;rsquo;Obiettivo
 &lt;a href="#post-exploitation-windows-e-active-directory-dal-foothold-allobiettivo" class="text-inherit opacity-0 group-hover/anchor-heading:opacity-100 decoration-transparent"&gt;#&lt;/a&gt;
&lt;/h1&gt;&lt;p&gt;Ottenere una shell è il punto di partenza, non il traguardo. La differenza tra un foothold e un obiettivo raggiunto sta nel metodo con cui si sfrutta quell&amp;rsquo;accesso iniziale. Una sessione post-exploitation gestita male — comandi rumorosi, tool lasciati su disco, dumping indiscriminato — viene rilevata prima di arrivare da nessuna parte.&lt;/p&gt;
&lt;p&gt;Il post-exploitation non è una sequenza fissa di comandi. È un ciclo decisionale che si adatta ai privilegi ottenuti, alle protezioni presenti sul sistema (Credential Guard, LSA protection, EDR) e allo scope dell&amp;rsquo;engagement. Dopo la situational awareness, credential access e privilege escalation vengono valutati &lt;strong&gt;in parallelo&lt;/strong&gt;, non in ordine rigido: a volte serve scalare prima di poter accedere alle credenziali, altre volte è il contrario.&lt;/p&gt;</description></item><item><title>Crontab Backdoor: Persistenza Linux con Cron Job nel Penetration Testing</title><link>https://hackita.it/articoli/crontab/</link><pubDate>Sat, 07 Feb 2026 00:00:00 +0000</pubDate><guid>https://hackita.it/articoli/crontab/</guid><description>&lt;h1
 id="crontab-backdoor-persistenza-linux-con-cron-job-nel-penetration-testing" class="group/anchor-heading"&gt;
 Crontab Backdoor: Persistenza Linux con Cron Job nel Penetration Testing
 &lt;a href="#crontab-backdoor-persistenza-linux-con-cron-job-nel-penetration-testing" class="text-inherit opacity-0 group-hover/anchor-heading:opacity-100 decoration-transparent"&gt;#&lt;/a&gt;
&lt;/h1&gt;&lt;h2
 id="introduzione" class="group/anchor-heading"&gt;
 Introduzione
 &lt;a href="#introduzione" class="text-inherit opacity-0 group-hover/anchor-heading:opacity-100 decoration-transparent"&gt;#&lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;Crontab è il task scheduler nativo di ogni sistema Linux. In un penetration test, sfruttarlo come meccanismo di persistenza significa ottenere un callback ricorrente senza installare software aggiuntivo — un vantaggio operativo enorme. Il Blue Team spesso monitora servizi e processi, ma i cron job dell&amp;rsquo;utente restano in angoli ciechi se non esiste un SIEM configurato ad hoc.&lt;/p&gt;</description></item></channel></rss>