Summary This report analyzes a UPX-packed Windows executable file identified as a Salat Stealer. The malware collects the victim's keystrokes, system information, browser-stored credentials, cryptocurrency wallet data, and messaging applications data. It can also access the victim's webcam and microphone. It compresses the collected data and then exfiltrates it to the command-and-control (C2) server over the Quick UDP Internet Connections (QUIC) protocol.
Link:
https://blog.pwndesal.xyz/salat-malware-...e-analysis

Attack Surface Management Platform
Discover hidden assets and vulnerabilities in your environment
[Find out more]


The ultimate pentesting toolkit
Integrate with the leading commercial and open source vulnerability scanners to scan for the latest CVEs and vulnerabilities.



Automate the most powerful tools
Security tools are expensive and time-consuming, but with Sn1per, you can save time by automating the execution of these open source and commercial tools to discover vulnerabilities across your entire attack surface.



Find what you can't see
Hacking is a problem that's only getting worse. But, with Sn1per, you can find what you can’t see—hidden assets and vulnerabilities in your environment.



Discover and prioritize risks in your organization
Sn1per is a next-generation information gathering tool that provides automated, deep, and continuous security for organizations of all sizes.




Github :  https://github.com/1N3/Sn1per

How to develop a malware?
That Question is always running on my mind when i was a beginner, but now every thing change until i saw this MalDev Academy, This is not promotion I just want to share it here maybe they know it.


This is the website : https://maldevacademy.com/   I hope It's helps.

Fuji is a free, open source program for performing forensic acquisition of Mac computers. It should work on any modern Intel or Apple Silicon device, as it leverages standard executables provided by macOS.Fuji performs a so-called live acquisition (the computer must be turned on) of logical nature, i.e. it includes only existing files. The tool generates a DMG file that can be imported in several digital forensics programs.
Link:
https://github.com/Lazza/Fuji

Attached Files

Thumbnail(s)
   

Link:
https://bak3n3ko.medium.com/atomic-red-t...ef1ef2f59a

Quote:Cheska is intended for red teamers, researchers, and malware analysts operating within legal boundaries and in controlled, consented environments. Unauthorized deployment or use against systems you do not own or have explicit permission to test is illegal.

Requirements
Python 3
MinGW-w64 (sudo apt install mingw-w64)
How it works
Cheska is a builder for analysis-aware Windows droppers. All the user has to provide is the payload file and an optional output path where the resulting dropper will be saved.

When executed, the build script does the following in a nutshell:

validates that the provided payload is a valid Windows PE executable.
generates a random 3-character key used to XOR encode the payload and strings in the stub (e.g. DLL names).
generates a random 3-5-character string to be used as the resource name for the encoded payload.
configures the stub with the key and now encoded string values.
compiles the stub and embeds the encoded payload as a resource.
The dropper, upon execution, does the following:

Performs anti-analysis checks (detailed below)
Loads and decodes the payload from the resources section
Drops and executes the payload
Anti-Analysis Techniques
Category Technique Description
Anti-debugging Unhandled exception filter Detects attached debugger via custom exception logic.
Anti-sandbox Mouse presence check Detects whether a mouse device is installed.
Number of processors (<=2) Flags limited CPU environments.
RAM size (<2GB) Detects low-memory VMs or sandboxes.
Anti-VM Virtualization feature flag Uses PF_VIRTUALIZATION_ENABLED to detect VT-x/AMD-V.
Native VHD boot check Detects OS booted from VHD, common in VMs/sandboxes.
Additional Defense Evasion Techniques
To further minimize detection and complicate analysis, the stub also employs:

PEB walking for stealthy module enumeration
Dynamic API resolution to bypass static import detection
String obfuscation (e.g. XOR-encoded DLL and function names)
Setup
The builder was developed and tested on a Linux environment, leveraging MinGW-w64 for cross-compiling Windows binaries.

Clone this repository
git clone https://github.com/nemuelw/cheska.git
Navigate to the project directory
Create a virtual environment and activate it
python3 -m venv .venv
. .venv/bin/activate
Install project dependencies
pip3 install -r requirements.txt
Usage
python3 cheska.py -p <PAYLOAD_FILE> [-o <OUTPUT_FILE>]
Contribution
Contributions are welcome! Ideas for improvement include:

