WHMCS exploit involving Stripe payments?

[drmike]

Someone sent me something this morning...

They have ongoing fraud/hack situation involving WHMCS and Stripe payments.

The hack involves generated credit cards that seem to get through Stripe as valid.

The orders are identifiable as certain fields in the account info are ALL CAPS.

So far the hacks have generated accounts with info in Utah.

Details of the account info are different account holder information along with different credit card used.

Anyone else seeing a similar issue?

 

[Reece-DM]

Doesn't Stripe have a set of default of card details you can use for testing?

 

[DomainBop]

Doesn't Stripe have a set of default card details you can use for testing?

common testing card numbers used by most gateways:

Credit Card Type

Credit Card Number

American Express

378282246310005

American Express

371449635398431

American Express Corporate

378734493671000

Australian BankCard

5610591081018250

Diners Club

30569309025904

Diners Club

38520000023237

Discover

6011111111111117

Discover

6011000990139424

JCB

3530111333300000

JCB

3566002020360505

MasterCard

5555555555554444

MasterCard

5105105105105100

Visa

4111111111111111

Visa

4012888888881881

Visa

4222222222222

Visa

 4242424242424242

Dankort (PBS)

76009244561

Dankort (PBS)

5019717010103742

Switch/Solo (Paymentech)

6331101999990016

 

[ryanarp]

SWEET, now I get to look through all my stripe orders. 

 

[SkylarM]

The test cards only work when you have your stripe gateway set to "test" pretty sure.

 

[drmike]

SWEET, now I get to look through all my stripe orders. 

Shouldn't be hard ALL CAPS is the fingerprint on these attempts --- in selected fields... Not all fields.

Accounts were set with Utah addresses. 

Believe there were prior attempts in past weeks with Peru addresses also.

 

[ryanarp]

The one that looks suspicious is from China and they used their full China address. Also stripe verifies the card has china origin. I will refund to be safe, it was a $2 order so I can always open a ticket and ask more info. If no response then I will take that as a sign. Always happy to work with people who open and respond to communication. 

 

[drmike]

More info on these transactions:

1. The orders mostly had UTAH in all caps in order details.

2. The details on the person ordering the service were accurate.  They are real people.  Phone numbers even match per se (although old).

3. The cards being used are STOLEN and reported as such in the past.  Meaning Visa/Mastercard/etc. already have these accounts flagged in the system(s).

4. https://stripe.com/ = the payment gateway and they SUCK.  Stripe totally pushed the accounts/transactions through as totally valid.   Address and such info they claimed all matched.  Amazingly, they seem to not even run the transaction through standard clearing methods... They must just be using the mod formula to "fake validate" the cards.

5.  The IPs of the people doing these transactions =

2 Comcast IPs (actually in Utah and not on any block/hack lists)

1 Web hosting provider

1 is Cogent line in Georgia, USA

 

[concerto49]

More info on these transactions:

1. The orders mostly had UTAH in all caps in order details.

2. The details on the person ordering the service were accurate.  They are real people.  Phone numbers even match per se (although old).

3. The cards being used are STOLEN and reported as such in the past.  Meaning Visa/Mastercard/etc. already have these accounts flagged in the system(s).

4. https://stripe.com/ = the payment gateway and they SUCK.  Stripe totally pushed the accounts/transactions through as totally valid.   Address and such info they claimed all matched.  Amazingly, they seem to not even run the transaction through standard clearing methods... They must just be using the mod formula to "fake validate" the cards.

5.  The IPs of the people doing these transactions =

2 Comcast IPs (actually in Utah and not on any block/hack lists)

1 Web hosting provider

1 is Cogent line in Georgia, USA

Can you contact Stripe and let them know?

 

[tchen]

You might be stumbling across this gem

https://support.stripe.com/questions/cvc-or-avs-failed-but-payment-succeeded

Also, Stripe.com does not do phone numbers.  All it handles per card are name, address-lines, cvc, zip code.  Even then, not all card banks verify all fields, and the API only tells you about cvc, address line 1, and zip results.  Added to that, some banks will oddly pass a card despite it all, at least according to the above knowledge base topic.

This is something you should take up with the author of the contrib module jclark.  I'm not sure what fields he's actually checking as a 'pass'.  There's probably some soft-fail combination that's slipping through. 

In the mean time, the least you could do is try setting it to hard-fail on AVS/CVC failures. 

 

[drmike]

@tchen, I looked at the Stripe link.  In this instance Stripe verified address and zip as valid.  They also verified card itself as valid (even though all of them were reported stolen).

Since Stripe passed the info, I assume it's them and not the plugin/payment API piece.  If it wasn't for manual approvals, these orders would have been auto fulfilled and who knows what they would have been used for.

 

[ComputerTrophy]

More info on these transactions:

1. The orders mostly had UTAH in all caps in order details.

2. The details on the person ordering the service were accurate.  They are real people.  Phone numbers even match per se (although old).

3. The cards being used are STOLEN and reported as such in the past.  Meaning Visa/Mastercard/etc. already have these accounts flagged in the system(s).

4. https://stripe.com/ = the payment gateway and they SUCK.  Stripe totally pushed the accounts/transactions through as totally valid.   Address and such info they claimed all matched.  Amazingly, they seem to not even run the transaction through standard clearing methods... They must just be using the mod formula to "fake validate" the cards.

5.  The IPs of the people doing these transactions =

2 Comcast IPs (actually in Utah and not on any block/hack lists)

1 Web hosting provider

1 is Cogent line in Georgia, USA

From a warranty security researcher's point of view, they could be using a VCC with $1 or so just to pass the pre-auth, which may explain UTAH. Can you PM me the addres? It may be that they're using a mail forwarding address as well.