Full Report
Spectral V2 allows people to create on-chain AI agents. Each agent owns a wallet that allows on-chain actions. There are three main contracts: AutonmousAgentDeployer.sol: handles swaps between SPEC and Agent tokens. AgentToken.sol: Goverance token with a taxing functionality. This tax is important for later. AgentBalances.sol: Manages and distributes tokens that came from taxes. When transferFrom() is used on the token, a tax is applied to the funds being moved in AgentToken. Whenever this occurs, the AgentBalances contract is given an infinite approval to spend funds on behalf of the caller contract. Infinite approvals are prone to abuse, but they typically involve simply stealing funds. The swapExactTokensForSPEC() function on the AutonomousAgentDeployer contract calls transferFrom(). If an attacker calls this function it gives the AgentBalances an infinite approval on this contract. The attacker called a public deposit() function that allowed for the specifying of the from, tokenAddress and amount values on the AgentBalances contract. They don't have the ability to steal the tokens though - only transfer them somewhere else by mode of approvals. Why is this useful though? The AutonomousAgentDeployer contract balances were used as part of the constant product market maker algorithm between AgentTokens and SPEC. Hence, if tokens were removed from the contract to somewhere else it would then change the price of the swap drastically! So, the attacker triggered the infinite approval and exploited the approval to manipulate the price of the SPEC token. Since there is almost not AgentToken left only a small amount of AgentToken needs to be used in order to take all of the SPEC tokens. This exploit stole about 250K worth of tokens. Overall, it is an interesting exploit! Sometimes, you find yourself with a primitive, like moving tokens from one account to another, but it isn't immediately useful. From there, you must find an exploitation route to profit from it. This feels like a good example of that.
Analysis Summary
# Incident Report: Spectral V2 Price Manipulation via Approval Abuse
## Executive Summary
Spectral V2 was exploited for approximately $250,000 due to an infinite approval vulnerability within its smart contract architecture. The attacker manipulated the `AgentBalances` contract to drain tokens from the `AutonomousAgentDeployer`, causing a massive price slippage in the internal Constant Product Market Maker (CPMM) which allowed the attacker to siphon funds.
## Incident Details
- **Discovery Date:** Not explicitly stated (Post-mortem analysis)
- **Incident Date:** October 2024 (Approximate based on Spectral V2 deployment)
- **Affected Organization:** Spectral
- **Sector:** Decentralized Finance (DeFi) / AI Agents
- **Geography:** Global / On-chain
## Timeline of Events
### Initial Access
- **Date/Time:** Incident duration was near-instantaneous (atomic transaction).
- **Vector:** Exploitation of a flawed `transferFrom()` implementation in `AutonomousAgentDeployer.sol`.
- **Details:** The attacker called `swapExactTokensForSPEC()`, which triggered a tax mechanism that granted the `AgentBalances` contract an infinite approval to spend tokens on behalf of the `AutonomousAgentDeployer`.
### Lateral Movement
- **Protocol Interaction:** The attacker moved from the deployment contract to the `AgentBalances` contract. By calling a public `deposit()` function, the attacker utilized the previously granted infinite approval to move tokens away from the `AutonomousAgentDeployer` to an arbitrary address.
### Data Exfiltration/Impact
- **Market Manipulation:** By moving tokens out of the `AutonomousAgentDeployer` (which acts as the liquidity provider/market maker), the attacker artificially altered the token ratios within the CPMM algorithm.
- **Drain:** With the liquidity pool depleted of Agent tokens, the attacker performed a swap with a nominal amount of tokens to withdraw approximately $250,000 worth of SPEC tokens.
### Detection & Response
- **How it was discovered:** Anomalous price movement and liquidity drainage on-chain.
- **Response actions taken:** Community and security researcher post-mortem analysis (specific protocol pause actions not detailed in the source).
## Attack Methodology
- **Initial Access:** Smart Contract Vulnerability (Unintended infinite approval).
- **Persistence:** N/A (Atomic exploit).
- **Privilege Escalation:** Exploiting the `AgentBalances` contract’s ability to use the approval granted by the `AutonomousAgentDeployer`.
- **Defense Evasion:** Use of standard contract functions to masquerade as legitimate protocol behavior.
- **Discovery:** Identification of a public `deposit()` function that allowed arbitrary `from` and `tokenAddress` inputs.
- **Lateral Movement:** Inter-contract approval exploitation.
- **Collection:** Draining SPEC tokens from the liquidity pool.
- **Exfiltration:** Transferring stolen SPEC tokens to the attacker's wallet.
- **Impact:** Liquidity depletion and financial theft via price manipulation.
## Impact Assessment
- **Financial:** Approximately $250,000 in digital assets stolen.
- **Data Breach:** None (On-chain incident).
- **Operational:** Disruption of SPEC/Agent token market and liquidity.
- **Reputational:** High; highlights risks in custom tax/balance management logic.
## Indicators of Compromise
- **Behavioral indicators:**
- Unexpected `approve(address(AgentBalances), type(uint256).max)` calls from the Deployer contract.
- Large-scale token movements out of the Deployer contract without corresponding SPEC/Agent swaps.
- Extreme price volatility in SPEC tokens within a single block.
## Response Actions
- **Containment measures:** Analysis of the `AgentBalances` and `AutonomousAgentDeployer` contracts.
- **Eradication steps:** Identifying the flawed `deposit()` and `transferFrom()` logic.
- **Recovery actions:** Community notification and ongoing security hardening.
## Lessons Learned
- **Key takeaways:** Infinite approvals remain one of the most dangerous primitives in DeFi, especially when granted to contracts with public "caller-defined" functions.
- **Hidden Dependencies:** A vulnerability that allows "moving" tokens (even if it isn't "stealing" them directly) can be fatal if those tokens are used as a price oracle or a liquidity base for a CPMM.
## Recommendations
- **Strict Approval Management:** Avoid infinite approvals where possible; use `increaseAllowance` and `decreaseAllowance`, or scoped approvals.
- **Input Validation:** Restrict public functions like `deposit()` so they cannot specify arbitrary `from` addresses unless the caller is the owner of those funds.
- **Economic Invariants:** Implement circuit breakers or checks to ensure that moving tokens does not result in an impossible price swing within a single transaction.