Operation Belgrade Curtain: Why That Iranian Flag on Your Firewall Is Probably Lying

Sigmund

18 Jul 2026 • 12 min read

I opened the CrowdSec Console on Saturday morning in Manila to a dashboard that looked like a foreign intelligence service had opened up on FalconEye.

2,143 alerts from a single IP. 99.3 percent of my total noise. The ASN column said Cipher Operations Doo Beograd. The source AS panel showed a little Iranian tricolor next to the entry. FalconEye is my public OSINT toolkit, running at falconeye.osintph.info. It has a recognizable name, a GitHub trail, and it does exactly the kind of investigative work that some governments would rather nobody did. An Iranian brute force campaign on that specific host would not be surprising, and it would be worth writing about.

Six WHOIS pivots later, the story had inverted. The Iranian flag was there for real, but it was the last thing about the attacker that was Iranian. Everything else about the operation was staged out of Serbia, Ukraine, the UAE, the UK, Ireland, South Africa, Romania, Moldova, and the Netherlands, wrapped around a single Iranian bulletproof hosting operator who runs a public retail storefront that anyone with a credit card can buy from.

This post is about how that pivot works. If you run a public-facing service and you rely on GeoIP-based attribution to understand who is hitting your box, you will get the wrong answer more often than you think. The story below is one example. The technique is general.

The dashboard shape is one persistent source, not many

The Source IP widget on the CrowdSec Console counts alert events per source. Sixteen source IPs appear in the window, but the top row swallows the chart entirely: 62.60.130.193 with 2,143 hits against a background of fifteen other IPs contributing between one and five alerts each. The rest of the noise is Sistemas Informaticos from Portugal, Microsoft and Amazon from AWS, Censys doing its usual internet-wide scans, and one Chinanet address. All legitimate background hum on any public host.

The Source AS widget makes it starker. Six ASNs total, six thousandths of a percent of noise, and one ASN at 99.3 percent.

The campaign has a clean shape on the chart. It started around 19:30 on July 17 and kept firing at a steady rate until it tapered off around 12:30 on July 18. Roughly seventeen hours of continuous grinding from a single node.

You can see the same shape at the CLI:

sudo cscli alerts list --scenario crowdsecurity/ssh-bf --since 24h
sudo cscli alerts list --scenario crowdsecurity/ssh-slow-bf --since 24h

Every row has the same value column: Ip:62.60.130.193. Every row has the same ASN: 215930 Cipher Operations Doo Beograd - Novi Beograd. The scenario has been firing about once per minute, refreshing the ban on every leaky-bucket overflow. It is one node grinding at a target list, not a distributed campaign.

That distinction matters. A distributed campaign implies coordination and infrastructure investment. A single node running for seventeen hours against a target that stopped answering after the first ten minutes implies a rented brute force VPS that the customer has not bothered to check on. The customer paid up front and does not care whether the packets land.

The bouncer did its job immediately. Chain counters climbed into the millions of dropped packets, and once the ban propagated sshd stopped seeing attempts from that IP. The CROWDSEC_CHAIN sits at position 1 in the INPUT chain, ahead of UFW, so nothing else has to work correctly for the ban to hold.

sudo iptables -nvL CROWDSEC_CHAIN

The defense held. The attacker never noticed. That is worth flagging as a data point in its own right, but the attribution was interesting enough to chase in parallel.

First pivot: the ASN says Serbia

62.60.130.193 geolocates to Iran in CrowdSec's built-in GeoIP database. That is the flag on the dashboard. But the ASN is registered in Serbia.

whois 62.60.130.193

The netblock 62.60.130.0/24 belongs to CIPHER OPERATIONS DOO BEOGRAD, registered at Jurija Gagarina 231, local 329, in Novi Beograd. "Local 329" is a suite number, the tell for a virtual or shared office. The Serbian company registration number is 21864242, registered November 2023. The /24 itself was allocated in July 2025 and route-registered in August 2025. Fresh space on a fresh company.

The Abuse Contact, is in the Ukraine:

The RIPE inetnum object says country: GB, which is a third country label on the same address. AbuseIPDB, when I checked it, said Lithuania.

