<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Attack-Automation on CuraSec</title><link>https://curasec.metacog.co.kr/tags/attack-automation/</link><description>Recent content in Attack-Automation on CuraSec</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 06 Aug 2026 13:03:19 +0000</lastBuildDate><atom:link href="https://curasec.metacog.co.kr/tags/attack-automation/index.xml" rel="self" type="application/rss+xml"/><item><title>Automated SSH Attacks Achieve Persistence in ~22 Seconds</title><link>https://curasec.metacog.co.kr/insights/2026-08-06-22-seconds-to-compromise-how-automated-ssh-actors-move-from/</link><pubDate>Thu, 06 Aug 2026 13:03:19 +0000</pubDate><guid>https://curasec.metacog.co.kr/insights/2026-08-06-22-seconds-to-compromise-how-automated-ssh-actors-move-from/</guid><description>&lt;ul>
&lt;li>&lt;strong>Engineer — Learn:&lt;/strong> Research on automated SSH attack timelines underscores why key-only auth, login alerting, and session monitoring must be in place before an attacker lands — no specific patch needed, but validates hardening posture on any SSH-exposed host.&lt;/li>
&lt;li>&lt;strong>SOC/IR — Plan:&lt;/strong> The ~22-second login-to-persistence window is a concrete benchmark: review SSH authentication alert latency in your SIEM and ensure post-login activity (new cron jobs, authorized_keys writes, shell spawns) triggers faster than that window closes.&lt;/li>
&lt;li>&lt;strong>Leader — Skip&lt;/strong>&lt;/li>
&lt;/ul></description></item></channel></rss>