Better anti-VM techniques (e.g. VM driver or MAC address checks)
Additional anti-sandbox methods
Stub optimization or improved evasion heuristics
Link:
https://github.com/nemuelw/cheska

Link:
https://github.com/Lazza/Fuji

Attached Files

Thumbnail(s)
   

Link:
https://bishopfox.com/blog/2025-red-team...ploitation

In today's digital landscape, APIs (Application Programming Interfaces) are a vital part of applications. However, they are also prime targets for attackers. Here's a detailed post covering API security, bypass techniques, and how to defend against them.
---
1. Understanding API Vulnerabilities
APIs often expose application logic and sensitive data, making them susceptible to several vulnerabilities. Here are some common API vulnerabilities:
A. Broken Authentication
APIs with flawed authentication mechanisms can allow attackers to impersonate legitimate users.
Example: Missing or weak authentication tokens.
Attack Scenario: Attacker intercepts an API request and reuses an old token to access resources.
B. Rate Limiting Bypass
APIs without proper rate limiting can be exploited to perform brute force attacks or DoS (Denial of Service).
Example: Login endpoints without request throttling.
Attack Scenario: Automated scripts try thousands of username/password combinations.
C. Sensitive Data Exposure
Poorly designed APIs might leak sensitive data like credentials, PII (Personally Identifiable Information), or system configurations.
Example: API responses include sensitive fields such as passwords or API keys.
Attack Scenario: Attacker views these fields in API responses to gain unauthorized access.
---
2. Bypass Techniques for APIs
Here are common API bypass techniques attackers use and examples of how they work:
A. Authentication Bypass Using JWT Tampering
JWTs (JSON Web Tokens) are commonly used for API authentication. Improperly validated tokens can be tampered with.
Example: A JWT payload:
{
  "user_id": 123,
  "role": "user"
}
The attacker modifies it to:
{
  "user_id": 123,
  "role": "admin"
}
Attack Scenario:
1. The attacker modifies the JWT payload.
2. If the signature validation is weak, the server accepts the tampered token.
B. Rate Limiting Bypass with IP Rotation
Technique: Use proxy tools to rotate IPs and bypass IP-based rate limiting.
Tools: Tools like burp suite with Turbo Intruder can automate this.
C. Exploiting Insufficient Input Validation
Example:
GET /user?id=123
The attacker modifies the parameter to SQL injection payload:
GET /user?id=123 OR 1=1
Attack Scenario: The API fails to validate inputs and executes malicious queries.
---
3. Defense Strategies for Secure APIs
Protecting APIs requires a multi-layered approach. Here’s how you can secure your APIs against common vulnerabilities:
A. Strong Authentication and Authorization
1. Use OAuth 2.0 and OpenID Connect: Implement token-based authentication.
2. Validate JWTs Properly: Ensure the token’s signature and expiration date are checked.
B. Implement Rate Limiting
1. Throttle Requests: Limit the number of requests per IP.
2. Use API Gateways: Tools like AWS API Gateway or Apigee help enforce rate limiting.
C. Secure Data Handling
1. Avoid Exposing Sensitive Data: Exclude fields like passwords and keys from API responses.
2. Encrypt Data: Use TLS for data transmission.
D. Input Validation and Sanitization
1. Use Allowlists: Accept only known good inputs.
2. Validate All Inputs: Use server-side validation to prevent injection attacks.
E. Monitoring and Logging
1. Log API Activities: Record all API requests and responses for auditing.
2. Monitor for Anomalies: Use tools like WAFs (Web Application Firewalls) to detect unusual patterns.
---
4. Real-World Example: API Testing and Defense
Scenario:
An e-commerce API endpoint:
POST /api/order
{
    "user_id": 123,
    "product_id": 456,
    "quantity": 2
}
Vulnerability: The API does not validate the user_id. An attacker modifies the request:
{
    "user_id": 789,
    "product_id": 456,
    "quantity": 2
}
The attacker places an order on behalf of another user.
Defense:
1. Validate the user_id against the authenticated user’s session.
2. Use authorization middleware to enforce user access controls.
---
5. Tools to Strengthen API Security
1. Postman: For API endpoint testing and validation.
2. Burp Suite: For manual testing and vulnerability detection.
3. OWASP ZAP: For automated security scans.
4. ffuf: For fuzzing API endpoints.
5. JWT.io: To decode and validate JWT tokens.
---
Conclusion
API security is critical in modern application development. Ethical hackers and developers must stay vigilant, understand vulnerabilities, and implement robust defenses. Always think like an attacker to protect your systems effectively.
What’s your favorite API testing tool? Let us know in the comments!`

Attached Files

Thumbnail(s)
   

(A Journey into Digital Forensics Through Deception, Destruction, and Discovery)
⸻
? Chapter 1: The Midnight Call
11:47 PM – I received a call from an old client, this time not for a routine review or training, but for a serious incident.
“We lost all the R&D data for our new product line. It seems someone intentionally erased the hard drive and the backup. The director is furious. Can you come right away?”
I nodded, grabbed my specialized bag: the forensic hard drive, the Autopsy copyright dongle, write blocker, flashlight, and a packet of instant coffee.
⸻
? Chapter 2: Cold Air-Conditioned Room, Hot Hard Drives
When I arrived, the room was dark and cold, and the server drive smelled faintly of ozone.
The suspect hard drive – number 12 – was placed separately in an anti-static box.
“I found it wiped yesterday around 3am. But no one was on duty. The camera logs are missing.”
I used a write blocker to connect the drive to the forensic machine.
The data had been “zeroed out” – meaning the entire sector had been overwritten with byte 00.
But luckily: not the entire drive, just a major portion. I decided to use photorec and then bulk_extractor to start scanning each sector.
⸻
? Chapter 3: Blood in the Log
After almost 2 hours of extracting data from the remaining part, I recovered some hidden logs: SRUM (System Resource Usage Monitor) - few people know that it saves the machine's activities for a long time.
Including:
• Specific command line launch time: cipher /w:C:\
• Executor: account "qa-dev1"
• From there, I traced the entire command line chain: a USB plugged in 2 minutes ago, the D drive mounted.
I started to see the scenario more clearly:
• A person with elevated privileges
• Accessing the R&D system
Using the encryption script to quickly overwrite the data and then removing the USB
⸻
? Chapter 4: Ghost in VPN
Watching from account qa-dev1, I analyzed the VPN logs. There was a connection from an IP address in Central Europe, which did not match this employee's address.
I asked to check qa-dev1's workstation. The employee was... on a 3-day vacation to Da Lat.
Analyzing his memory dump, I found:
• Remote access tool (AnyDesk) running in the background
• Small executable file called update_vpn_svc.exe - a lightweight RAT backdoor
And more: the keepalive.log file records a strange IP address - similar to the VPN IP address mentioned above
It seems that someone used the QA account, combined with a long-installed Trojan - to attack the company itself.
⸻
? Chapter 5: The Man in the Shadows
I analyzed the timeline in more depth. In the last 6 weeks, the update_vpn_svc.exe software was installed after QA borrowed a USB from an external partner to "copy the test library".
The USB - the silent killer - is back once again.
⸻
? Chapter 6: The Last Wall
I had to run Plaso to reconstruct the detailed timeline: every login, USB insertion, script execution. After almost 12 hours, I built the big picture:
1. Backdoor secretly installed 6 weeks ago via USB.
2. Attacker was patiently observed via AnyDesk.
3. Waited until QA was on vacation - attacked via VPN.
4. Accessed R&D server, downloaded data via SMB.
5. Finally: used encryption to destroy the drive and hide the traces.
⸻
⚖️ Final Chapter: Justice and Reform
The company reported to the investigation agency. We extracted all the IOCs, wrote a 50+ page report of findings, including:
• Forensic images of hard drive 12
• IOCs: IP, file hash, backdoor, script deletion
• Detailed timeline
• Key vulnerabilities: no USB monitoring, no 2FA for VPN enabled, no regular remote tool checks
⸻
✅ Message from hard drive 12
“The bad guys don’t have to be good. They just have to be patient.
And if you don’t look at the usage logs, they’ll disappear like water – until it’s too late.”