Four different sources, four different countries. Iran on CrowdSec, GB in RIPE, RS on the corporate registration, LT on AbuseIPDB. If you stop at any one of these, you get a wrong answer about what you are dealing with. It is also a good reminder that GeoIP is not as straightforward as it seems.

Second pivot: the abuse contact does not care

The RIPE inetnum object also lists an abuse contact. That contact is a Gmail address:

role:           Abuse contact role object
abuse-mailbox:  [email protected] (a personal Gmail)
address:        Khreshhatik St., 14D, Kyiv, UA
nic-hdl:        ACRO58704-RIPE

Kyiv postal address. Gmail address. Yoruba-pattern personal name in the local part of the email. This is a Serbian company, with a Ukrainian postal address for its abuse contact, with a Nigerian-flavored personal Gmail as the abuse channel. Legitimate hosting providers put abuse contacts on their own corporate domain. This pattern of virtual office plus mobile phone plus disposable Gmail is the standard fingerprint of a small-scale bulletproof reseller.

A quick Crimewall Check on the email address alone gives a useless LinkedIn Profile and some interesting further leads. This will be a new article, the second of my Crimewall Series. Standby for that.

Two more identifiers on the object are worth pulling. admin-c: ACRO58704-RIPE is the RIPE handle for that abuse contact. mnt-by: mm500-mnt and mnt-ref: wcd are the maintainer objects that gate write access to the RIPE record. Handles and maintainers are the pivot points that turn one bad IP into a picture of an operation.

Third pivot: the maintainers unlock the empire

whois -h whois.ripe.net -- '-i mnt-by mm500-mnt'
whois -h whois.ripe.net -- '-i mnt-by wcd'

The reverse maintainer queries take about ninety seconds to run and return several megabytes of RIPE objects. This is where the story stops being about 62.60.130.193 and starts being about the empire behind it.

mm500-mnt is owned by a person named Majid M. at "Sar Sabz St., Tehran, Iran". His personal Gmail address, [email protected], appears on multiple LIR abuse contacts. His formal RIPE organization is Abdolmajid M under the LIR handle ORG-AM403-RIPE, based at "No. 13, Khavari Alley, TAT Str., Marzdaran Blvd, Tehran".

wcd is owned by Mohammad K., RIPE handle INN21-RIPE, using the alternate person identity DWCI NET at a Burj Khalifa Bur Dubai address, with the abuse [email protected].

These two people run everything.

The maintainer objects are stamped across dozens of RIPE resources, and the picture that comes together is a hosting reseller brand called LordVPS. [email protected] appears as the abuse address on netblocks named IR-LORDVPS1-20240109, IR-LORDVPS2-20240112, and onward through IR-LORDVPS12-20240625. Twelve numbered LordVPS sub-organizations, each backing a different /24 in European, Emirati, or US IP space, all sponsored by the Iranian LIR Atis Omran Sevin PSJ at Unit 7 Negin Mall Tehran.

Twelve netblocks is only the visible half. The other half is a set of shell companies registered in nine different countries, each holding IP space and each nominally independent, all traceable back through the maintainer objects to the same two Iranian operators.

The corporate front graph

Here is the list of shell entities and where they are registered, all tied together by mm500-mnt or wcd:

Cipher Operations Doo in Serbia holds AS215930 and 62.60.130.0/24
SafeshipNetworks in Ukraine holds 81.30.107.0/24
AMWAJ Alkhyr Commercial Brokers in the UAE holds AS44947 and AS213456
Feo Prest SRL in Romania holds 62.60.131.0/24 and AS208137
SKYNET NETWORK LTD at a Luton UK address holds an IPv6 block
KOI Cloud Services (Pty) Ltd in South Africa, fronted by a person named Kenneth (REDACTED), holds AS209425
FIRSTBYTE HOSTING LTD at a London UK address holds AS210703
Sariff Industries in Ireland and the UK holds AS210703 co-maintenance
Audit Data SRL in Moldova holds 194.0.234.0/24
IPNET in the Netherlands with an [email protected] contact holds 62.60.134.0/24

The abuse contacts on this graph are a rotating cast of throwaway Gmail addresses, redacted here, but you can get them by looking it up via WHOIS records. ([email protected], [email protected], [email protected], [email protected]), a Yandex address ([email protected]), and a set of xxx@[disposable-domain] addresses like [email protected] and [email protected]. The Nigerian-name Gmail alone appears across four separate organizations in four separate countries.

The BGP peering fabric closes the loop. AS215930 (Cipher Operations, the Serbian front) peers with AS44947 (Amwaj, the UAE front), AS209425 (KOI, the South African front), and AS133398 (external transit). Three of the four peers are inside the same operation. AS215930's sponsoring organization is ORG-AOSP1-RIPE, which is the original LordVPS LIR. Cipher Operations Doo Beograd is not an independent Serbian company that happens to have Iranian customers. It is one of M's own European fronts, sponsored by his Iranian LIR.

That is why the flags do not agree with each other. Traffic from 62.60.130.193 can egress via AS44947 in the UAE, AS209425 through South African peering, or AS133398 for external transit. Whichever egress the GeoIP database last saw determines which flag appears next to the IP. All four flags are technically correct at some point in the packet's journey. None of them tells you the operator is Iranian.

Fourth pivot: what the box actually is

Censys sees the attacker as an Ubuntu Linux host on Vilnius infrastructure, running one service and only one service:

No web panel. No monitoring service. No cPanel or Plesk. No mail. No game server. No VPN endpoint. Just OpenSSH.

A normal VPS customer buys a box to run something. This box runs nothing. It exists to initiate SSH connections outbound, and its inbound SSH is presumably how the operator manages it. That is the operational fingerprint of a dedicated brute force node, not a customer's general-purpose server.

Shodan confirms the fingerprint at the ASN level:

1,452 hosts on AS215930, of which only 41 are running visible SSH and only 49 are running HTTP. A legitimate hosting provider with 1,452 customer boxes would have hundreds of visible web servers and mail services. This ASN does not have that. What it has is 315 mDNS leaks and a handful of nginx and OpenSSH surfaces. The composition looks like proxy or brute force infrastructure with a thin customer-facing veneer.

GreyNoise closed the last loose end:

curl -s https://api.greynoise.io/v3/community/62.60.130.193 | jq
{
  "ip": "62.60.130.193",
  "noise": false,
  "riot": false,
  "message": "IP not observed scanning the internet."
}

GreyNoise runs a global sensor network specifically to catch mass scanners. "Not observed scanning" means this IP is not participating in indiscriminate internet-wide scanning. It is targeted. Combined with the 78 AbuseIPDB reports at 100 percent confidence and my own 2,143 alerts on FalconEye, that means multiple targets are being hit, but from a curated list rather than a scattergun. Someone specifically chose to point this node at me.

Spamhaus closes the case

Spamhaus does not add networks to their Don't Route Or Peer list on a hunch. DROP is reserved for networks Spamhaus has classified as directly controlled by cybercriminals or hijacked. Getting on DROP means a formal listing with an SBL evidence trail.

curl -s https://www.spamhaus.org/drop/drop_v4.json | grep "62.60.130"
{"cidr":"62.60.130.0/24","sblid":"SBL683637","rir":"ripencc"}

The specific /24 that hit FalconEye is on Spamhaus DROP as SBL683637.

The ASN-DROP list adds two more confirmations:

curl -s https://www.spamhaus.org/drop/asndrop.json | grep -E "215930|209425"
{"asn":209425,"rir":"ripencc","domain":"lordvps.net","cc":"IR","asname":"KOI-AS"}
{"asn":215930,"rir":"ripencc","domain":"almaseabi.net","cc":"IR","asname":"COD"}

Spamhaus explicitly tags AS215930 (Cipher Operations, the Serbian front) and AS209425 (KOI Cloud, the South African front) with cc: IR. They independently reached the same conclusion I did from the WHOIS pivots. Both ASNs are classified as Iranian operations regardless of their nominal registration country. Spamhaus also explicitly links AS209425 to the domain lordvps.net and AS215930 to almaseabi.net.

Which brings us to the storefront.

The retail brand is publicly online

whois lordvps.net
curl -sI https://lordvps.net

Domain created November 2020. Registered through Bluehost, hidden behind Perfect Privacy LLC in Jacksonville Florida. Nameservers NS1.UAEDNS.COM and NS2.UAEDNS.COM, tying it back to the K. Dubai infrastructure. And critically, HTTP/1.1 200 OK. The website is live and serves 98 kilobytes of HTML.

But it's obviously not meant to get regular customers directly, as it's basically all placeholder text:

This is the retail surface of the operation. Placeholder text is telling on its own. A legitimate reseller invests in their storefront because they want new customers. This site does not, because it does not need them. The customer base finds LordVPS through channels the operator does not advertise on the front page.

The other domain Spamhaus named, almaseabi.net, was registered in 2009, currently sits behind Cloudflare with the origin misconfigured (HTTP 525), and uses privacy WHOIS. The .ir counterpart, almasnet.ir, hides behind IRNIC privacy but points its nameservers at morvahost.com, an Iranian hosting brand. Classic bulletproof pattern: one export brand for foreigners, one domestic brand for the local market.

What this changes about the incident

Nothing about my defensive posture. CrowdSec caught the campaign, the bouncer banned the IP, and the chain counters climbed while the attacker chewed vainly on packet drops. I added a persistent 30-day local decision to keep the ban past the scenario expiry, and left it there.

What it changes is the interpretation. The Iranian flag on the CrowdSec dashboard suggested one thing. The reality was a dedicated brute force node inside a documented Iranian bulletproof hosting operation, sold as retail VPS service under the LordVPS brand, hosted through a Serbian shell company, exiting via Lithuanian IP space, appearing in every GeoIP database with a different flag depending on which egress the packet took.

For any target running a public service, the correct question is not "who is this IP" but "what is this IP part of." A single address on a fresh /24 registered to a Serbian company you have never heard of is worth thirty seconds of whois and whois -i mnt-by to see if that company is real. In this case the answer was a 12-netblock, 9-country empire run by two operators in Tehran.

Practitioner takeaways

If you are running CrowdSec or any other detection stack, three things from this incident are worth internalizing.

Read alert counts as event counts, not unique-source counts. The Source IP widget puts the winner at the top, but if you glance at Source Countries or Source AS without breaking it down further, one persistent node can read like a distributed campaign. Always drop to cscli alerts list and check the value column.

Never stop at the flag. GeoIP is telling you where the packet's last hop looked geographic. It is not telling you where the operator is. The abuse-c email, the maintainer objects, and reverse maintainer queries take five minutes and yield the actual attribution.

The pivot chain matters more than the tool. AbuseIPDB, Censys, Shodan, GreyNoise, Spamhaus, and RIPE WHOIS each told a partial story. Stacking them turned "one persistent IP" into a documented view of an operator's infrastructure. Any one of those sources on its own would have left the picture incomplete.

The IP is now on my Cloudflare account block list, the CrowdSec local decision is set to 720 hours, and 62.60.130.0/24 stays banned at the origin until Spamhaus tells me otherwise. If the same operator rotates to a sibling IP on a different LordVPS block, the community feed will catch it. That is the point of the CrowdSec model.

If anyone else is seeing this ASN in their logs, drop a comment. The evidence is already public, and every practitioner who confirms an incident against AS215930 or AS44947 or AS209425 adds another data point to the community view of what LordVPS actually is.

This investigation was written up in the hours immediately after the incident using publicly available tools: RIPE WHOIS, AbuseIPDB, Censys, Shodan, GreyNoise Community, Spamhaus DROP and ASN-DROP, and Cloudflare DNS. All commands used to gather this data are shown inline. Screenshots are from my own CrowdSec Console, Censys, Shodan, and Spamhaus. If you want to reproduce the investigation on your own logs, the same commands work against any suspicious IP. Crimewall deep dive to follow.

The FalconEye toolkit lives at falconeye.osintph.info. Blog subscribers get new investigations by email when they drop.

Reach out if you have questions or comments or what to collaborate

Session ID: 059db238ab37c3d92615c5cc24b694da29c598cc13e27886053722404118e14271